Come rilevare un processo nascosto in Linux?

Abbiamo una scatola che sospettiamo sia stata radicata al lavoro. La domanda è: come la troviamo? Non sono un amministratore di sistema, ma sono stato coinvolto nel team per risolvere la situazione e sono curioso di sapere dove potrebbero essere i posti migliori in cui cercare, ad esempio un problema?

Il motivo per cui sospettiamo questo è che abbiamo notato un utilizzo di rete superiore al normale sulla macchina da porte alte (che sembrano essere casuali).

Cosa possiamo fare per localizzare il problema bambino? Cosa possiamo fare per proteggerci da questo in futuro? Esiste un monitoraggio che possiamo eseguire per renderci consapevoli di ciò in futuro? (A parte il monitoraggio della rete su cui stiamo già lavorando per tenere d'occhio.)

Grazie in anticipo e posso fornire maggiori dettagli se necessario. Apprezzo il tuo tempo.

Non puoi fidarti di tutti gli strumenti di sistema che hai sulla macchina. I rootkit sostituiranno ps, netstat, ls e altro per nascondere la loro presenza. Dovresti portare la macchina offline, estrarre il suo disco rigido, fare una copia forense (pensa dd), quindi lavorare da quella su una macchina separata per cercare il rootkit.

Se insisti a lavorare sulla macchina live (che di solito è inutile), puoi provare a scaricare una distribuzione di salvataggio su CD (è molto importante che la copia sia di sola lettura) e utilizzare le sue copie di ps, lsmod, ecc.

Anche questo potrebbe non riuscire poiché un rootkit può installare moduli del kernel per nascondere le voci in / proc su cui normalmente operano strumenti come ps.

In bocca al lupo!

Il problema con il rootkit ben costruito è che modificano il comando del tuo sistema; come ps e top per non mostrare i processi del rootkit e ls per non mostrare i file del rootkit.

Quindi quello che devi fare è ottenere questi comandi possibilmente dalla fonte o in forma di binairies. (Assicurati di essere ben firmato). Ma il trucco di un kit di root (l'ho visto) è che forse hanno corrotto anche il tuo compilatore. Quindi quando il compilatore sa che sta compilando ls o ps o qualsiasi comando, li infetta pure.

Quando ho visto questo problema, ho detto che va bene ricompilare gcc, ma niente di ciò che mi serve per compilare gcc ... infecte gcc .... quindi quando sa che si sta compilando da solo, lo infetta in modo che possa infettare il comando.

Dirai che questo diventa grande e difficile da rilevare, sì ma rari sono i kit di root che sono così a prova di proiettile che ho appena citato il caso peggiore.

Seriamente, se sei sicuro che ci sia un kit di root nel tuo server, reinstallalo!

Il modo migliore per sapere se il tuo server è stato "rootato" è eseguire un sistema di rilevamento delle intrusioni (HIDS) basato su host. Sfortunatamente, se non stai eseguendo un HIDS ora, è troppo tardi per installarne uno. Il momento giusto per installare un HIDS è quando il server viene installato per la prima volta e prima che venga inserito in una rete.

In breve, la maggior parte degli HIDS funziona calcolando gli hash crittografici di tutti i file binari di sistema e memorizzando tali hash (insieme a numerose altre statistiche sui file) in un database, chiamato database di base. Quindi, periodicamente, HIDS esegue nuovamente la scansione del sistema, confrontando tutti i file nel suo database di base con i file di sistema effettivi.

Sì, ovviamente, è possibile per un rootkit modificare il database di base, motivo per cui è necessario prendere una copia di quel database e archiviarlo separatamente dal server prima di metterlo online. Quindi, se si sospetta di essere "rooted" (e si sospetta che anche il database di base sia stato manomesso), è possibile avviare il sistema dal supporto di installazione, ripristinare il database noto dal backup e quindi eseguire una scansione sul nota bene. È molto più probabile, tuttavia, che un rootkit non preveda di dover sconfiggere il tuo particolare HIDS, e quindi riceverai una notifica dall'HIDS che i file di sistema sono cambiati, indicando una probabile intrusione del sistema.

Dato che non stavi eseguendo un HIDS, non hai modo rapido per determinare con certezza se sei stato rootato o quali file di sistema sono stati modificati. Potresti dedicare molto tempo a confrontare i tuoi file di sistema con file di buona qualità estratti da supporti di installazione di buona qualità, ma è molto probabile che questo tempo sia meglio impiegato per reinstallare il tuo sistema da quel supporto. Se vuoi indagare su come sei stato rootato dopo il fatto, il modo migliore è quello di scattare un'immagine del tuo sistema prima di cancellarlo e reinstallarlo.

Si prega di fare riferimento a un post precedente fatto

Dolore durante la rimozione di un rootkit perl

È molto importante leggere questo ..

Come rispondere alle tue domande ..

Di solito eseguo un IDS / IPS (sistema di rilevamento / protezione dalle intrusioni) come uno snort .. fa un ottimo lavoro contro il gioco disgustoso, e l'ho visto fare un ottimo lavoro in azione ..

Uso anche i server Syslog per tenere lontani i messaggi di log dai server di produzione, in modo da poter risalire a problemi e modifiche / essere rootkit

Inoltre, utilizzo spesso strumenti di gestione come cactus, che rappresentano graficamente CPU, memoria, disco, utilizzo della rete e segnalano se qualcosa è fuori dal comune.

Essere rootkit è un problema serio, sicuramente cerca di capire la causa ..

Spero che questo aiuti ..: D

Le porte alte casuali sono le porte effimere, il che indica che probabilmente hai una o più connessioni di programmi verso l'esterno da questo sistema.

Se non è rootato, netstat -np | grep -v ^unixpotrebbe darti un suggerimento su quale programma (i) sta generando il traffico.

Potresti anche essere in grado di scansionare il traffico da un sistema vicino usando tcpdump per scaricare pacchetti originati dal sistema che ritieni sia rootato. Se il programma problematico non è in esecuzione come root, è possibile farlo dal sistema infetto.

Ci sono diverse cose che puoi fare per evitare di radicarti:

• Mantieni il tuo sistema patchato, specialmente il kernel. Monitorare i motivi del rilascio del kernel per determinare i vettori di attacco.
• Installa e usa solo i programmi richiesti. Eseguire l'installazione minima possibile.
• Esegui il meno possibile come root. Molti programmi cambieranno in userid senza privilegi una volta completata l'installazione che richiede il privilegio di root.

EDIT: se si è rootati, l'uso di programmi ps e ls collegati staticamente può indicare una differenza tra i programmi in esecuzione che i due strumenti trovano. Le differenze nella lista possono anche sorgere quando i programmi di breve durata si estinguono.

La vera soluzione per un sistema che può essere rootato è reinstallarlo da fonti sicure. Come i CD di installazione. Quindi ripristinare i dati solo dal backup. Eventuali file binari o script nel backup potrebbero essere stati compromessi e salvati nel backup.

Per trovare il kit di root su un sistema in esecuzione, un modo per farlo è compilare un modulo del kernel progettato per rilevare i rootkit. Compilalo su un altro computer che esegue la stessa versione del sistema operativo. Quindi copiarlo e inserirlo.

Un rilevatore di rootkit avrà strumenti integrati nel modulo del kernel per scaricare la tabella dei processi in esecuzione, verificare la tabella syscall (per cercare intercettazioni syscall) e altre funzionalità. Potrebbe avere degli script che prenderanno l'output dal modulo e lo confronteranno con l'output di ps, netstat, ls, ecc. Oppure potrebbero essere in grado di scansionare la memoria nello spazio del kernel alla ricerca di firme e report rootkit noti.

È come un topo: se ne vedi uno, ci sono un centinaio di persone che vivono lì dentro. Se vedi segni di compromesso, devi presumere che l'intero sistema sia compromesso. Ecco perché tutti suggeriscono di reinstallare il sistema piuttosto che passare molto tempo a cercare. Ho riscontrato diverse situazioni in cui una macchina era stata compromessa e gli amministratori di sistema pensavano di aver ripulito il casino, solo per rimpiangerlo in seguito.

È molto comune per i rootkit sostituire i binari di sistema come ps, top, netstat. Ed è anche comune a trojan ssh. Quindi, cercare le stranezze di checksum in quei file è un approccio fondamentale. Se usi un sistema basato su rpm, rpm -V è di solito un buon strumento, o dpkg-verificato su Debian / Ubuntu. Oppure puoi controllare direttamente i checksum (ma fai attenzione a prelink, che cambia i binari al volo per motivi di velocità). Questo non è affidabile, ma molti attacchi di script kiddie non coprono queste tracce. (In altre parole, se trovi qualcosa, bene. Se non trovi qualcosa, ciò non dimostra che sei pulito.)

Altre cose da cercare: porte mostrate aperte da un esterno nmapche non sembrano aperte netstatsulla macchina e pid in /proccui non appaiono ps. E se ti capita di avere il syslog remoto abilitato, cerca gli accessi ssh che non hanno record nell'ultimo log.

Prendi una copia di RKhunter e chkrootkit. Di solito sono abbastanza decenti nell'aiutare a trovare cose che non dovrebbero essere lì.

È sempre utile eseguire mod_security anche sul layer Apache insieme a un firewall. Di solito troveranno una webapp o uno script obsoleto e miglioreranno l'accesso da lì con gli script della shell Perl e altre cose divertenti.

ps auxfww di solito è fantastico trovare processi che non appartengono.

Inoltre: netstat -anp per vedere cosa è in ascolto su determinate porte.

Anche in questo caso sono buoni se non sei stato rootato, solo compromesso.