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 principali file di log (come sempre importantissimi), e in particolare i messaggi del kernel:
# dmesg
e gli ultimi log di sistema:
# cat /var/log/syslog
Controlliamo gli accessi falliti su SSH, soprattutto nel caso in cui il server sia esposto direttamente su Internet, verificando il file /var/log/auth.log in Debian e derivate, e /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 quelli dei server web (/var/log/apache/error.log e /var/log/apache/access.log per Apache, …).
9. Tool di auditing
Lanciamo un tool completo di auditing, come sysdig, seguendo le istruzioni di una delle seguenti guide:
- https://github.com/draios/sysdig/wiki/Sysdig%20Examples
- https://sysdigcloud.com/fishing-for-hackers-part-2/
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:
11. Controllare cron e crontab
E’ importante controllare che non siano presenti script o comandi non noti schedulati all’interno del sistema tramite il servizio crond. Pertanto, è necessario verificare sia il file crontab, per tutti gli utenti di sistema, non solo per root, con il seguente comando:
# crontab -l
Il comando mostrerà eventuali comandi o script schedulati a giorni oppure ore particolari. Prestare dunque attenzione alla presenza di tutto ciò che non abbiamo apertamente configurato.
Analogamente, sarà necessario controllare all’interno di tutti gli altri percorsi usati dal demone crond, tra cui:
- /etc/cron.d
- /etc/cron.daily
- /etc/cron.weekly
- /etc/cron.monthly
- /etc/cron.hourly
roghan
[aggiornamento 16/09/2020]
Ombre sul Web 