No results found
Non si può negare che la cybersecurity è diventata argomento di grande attualità e rilevanza e tutto quel che concerne l’identificazione, la prevenzione e lo studio delle metodiche di attacco informatico è seguito con vivo interesse dagli operatori IT, dagli amministratori di sistema e da chi opera nel Cloud.
In questo tutorial affronteremo la materia con un focus particolare sui sistemi difensivi e sulle tecniche con le quali ci si può difendere dagli attacchi informatici e descriveremo in generale le metodologie che si possono applicare; quindi ci concentreremo più su aspetti di difesa che di attacco e relativa simulazione, vale a dire che non andremo conoscere le vulnerabilità che sfruttano gli attaccanti per penetrare in un sistema IP (gli interessati possono trovare in questo sito tutorial e video sulla materia) ma più che altro sulle metodologie che possiamo mettere in pratica per difenderci da attacchi anche al momento non noti e quindi attacchi she sfrutterebbero vulnerabilità che fino a quell’istante non sono note.
Studieremo sistemi e metodologia difensiva basati sull’intercettazione degli attacchi informatici, che rappresenta un’utilissima arma di difesa che ogni operatore IT, sviluppatore e sistemista deve conoscere almeno a livello generale, perché nella progettazione di un sistema informativo bisogna tenere conto ovviamente degli aspetti legati alla sicurezza.
Al di là delle considerazioni banali, siamo in qualche modo bombardati da termini legati alla cybersecurity perché il tema è entrato a far parte della cultura di massa e il motivo è che, essendo il il mercato in continua crescita, da una parte i sistemi informativi diventano sempre più complessi sia dal punto di vista software che dal punto di vista architetturale e quindi la “superficie di attacco” esposta agli hacker aumenta inevitabilmente e dall’altra perché tutti i sistemi IT sono ormai interconnessi in quanto oggi la rete esternamente pervasiva (basti pensare all’IoT e ai suoi dispositivi, anch’essi soggetti alle vulnerabilità che ormai purtroppo conosciamo).
Non solo il mercato IT è in crescita per i motivi che abbiamo appena esposto, ma in particolare la spesa per la cybersecurity è in continua crescita e ciò è una naturale conseguenza. Il grafico proposto nell’immagine seguente mostra la crescita della spesa per cybersecurity che ad oggi è 173 miliardi di dollari USA, prevede un target di 273 entro il 2026.
Un elemento che può dare una misura di quanto il tema sia sentito e rilevante è che esiste una classificazione delle vulnerabilità che viene fatta e mensilmente e dalla quale risulta che mensilmente per il 2020 sono state scoperte circa 1.500 vulnerabilità al mese; questo dato che in prima battuta ha un’accezione negativa, in realtà è un aspetto positivo perché significa che sempre più persone operano nel mercato della cybersecurity e vanno alla ricerca di vulnerabilità per correggerle prima che possano essere sfruttate da potenziali attaccanti. In breve, scoprire le vulnerabilità significa che qualcuno le cerca e le studia; se non venissero classificate, potrebbe voler dire che esistono ma nessuno lo sa e questo è peggio.
Prima di vedere gli strumenti utilizzabili per intercettare gli attacchi informatici occorre precisare che chi è responsabile di una determinata infrastruttura, sia essa la piccola rete di una PMI o un sistema informativo di grosse dimensioni, non può esimersi dal conoscere almeno per grandi linee qual è la superficie di attacco, da dove può arrivare l’attacco, in che modo la rete può essere vulnerabile.
In quest’ottica, uno strumento molto semplice con il quale si può fare un audit per esempio per comprendere e documentare le caratteristiche della nostra rete e classificare le vulnerabilità è il Risk Assessment (una sorta di inventario del rischio) e di fatto un output del Risk Assessment nel caso della cybersecurity è il Threat Model, che consiste in una descrizione delle vulnerabilità che caratterizzano il nostro sistema, ma in un modo del tutto generico perché il sistema può essere inteso come il singolo prodotto software o l’intero sistema informativo complesso costituito da diversi nodi e che opera in rete.
Poi ci sono degli strumenti veri e propri (dei tool software) come quelli che vedremo in questo tutorial, ossia strumenti di monitoraggio continuo e audit (SIEM), sistemi antintrusione (e IDS – Intrusion Detection System) e sistemi di difesa attiva come i firewall ormai tradizionalmente utilizzati e i sistemi IPS (Intrusion Prevention System) che operano osservando il traffico a un livello più più elevato rispetto a quanto non faccia un firewall.
Non meno importante di questi è investire adeguatamente nella formazione del personale, perché tutti gli strumenti elencati possono essere vanificati da un dipendente che va a finire su una pagina di phishing e digita le proprie credenziali perché non se ne avvede.
Quindi, sebbene gli aspetti tecnici siano rilevanti, non va scordato che la Sicurezza Informatica non appannaggio solo dei tecnici ma in realtà riguarda tutti e quindi nel caso di realtà aziendali è fondamentale che si facciano corsi di aggiornamento periodici per far sì che tutti sappiano più o meno riconoscere ad esempio un’e-mail con un link di phishing e cose del genere.
In questa sede ci concentreremo sui sistemi di monitoraggio e nello specifico sugli Intrusion Detection System: l’IDS è un tool che monitora l’attività del sistema che osserva, quindi esistono IDS che monitorano una rete (si chiamano NIDS - Network Intrusion Detection System) e software che monitorano l'attività di una singola (si parla di HIDS, ossia Host Intrusion Detection System). L’oggetto dell’osservazione è l’attività di quel particolare sistema, quindi l’interazione tra i componenti software che sono installati; non è soltanto l'attività di rete che viene osservata.
Invece quando ci riferiamo comunemente a un IDS in realtà ci riferiamo al Network Intrusion Detection System e quindi un sistema che analizza l’attività della rete (o porzione di essa) alla ricerca di pattern conosciuti, di anomalie e interviene riportando queste anomalie al management.
Un IDS funziona più o meno come un antivirus: non c’è alcunché di particolarmente “intelligente” in un sistema del genere, perché è caratterizzato da un database (da un archivio di regole) e il suo scopo è trovare eventuali corrispondenze tra l’attività che viene osservata e le regole presenti nel suo archivio, esattamente come fa un antivirus; infatti un antivirus capisce se un file è infetto perché confronta gli ash del file con le cosiddette firme presenti nel database dei virus e se trova un match vuol dire che quel file è un virus o contiene un virus.
Analogamente, un IDS cerca dei pattern già presenti nel suo database di regole.
Qui è opportuno sottolineare che parliamo di regole anche nel caso dell’IDS, ma c'è una distinzione ben precisa da fare rispetto ad altre regole che potremmo trovare nella cybersecurity, come per esempio le regole di un firewall: quest’ultimo opera a un livello molto più semplice nel senso che osserva i pacchetti che transitano e si limita ad applicare le sue regole al singolo pacchetto, quindi nel caso del firewall le regole caratterizzano alcune proprietà dei pacchetti in transito, le porte alle quali sono indirizzati, il protocollo, gli indirizzi IP e quant’altro.
Invece le regole di un IDS caratterizzano il comportamento del traffico e non di un singolo pacchetto, quindi una regola di un IDS può essere quella che impone di bloccare un tentativo di sfruttare la vulnerabilità poodle contro TLS; si tratta di una vulnerabilità di downgrading cioè consiste nel forzare un client ad utilizzare una vecchia versione di SSL invece che una versione TLS sicura e quindi durante la negoziazione dei protocolli sicuri il client che vuole sfruttare questa vulnerabilità deve comunicare al server che non conosce i protocolli nuovi ma conosce solo i vecchi SSL e quindi impone al server di utilizzare i vecchi, magari vulnerabili. Qqui c’è uno scambio di messaggi e di pacchetti che avviene a livello applicativo: non si tratta soltanto di un pacchetto che passa e che può essere flaggato.
Però un IDS può avere delle regole in grado di imporre che questo scambio tra client e server combacii con un potenziale sfruttamento di vulnerabilità.
Quindi l’IDS dev’essere un sistema decisamente più complesso perché deve tenere conto dello stato delle connessioni e per funzionare deve essere in grado di osservare quello che transita nella rete.
Esistono diverse topologie, perché un IDS può anche essere deployato per monitorare esclusivamente il traffico di rete locale, magari perché ci interessa verificare se i nostri host e i nostri client sono stati compromessi e quindi andiamo solo a vedere qual è l’attività che effettuano sulla rete locale.
In generale un IDS si trova sul perimetro della rete, quindi immediatamente dopo i firewall perimetrali; l’IDS si colloca a cavallo tra il perimetro e la rete interna e che di fatto osserva tutto quello che transita.
C’è una differenza, in realtà banale perché molti prodotti software sono sia l’'uno che l’altro, tra IDS e IPS (ovvero tra Intrusion Detection System e Intrusion Prevention System) nel senso che l’IDS è un componente che gioca un ruolo passivo, osserva ma non intraprende delle azioni in autonomia e nel caso in cui identifichi un traffico (uno scambio di dati) anomalo, semplicemente si limita a generare un alert verso la stazione di management e verso un database di vulnerabilità (dipende dalla realtà aziendale in cui opera).
Invece l’IPS, nel momento in cui la componente IDS verifica una situazione anomala, blocca il traffico; quindi un Intrusion Prevention System è di fatto un IDS con potere di agire in piena libertà.
Per farvi comprendere bene il funzionamento, nell’immagine seguente riportiamo collocazione e funzionamento dell’IDS (a sinistra) e dell’IPS (a destra).
Questi due componenti possono essere incorporati nel firewall e in questo caso l’IDS è quel servizio che in realtà registra in un log che si chiamerà Filter, Security o qualcosa del genere, tutte le impronte come se fosse un antivirus secondo cui rappresentano una minaccia.
Tutti gli alert vengono generati dall’IDS engine, che osserva il traffico a più alto livello fino al livello 7.
Notare che non sempre è bene abilitare anche l’IPS o applicare tutte le regole degli IDS come regole IPS, perché esistono i falsi positivi e così come accade per gli antivirus, anche nel momento in cui si utilizza un IDS possono nascere falsi rilevamenti; quindi finché si utilizza il solo IDS, un falso positivo genera al limite un alert, ma se è in funzione l’IPS, lo stesso falso positivo blocca l’attività.
Quindi bisogna trovare un giusto equilibrio tra protezione e possibilità di introdurre dei disservizi, perché se l’IPS comincia a interpretare erroneamente del traffico come traffico anomalo quando in realtà è perfettamente lecito, lo blocca e di fatto non rende il servizio fruibile correttamente da parte degli utenti esterni.
Andiamo ora a conoscere un IDS open source molto interessante, che si chiama Suricata; lo faremo con un’esercitazione per la quale sfrutteremo un firewall open source che si chiama PFSense basato su BSD, che prevede una gestione unificata e semplificata dei pacchetti che vengono installati sul firewall
PFSense trova posto in delle appliance vendute da Netgate ma può anche essere scaricato e installato su una qualsiasi macchina x86 o su una VM, magari per provarlo.
Prima di procedere con l’esempio pratico spendiamo qualche paragrafo per introdurre Suricata: si tratta di un prodotto open source interamente gestito da una fondazione che è la Open Information Security Foundation (OSIF) ed integra tutti i componenti tipici, quindi un engine IDS e un IPS. Il prodotto agisce sia da IDS, che da IPS ed NSM (Network Security Monitor) e il suo engine può lavorare sia sul traffico catturato in real-time che su pacchetti off-line, scaricati in precedenza. Quindi può servire anche per verificare a posteriori del traffico che è stato catturato prima.
Si è diffuso negli ultimi anni rispetto a Snort (il suo diretto concorrente, che pur essendo open nacque come progetto commerciale, poi acquisito dalla Cisco) perché è veloce, basato su un engine che è stato riscritto da zero. Suricata ha addirittura un modulo di accelerazione hardware che può far girare il proprio engine su GPU, il che garantisce la possibilità di lavorare con traffici con banda decisamente più elevata.
Suricata è multipiattaforma, quindi è disponibile per Linux, Windows e in generale su varie distribuzioni BSD e applicazioni come TFSense, appunto, che è basato su FreeBSD.
Funziona con la tecnica del pattern matching, quindi non considera il singolo pacchetto come fa il firewall ma guarda allo scambio continuo che dipende molto dal protocollo che si sta osservando; questo, anche perché non tutti i protocolli sono orientati alle connessioni e sempre più spesso si lavora con protocolli connectionless, pertanto riuscire a identificare uno scambio tra client e server diventa sempre più complesso.
Suricata lavora a livello applicativo, quindi anche al livello 7 e questa caratteristica è utile in casi come ad esempio quello in cui un nodo all’interno della nostra rete (un computer in azienda) sta provando a scaricare un file malevolo e magari l’antivirus installato sulla macchina non si è accorto di nulla, Suricata è in grado di identificare il file malevolo nell’istante in cui un host della rete lo sta scaricando, andando a bloccare il download; per osservare il relativo traffico, allo scopo supporta i protocolli HTTP, SMTP, FTP, NFS ed SMB che gli permettono di analizzare i file mentre vengono scaricati.
Ancora, il prodotto è in grado di identificare dei tentativi di attacco dall’esterno verso un server che si trova nella nostra rete, quindi può essere dotato di regole che per esempio permettono di identificare degli scambi che sono associabili a dei tentativi di running o a tentativi di sfruttare le vulnerabilità note.
Passiamo quindi a un esempio pratico dove abbiamo installato e configurato PFSense come gateway; quindi il traffico passerà attraverso un’istanza PFSense prima di arrivare alla nostra macchina di prova.
L’interfaccia di PFSense è abbastanza semplice da utilizzare e l'installazione dei servizi necessari passa semplicemente dal packet manager di sistema, dal quale si installano i pacchetti che si desiderano; per il nostro esempio abbiamo installato Suricata e Snort.
Nell’immagine seguente vedete l’interfaccia utente di PFSense aperta sulla pagina Status, dove a destra troviamo una connessione LAN e una WAN utilizzate per le prove.
Vediamo cosa succede nel momento in cui andiamo ad analizzare gli eventuali alert prodotti da Suricata, premettendo che lavoriamo nella modalità in cui è configurato per agire solo da IDS e quindi con il Blocking Mode disabilitato; come mostra l’immagine seguente, che propone le interfacce di Suricata, tra le altre impostazioni non è stato configurato alcun upstream per il logging e quindi gli alert vengono salvati in locale (ma c’è la possibilità di configurarlo per fare l’output dei log verso Syslog, verso database MySQL in generale verso un’istanza Barnyard2).
Andiamo quindi a vedere gli alert attraverso un esempio banale: per prima cosa spostiamoci, nell’interfaccia utente del programma, sulla sezione Alerts poi apriamo la riga di comando (shell Bash) in una macchina Linux utilizzata per il test e collegata in rete con quella su cui gira PFSense .e da qui facciamo impartiamo il comando CURL seguito dall’URL di Google Immagine seguente).
Il server risponde con un errore 301 dicendo che in realtà dovremmo collegarci a www.google.it e non direttamente su Google.it comunque ha risposto. Se andiamo a vedere negli alert di Suricata, vediamo che ne ha generato uno proprio relativo a questa connessione: attempt information leak che è una policy che dice che ha identificato uno scambio HTTP con lo user agent di curl (immagine seguente).
Ma perché è stato generato l’alert? Perché le connessioni che vengono effettuate tramite curl spesso vengono utilizzate dai trojan, ad esempio per effettuare delle POST sui server di command and control; infatti quando ci sono dei virus che si diffondono, tipicamente ci sono in mezzo anche dei server attraverso i quali possono ottenere dei comandi dall’attaccante. Questa è stata una cosa molto comune per per una serie di malware che si sono diffusi negli ultimi anni e che tipicamente utilizzano tutti la libreria di curl per fare delle connessioni HTTP.
Ecco perché identificare questo scambio ci consente di identificare la relativa minaccia ed eventualmente di bloccarla; per farlo è sufficiente cliccare sul pulsantino col simbolo + in basso a sinistra nella relativa riga e questa azione permette di aggiungere l’alert alla lista e quindi al database degli alert che comportano il blocco del traffico (Add this alert to suppress list – immagine seguente).
Ora va precisato che un IDS utilizzato in questo modo è poco utile, nel senso che è utile per bloccare una serie di minacce come vecchi malware che continuano a utilizzare questi metodi, ma come sappiamo questi sistemi sono resi inefficaci in buona parte dall’adozione ormai pervasiva della crittografia.
Quindi se torniamo alla shell della macchina Linux e impartiamo il comando:
curl https://google.it
non abbiamo più, nell’interfaccia utente di Suricata, messaggi di alert perché con https l’intera comunicazione viene cifrata attraverso TLS e qui Suricata non è più in grado di ispezionare il traffico http perché a quel punto è cifrato.
A questo punto verrebbe da chiedersi che senso ha utilizzare un sistema di questo tipo se poi non è in grado di vedere all’interno del traffico, visto che viene tutto cifrato; in realtà Suricata è estremamente utile nel caso in cui ci si voglia difendere da attacchi esterni e non tanto verificare se le macchine della rete sono state compromesse.
Il fatto che al perimetro non siamo in grado di ispezionare il traffico può tecnicamente essere aggirato perché per come funziona la cifratura (in questo caso TLS o SSL che sia...) si basa sul fatto che è il client autentica il server, quindi è in grado di stabilire la veridicità delle identità del server attraverso l’uso di certificati; se il certificato è valido il client accetta la connessione e negozia una chiave di cifratura con il server, che poi verrà utilizzata per cifrare lo scambio.
Per effetto di ciò, installando al perimetro un proxy trasparente e installando sui client un certificato autoprodotto di Certification Authority che verrà utilizzato per cifrare tutto il traffico, si potrebbe decifrare il traffico al perimetro e poi ricifarlo verso l’esterno.
Questa pratica (Deep Packet Inspection) è tecnicamente possibile ma illegale in molti paesi per ovvi motivi, ad esempio perché di fatto viene meno la cifratura; poi ci sono altre implicazioni, come ad esempio il fatto che alcune applicazioni si rifiutano di lavorare in questo modo perché sono fatte per verificare l’autenticità proprio dell’applicazione alla quale si stanno collegando e quindi non accetteranno un certificato, pur valido, proveniente dal fireweall.
Alla luce di quanto visto si può affermare che la cifratura non rende l’IDS inutile perché lo scopo di tale strumento non è proteggere i client o di monitorarne l’attività verso la rete: per quello esistono degli strumenti installati sui client stessi che sono efficaci, quindi l’antivirus, il sistema anti-intrusione e anti malware a bordo dell’host, che è in grado di verificare se ci sono state delle compromissioni.
Molto più importante è il ruolo dell’IDS a protezione dei propri dei propri server e quindi nel riconoscere tentativi di attacco dall’esterno, come forzare il downgrading del TLS, bloccare certificati noti, identificare esploit ecc.
C’è una precisazione da fare relativamente alla bontà di questi sistemi: quello che li rende intelligenti ed efficaci sono le regole che definiscono cosa andare a cercare e i pattern da confrontare; ed è lì che sta tutto il valore di Suricata.
Se andiamo nella configurazione di Suricata ci vengono proposte delle opzioni per abilitare o disabilitare delle fonti di regole del sistema IDS, il quale ha un modulino al suo interno che periodicamente contatta dei server esterni per poter scaricare le regole aggiornate; esattamente come avviene per un antivirus, c’è un database aggiornato delle regole per riconoscere le nuove minacce che vengono identificate nel tempo.
Suricata utilizza le stesse fonti di Snort e le fonti delle Emergency Threats, quindi regole che ho messe on-line proprio nel momento in cui vengono identificate delle ondate di attacco. Ciò è importante perché magari si è individuata una vulnerabilità per la quale al momento non c’è una patch software e quindi senza uno strumento di questo tipo, saremmo completamente esposti se offriamo un servizio.
Un esempio è quanto è successo di recente con Exim: se abbiamo delle istanze di Exim che sono vulnerabili e dobbiamo continuare a offrire il servizio ai nostri clienti pur nella condizione in cui il software non può essere aggiornato perché ancora l'aggiornamento non è disponibile, come facciamo a proteggerci? Ebbene, in un caso del genere la risposta è nell’IDS, perché può far passare tutti gli altri ma bloccare quelli che stanno provando a sfruttare questa vulnerabilità.
Riguardo ai database delle regole, l’installazione o meglio, la scelta di quali scaricare e dei servizi cui appoggiarsi, si effettua dall’apposita sezione dell’interfaccia utente che è Global Settings (immagine seguente).
Va precisato che esistono tipicamente due o più (ma di solito sono due) tipi di sottoscrizione ai relativi servizi: una open completamente gratuita e un’altra pagamento; in Suricata è possibile impostare anche l’utilizzo delle regole di Snort. Proprio nel caso di Snort, ci sono le regole fornite dalla community e rilasciate sotto licenza GPLv2 (Install Snort GPLv2 Community rules) scaricabili da chiunque e modificabili da chiunque a patto che le pubblichi e poi ci sono le regole fornite tramite una subscription a pagamento (Install Snort rules).
Qual è la differenza tra le due opzioni? Ebbene, soprattutto nel caso di vulnerabilità emergenti, le relative regole finiscono prima nella versione a pagamento, giacché la versione free è indietro di 30 giorni rispetto alla versione a pagamento; questo è un modo per invogliare ad acquistare una subscription a pagamento.
Chiaro che per un utilizzo professionale finalizzato a proteggerci dalle vulnerabilità zero-day, 30 giorni sono una finestra veramente ampia, in quanto mediamente in 30 giorni il manteiner del prodotto vulnerabile probabilmente ha rilasciato un aggiornamento con relativa patch.
La stessa cosa accade con le regole ETOpen Emergency Threats rules installabili dall’interfaccia di Suricata: ci sono le ETOpen Emergency Threats rules che sono scaricabili da chiunque e le ETPro Emergency Threats rules, che invece richiedono una sottoscrizione a pagamento. Un particolare interessante per quanto riguarda i tipi è che esiste in realtà una terza modalità di fruizione delle regole ETPro che non è necessariamente a pagamento, ma è è una sorta di freemium perché in pratica nella subscription si accetta di fornire dei dati di telemetria ai manteiner, quindi in cambio dei dati di telemetria non si paga la sua subscription.
Nel momento in cui si attivano le varie regole si possono definire degli intervalli di aggiornamento, allo scadere dei quali il sistema le aggiornerà e le metterà in attività. Se si va nella sezione Updates dell’interfaccia utente è possibile vedere quando le regole sono state aggiornate l’ultima volta (un esempio è proposto nell’immagine seguente).
Al momento della messa on-line di questo tutorial esiste un’altra piccola differenza tra Suricata e Snort che può essere interessante conoscere: dopo l’acquisizione da parte di Cisco è stata introdotta una nuova funzionalità in più rispetto a Suricata, che è la possibilità di sfruttare le regole Open App ID (immagine seguente); si tratta di regole speciali che servono a riconoscere una particolare applicazione e quindi ad esempio se nella nostra rete aziendale vogliamo bloccare l’accesso a Facebook o a Netflix, possiamo utilizzare le App ID.
A riguardo verrebbe da obiettare che si potrebbe semplicemente filtrare l’applicazione a livello di DNS o a livello di proxy, però l’IPS opera un livello più alto e prescinde da quale sia l’indirizzo IP specifico del server cui si connette: non deve sapere se quell'indirizzo corrisponde a Facebook perché sfrutta degli altri marcatori nell’applicazione che possono essere riconosciuti analizzando il traffico, che permettono di dire con un discreto livello di accuratezza se quel traffico è inerente a una particolare applicazione. In quel caso si può decidere di bloccarlo oppure no. Per esempio si usano spesso i marcatori di Open App ID per bloccare l’accesso a siti di gaming e quant'altro.
In conclusione IDS e IPS sono sicuramente strumenti utili ma non vanno trattati come la Panacea di tutti i mali, perché non bastano da soli: la bontà degli IPS/IDS in buona parte è fatta dalle regole che gli forniamo, quindi scegliere a quali attingere è parte integrante del livello di protezione atteso.
