Come faccio a sapere se il mio server Linux è stato violato?

Soluzione 1:

1. Conserva una copia originale di file di sistema critici (come ls, ps, netstat, md5sum) da qualche parte, con un md5sum di essi, e confrontarli regolarmente con le versioni live. I rootkit modificheranno invariabilmente questi file. Usa queste copie se sospetti che gli originali siano stati compromessi.
2. aiutante o tripwire ti informerà di tutti i file che sono stati modificati, supponendo che i loro database non siano stati manomessi.
3. Configura syslog per inviare i tuoi file di registro a un server di registro remoto dove non possono essere manomessi da un intruso. Controlla questi file di registro remoti per attività sospette
4. leggi i tuoi log regolarmente - usa logwatch o logcheck sintetizzare le informazioni critiche.
5. Conosci i tuoi server . Scopri quali tipi di attività e registri sono normali.

Soluzione 2:

Tu no.

Lo so, lo so - ma è la paranoica, triste verità, davvero;) Ovviamente ci sono molti suggerimenti, ma se il sistema fosse preso di mira in modo specifico - potrebbe essere impossibile dirlo. È bene capire che nulla è mai completamente sicuro. Ma dobbiamo lavorare per una maggiore sicurezza, quindi indicherò invece tutte le altre risposte;)

Se il tuo sistema è stato compromesso, non ci si può fidare di nessuno dei tuoi strumenti di sistema per rivelare la verità.

Soluzione 3:

Tripwire è uno strumento comunemente usato:ti avvisa quando i file di sistema sono cambiati, anche se ovviamente devi averlo installato in anticipo. Altrimenti elementi come nuovi account utente che non conosci, strani processi e file che non riconosci o un maggiore utilizzo della larghezza di banda senza una ragione apparente sono i soliti segni.

Altri sistemi di monitoraggio come Zabbix possono essere configurati per avvisarti quando vengono modificati file come /etc/passwd.

Soluzione 4:

Alcune cose che mi hanno dato una soffiata in passato:

• Carico elevato su un sistema che dovrebbe essere inattivo
• Segfault strani, ad es. da utilità standard come ls (questo può accadere con i root kit rotti)
• Directory nascoste in / o /var/ (la maggior parte dei copioni sono troppo stupidi o pigri per coprire le proprie tracce)
• netstat mostra le porte aperte che non dovrebbero esserci
• Demoni nell'elenco dei processi di cui normalmente usi versioni diverse (ad es. bind , ma usi sempre djbdns )

Inoltre ho scoperto che c'è un segno affidabile che una scatola è compromessa:se hai un brutto presentimento riguardo alla diligenza (con aggiornamenti, ecc.) dell'amministratore da cui hai ereditato un sistema, tienilo d'occhio!

Soluzione 5:

C'è un metodo per controllare i server compromessi tramite kill -

In sostanza, quando si esegue "kill -0 $PID" si invia un segnale nop all'identificatore di processo $PID. Se il processo è in esecuzione, il comando kill terminerà normalmente. (FWIW, poiché stai passando un segnale nop kill, non accadrà nulla al processo). Se un processo non è in esecuzione, il comando kill fallirà (exit status minore di zero).

Quando il tuo server viene violato / viene installato un rootkit, una delle prime cose che fa è dire al kernel di nascondere i processi interessati dalle tabelle dei processi ecc. processi. E quindi questo significa che

a) Questo controllo non è un controllo esteso, poiché i rootkit ben codificati/intelligenti assicureranno che il kernel risponda con una risposta "il processo non esiste" rendendo questo controllo ridondante.b) Ad ogni modo, quando un server violato ha un processo "cattivo" in esecuzione, il suo PID di solito non viene visualizzato in /proc.

Allora , se sei qui fino ad ora, il metodo è uccidere -0 ogni processo disponibile nel sistema (qualsiasi cosa da 1 -> /proc/sys/kernel/pid_max) e vedere se ci sono processi in esecuzione ma non segnalati in /proc.

Se alcuni processi vengono visualizzati come in esecuzione, ma non segnalati in /proc, probabilmente hai un problema in qualunque modo tu lo guardi.

Ecco uno script bash che implementa tutto ciò - https://gist.github.com/1032229 . Salvalo in un file ed eseguilo, se trovi un processo che non viene segnalato in proc, dovresti avere qualche indizio per iniziare a scavare.

HTH.