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

Quali sono i segnali rivelatori che un server Linux è stato violato? Esistono strumenti in grado di generare ed inviare per e-mail un rapporto di audit su base programmata?

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

Non

Lo so, lo so - ma è la verità paranoica e triste, davvero;) Ci sono molti suggerimenti ovviamente, ma se il sistema fosse mirato in modo specifico - potrebbe essere impossibile dirlo. È bene capire che nulla è mai completamente sicuro. Ma dobbiamo lavorare per essere più sicuri, quindi indicherò invece tutte le altre risposte;)

Se il tuo sistema è stato compromesso, nessuno degli strumenti di sistema può essere considerato affidabile per rivelare la verità.

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 di cui non si è a conoscenza, strani processi e file che non si riconoscono o un maggiore utilizzo della larghezza di banda senza motivo apparente sono i soliti segni.

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

Alcune cose che mi hanno dato la mancia in passato:

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

Inoltre ho trovato il segno affidabile che una scatola è compromessa: se hai una brutta sensazione della diligenza (con aggiornamenti, ecc.) Dell'amministratore da cui hai ereditato un sistema, tienilo d'occhio!

Esiste un metodo per controllare i server compromessi tramite kill-

In sostanza, quando si esegue "kill -0 $ PID", si invia un segnale nop per elaborare l'identificatore $ PID. Se il processo è in esecuzione, il comando kill termina normalmente. (FWIW, poiché stai trasmettendo un segnale di nop kill, non succederà nulla al processo). Se un processo non è in esecuzione, il comando kill avrà esito negativo (stato di uscita inferiore a zero).

Quando il tuo server viene hackerato / viene installato un rootkit, una delle prime cose che fa è dire al kernel di nascondere i processi interessati dalle tabelle dei processi, ecc. Tuttavia può fare ogni sorta di cose interessanti nello spazio del kernel per confondersi con il processi. E quindi questo significa che

a) Questo controllo non è un controllo approfondito, poiché i rootkit ben codificati / intelligenti assicureranno che il kernel risponderà con una risposta "processo inesistente" rendendo superfluo questo controllo. b) Ad ogni modo, quando un server compromesso ha un processo "cattivo" in esecuzione, il suo PID di solito non viene visualizzato sotto / proc.

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

Se alcuni processi risultano funzionanti, ma non riportati in / proc, probabilmente hai un problema in qualunque modo 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.

Seguirò le risposte fornite qui e ne aggiungerò una mia.

find /etc /var -mtime -2

Questo ti darà una rapida indicazione se uno dei file del tuo server principale è cambiato negli ultimi 2 giorni.

Questo è tratto da un articolo sul rilevamento degli hack Come rilevare se il tuo server è stato violato.

Da Come posso rilevare intrusioni indesiderate sui miei server?

• Usa un IDS

  SNORT® è un sistema di prevenzione e rilevamento delle intrusioni di rete open source che utilizza un linguaggio basato sulle regole, che combina i vantaggi dei metodi di ispezione basati su firma, protocollo e anomalie. Con milioni di download fino ad oggi, Snort è la tecnologia di rilevamento e prevenzione delle intrusioni più diffusa al mondo ed è diventata di fatto lo standard per l'industria.

  Snort legge il traffico di rete e può cercare cose come "test drive by pen" in cui qualcuno esegue solo una scansione metasploit completa sui tuoi server. Bello sapere questo genere di cose, secondo me.

• Usa i registri ...

  A seconda dell'utilizzo è possibile configurarlo in modo da sapere ogni volta che un utente accede, o accede da un IP dispari, o ogni volta che si accede alla radice, o ogni volta che qualcuno tenta di accedere. In realtà ho il server e-mail me ogni messaggio di registro superiore a Debug. Sì, anche avviso. Ovviamente ne filtro alcuni, ma ogni mattina quando ricevo 10 e-mail su cose mi viene voglia di risolverlo in modo che non accada più.

• Monitora la tua configurazione - In realtà mantengo il mio intero / etc in sovversione in modo da poter tenere traccia delle revisioni.

• Esegui scansioni. Strumenti come Lynis e Rootkit Hunter possono avvisarti di possibili falle nella sicurezza delle tue applicazioni. Esistono programmi che mantengono un albero di hash o hash di tutti i tuoi contenitori e possono avvisarti delle modifiche.

• Monitora il tuo server - Proprio come hai detto spazio su disco - i grafici possono darti un suggerimento se qualcosa è insolito. Uso Cactus per tenere d'occhio CPU, traffico di rete, spazio su disco, temperature, ecc. Se qualcosa sembra strano è strano e dovresti scoprire perché è strano.

Vorrei solo aggiungere a questo:

Controlla la tua cronologia bash, se è vuota e non l'hai annullata o svuotata, c'è una buona possibilità che qualcuno abbia compromesso il tuo server.

Controlla per ultimo. O vedrai IP sconosciuti o sembrerà molto vuoto.

Quindi, come indicato nella risposta accettata, i file di sistema vengono spesso modificati, controllare la data modificata. Tuttavia, spesso manomettono la data modificata.

Spesso installano un'altra versione di ssh in esecuzione su una porta casuale. Questo è spesso nascosto in alcuni posti davvero strani. Nota che normalmente verrà rinominato in qualcosa di diverso da ssh. Quindi controlla netstat (potrebbe non funzionare poiché spesso lo sostituiscono) e usa iptables per bloccare eventuali porte sconosciute.

In ogni caso, questa è una situazione in cui prevenire è meglio che curare. Se sei stato compromesso, è meglio formattare e ricominciare. È quasi impossibile confermare di aver ripulito l'hack con successo.

Prendere nota di quanto segue per evitare che il server venga compromesso.

1. Cambia porta ssh
2. Impedisci a root di poter accedere
3. consentire solo determinati utenti
4. Impedisci accesso con password
5. Usa chiavi ssh, preferibilmente chiavi protette da password
6. Ove possibile, inserire nella blacklist tutti gli IP e inserire nella lista bianca gli IP richiesti.
7. Installa e configura fail2ban
8. Utilizzare tripwire per rilevare intrusioni
9. Monitora il numero di utenti che hanno effettuato l'accesso con Nagios o zabbix. Anche se ricevi una notifica ogni volta che accedi, almeno saprai quando qualcun altro sta giocando.
10. Se possibile, mantieni il tuo server su una VPN e consenti solo ssh tramite IP VPN. Proteggi il tuo VPN.

Vale la pena notare che una volta che si trovano in un server, controlleranno la cronologia di bash e cercheranno altri server a cui ti sei connesso tramite ssh da quel server. Tenteranno quindi di connettersi a tali server. Quindi, se vieni forzato a causa di una password scadente, è molto probabile che possano connettersi all'altro server e compromettere anche quelli.

È un brutto mondo là fuori, ribadisco che prevenire è meglio che curare.

Dopo aver cercato un po ', c'è anche questo, fa quello che ho elencato sopra, tra le altre cose: http://www.chkrootkit.org/ e http://www.rootkit.nl/projects/rootkit_hunter.html

Dovresti dare un'occhiata a GuardRail. Può scansionare il tuo server su base giornaliera e dirti cosa è cambiato in un bel modo visivo. Non richiede un agente e può connettersi tramite SSH, quindi non è necessario eseguire il junking della macchina e delle risorse con un agente.

Soprattutto, è gratuito per un massimo di 5 server.

Controllalo qui:

https://www.scriptrock.com/