Dolore durante la rimozione di un rootkit perl

8

Quindi, ospitiamo un server web geoservizio in ufficio.

Qualcuno apparentemente è entrato in questa casella (probabilmente via ftp o ssh), e ha messo una specie di rootkit gestito da irc.

Ora sto cercando di ripulire il tutto, ho trovato il processo pid che tenta di connettersi tramite irc, ma non riesco a capire chi è il processo di invocazione (già guardato con ps, pstree, lsof) Il processo è un perl script di proprietà dell'utente www, ma ps aux | grep visualizza un percorso file falso nell'ultima colonna.

C'è un altro modo per rintracciare quel pid e catturare l'invocatore?

Ho dimenticato di menzionare: il kernel è 2.6.23, che è sfruttabile per diventare root, ma non riesco a toccare troppo questa macchina, quindi non posso aggiornare il kernel

EDIT: lsof potrebbe aiutare:

lsof -p 9481
UTENTE PID COMANDO TIPO FD MISURA DISPOSITIVO NOME NODOss
perl 9481 www cwd DIR 8,2 608 2 / ss
perl 9481 www rtd DIR 8,2 608 2 / ss
perl 9481 www txt REG 8,2 1168928 38385 / usr / bin / perl5.8.8ss
perl 9481 www mem REG 8,2 135348 23286 /lib64/ld-2.5.soss
perl 9481 www mem REG 8,2 103711 23295 /lib64/libnsl-2.5.soss
perl 9481 www mem REG 8,2 19112 23292 /lib64/libdl-2.5.soss
perl 9481 www mem REG 8,2 586243 23293 /lib64/libm-2.5.soss
perl 9481 www mem REG 8,2 27041 23291 /lib64/libcrypt-2.5.soss
perl 9481 www mem REG 8,2 14262 23307 /lib64/libutil-2.5.soss
perl 9481 www mem REG 8,2 128642 23303 /lib64/libpthread-2,5.soss
perl 9481 www mem REG 8,2 1602809 23289 / lib64 / libc -2.5.soss
perl 9481 www mem REG 8,2 19256 38662 /usr/lib64/perl5/5.8.8/x86_64-linux-threa d-multi / auto / IO / IO.soss
perl 9481 www mem REG 8,2 21328 38877 /usr/lib64/perl5/5.8.8/x86_64-linux-threa d-multi / auto / Socket / Socket.soss
perl 9481 www mem REG 8,2 52512 23298 /lib64/libnss_files-2.5.soss
perl 9481 www 0r FIFO 0,5 1068892 pipess
perl 9481 www 1w FIFO 0,5 1071920 pipess
perl 9481 www 2w FIFO 0,5 1068894 pipess
perl 9481 www 3u IPv4 130646198 TCP 192.168.90.7:60321->www.****.net:ircd (SYN_SENT)

— paul.ago
fonte

2

A meno che non si aggiorni il kernel, cosa impedisce all'hacker di ripetere l'hacking non appena si rimuove il rootkit? Potrebbe esserci un modulo del kernel trojan che nasconde i processi.

— pjc50,

sembra molto simile al bot irc ddos che ho appena ripulito dal mio vps: serverfault.com/questions/639699/…

— Hayden Thring,

37

Se posso darti qualche consiglio, è di smettere di perdere tempo a ripulire. Crea un'immagine del sistema operativo per roba forense per dopo e reinstalla il server.

Siamo spiacenti, ma è l'unico modo sicuro per risolverti dal rootkit.

Successivamente puoi controllare l'immagine, per alcuni motivi, perché è successo.

Dalla mia esperienza personale, l'ho fatto e in seguito ho trovato un utente interno che aveva una chiave SSH contenente il difetto di openssl nel 2008.

Spero che chiarisca le cose.

Nota:
se si desidera visualizzare l'immagine / eseguire il backup del server prima della reinstallazione, fare molta attenzione a come procedere. Come diceva @dfranke, avvia da un supporto affidabile per il backup.

Non dovresti connetterti ad altre macchine da un server rootato, poiché è noto che i rootkit eccezionali siano in grado di diffondersi attraverso sessioni attendibili come SSH.

— Arenstar
fonte

11

Sono assolutamente d'accordo con questo consiglio. Hai trovato un rootkit, ma non hai assolutamente idea di cos'altro abbia manipolato l'attaccante. Una volta radicato, sempre radicato. Avvio da un supporto attendibile, azzerare l'unità. Fdisk, formattazione, reinstallazione, doo dah, doo dah.

— dfranke,

Yah ... I buoni kit di root corrono sotto il tuo kernel .. Nessuna possibilità di eliminarli, senza

— MOLTO

4

+1 Per qualsiasi sistema di produzione (davvero, qualsiasi sistema) non c'è motivo di pulire. Uccidilo con il fuoco e ricostruiscilo.

— phoebus l'

1

+1 per reinstallare. Il rootkit probabilmente ha fatto casino con i tuoi binari o kernel e tutto ciò che stai vedendo (percorsi falsi, ecc ...) è probabilmente fumo corteccia dal rootkit per nascondersi.

— coredump,

1

Oblig. citazione : "Dico che togliamo e nuotiamo l'intero sito dall'orbita. È l'unico modo per essere sicuri."

— Charles Stewart,

1

La riga di comando può essere modificata se il processo modifica argv [0]. Provarels -l /proc/[pid]/exe

A partire dal man 5 proc

questo file è un collegamento simbolico contenente il percorso effettivo del comando eseguito. Questo collegamento simbolico può essere normalmente referenziato; il tentativo di aprirlo aprirà l'eseguibile. Puoi anche digitare / proc / [numero] / exe per eseguire un'altra copia dello stesso eseguibile che viene eseguito dal processo [numero]. In un processo multithread, i contenuti di questo collegamento simbolico non sono disponibili se il thread principale è già terminato

ps auxwf | less ti offre la "visualizzazione foresta" dei processi che possono mostrarti quale processo ha avviato questo processo (a meno che il rootkit non lo nasconda o il genitore dell'app sia uscito ed è stato sostituito da init).

Questo sarebbe per lo più accademico e probabilmente solo una perdita di tempo, ma strings -n 10 /proc/[pid]/mempotrebbe essere divertente guardare scorrere oltre. Potresti anche echo 0x7 > /proc/[pid]/coredump_filterusare gdb gcoreper forzare un coredump con tutto il possibile, ma il processo muore, il che potrebbe bloccare ulteriori analisi.

Ma sicuramente accetta il consiglio di Arenstar. Esegui il backup dei soli dati, ripristina tutti i file eseguibili dai backup e ricomincia. Probabilmente dovresti ripristinare il sito Web anche dai backup, potrebbe essere aggiunto javascript dannoso a ogni file html o php. Se stai prendendo in considerazione un'azione legale, ti consigliamo di mettere da parte la macchina, scollegarla dalla rete e interrompere tutto ciò che stai facendo fino a quando gli esperti forensi non hanno fatto il loro lavoro.

— DerfK
fonte

Davvero un'ottima risposta.

— paul.ago,

sfortunatamente ls -l / proc / [pid] / exe restituisce il percorso bin perl5.8.8 e ps / pstree dice che il processo padre è init, questa cosa sembra davvero ben nascosta. Ricomincerei sicuramente con una nuova installazione, ma lo sviluppatore originale dell'applicazione in esecuzione su di esso è fuori dal paese per un po ', quindi stavo cercando una soluzione temporanea. A proposito, risposta davvero eccezionale

— paul.ago,

0

Prova "cat / proc / [process id] / cmdline" Anche se si tratta di un vero rootkit può modificare il kernel per nascondersi meglio.

— mfarver
fonte

mi dà lo stesso di ps aux "/ usr / sbin / apache / logs" che è falso. Né la directory / usr / sbin / apache esiste

— paul.ago l'

0

Dovresti reinstallare, sono d'accordo. Hai provato a sfuggire ai personaggi nel percorso? Forse una di queste barre fa effettivamente parte di un nome file e non di una directory. Come minimo dovresti usare iptables per bloccare il traffico in uscita verso quell'host o il generale IRC fino a quando non sarà risolto. Controlla anche netstat.

— sinping
fonte

no, il percorso sembra "reale". Purtroppo iptables sembra installato ma manca il modulo del kernel, quindi devo ricompilare il kernel. Probabilmente andrei in quel modo per risolvere il problema per alcuni giorni fino a quando non entrerò in contatto con il ragazzo che ha il codice sorgente dell'app, quindi posso reinstallare il server

— paul.ago

0

Penso che ormai hai reinstallato. Il tuo giusto spreco di tempo nel cercare di tracciare i processi e fare analisi forensi poiché le possibilità che qualcosa si sviluppi legalmente da esso sarebbero molto ridotte e le probabilità di trovare l'hacker sarebbero comunque inutili. A meno che non ti interessi solo a cercare e invertire i rootkit che possono essere divertenti :)

— nullo
fonte