Log dei firewall: usiamoli per monitorare le attività di rete e individuare tracce di eventuali cyber attacchi

Nelle moderne reti “real time” i log dei firewall possono essere molto utili a monitorare e regolarizzare il traffico e le attività sulla scheda di rete, ma anche a fornire utili evidenze durante le investigazioni a seguito di attacchi informatici. Ecco una guida pratica per gestirli al meglio

Imparare a “leggere” i log dei firewall può essere utile oltre che a monitorare e regolarizzare il traffico e le attività sulla scheda di rete su cui sono operativi, anche a fornire utili evidenze durante le investigazioni a seguito di attacchi informatici.

Una delle sfide aperte della cyber security, infatti, è che qualunque cosa attraversi la Rete scompare nel momento stesso in cui l’attraversa. Una scheda di rete non “storicizza” i pacchetti che hanno attraversato le sue interfacce un mese fa, ma neanche un minuto fa.

Con un’analogia, le schede di rete (che siano wireless o wired non fa differenza) attuano un processo inverso rispetto a quello attuato dagli hard drive, che nascono appunto per “memorizzare” cumulativamente informazioni.

Indice degli argomenti

Sistemi di logging: cosa sono e come funzionano

Per questo motivo le moderne reti si definiscono “real time”: nulla di ciò che è stato, che è indietro si conserva una volta che i pacchetti di dati sono giunti a destinazione. Questo complica le investigazioni a seguito di attacchi informatici, a meno che non si adottino infrastrutture dedicate alla memorizzazione degli accessi e delle connessioni che si sono instaurate nel tempo tra i vari nodi della rete (client compresi).

Mentre i pacchetti vengono consegnati a destinazione, dispositivi configurati ad hoc possono memorizzarne l’origine, la destinazione, la tipologia e altri metadati informativi fondamentali per “tracciare le connessioni” instauratesi tra client e server (connessioni che non necessariamente significano “navigazione”).

Salvo connessioni su stessi (il classico localhost, o 127.0.0.1, o appunto auto-connessioni), le connessioni di rete non sono un’isola. L’origine e il termine delle connessioni di rete sono le applicazioni, client da una parte e server dall’altra. Se raramente i client alimentano in automatico dei file di log, i processi server lo fanno quasi sempre, anche se i dettagli dipendono dal sistema operativo – nonché dalla versione sia del server che dell’evento – su cui sta girando l’applicativo a cui siamo interessati.

Tra i log del sistema operativo e i log degli “hop” che il client ha dovuto superare – prima d’instaurare una connessione di rete con il server su cui gira l’applicativo – è opportuno memorizzare una serie di metadati volti ad agevolare gli analisti e i tecnici chiamati a gestire l’anomalia e/o il vero e proprio incidente informatico.

Microsoft Windows e Linux, due tra i principali sistemi operativi usati globalmente lato server, forniscono sottosistemi in grado di tracciare le attività delle applicazioni e degli utenti. I sistemi Windows utilizzano di default lo snap-in denominato Event Viewer, mentre i sistemi Linux mettono a disposizione il servizio Syslog (ma anche rsyslog e/o syslog-ng, a seconda delle versioni stesse del sistema operativo e delle scelte architetturali).

Non tutte le applicazioni server loggano di default sui servizi menzionati: molto spesso, servizi legati al web possono utilizzare un sistema di logging interno, peraltro con un formato proprietario. Altri device, come per esempio gli UTM (Unified Threat Management), possono loggare in diversi formati a seconda del vendor (un caso non comune è ad esempio quello dei firewall Check Point e del logging tramite protocollo OPSEC).

Ciononostante, se i sistemi di logging da una parte si differenziano per formati che non sempre risultano uniformi, dall’altra hanno in comune il (non trascurabile) fatto che si tratta sempre e comunque di uno stream testuale: un flusso di caratteri che consente non solo a chi di competenza di leggere visivamente il file di testo oggetto di analisi, ma anche e soprattutto di poter impostare allarmi e istruire script al verificarsi di un certo pattern, o nel caso contrario, al verificarsi dell’assenza di un certo pattern per un dato tempo “t”.

Syslog: il protocollo di rete per la trasmissione di file log

Syslog nacque come componente di sendmail, servizio per il trasferimento per la posta elettronica in ambiente Unix, ma presto la sua semplicità e praticità lo portarono alla ribalta per un impiego generalizzato. Tuttavia, questa genesi fece sì che vi fossero varie implementazioni indipendenti, spesso incompatibili tra loro. Tutt’oggi, nonostante il fallimento della specifica formale del protocollo inizialmente prevista nel 2005, vi è una grande diffusione di questo standard, anche per il diffondersi di apparati connessi a sempre più reti, e quindi necessitanti di verifiche e monitoraggio.

Syslog viene generalmente utilizzato su protocollo UDP attraverso la porta 514 (il numero di porta è chiaramente customizzabile); in applicazioni e infrastrutture dove il monitoraggio risulta critico, oppure in contesti in cui certi eventi possono pilotare azioni da parte del Syslog server, si ricorre ad implementazioni TCP e/o a crittografia.

Il servizio Syslog offre numerose opzioni, ma le impostazioni fondamentali riguardano le facility e le severity. Le prime rappresentano una sorta di organizzazione per categorie dei messaggi di log, che specificano il sottosistema che ha generato il messaggio.

Ad esempio, tutti i programmi che gestiscono la posta e che utilizzano il servizio Syslog per il logging dovrebbero usare la facility “mail”. I messaggi generati non vengono scritti direttamente sui file di log, bensì passati ad un apposito servizio, syslogd, che si occupa di gestirli.

In base appunto ai valori di facility e priority è possibile scegliere, usando opportune regole configurabili dall’amministratore di sistema (AdS d’ora in poi nel testo), in quale path dirigere l’output dei diversi messaggi.

Il tipo e la quantità degli eventi generati variano da programma a programma, e possono in molti casi essere cambiati utilizzando degli appositi selettori (da linea di comando) con cui si esegue il programma stesso. Nel caso dei daemon che gestiscono servizi Internet, questo aspetto va tenuto in seria considerazione in quanto sono servizi accessibili anche da persone all’esterno dell’host su cui gira il servizio stesso.

Le facility definite nella RFC (Request for Comments) 5424.

In aggiunta alle facility, il servizio Syslog adotta le severity per “categorizzare” i messaggi in arrivo. Le applicazioni possono generare un “numero di livello” nei messaggi in base a ciò che sta succedendo nell’applicazione stessa: ad esempio, di default un’applicazione può inviare messaggi informativi al solo scopo di segnalare l’inizio stesso del logging.

L’elenco delle severity del servizio Syslog.

Sfogliando la RFC 5424 è possibile riscontrare che Syslog definisce una priorità sommando il codice della facility moltiplicato per 8, e successivamente aggiunge il codice della severity. Il numero più basso avrà la priorità maggiore. Esempio: se nel caso di kernel panic il sistema operativo genera un messaggio d’emergenza, si otterrà uno 0 come numero risultante (0*8 + 0); infatti, ogni messaggio d’emergenza relativo al kernel dovrebbe sicuramente avere priorità rispetto agli altri messaggi.

Poiché non è definito alcuno standard relativamente a quali sono i file utilizzati per loggare i messaggi, occorre riferirsi al file di configurazione del daemon syslog in base alla distribuzione *nix su cui si sta lavorando.

La seguente immagine mostra parte di una configurazione rsyslog di un server Arch Linux:

Si noti come tutti i file di log sono nella directory /var/log. Sebbene non sia un requisito, è una convenzione piuttosto diffusa quella di rendere più facilmente ricercabili i file di log. Lo standard FHS (Filesystem Hierarchy Standard) è utilizzato nella maggior parte dei sistemi Linux e *nix. La notazione usata nella precedente tabella è facility.severity.

Lì dove è presente il carattere *, significa che si sta utilizzando una wildcard che matcha tutti i valori disponibili: ad esempio nella linea in cui è indicato lpr.*, syslog scriverà in /var/log/lpr.log tutti gli output generati da ogni severity; ciò indica appunto che qualunque evento generato con quella facility sarà tracciato su file.

Si può essere più granulari, chiaramente. Ad esempio, in mail.info è stato scelto di loggare tutti i messaggi “informativi” relativi alla posta elettronica, mentre gli errori verranno salvati nel file mail.err

Nell’immagine che riporta la configurazione di rsyslog, i nomi dei file sono piuttosto descrittivi. I messaggi relativi al servizio di posta elettronica sono salvati in file che iniziano per “mail”, e che hanno appunto qualche aggiunta nel nome del file.

Log dei firewall: cosa sono e a cosa servono

Fatta questa doverosa premessa sul servizio Syslog, possiamo ora trattare i log dei firewall, che nella maggior parte dei casi sono in grado di esportare i propri eventi su di un flusso syslog.

Esistono numerosi vendor di firewall, nonché diverse tipologie. Semplificando possiamo dire che ci sono firewall “network-based” (definibili anche come UTM per gli addetti ai lavori) e “host-based”.

I firewall basati su host monitorano e regolarizzano il traffico e le attività sulla scheda di rete su cui sono operativi: a tal proposito, sul mercato si possono trovare endpoint multifunzione (aventi cioè più feature, ossia maggiori funzionalità di monitoraggio della pila ISO-OSI, e mettendo appunto al servizio degli host su cui sono installati, tutta una serie di controlli e verifiche applicative impostate nella manager centralizzata e gestita dall’amministratore della piattaforma) in grado di offrire capacità di firewalling, sebbene l’intero pacchetto applicativo non sia appunto esclusivamente un modulo firewall (a tal proposito è possibile consultare i datasheet degli endpoint Symantec e Kaspersky, giusto per citare due vendor piuttosto diffusi di questo tipo di soluzioni).

Gli UTM, invece, nella maggior parte dei casi risultano veri e propri apparati di rete composti da un box fisico, oppure virtualizzati all’interno di un bare-metal (su hardware che dovrà essere ben carrozzato per supportare l’analogo calcolo computazionale (ad esempio il numero di sessioni NAT gestibili al secondo) del box fisico), posti in un opportuno segmento di rete a vigilanza del traffico in transito tra le sue varie schede di rete (che possono essere N, a differenza dei più comuni firewall “host based”, in genere installati su workstation che montano al più una scheda di rete) dietro cui possono esserci altrettante reti con uno o più host, con la necessità di dialogare su Internet e/o verso altre reti collegate (come primo “hop”) ad una delle interfacce di rete del firewall.

Senza entrare nel merito delle scelte architetturali relativamente a quali siano le più opportune combinazioni per il posizionamento di firewall e IDS/IPS, facciamo un passo indietro parlando dei firewall stateless: essenzialmente stiamo parlando di access-list, ossia di semplici regole cablate dall’amministratore del firewall, che determinano se un certo traffico di rete possa o non possa transitare attraverso le interfacce disponibili, in base appunto ad un “pattern” distinto da:

indirizzo IP (o subnet) del mittente;
indirizzo IP (o subnet) destinazione del pacchetto;
protocollo del pacchetto;
porta sorgente;
porta destinazione.

Perché nel 2019 si parla ancora di firewall stateless? Perché sono ancora numerosissime le installazioni in produzione (workstation con una distribuzione Linux dedicata al networking, server di frontiera con una doppia scheda di rete, o semplicemente reti di PMI collegate a vetusti apparati con a bordo poche regole di iptables e/o di IoS configurate magari anni prima) in cui si adottano soluzioni basate su modulini di firewall stateless, peraltro senza una reale management centralizzata, né un annesso sistema di monitoraggio.

Un firewall deep-packet è in grado di analizzare il pacchetto in maniera ben più approfondita che un firewall stateless o statefull: analizza il traffico fino all’ultimo livello della pila ISO-OSI (ossia al settimo livello, motivo per cui molto spesso ci si riferisce a questo tipo di apparati come firewall layer7), ergo analizza anche il payload del pacchetto, non limitandosi quindi all’header (“intestazione” di un pacchetto TCP-IP).

Il tutto richiede chiaramente un elevato carico computazionale (motivo per cui i firewall di questo tipo sono in genere scelti con grande cura anche alla luce del throughput che è stato pattuito con il cliente), e motivo per cui i firewall di questo tipo sono generalmente molto più costosi.

Perché i log dei firewall sono utili all’analista cyber

Al di là del device in esame, al lettore risulterà palese quanto i log dei firewall (non solo relativi alle connessioni instaurate tra host e host (nel caso di moduli firewall “host-based”), nonché tra client Internet e sottoreti protette dal firewall, ma anche i log relativi alle autenticazioni verso le porte di management del firewall stesso) siano fondamentali per l’analista cyber quanto per un CTU/CTP chiamato ad eseguire una perizia informatica a seguito di un contenzioso legale che abbia a che fare con sistemi o servizi informatici oggetto di accesso abusivo da Internet o da sottoreti attraverso cui il servizio o il sistema è raggiungibile (è un luogo comune pensare agli accessi abusivi ad un sistema informatico – e in generale agli attacchi informatici – come solo a quelli provenienti da Internet).

Ad esempio, nella sola città di Roma, alle ore 19:33 del 30 settembre 2019 (orario in cui sto editando l’articolo), risultano ben 2.030 gli host indicizzati da Shodan che hanno la porta 3389 (tipicamente associata ad un servizio RDP) raggiungibile potenzialmente da chiunque (worm compresi).

Shodan offre diversi parametri di ricerca: un paio veramente “preoccupanti” riguardano la possibilità di effettuare ricerche tramite coordinate (geo) e tramite l’hash dei banner (in videata mi sono limitato ad una mera ricerca riguardante la combinazione delle tre hotkeys city, country e port).

Ci sono firewall a protezione di questi host? Ad esempio, le autenticazioni e (soprattutto) gli iterati tentativi di autenticazione non andati a buon fine (riassumo l’immediata precedente frase con una parola chiave: bruteforcing) diretti verso il servizio RDP vengono regolarmente loggati tra gli eventi del servizio Windows Firewall e – nel caso invece di un tipico host Linux – tra gli eventi tracciati dal servizio iptables/Fail2Ban? I log del firewall, vengono analizzati da una qualche sonda preventivamente istruita (e aggiornata) con precise policy di alerting e remediation?

Un piccolo esempio di come sia fondamentale predisporre una chiara e precisa catena di logging dal punto A (nelle architetture più scontate, il firewall o la catena di N-firewall esposti su Internet a protezione delle risorse aziendali) al punto Z (autenticazione finale dell’utente che fruisce con successo del servizio “protetto” non solo dai firewall di frontiera ma anche da quelli locali al server, sia essa una sessione RDP, FTP, SMB, HTTPS ecc.) al fine di poter ricostruire celermente lo scenario dell’intrusione o del tentativo d’intrusione sotto esame, nonché degli attori coinvolti.

Perché preoccuparsi dei log dei firewall nello scenario illustrato dalla videata di Shodan? Perché nel caso di un accesso abusivo dall’esterno tramite autenticazione andata a buon fine verso il servizio RDP di un qualche server interno, ammesso che il servizio RDP stesso non sia stato oggetto di logging, sicuramente la connessione dell’attaccante è transitata attraverso un UTM, o un router/firewall di frontiera (accedendo a questa URL è possibile leggere un elenco non esaustivo di distribuzioni Linux dedicate a soluzioni di firewalling; mentre qui è possibile consultare un elenco degli UTM più diffusi secondo Gartner MQ) oppure attraverso l’interfaccia di rete di server esposti direttamente su Internet (sì, c’è ancora chi lo fa) senz’alcuna DMZ.

Il seguente listato tratto da una sessione Syslog, mostra gli eventi generati da un firewall operativo all’interno di un host Linux:

Mar 18 15:13:23 dmzlab kernel: IN=ens160 OUT=