Indagare sui server compromessi

Questo articolo elenca gli strumenti disponibili per eseguire un'analisi di un server compromesso. (La pulizia del server compromesso non rientra nel suo ambito.)L'utilizzo di questi strumenti consente di determinare le seguenti informazioni:

• Il punto di ingresso
• L'origine dell'attacco
• Quali file sono compromessi
• Il livello di accesso ottenuto dall'attaccante
• L'audit trail delle impronte dell'attaccante

Molti diversi tipi di compromessi possono sfruttare un server Unix®. Gli aggressori potrebbero lanciare un attacco di forza bruta, indovinare una password debole o tentare di utilizzare vulnerabilità software note nella speranza che il server non abbia una pianificazione regolare delle patch. È importante capire in che modo la macchina è stata compromessa per determinare l'entità del danno al server e ad altri host accessibili alla macchina compromessa.

Per la maggior parte dei compromessi a livello di root, l'approccio di ripristino più semplice consiste nell'eseguire un'installazione pulita del server e ripristinare tutti i dati critici dai backup. Tuttavia, finché non si conosce il punto di ingresso del compromesso, questo passaggio potrebbe non essere sufficiente perché è necessario comprendere il compromesso in modo da poter chiudere correttamente la falla nella sicurezza.

Documenta l'attacco

Quando ti viene notificato che un sistema sotto il tuo controllo potrebbe essere compromesso, assicurati di ottenere quante più informazioni possibili dal segnalante, inclusi i seguenti elementi:

• Come è stato individuato il problema iniziale
• Il tempo stimato in cui si è verificata la compromissione
• Se il server è stato modificato dopo il rilevamento della compromissione
• Qualsiasi altra cosa che il giornalista dice che è importante

Importante :se prevedi di coinvolgere le forze dell'ordine, è imperativo non intraprendere ulteriori azioni sul server. Il server deve rimanere nel suo stato attuale ai fini della raccolta delle prove.

Se scegli di procedere con l'indagine, documenta tutto ciò che trovi sul server. Questo passaggio può essere semplice come copiare e incollare un comando e i suoi risultati.

Strumenti di indagine

In alcuni compromessi, l'attaccante riesce a eliminare tutti i file di registro importanti per nascondere le proprie tracce. Tuttavia, questo non si verifica sempre. Di conseguenza, i file di registro contengono preziosi indizi su ciò che l'attaccante ha fatto al server. I file di registro potrebbero anche aiutarti a determinare se l'attacco è stato un attacco Web di base o una compromissione a livello di root. Usa i comandi in questa sezione per trovare indizi che ti aiutino a svelare l'entità del compromesso.

ultimo comando

L'last comando elenca le sessioni degli utenti che hanno effettuato l'accesso di recente al sistema. Il suo output include timestamp e nomi host e indica se l'utente è ancora connesso. Se nell'output viene visualizzato un indirizzo IP (Internet Protocol) dispari, puoi fare un riferimento incrociato contro un attacco Secure Shell (SSH) di forza bruta nel /var/log/messaggi o /var/log/secure directory. Questo passaggio potrebbe indicare in che modo l'attaccante ha ottenuto l'accesso, quale nome utente ha utilizzato per accedere e se è stato in grado di aumentare i propri privilegi a root .

ls -lart comando

Il ls -lart Il comando restituisce un elenco ordinato nel tempo di file e directory a cui è possibile correlare quando si è verificata la compromissione. Questo output può aiutarti a determinare cosa l'attacco ha aggiunto o rimosso dal sistema.

comando netstat -na

Il netstat -na Il comando visualizza i socket di ascolto correnti sulla macchina. L'esecuzione di questo comando potrebbe rivelare eventuali backdoor in ascolto o servizi errati in esecuzione.

comando ps -wauxef

Questo comando ti aiuta a rintracciare eventuali processi errati in ascolto e mostra altri processi strani (ad esempio, l'utente www eseguendo un processo Bash). Puoi anche eseguire il comando lsof |grep <pid> per trovare ulteriori informazioni sui file aperti utilizzati da un processo. Contemporaneamente, eseguendo cat /proc/<pid>/cmdline potrebbe anche dirti dove esiste il file che controlla un processo.

comando bash_history

Il file storico è spesso la pietra di Rosetta per rintracciare ciò che ha richiesto un compromesso. Usando bash_history comando per esaminare il .bash_history dell'utente spesso mostra esattamente quali comandi hanno eseguito, quali programmi dannosi hanno scaricato e le directory su cui si sono concentrati.

comando superiore

I processi dannosi spesso causano problemi di contesa tra le unità di elaborazione centrale (CPU) all'interno dell'ambiente e pertanto vengono visualizzati in cima all'elenco dei processi. Usa il top comando per visualizzare questo elenco. Quando stai rintracciando una compromissione, considera sospetti tutti i processi che causano problemi di contesa della CPU.

comando strace

Quando esegui strace -p pid comando su un processo sospetto, il strace comando potrebbe fornire informazioni importanti su ciò che sta facendo il processo.

Altri strumenti

I comandi precedenti potrebbero non fornire molti indizi su ciò che è accaduto durante l'attacco. In tal caso, puoi utilizzare strumenti più specializzati.

Importante :prima di utilizzare gli strumenti in questa sezione, dovresti confermare che i file binari che stai utilizzando per indagare non sono versioni di trojan. Le versioni di trojan possono eseguire attività per conto dell'attaccante, come l'omissione di informazioni che potrebbero rivelare ciò che la compromissione stava cercando di ottenere.

Esegui il comando seguente per verificare di disporre di un buon set di strumenti funzionante:

rpm -Va

La verifica di un pacchetto confronta le informazioni sui file installati del pacchetto con i metadati del pacchetto archiviati nel database RPM Package Manager (RPM). La verifica confronta le informazioni su dimensione, somma MD5, autorizzazioni, tipo, proprietario e gruppo associati a ciascun file. L'output mostra eventuali discrepanze.

Importante :I pacchetti contrassegnati nelle seguenti directory potrebbero indicare che stai utilizzando una versione trojan del binario e quindi non puoi fidarti del suo output:

• /bin
• /sbin
• /usr/bin
• /usr/sbin

L'esempio seguente mostra un file di trojan:

S.5….T /bin/login

comando rpm -qa

Puoi usare il comando rpm -qa per mostrare l'ordine cronologico dei pacchetti installati di recente. Tuttavia, nel caso di una compromissione di root, anche il database rpm potrebbe essere compromesso.

comando lsattr

Se l'attaccante ottiene l'accesso come root e invia trojan a determinati binari, potrebbe rendere immutabili quei binari in modo che non sia possibile reinstallarne le versioni pulite. Controlla le seguenti directory:

• /bin
• /sbin
• /usr/bin
• /usr/sbin

L'esempio seguente mostra un file che un utente malintenzionato ha reso immutabile:

-------i----- /bin/ps
Under normal circumstances in these directories, the rules should all look similar to:

------------- /bin/ps

trova comando

find è uno strumento Unix che può essere fondamentale per trovare i file modificati di recente. Ad esempio, puoi trovare i file modificati negli ultimi cinque giorni eseguendo il comando seguente:

find / -mtime 5

Directory comuni per exploit web

Controlla le seguenti directory scrivibili in tutto il mondo in cui Apache® scrive comunemente file temporanei:

• ls -al /tmp
• ls -al /var/tmp
• ls -al /dev/shm

Cerca i file che non riconosci o che sembrano sospetti. Stai alla ricerca di file nascosti e file che dispongono di autorizzazioni di esecuzione.

Se hai impostato le autorizzazioni per le directory sul tuo sito Web su 777, controlla anche quelle.

Trova il punto di ingresso

Se trovi informazioni utili utilizzando gli strumenti nelle sezioni precedenti, potresti anche avere un timestamp di quando l'hacker ha installato il file oi file dannosi sul server.

Puoi utilizzare quel timestamp per rivedere i registri di accesso del tuo sito Web alla ricerca di voci sospette che sono state aggiunte durante quel periodo di tempo. Se trovi qualcosa di sospetto, puoi fare un riferimento incrociato con la posizione dei file dannosi per restringere il punto di ingresso.

Sebbene la maggior parte dei compromessi provenga da codice sfruttabile all'interno del tuo sito Web, non puoi escludere altri punti di ingresso. Assicurati di rivedere/var/log/* per tutto ciò che appare sospetto durante il periodo di tempo segnalato.

Esempio di indagine

L'indagine di esempio in questa sezione mostra il processo da utilizzare quando si indaga su una sospetta compromissione a livello di root.

Identifica il tipo di attacco

Verifica se si trattava di un hack web di base o se l'hacker ha effettivamente ottenuto i privilegi di root. Nella maggior parte dei casi, l'attacco è un semplice hack web che puoi pulire in sicurezza.

1. Esegui i seguenti comandi per determinare se l'attaccante ha ottenuto i privilegi di root:

   lsattr /usr/sbin | meno

   lsattr /usr/bin | meno

   lsattr /bin | meno

   lsattr /sbin | meno

2. Cerca gli attributi modificati, come i file binari che sono stati impostati su immutabile.

   Uscita:

    s---ia------- /sbin/shs
   

   Quando usi le strings comando su quel file, vedi che è una backdoorshell.

Controlla se l'attaccante ha pulito le sue tracce

In molti casi, gli aggressori sono inesperti o sciatti e non hanno cancellato le loro tracce. Utilizzare i seguenti passaggi per verificare se l'attaccante ha lasciato indizi:

1. Verifica che tutti gli account utente in /etc/passwd avere una shell valida eseguendo il seguente comando:

   gatto /home/$USER/.bash_history

2. Recupera la cronologia dell'utente root eseguendo i seguenti comandi:

   storia

   gatto /root/.bash_history

In questo esempio, l'output da /root/.bash_history comando rivela che l'attaccante ha eseguito le seguenti azioni sul server:

• Strumenti dannosi scaricati da pubblicare tramite Apache® in /var/www/html/* .
• Strumenti IRC (Internet Relay Chat) installati e altri strumenti in/var/tmp/.ICE-unix .
• Modificato il crontab di root per scaricare nuovamente gli strumenti dannosi se qualcuno li rimuove dal server (* * * * * /var/tmp/.ICE-unix/update >/dev/null 2>&1 ).

Cerca gli hack web di base

Fino a questo punto, abbiamo stabilito che l'attacco è probabilmente un semplice hack web che puoi pulire facilmente senza formattare il server.

Tuttavia, in questo esempio, sappiamo che l'hacker ha ottenuto i privilegi di root. Potrebbero anche aver sfruttato phpMyAdmin . Dopo il caricamento della shell PHP backdoor, l'attaccante è stato in grado di eseguire un exploit root locale per aumentare i propri privilegi.

1. Esegui i seguenti comandi per trovare file e directory nascosti nelle directory leggibili dal mondo in cui Apache scrive tipicamente tmp file:

   ls -al /var/tmp |meno

   ls -al /tmp

   ls -al /dev/shm

2. In questo esempio, i comandi restituiscono il seguente output:

   drwx—— 3 70 70 4096 19 nov 02:00 /var/tmp/.ICE-unix

3. Se trovi elementi qui, devi cercare di rintracciare il punto di ingresso in modo da poter rimuovere il sito, aggiornare il codice del sito o correggere in altro modo il codice sfruttabile. Il passaggio 5 presenta un modo rapido per eseguire questa attività. Tuttavia, se l'output di ps -waux il comando mostra che i bot IRC sono in esecuzione, quindi puoi provare a capire da dove viene eseguito il processo usando lsof comando ops -wauxxef |grep <pid> .

Cerca gli identificatori di processo che stanno ascoltando le connessioni in entrata

1. Esegui i seguenti comandi per cercare gli identificatori di processo (PID) che stanno ascoltando le connessioni in entrata:

• netstat -natp :cerca eventuali connessioni sospette in esecuzione su oddport

• ps -wauxxef :Cerca file sospetti, come bash in esecuzione sotto un www contesto

• lsof <pid> :aiuta a determinare da dove viene eseguito il PID

  L'output appare simile al seguente esempio:

    tcp 0 0 0.0.0.0:1144 0.0.0.0:* LISTEN 1008/bash
  
    tcp 0 1 172.16.23.13:60968 22.22.22.22:7000 SYN_SENT 6860/sshd
  

  In questo esempio, anche molte altre connessioni stabilite da SSH vengono eseguite da porte di alto livello, come mostrato nell'esempio seguente:

    [root@www tmp]# netstat -natp |grep sshd |awk '{print $4,$5,$6,$7}'
  
    0.0.0.0:22 0.0.0.0:* LISTEN 1046/sshd
  
    172.16.23.13:60986 22.22.22.22:6667 SYN_SENT 6860/sshd
  
    123.123.123.123:22 22.22.22.22:59361 ESTABLISHED 22795/sshd
  
    123.123.123.123:22 22.22.22.22:57434 ESTABLISHED 22796/sshd
  
    123.123.123.123:57139 143.143.143.143:6667 ESTABLISHED 6860/sshd
  
    123.123.123.123:57402 22.22.22.22:6667 ESTABLISHED 6860/sshd
  
    123.123.123.123:22 143.143.143.143:49238 ESTABLISHED 8860/sshd
  
    123.123.123.123:57134 22.22.22.22:6667 ESTABLISHED 6860/sshd
  
    123.123.123.123:56845 22.22.22.22:6667 ESTABLISHED 6860/sshd
  
    123.123.123.123:57127 143.143.143.143:6667 ESTABLISHED 6860/sshd
  

  Questo output indica che gli aggressori sono ancora collegati a questa macchina. Tuttavia, non puoi vederli perché probabilmente hanno modificato i binari per nascondersi.

Determina il punto di ingresso per il compromesso originale

Utilizzare i seguenti passaggi per determinare il punto di ingresso per il compromesso originale:

1. Controlla /var/log/[messages|secure] per tentativi SSH di forza bruta.

2. Controlla i log di accesso e i log degli errori di Apache. Questo passaggio potrebbe aiutare a determinare quale sito è sfruttabile.

   Dovresti anche fare un riferimento incrociato tra gli IP e i log se ritieni che ci sia la possibilità che possa aver avuto origine da lì. Questo è un modo rapido e diretto per risalire al punto di origine.

   Puoi controllare rapidamente i server che hanno un numero elevato di log web utilizzando i seguenti comandi:

   cd /var/log/httpd
   
   for i in `ls * |grep access`; do echo $i && grep wget $i; done
   
   for i in `ls * |grep access`; do echo $i && grep curl $i; done
   

   Nota :Questo esempio cerca wget perché wget era nel file history di root sotto quello che avrebbe potuto essere parte del punto di ingresso.

Risultato

In questo esempio, la nostra indagine ha rivelato che un utente malintenzionato ha sfruttato phpMyAdmin installazione nel /var/www/html directory, molto probabilmente a causa della versione diphpMyAdmin installato sul server era gravemente obsoleto. Applicazione di patch a phpMyAdmin un programma regolare impedisce che questa situazione si verifichi.