Re: [ml] Mi hanno bucato il server

> Ho poi 
> fatto un NMAP e mi risulta aperta una porta 34845...
> Ho cercato di 
> capire quale processo à in ascolto...ma con netstat
> non mi da nessuna 
> informazioni...
> 
> netstat -apl | grep LISTEN
> ......
> tcp        0      0 
> *:microsoft-ds          *:*                     LISTEN     17164/smbd
> tcp        0      0 *:34845                 *:*                     
> LISTEN     -
> tcp6       0      0 *:ssh                   *:
> *                     LISTEN     15660/sshd
> ......
> C'Ã modo di sapere 
> per una porta quale processo à in ascolto ?

Potrebbe aver "nascosto" il PID del processo sulla tabella dei socket in
listening intervenendo sul kernel in esecuzione (o tramite un modulo, o
mediante una serie di accessi in /dev/kmem o facendo patching
dell'immagine del kernel) ..
cosà non trovi nulla
Ti potrei consigliare di avviare un altro kernel, perà c'à il rischio
che l'init sia stato a sua volta patchato per intaccare ogni volta
all'avvio del sistema la tabella dei socket del kernel in esecuzione.

Se stavi utilizzando un kernel 2.6 ed hai la possibilita' di far partire
un kernel 2.4 all'avvio, fallo!!
Perche' se c'e' qualcosa nell'init che ti va' a modificare la tabella
dei socket per il kernel 2.6 questo non funziona sul 2.4 e te ne
accorgeresti o perche' non c'e' piu' in ascolto niente su quella porta,
oppure perche' ottieni un bel kernel panic!


> Oppure l'unica soluzione 
> Ã reinstallare tutto ?

IMHO la seconda che hai detto....
a meno che tu non sia interessato ad una analisi forense del sistema.
Il consiglio, se deciderai di reinstallare, e' quello di fare un
hardening del Kernel tramite ad esempio:
grsecurity

un ulteriore consiglio se deciderai di seguire questa strada>
compilati un kernel statico (senza moduli) e disabilita gli accessi in
/dev/kmem cosi' come le operazioni di "iopl" per l'accesso alle porte di I/O
Prendi anche in seria considerazione l'ipotesi di configurare RBAC.

Comunque se guardi qui:
http://www.dshield.org/port.html?port=34845


non sembra si tratti di una backdoor comune.