Il server Linux è stato violato… mettiamolo in sicurezza!


Difficoltà articolo (0->10): 8

Requisiti: conoscenza intermedia della shell di Linux, e hardening di un sistema.

Sospettiamo che il nostro server Linux sia stato violato? Abbiamo notato processi o attività strane? Vediamo in questo primo articolo come identificare un server Linux che è stato compromesso, e come cercare di ripristinare la situazione e chiudere fuori gli intrusi.

Partiamo dal presupposto che ad essere esposti a questo problema sono soprattutto i server che pubblicano servizi e applicazioni all’esterno (server web, ftp, …), e ancora più presi di mira sono i server messi a disposizioni dai principali provider del settore (Aruba, Register, OVH, …). I server di questi provider sono infatti presi di mira in modo massivo, e quotidianamente sono soggetti a tentativi di attacco su tutti i servizi e porte standard (ssh, http, …). Il motivo è semplice: ogni provider ha a disposizione determinati range di IP, dunque per un attaccante, chiunque esso sia (persona fisica o bot) è sufficiente eseguire degli scan e attacchi su questi range selezionati. Ad esempio, questi sono alcuni range che appartengono al noto OVH:

  • 142.4.192.0/19
  • 149.56.0.0/16
  • 158.69.0.0/16

Inoltre, preciso che buona norma per un server compromesso, sarebbe quello di radere tutto al suolo, reinstallato da zero sistema operativo e servizi. Questa pratica non è tuttavia sempre praticabile, poiché spesso sul server sono eseguiti applicativi fondamentali aziendali o per clienti, e la prima soluzione è invece quella di cercare di ripristinare il sistema ad uno stato consistente e sicuro.

Dunque, veniamo in dettaglio ai controlli da effettuare su un server che ipotizziamo essere stato compromesso.


1. Servizi in ascolto e porte aperte

Controlliamo i servizi attivi e le porte sui quali sono in ascolto:

# netstat -tulpn
# ss -nap

Devono indurre sospetto servizi in ascolto su porte non standard e soprattutto porte alte, tipicamente dalla 40000 in su, ad esempio:

# netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
[...]
tcp 0 0 100.100.100.100:51553 0.0.0.0:* LISTEN 410/theerhd
[...]

Per controllare che non ci siano eventuali servizi nascosti usare poi il seguente tool:

# unhide-tcp
Unhide-tcp 20121229
Copyright © 2012 Yago Jesus & Patrick Gouin
License GPLv3+ : GNU GPL version 3 or later
http://www.unhide-forensics.info
Used options: use_fuser
[*]Starting TCP checking
[*]Starting UDP checking

Nel caso sopra, l’output è normale, nel senso che non sono stati rilevati servizi nascosti in ascolto, quindi possiamo stare tranquilli.


2. Processi attivi

Controlliamo tutti i processi in esecuzione:

# ps -ef

e l’albero dei processi attivi con relativi pid:

# pstree -pa

Il comando seguente, come nel punto precedente, può rilevare eventuali processi malevoli nascosti:

# unhide proc
# unhide sys
# unhide brute

Devono indurre sospetto eventuali processi con nomi strani (thweih43, lpevntw, 6oetheq, …), processi di cui non riconosciamo l’origine, o processi nascosti, come:

# unhide sys
[...]
Found HIDDEN PID: 256 Wchan: "[34ljyjil]"

3. Scansioni alla ricerca di malware

Installiamo il software rkhunter, per trovare eventuali trojan o malware in esecuzione.

Possiamo trovare una guida completa e ben fatta a questo link, perché la spiegazione di utilizzo del tool richiederebbe un intero articolo…


4. Ultimi accessi al sistema e utenti collegati

Facciamo un controllo sugli ultimi utenti che si sono collegati al sistema:

# last

e quali sono gli utenti attualmente collegati:

# who

Ovviamente, in questo caso dovrebbero far pensare eventuali connessioni di utenti non riconosciuti, oppure connessioni che sappiamo per certo non essere state fatte da noi.


5. Utenti attivi nel sistema

Controlliamo tutti gli utenti definiti all’interno del sistema:

# cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
admin:x:1000:1000:,,,:/home/admin/:/bin/bash
[...]

Indice di sospetto dovrebbe essere la presenza di utenti nuovi non noti, o con nomi sospetti (come ad esempio l’utente admin nell’output precedente). Facciamo attenzione però, perché l’output del comando precedente può essere più o meno lungo, e può contenere anche molti utenti che potrebbero destare sospetti ma che in realtà sono utenti di sistema! Tipicamente, gli ultimi utenti ad essere stati creati sono aggiunti alla fine del file, quindi dobbiamo concentrarci su quelli.


6. Ultimi reboot del sistema

Controlliamo da quanto tempo è in esecuzione il server:

# uptime
 15:47:02 up 143 days, 12:07, 1 user, load average: 0,00, 0,00, 0,00

quando è stato fatto l’ultimo reboot:

# who -b
 system boot 2016-12-15 02:40

e il momento esatto di tutti gli ultimi reboot:

# last reboot
reboot system boot 2.6.15.4 Sun Apr 30 15:08 - 16:22 (01:13)
[...]

7. File modificati recentemente

Verifichiamo quali file sono stati modificati negli ultimi giorni (7-10 giorni):

find / -mtime -7

Facciamo attenzione che l’output del comando seguente potrebbe essere lungo e potrebbe impiegare tempo a essere visualizzato interamente. Eventualmente possiamo diminuire il numero di giorni, se si sospetta che l’attacco sia stato fatto da pochi giorni.


8. Analisi dei file di log

Esaminiamo i file di log (come sempre importantissimi), e in particolare i messaggi del kernel:

# dmesg

gli ultimi log di sistema:

# cat /var/log/syslog

 

Controlliamo gli accessi falliti su ssh, /var/log/auth.log in Debian e derivate, /var/log/secure in Red Hat e derivate.

(Debian e derivate)
# cat /var/log/auth.log

(Red Hat e derivate)
# cat /var/log/secure

Potrebbe essere importante esaminare anche i log di eventuali servizi in ascolto, qualora presenti, tipo server web.


9. Tool di auditing

Lanciamo un tool completo di auditing, come sysdig, seguendo le istruzioni di una delle seguenti guide:


10. Dump della memoria e analisi approfondita del sistema

Qualora nei punti precedenti avessimo rilevato la presenza reale di una minaccia, o di qualche intrusione, è bene approfondire l’analisi con tool specifici, come ad esempio volatility.

Possiamo trovare una guida ben fatta al seguente link:

 

roghan

Annunci

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...