SICUREZZA INFORMATICA

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

26 Nov 2019
D
Marco Di Muzio

Network Security Consultant


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.

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:

  1. indirizzo IP (o subnet) del mittente;
  2. indirizzo IP (o subnet) destinazione del pacchetto;
  3. protocollo del pacchetto;
  4. porta sorgente;
  5. 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=

MAC=00:0c:29:3f:0f:1e:f4:5c:89:b7:2c:89:08:00

SRC=192.168.86.65 DST=192.168.86.110 LEN=40 TOS=0x00

PREC=0x00 TTL=64 ID=129 PROTO=TCP SPT=65403 DPT=22

WINDOW=4096 RES=0x00 ACK URGP=0

Mar 18 18:27:41 dmzlab kernel: IN=ens160 OUT=

MAC=00:0c:29:3f:0f:1e:f4:5c:89:b7:2c:89:08:00

SRC=192.168.86.65 DST=192.168.86.110 LEN=40 TOS=0x00

PREC=0x00 TTL=64 ID=31938 PROTO=TCP SPT=49898 DPT=22

WINDOW=4096 RES=0x00 ACK URGP=0

Mar 18 20:26:25 dmzlab kernel: IN=ens160 OUT=

MAC=00:0c:29:3f:0f:1e:f4:5c:89:b7:2c:89:08:00

SRC=192.168.86.65 DST=192.168.86.110 LEN=64 TOS=0x00

PREC=0x00 TTL=64 ID=63522 DF PROTO=TCP SPT=57743 DPT=22

WINDOW=65535 RES=0x00 SYN URGP=0

Mar 18 20:27:52 dmzlab kernel: IN=ens160 OUT=

MAC=00:0c:29:3f:0f:1e:f4:5c:89:b7:2c:89:08:00

SRC=192.168.86.65 DST=192.168.86.110 LEN=64 TOS=0x00

PREC=0x00 TTL=64 ID=37753 DF PROTO=TCP SPT=57753 DPT=22

WINDOW=65535 RES=0x00 SYN URGP=0

Mar 18 20:37:25 dmzlab kernel: IN=ens160 OUT=

MAC=00:0c:29:3f:0f:1e:f4:5c:89:b7:2c:89:08:00

WEBINAR
Network e Security Automation: i vantaggi per le aziende
Sicurezza
Software

SRC=192.168.86.65 DST=192.168.86.110 LEN=64 TOS=0x00

PREC=0x00 TTL=64 ID=48005 DF PROTO=TCP SPT=57965 DPT=80

WINDOW=65535 RES=0x00 SYN URGP=0

Mar 18 20:37:25 dmzlab kernel: IN=ens160 OUT=

MAC=00:0c:29:3f:0f:1e:f4:5c:89:b7:2c:89:08:00

SRC=192.168.86.65 DST=192.168.86.110 LEN=64 TOS=0x00

PREC=0x00 TTL=64 ID=16288 DF PROTO=TCP SPT=57966 DPT=80

WINDOW=65535 RES=0x00 SYN URGP=0

Mar 18 20:37:25 dmzlab kernel: IN=ens160 OUT=

MAC=00:0c:29:3f:0f:1e:f4:5c:89:b7:2c:89:08:00

SRC=192.168.86.65 DST=192.168.86.110 LEN=64 TOS=0x00

PREC=0x00 TTL=64 ID=4327 DF PROTO=TCP SPT=57967 DPT=80

WINDOW=65535 RES=0x00 SYN URGP=0

Mar 18 20:37:27 dmzlab kernel: IN=ens160 OUT=

MAC=00:0c:29:3f:0f:1e:f4:5c:89:b7:2c:89:08:00

SRC=192.168.86.65 DST=192.168.86.110 LEN=64 TOS=0x00

PREC=0x00 TTL=64 ID=39602 DF PROTO=TCP SPT=57968 DPT=80

WINDOW=65535 RES=0x00 SYN URGP=0

Mar 18 20:37:27 dmzlab kernel: IN=ens160 OUT=

MAC=00:0c:29:3f:0f:1e:f4:5c:89:b7:2c:89:08:00

SRC=192.168.86.65 DST=192.168.86.110 LEN=64 TOS=0x00

PREC=0x00 TTL=64 ID=8476 DF PROTO=TCP SPT=57969 DPT=80

WINDOW=65535 RES=0x00 SYN URGP=0

Ho indicato Linux, ma per essere più precisi trattavasi di un CentOs7 che monta firewalld; altri moduli firewall potrebbero a loro volta generare log analoghi, ma diversi in alcune sottosezioni: ogni modulo firewall comunque (che si parli di Windows, Linux, Unix-like o di altri sistemi operativi) in genere dispone di una guida ufficiale (se non direttamente disponibile nel “man” o nelle guide online, verosimilmente si trovano guide pratiche pubblicate in community o nei forum dedicati a tematiche di netsec) e consente all’analista cyber (o, di nuovo, allo specialista di turno in Digital Forensics) di risalire al significato del messaggio trascritto nei log.

Tornando al nostro listato, poiché i messaggi contenuti nel log sono stati generati dal kernel del s.o., sono a loro volta stati inviati al servizio Syslog, in cui, come in ogni sua riga, riscontriamo data e orario seguiti dal nome breve del servizio tracciato. Nel listato di sopra possiamo notare che il nome del servizio è “dmzlab”. Per gli addetti ai lavori alcuni dei campi indicati nel listato sono autoesplicativi, mentre richiedono qualche spiegazione in più per il lettore meno “tecnico”:

  • IN/OUT: questi due valori indicano le interfacce utilizzate. Perché nel listato precedente non è presente alcun valore riferito all’OUT? Forse un errore di configurazione? No, semplicemente in questo caso non c’era una seconda interfaccia. Se il firewall avesse forwardato il pacchetto sarebbe stato presente anche il valore OUT, appunto indicativo dell’interfaccia verso cui il pacchetto sarebbe stato inoltrato.
  • MAC: acronimo di Media Access Control, è l’indirizzo utilizzato al secondo livello della pila ISO-OSI (nello slang tecnico, a questo valore ci si riferisce spesso come indirizzo “layer2”).
  • SRC/DST: indirizzi IP sorgente e, rispettivamente, destinazione del pacchetto.
  • LEN: lunghezza in byte del pacchetto.
  • TOS/PREC: il primo indicato il Tipo di Servizio, mentre l’altro se al pacchetto occorre dare precedenza. Tali valori vengono utilizzati se sui router è stata attivata una politica QoS (Quality of Servics).
  • TTL: TimeToLive, ossia il numero di hop che il pacchetto può ancora effettuare prima che sia considerato perso (di norma dovrebbe essere scartato).
  • ID: è un identificatore del pacchetto in transito, ed è utilizzato per la ricostruzione dei pacchetti frammentati.
  • DF: indica se è stato impostato il bit Don’t Fragment.
  • PROTO: impostato nell’header del pacchetto, indica il protocollo di trasporto utilizzato.
  • SDP/DPT: rispettivamente, la porta sorgente e destinazione del pacchetto.
  • WINDOW: numero di byte che possono essere trasmessi senza che venga trasmesso un messaggio di acknowledgement (ACK).
  • RES: bit riservati, che in genere non dovrebbero essere utilizzati.
  • SYN: indica che è stato impostato il bit del messaggio SYN.

Scontato scrivere che qualunque “storpiatura” continuativa dei valori in questi campi può essere un campanellino d’allarme non dico automaticamente di compromissioni dell’apparato o delle risorse protette dal firewall, ma sicuramente di situazioni che andrebbero analizzate con cura al fine di accertarsi se tecnicamente l’anomalia derivi da una cattiva configurazione dei device piuttosto che del servizio, da un aggiornamento software andato a male, o se appunto ci sia una volontà “esterna” di manipolare ad-hoc i byte diretti al target (esempio, un innovativo attacco informatico che sfrutti una particolare sequenza di messaggi in grado di causare veri e propri DDoS del servizio, o una sequenza volta a ispezionare eventuali servizi dormienti poiché attivabili solo tramite port knocking).

L’utilità dei log dei firewall per gli auditor ICT

Riflessioni dedicate agli auditor ICT: a fronte di un accesso al/ai firewall via CLI, c’è corrispondenza oraria nei log? Ergo, chi ha configurato il firewall, si è preoccupato – ad esempio – di impostare il tracciamento di tutte le interfacce attraverso cui un sistemista – o nel caso peggiore un attacker – può potenzialmente autenticarsi sul device? Altro quesito, si è certi che le uniche interfacce attraverso cui il sistemista possa accedere al firewall siano la porta SSH e l’interfaccia di management? L’accesso da console e quello tramite GUI (nel caso che il device in esame ne disponga) sono gli unici accessi possibili? E se invece (il protagonista di questi esempi è il sistemista oppure un attacker) chi si autentica lo fa tramite una chiamata REST, tale chiamata andata a buon fine viene tracciata nei log? E le chiamate invece non andate a buon fine?

Altro scenario: negli UTM che mettono a disposizione firewall virtuali (Fortinet ad esempio, ma non solo), le autenticazioni andate a buon fine alle interfacce esposte nei vari VDOM sono correttamente tracciate? Anche le VLAN interne sono realmente oggetto di logging?

Altre tematiche: le liste degli utenti a cui è stato assegnato un account per la gestione dei firewall sono ancora in azienda o hanno cambiato società? In questo secondo caso, il loro account è stato sospeso/eliminato? Le autenticazione alla rete tramite VPN vengono regolarmente tracciate nei log?

Gli eventi dei log dei proxy web

Lasciando gli UTM (sicuramente senza aver concluso esaustivamente né il discorso su tutte le funzionalità di un UTM, né le associate tematiche di logging aperte), possiamo ora parlare degli eventi dei log dei proxy web, altra classe di firewall, giacché trattasi comunque di apparati (o come nelle più contenute realtà SoHo, di appliance software) in grado di autorizzare o negare l’accesso degli utenti a risorse web a seguito di policy dette appunto, “di navigazione“.

I server proxy sono utilizzati in primis per conservare la banda disponibile per la navigazione (bandwidth), giacché mantengono copie locali delle risorse Internet a cui gli utenti accedono: ciò significa che quando un nuovo utente fa richiesta di una certa risorsa web, il proxy si occupa di verificare se al suo interno dispone già di una copia di quella medesima richiesta, e solo in caso negativo provvederà ad effettuare una nuova richiesta di quella risorsa (aggiornando quindi la propria “copia locale” che sarà archiviata per far a fronte a successive richieste) fornendo quindi all’utente tale risorsa aggiornata.

Altra feature dei proxy web è quella di essere configurabili con una lista dei siti autorizzati (o di quelli bannati – ossia di siti non navigabili dagli utenti – a seconda delle diverse scuole di pensiero).

Il seguente listato è estratto dai log di un proxy server piuttosto diffuso, Squid:

1489887470.182 623 172.30.42.12 TCP_MISS/302 1054 GET

http://s1133198723.t.eloqua.com/visitor/v200/svrGP? –

HIER_DIRECT/142.0.160.13 text/html

1489887470.526 701 172.30.42.12 TCP_MISS/200 455 GET

http://s1342121626.t.eloqua.com/visitor/v200/svrGP.aspx? –

HIER_DIRECT/142.0.160.13 image/gif

1489887470.851 667 172.30.42.12 TCP_MISS/200 455 GET

http://s1133198723.t.eloqua.com/visitor/v200/svrGP.aspx? –

HIER_DIRECT/142.0.160.13 image/gif

1489887470.875 18 172.30.42.12 TCP_MISS/200 1769 GET

http://media.wiley.com/spa_assets/R16B094RC8/site/wiley2/pvo/

images/favicon.ico – HIER_DIRECT/23.216.88.157 image/x-icon

1489887470.920 63 172.30.42.12 TCP_MISS/200 691 GET

http://nsg.symantec.com/Web/Seal/Dynamic.aspx? –

HIER_DIRECT/184.85.193.14 text/javascript

1489887471.225 369 172.30.42.12 TCP_MISS/200 621 GET

http://zn3lwsfwmnkphu1zr-wiley.siteintercept.qualtrics.com/

WRSiteInterceptEngine/? – HIER_DIRECT/23.206.197.230

application/javascript

1489887473.362 4199 172.30.42.12 TCP_TUNNEL/200 73998 CONNECT

script.hotjar.com:443 – HIER_DIRECT/23.111.9.32 –

1489887473.388 4218 172.30.42.12 TCP_TUNNEL/200 6278 CONNECT

vars.hotjar.com:443 – HIER_DIRECT/94.31.29.64 –

1489887477.631 8339 172.30.42.12 TCP_TUNNEL/200 3485 CONNECT

gtrk.s3.amazonaws.com:443 – HIER_DIRECT/52.216.18.128 –

1489887477.632 8339 172.30.42.12 TCP_TUNNEL/200 3485 CONNECT

gtrk.s3.amazonaws.com:443 – HIER_DIRECT/52.216.18.128 –

1489887481.198 11948 172.30.42.12 TCP_TUNNEL/200 470 CONNECT

logx.optimizely.com:443 – HIER_DIRECT/34.196.177.18 –

1489887481.198 11896 172.30.42.12 TCP_TUNNEL/200 655 CONNECT

www.google.com:443 – HIER_DIRECT/216.58.217.4 –

Dal listato è possibile notare delle richieste al sito web wiley.com e Google. Analizzando le attività elencate nel log, è interessante notare come alcune richieste sono indubbiamente il risultato di pagine web che sono state visitate dall’utente in precedenza, in relazione al motore analitico che ha avuto il compito di tracciare le attività degli utenti e l’utilizzo delle risorse web.

Hotjar.com, per esempio, consente ai webmaster che si iscrivono al servizio una miglior comprensione della fruizione dei propri siti da parte degli utenti che li visitano.

Non tutte le richieste che si leggono nei log dei proxy (in questo caso Squid, ma non solo) sono originate dagli utenti finali: molte, moltissime delle richieste HTTP/HTTPS non sono appunto generate manualmente dagli utenti, ma automaticamente da script collegati a motori di profilazione utente (altro esempio popolare è rappresentato da Google Analytics).

A tal fine, risulta fondamentale consultare le opportune guide ufficiali dei vari motori e moduli coinvolti, poiché tali richieste possono generare traffico di navigazione apparentemente non standard o comunque di interpretazione inusuale.

I log dei proxy possono essere sottoposti a strumenti di analisi e reportistica come Matomo (disponibile anche in versione freeware), di cui riporto una videata d’esempio:

Superfluo aggiungere che a questi grafici, così come ai valori numerici riportati in riga, possono essere agganciati script in grado di pilotare ban di vario tipo sulla navigazione degli utenti, nonché allarmi (e-mail, SMS ecc.) volti all’intervento tecnico di sistemisti e/o altri gruppi di lavoro coinvolti nel monitoraggio dei sistemi dedicati alla navigazione degli utenti.

I Web Application Firewall: cosa sono e a cosa servono

Mentre i proxy monitorano la navigazione degli utenti al fine di conservare un bandwith tale da consentire un’appropriata e tempestiva fruizione dei servizi Internet, i Web Application Firewall (WAF) sono utilizzati per proteggere i servizi esposti.

A differenza dei proxy (che essenzialmente bloccano il traffico in uscita dalla rete), i WAF filtrano il traffico in ingresso.

Tali sistemi sono generalmente utilizzati in accoppiata a firewall perimetrali, che non sempre dispongono di funzionalità di network security layer7 (essenzialmente a livello applicativo). Ispezionando il traffico in ingresso, i WAF verificano la presenza di chiamate malformate o di determinati pattern riconducibili ad exploit. Analogamente ai firewall e ai proxy, i WAF si basano su regole. Le firme (“signatures”) sono utilizzare per mappare un certo tipo di attacco.

Non ci dilungheremo sui vari WAF disponibili sul mercato (per un elenco di alcuni dei vendor commerciali più diffusi è possibile consultare questa pagina), ma ci limiteremo ad analizzare il seguente file di log, estratto da uno dei più diffusi WAF open-source:

–d480d20a-A–

[09/Oct/2019:22:30:24 –0500] WKpivH8AAQEAAUwA904AAAAH

192.168.86.65 57575 192.168.86.83 80

–d480d20a-B–

OPTIONS /security.php HTTP/1.1

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:42.0)

Gecko/20100101 Firefox/42.0

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-US,en;q=0.5

Referer: http://192.168.86.83/security.php

Cookie: PHPSESSID=e945t3jli2psaes0klfd7upnl2; security=impossible

Connection: keep-alive

Content-Type: application/x-www-form-urlencoded

Content-Length: 77

Host: 192.168.86.83

–d480d20a-F–

HTTP/1.1 500 Internal Server Error

Content-Length: 532

Connection: close

Content-Type: text/html; charset=iso-8859-1

–d480d20a-E–

<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>

<html><head>

<title>500 Internal Server Error</title>

</head><body>

<h1>Internal Server Error</h1>

<p>The server encountered an internal error or misconfiguration and was unable to complete

your request.</p>

<p>Please contact the server administrator at webmaster@localhost to inform them of the time this error occurred, and the actions you performed just before this error.</p>

<p>More information about this error may be available in the server error log.</p>

</body></html>

–d480d20a-H–

Message: Error reading request body: Partial results are valid but processing is incomplete

Apache-Handler: application/x-httpd-php

Stopwatch: 1487561404207982 20005648 (- – -)

Stopwatch2: 1487561404207982 20005648; combined=770, p1=762, p2=0, p3=1,

p4=0, p5=6, sr=203, sw=1, l=0, gc=0

Response-Body-Transformed: Dechunked

Producer: ModSecurity for Apache/2.9.0 (http://www.modsecurity.org/);

OWASP_CRS/2.2.9.

Server: Apache/2.4.18

Engine-Mode: “DETECTION_ONLY”

–d480d20a-Z–

In questo listato Modsecurity (disponibile di default con il webserver Apache, ma anche su IIS e Nginx) notiamo che è utilizzato un formato log suddiviso in più parti.

Ogni sezione ha un differente scopo, sicché non tutte le sezioni sono popolate a fronte di una determinata chiamata. Le sezioni presenti in questo esempio sono la A, B, F, E, H e Z.

La linea –d480d20a-A– indica l’inizio della sezione A; le altre sezioni del log sono distinguibili dal fatto che si presentano col medesimo header (–d480d20a- nell’esempio) ma con l’ultima lettera differente. La sezione A riporta eventi di audit, comprensivi di timestamp. La sezione B è l’header richiesto dal client (è il messaggio HTTP inviato, senza i dati inviati fuori dall’header). La sezione F mostra l’header di risposta: in questo esempio al client è stato restituito un classico “internal server error”. La sezione E è relativa alla F, ed include informazioni aggiuntive: in questo esempio possiamo leggere il contenuto dell’intera pagina HTML che è stata restituita al client. La sezione H mostra informazioni diagnostiche affini a ciò che è accaduto: l’header stopwatch, ad esempio, comunica informazioni di stato relative alle performance del webserver, inoltre, veniamo informati dell’esatta versione di Modsecurity in uso, ma anche che il medesimo modulo sta utilizzando un set di regole (CRS) rilasciate dalla community OWASP; infine, leggiamo che il modello di rilevamento applicato è detection-only, che sta a significare che se Modsecurity dovesse riscontrare delle anomalie, si limiterà a comunicarlo nel file di log, senza compiere azioni di contenimento.

Bibliografia e letture di approfondimento consigliate:

  • Critical Log Review CheckList for Security Incidents, SANS Institute
  • ModSecurity Handbook
  • Dmitry Sklyarov, Hidden Keys to Software Break-Ins and Unauthorised Entry
  • Syslog-ng Open Source Edition Administration Guide
  • Andrew Douma, Penetration Testers’ Guide to Windows Privacy & Security
  • Ric Messier, Network Forensics
  • Bettany e Warren, Configure Windows Firewall with Advanced Security
  • William Stallings, Cryptography and Network Security Principles and Practices
FORUM PA 6 - 11 LUGLIO
Costruire la fiducia digitale: cybersecurity e privacy
Network Security
Privacy

@RIPRODUZIONE RISERVATA

Articolo 1 di 5