[Articolo] La guida definitiva per verificare se un server Linux è stato violato e metterlo 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 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:

• https://eforensicsmag.com/finding-advanced-malware-using-volatility/

---

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]

Hacking/sicurezza – Reati informatici in azienda

Ecco un interessante seminario gratuito che si svolge ad Empoli, in provincia di Firenze, il giorno 2 marzo 2011 a partire dalle ore 14:30. Di seguito è mostrato il programma dettagliato dell’evento:

La legislazione vigente in tema di reati informatici commessi in azienda
– Avv. Valentina Frediani (Studio Frediani) Il D.LGS 231/01 e la responsabilità amministrativa e penale delle aziende
– Avv. Valentina Frediani (Studio Frediani)L’Analisi Forense sui sistemi informatici
– Ing. Giuseppe Gottardi (Reply)

I modelli organizzativi e architetturali per la prevenzione e la gestione della sicurezza IT:
– i processi di ITIL per la sicurezza
Dott. Gionni Bernardini (Var Group)

– un modello per un’architettura di rete sicura
Dott. Elvino De Luca (Var Group)

Il seminario si rivolge alle seguenti figure professionali: Direzione dell’Organizzazione, Responsabili della Sicurezza, Responsabili della Qualità, Internal Auditor, Direzione IT, Direzione del Personale, Giuristi d’Impresa delle seguenti organizzazioni: Enti pubblici, Banche e Assicurazioni, Imprese industriali.

Il link alla pagina ufficiale dell’evento, con tutte le informazioni dettagliate e il modulo per l’iscrizione, è il seguente:

Reati informatici in azienda

Matteo

Security ed Anti-Forensic nell’ambito della rete aziendale

Al convegno e-privacy del 28 maggio 2010 mi ha particolarmente interessato una discussione riguardante le tecniche di anti-forensic presentata da Daniele Martini, alias cyrax. Le tecniche di anti-forensic sono tutte quelle tecniche, opposte alle forensic (o investigazioni forensi), che mirano a nascondere le informazioni e a proteggere i dati da potenziali controlli e investigatori.

Le tecniche presentate durante la relazione non sono state descritte nei dettagli, ma vogliono essere solo un pretesto per illustrare il panorama attuale in materia, e sono le seguenti:

• Artifact wiping
  Questa tecnica prevede la cancellazione dei dati utilizzando ad esempio più riscritture dei blocchi in memoria, da un minimo di 3, arrivando addirittura a 14 o anche molte più riscritture. Tuttavia esistono sistemi che permettono di recuperare i dati anche in seguito a numerose riscritture, e per questo motivo è consigliabile effettuare sempre un elevato numero di riscritture dei blocchi. L’eliminazione definitiva dei dati può passare anche da azioni “definitive” come la rottura fisica del dispositivo di archiviazione, oppure l’utilizzo di campi magnetici in modo da rendere illeggibile il contenuto. Tra le tecniche mostrate che permettono il recupero dei dati c’è stato il Cold Boot Attack (link1 e link2), che, lo ammetto, non avevo mai sentito nominare! E’ un particolarissimo tipo di attacco fisico (ossia l’attaccante deve avere accesso fisico al dispositivo bersaglio), in cui viene congelata la RAM e quindi tolta dal dispositivo. Il congelamento è necessario per permettere ai dati di rimanere in memoria alcuni minuti, dal momento che la RAM per definizione è un tipo di memoria volatile, in cui i dati vanno persi non appena il sistema viene spento.
• Data Hiding
  Questa è l’arte di nascondere le informazioni all’interno di “luoghi” improbabili, che si suppone non saranno controllati dall’eventuale indagatore. Tra queste tecniche vi è quella di celare i dati in determinati blocchi della memoria, per poi etichettarli come bad block, oppure in spazi riservati del filesystem (come ad esempio la directory /dev sui sistemi Linux), o ancora nello slack space.
• Encryption
  Il metodo “classico” per nascondere i dati, attraverso la cifratura dell’intero filesystem, o di determinate directory (viene citato come esempio il noto TrueCrypt). Infine viene discussa la tecnica della steganografia, l’arte di nascondere un messaggio in un determinato contesto, come l’occultamento di un testo in una foto o in un video/audio.
• Trail obfuscation
  Qui sono state discusse le tecniche per offuscare i dati come la modifica dell’hash di un file o degli attributi di un file (data modifica, ultimo accesso, …). Un’azione invece più deplorevole potrebbe essere di installare un po’ di diavolerie sul proprio sistema, come worm, virus o cavalli di troia, al fine di dire “non sono stato io perché ho preso un virus!”. In questo modo è possibile cercare di confondere chi vuole accedere ai dati e controllarli.
• Attacks against CF
  Questa categoria infine racchiude tutte le azioni che cercano di nascondere e/o rimuovere certi dati al verificarsi di particolari condizioni. Ad esempio potrebbero essere creati degli script che eliminano dei dati se viene effettuato il login da un certo utente, o se si verificano particolari procedure di avvio, o in alternativa potrebbe essere avviata una Virtual Machine. Un’altra tecnica, però molto pericolosa :-P, è anche quella di controllare la rete a cui è collegato il dispositivo, e nel caso cambi effettuare determinate operazioni.

L’intervento è liberamente distribuito e scaricabile dal sito del convegno e-privacy, sia come file pdf che come audio in formato mp3. Ecco il link:

e-privacy.winstonsmith.org/interventi.html#martini

Altrimenti il pdf è scaricabile direttamente dal seguenti link:

download pdf

roghan