Newsgroup: it.comp.sicurezza.unix
Titolo: apache web server compromesso

salve,
ieri il mio web server e' stato compromesso da un'intrusione hacker.
oggi, mentre cercavo di upgradare apache dalla 1.3.27 alla 1.3.29, effettuando
un riavvio del server mi sono accorto che lo stesso non riusciva ad avviarsi
in quando un altro processo era gia' in ascolto sulla porta 80!
non era, come speravo il vecchio apache.
tramite ps -ef mi accorgevo della presenza di un processo chiamato "./f".
ho ucciso tale processo e sono stato in grado di ripartire.
quello che vorrei chiedrvi e': sapete quale backdoor/trojan/exploit/quello che
volete voi ha fatto questo?
chkrootkit ha dato esito negativo a tutti i test effettuati.
grazie anticipatamente
-- 
giovanni


può essere effettivamente di tutto, sei andato poi a recuperare il binario
di nome "f" lanciato da chissà quale cartella?
inoltre un consiglio, se la tua macchina è stata bucata ti conviene
riformattarla, in un sistema unix compromesso è facile nascondere altre
sorprese.
a dovere di cronaca comunque non è stato un "hacker" ;)
kain
kuht.it

Giovanni wrote:

whereis /f 
guarda se nel binario si recupera qualcosa...
mettici un bel server casereccio, che ti logga l'ip....e fagli una bella
sorpresa....;)
nei sistemi unix non è facile nascondere la roba, come qualcuno qui
sostiene, è facile solo nasconderlo agli ignoranti.
1bit

 Dici che me ne accorgo cosi' facilmente?
In ogni modo è vero, quando una macchina viene compromessa, l'unica è il
formattone con reinstallazione dai cd di sistema. Unico modo per stare
tranquilli.
-- 
Massimo Bacilieri AKA Crononauta 
ICQ:4005815

 caricato il modulo esterno... :-bbbbb
volendo dd of=/proc/kcore
Non che sia facile :-D
-- 
Afterlife confessions
Tell me who you used to be
Looking on in wonder
As I show you it was me

ciao a tutti,
oggi ho maggiori info riguardanti l'intrusione: in primis sottolineo che non
la colpa non e' attribuibile al povero sysadmin (me), in quanto l'ingresso
al sistema non e' stato garantito da servizi obsoleti o buggati ma bensi'...
udite udite... e' stato fatto l'upload di due exploit nella cartella /tmp
usando una vecchia copia (4 anni) di oscommerce!!! gli exploit erano
conservati in due server su internet: il giorno dopo non erano gia' piu'
disponibili :(
quello che mi chiedo e' come siano riusciti ad eseguire un comando da tmp
dopo averlo uploadato senza avere accesso telnet/ssh: pareri?
btw, ho varificato tramite chkrootkit la presenza di rootkit: negativo;
ho verificato la correttezza delle md5 signs del software installato: negativo
purtroppo io penso che, nel dubbio, sia meglio dismettere al piu' presto
quella macchina di cui ormai, non mi fidero' piu'.
grazie a tutti per le pronte risposte e, fatemi sapere qualcosa riguardo
all'esecuzione remota dei comandi via web!!
giovanni


scusate per il cattivo uso della parola "hacker": rileggero' 100 volte il
jargon file per punizione :(

-- 
giovanni

 > 1bit
consiglirei:
1) se scopri qualche processo che non ti quadra, prima di killarlo fai
un bel:
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT --dport 80 -j LOG --log-prefix "TRAFFICO WEB: "
Lasciati aperta la porta per la tua connessione sicura in ssh dalla
macchina da cui amministri, se sei in remoto, altrimenti chiudi tutto
e lavora in console.
Lascia che il server vada per un pň e controlla cosa succede sulla
porta 80
2) recupera un System.map FIDATO! e montati kstat (S0ftpj - FuSyS) :
./kstat -i TUA_INTERFACCIA_ESTERNA (verifica tutte le impostazioni
dell'interfaccia)
./kstat -p (verifica tutti i processi, anche quelli nascosti)
./kstat -p PID_PROCESSO_SOSPETTO (gli leggi la vita, specie i socket
aperti e bind vari)
./kstat -M (elenca tutti i moduli installati, anche quelli nascosti)
./kstat -s (verifica la presenza di dirottamenti delle sys_call)
3) installa grsecurity e tramite le ACL concedi socket ai soli
processi che hai installato tu. cosě non rischi che un altro processo
possa bindare porte e lanciarsi come server. inoltre blocchi la
scrittura su /dev/kmem etc. e non corri rischi di moduli tipo adore e
vari
ciao
m.