Newsgroup: it.comp.os.linux.sys
Titolo: Problema named improvviso... ma non solo.

Salve ho una RH7.3 in funzione da più di un anno (upgrade dalla 7.2) per il 
collegamento internet adsl.
Kernel 2.4.20.
Vari servizi httpd, mysql, snort, netfilter.
Questa sera all'improvviso scopro che il cache dns non funziona più perchè 
named si è arrestato e non riparte, e se tento di avviarlo manualmente 
ottengo :/usr/sbin/named: cannot execute binary file.
Ho provato a fare un refresh con rpm ma non rieco a sovrascrivere il file ed 
anche manualmente da root è impossibile cancellarlo o modificarne i 
permessi. Già questo potrebbe bastare.
Il comando ps (nonostante esista il file) riporta 
bash: bin/ps: non such file o directory.
Al boot della macchina ottengo un errore che è dovuto all'avvio della 
configurazione di rete dello script /etc/init.d/network più precisamente 
quando viene eseguito :
sysctl -p /etc/sysctl.conf
che conclude con :
kernel.core_uses_pid=1
error: 'kernel.sysrq' is an unknow key.
La policy di netfilter e drop su tutte le catene e la "INPUT" permette 
l'accesso alle sole porte 80, 443 e 22.
Loggo con snort e netfilter sia in locale che su un'altra macchina linux 
configurata come bridge su interfaccia ethernet adsl ma non ho trovato 
niente di particolare.
Anche i log di apache non riporta niente di interessante.
Qualche consiglio...per capire,  grazie 
Antonio C.

 l'accesso alle sole porte 80, 443 e 22.
Domanda... il kernel era patchato per l'exploit sul ptrace?
-- 
| /
| \Byte - Andrea Briganti - kbytesys(aaattt)
tiscali.it
CSLug member: 
http://cslug.linux.it
 - JID: 
kb...@jabber.linux.it
***Un errore di lancio o puntamento rende la bomba intelligente stupida

 
No. !
Antonio C.

 No. !
Ecco... se hanno messo un root kit, c'e' buona possibilità che sia stato 
qualcuno con un account ssh... (non so se il tuo apache è fixato per i 
precedenti exploit e worm, ma vedendo che quella è storia vecchia lo do per 
scontato)
-- 
| /
| \Byte - Andrea Briganti - kbytesys(aaattt)
tiscali.it
CSLug member: 
http://cslug.linux.it
 - JID: 
kb...@jabber.linux.it
***Chi non ha rispetto non merita considerazione

 
Anche se il PC come desktop continua ad essere utilizzabile è mia intenzione 
installare tutto di nuovo. Continua ad essere per me un mistero il fatto di 
non riuscire a cancellare il file /usr/sbin/named anche se avvio da cd di 
emergenza e monto la partizione in scrittura. Come è possibile che root non 
riesca a cancellare un file di cui è proprietario ?
Ssh è installato solo col protocollo versione 2 e il login da root è 
disabilitato. 
L'unica traccia anomala che ho trovato e quella riportata qui sotto relativa 
al momento in qui ho fatto un adsl-stop poi adsl-start per altri motivi. Da 
allora il dns ha cessato di funzionare. Da notare i continui restart di 
syslogd.
Potresti per cortesia fornirmi qualche link ove possa reperire informazioni 
in merito ai sospetti da te avanzati ? col tempo posso anche ripristinare 
tutto, ma questo non basta.... quello che conta è non compiere i soliti 
errori.
Ciao e grazie.
Antonio C.
---------------------------------
Apr  1 20:52:12 fwrll kernel: request_module[net-pf-14]: waitpid(14152,...) 
failed, errno 1
Apr  1 20:58:07 fwrll modprobe: modprobe: Can't locate module binfmt-464c
Apr  1 20:58:07 fwrll modprobe: modprobe: Can't locate module binfmt-464c
Apr  1 20:58:12 fwrll syslogd 1.4.1: restart.
Apr  1 20:58:17 fwrll syslogd 1.4.1: restart.
Apr  1 20:58:19 fwrll syslogd 1.4.1: restart.
Apr  1 20:58:23 fwrll syslogd 1.4.1: restart.
Apr  1 20:58:24 fwrll syslogd 1.4.1: restart.
Apr  1 20:58:27 fwrll syslogd 1.4.1: restart.
Apr  1 20:58:29 fwrll syslogd 1.4.1: restart.
Apr  1 20:58:30 fwrll syslogd 1.4.1: restart.
Apr  1 20:58:34 fwrll syslogd 1.4.1: restart.
Apr  1 20:58:37 fwrll syslogd 1.4.1: restart.
Apr  1 20:58:39 fwrll syslogd 1.4.1: restart.
Apr  1 20:58:40 fwrll syslogd 1.4.1: restart.
Apr  1 20:58:42 fwrll syslogd 1.4.1: restart.
Apr  1 20:58:44 fwrll syslogd 1.4.1: restart.
Apr  1 20:58:46 fwrll syslogd 1.4.1: restart.
Apr  1 20:58:48 fwrll syslogd 1.4.1: restart.
Apr  1 20:58:50 fwrll syslogd 1.4.1: restart.
Apr  1 20:58:51 fwrll syslogd 1.4.1: restart.
Apr  1 20:58:55 fwrll syslogd 1.4.1: restart.
Apr  1 20:58:57 fwrll syslogd 1.4.1: restart.
Apr  1 20:58:59 fwrll syslogd 1.4.1: restart.
Apr  1 20:59:01 fwrll syslogd 1.4.1: restart.
Apr  1 20:59:03 fwrll syslogd 1.4.1: restart.
Apr  1 20:59:05 fwrll syslogd 1.4.1: restart.
Apr  1 20:59:07 fwrll syslogd 1.4.1: restart.
Apr  1 20:59:09 fwrll syslogd 1.4.1: restart.
Apr  1 20:59:11 fwrll syslogd 1.4.1: restart.
Apr  1 22:57:26 fwrll syslogd 1.4.1: restart.
apr  1 22:57:26 fwrll syslog: Avvio syslogd succeeded

 Apr  1 20:58:12 fwrll syslogd 1.4.1: restart.
Questo davvero non saprei...
Magari qualche informazione in piu' (se c'e') non guasterebbe.
-- 
Trimack -- GPGKey 61A6ABFD on 
keyserver.linux.it
"Running Windows on a Pentium is like having a brand new Porsche but only
be able to drive backwards with the handbrake on."

 Magari qualche informazione in piu' (se c'e') non guasterebbe.
Purtroppo è l'unica cosa strana che ho trovato nei log è questa.
Comunque ho fatto ulteriori indagini:
Nmap da altro PC in lan non rileva alcuna porta anomala, e lanciando una 
copia di lsof (prelevato da macchina sicura) conferma le corrispondenze di 
nmap. Netstat -an non riporta niente da aggiungere.
Ho il file di conf del mio kernel compilato quindi proverò a ricompilare, se 
il problema è dovuto ad un modulo che non esiste spero risolvere.
Il secondo e ultimo problema rimasto è /bin/ps che nonostante tutti i 
permessi siano coretti (anche lsattr) non funziona. Provero e ritrovarlo 
nell' archivio rpm della RH7.3 e sostituirlo.
I dubbi rimangono per la particolarità dei files in oggetto... vedremo.
Sicuramente mantengo l'installazione e provo ancora a lavorarci, il tuo 
consiglio mi ha dato fiducia.
Se avrò novità posterò nuovamente.
Grazie.
Antonio C.