Network intrusion detection system: differenze tra le versioni

I '''NIDS''', '''Network Intrusion Detection System''', sono degli strumenti [[informatica|informatici]], [[software]] o [[hardware]], dediti ad analizzare il [[Traffico (telecomunicazioni)|traffico]] di uno o più segmenti di una [[LAN]] al fine di individuare anomalie nei flussi o probabili intrusioni informatiche.

In un sistema informatico che implementa valide politiche di sicurezza, un buon sistema di incident response e che adotta firewall, antivirus e tutte le più moderne misure di sicurezza, i NIDS giocano un ruolo fondamentale, in quanto:

* analizzano il payload dei pacchetti identificando il traffico anomalo;

* danno informazioni sulle scansioni che la rete ha ricevuto;

* permettono di ricevere allarmi real-time;

* evidenziano eventuali errori nella configurazione del sistema;

* evidenziano eventuali vulnerabilità della rete;

* permettono di monitorare il comportamento degli utenti interni alla rete;

* segnalano se qualche altra misura di sicurezza, come il firewall o l’antivirus, non ha funzionato correttamente;

* rilevano eventuali attacchi provenienti dalla rete interna verso la rete esterna;

* rilevano la presenza di eventuali worm che cercano di inviare informazioni all’esterno della rete;

* effettuano il monitoraggio delle risorse condivise utilizzate;

* permettono di capire quali misure preventive adottare al fine di evitare eventuali attacchi futuri;

* sono difficili da rilevare in quanto agiscono passivamente.

Le ampie funzionalità descritte hanno portato alcuni amministratori di rete a pensare che i NIDS siano in grado di segnalare e risolvere qualsiasi problema di sicurezza. Paradossalmente, pensare che i NIDS garantiscano totale sicurezza date le loro enormi potenzialità, può risultare controproducente in quanto ciò genererebbe un falso senso di sicurezza. Non esiste, infatti, né totale sicurezza, né un unico prodotto che permetta di essere totalmente sicuri.

Anche se i NIDS sono sicuramente necessari a garantire un buon livello di sicurezza del sistema, da soli non sarebbero sufficienti in quanto:

* non sostituiscono l’esistente staff di sicurezza in quanto necessitano di costante monitoraggio;

* non individuano attacchi che sfruttano vulnerabilità non ancora rese pubbliche detti 0-day;

* agiscono passivamente, ovvero non bloccano il traffico dannoso anche se possono essere configurati per interagire con un firewall;

* quando c’è una grande quantità di traffico da processare, è possibile che vengano persi dei pacchetti, con conseguente fallimento nella rilevazione di un attacco;

* non possono analizzare informazioni criptate;

* identificano un tentativo d’attacco ma non rilevano se questo è riuscito;

* presentano problemi nel gestire attacchi che utilizzano pacchetti frammentati;

* incrementando il numero delle firme, può essere ridotta l’efficenza del NIDS;

* richiedono notevoli risorse in termini di spazio per l’archiviazione dei log;

* non sostituiscono gli altri meccanismi di protezione.

Sia i firewall che i NIDS collaborano al fine di prevenire accessi abusivi ad una rete. Entrambi sono fondamentali ma nessuno è sufficiente a garantire da solo un elevato livello di sicurezza. A parte queste analogie, ci sono delle sostanziali differenze tecniche che li caratterizzano.

I firewall hanno funzione di filtraggio dei pacchetti allo scopo di bloccare il traffico non conforme alle loro politiche. I pacchetti vengono filtrati in base all’indirizzo IP sorgente o di destinazione e alle corrispettive porte. Difficilmente i log memorizzati riguardano il traffico permesso, in quanto ritenuto affidabile. Se alcuni dei pacchetti dannosi riuscissero a superare il firewall a causa di una configurazione non corretta dello stesso, o di una qualsiasi vulnerabilità sfruttata, non solo sarebbe possibile portare a termine un attacco con successo ma, soprattutto, non verrebbe memorizzata alcuna informazione in merito.

Per ovviare a questo problema, entrano in gioco i NIDS, i quali analizzano il contenuto di tali pacchetti e segnalano con un allarme ogni attività anomala individuata, indipendentemente dal successo o dall’insuccesso della stessa.

Inoltre nel caso in cui un attacco provenisse dall’interno della rete, il firewall non avrebbe utilità alcuna. Esso infatti, pur essendo capace di filtrare il traffico verso e dalla rete esterna, non ha alcun potere sul traffico interno alla rete.

Impostando la scheda di rete del NIDS in modalità promiscua, è possibile ascoltare in maniera passiva tutto il traffico passante sul segmento di rete, senza interferire sullo stesso. L'analisi dei pacchetti può essere effettuata mediante tre tecnologie: la pattern matching analysis, la stateful pattern matching analysis e la protocol analysis.

La '''Pattern Matching Analysis''' si occupa di analizzare i contenuti dei pacchetti alla ricerca di sequenze di bit prefissate. Questo è un approccio semplice da implementare ma, allo stesso tempo, abbastanza rigido e pesante dal punto di vista computazionale in quanto ogni pacchetto deve essere confrontato con centinaia di firme di intrusion detection. Ogni firma è associata a un attacco specifico e istruisce l'IDS sul tipo di pacchetto da considerare anomalo. Ciascuna firma assume una struttura composta da sei componenti <protocollo>, <ip_src>, <porta_src>, <ip_dst>, <porta_dst> e <payload_con_exploit> che vengono confrontati con i pacchetti in ingresso e in uscita nel seguente modo: SE il protocollo utilizzato è <protocollo>, l'indirizzo IP sorgente è <ip_src>, la porta associata all'indirizzo IP sorgente è <porta_src>, l'indirizzo IP di destinazione è <ip_dst>, la porta associata all'indirizzo IP di destinazione è <porta_dst> e il payload contenuto nel pacchetto è <payload_con_exploit>, ALLORA genera un allarme.

In base a quanto descritto fino ad ora, un allarme viene generato quando si verifica il pattern matching tra un pacchetto e una regola. Questo significa che sarebbe sufficiente dividere la stringa dell'exploit contenuta nel payload in due frame TCP, per non far rilevare l'attacco. Per risolvere questo problema, è statostata introdotta la '''Stateful Pattern Matching Analysis''' che è un criterio più sofisticato di analisi che effettua gli stessi controlli della Pattern Matching Analysis tenendo però conto dello stream TCP dei dati. Questo comporta maggiore carico computazionale in quanto capita spesso che ci siano sessioni TCP aperte da monitorare per un lungo periodo.

La '''Protocol Analysis''' invece, genera un allarme per ogni violazione delle specifiche tecniche di un protocollo. Si supponga, per esempio, che un client intenda aprire una connessione TCP con un server, a tal fine invia un pacchetto SYN e si aspetta di ricevere o un pacchetto SYN/ACK o un RST/ACK. Qualsiasi altro pacchetto ricevuto viene considerato una violazione e genera un allarme.

I NIDS lavorano con grandi quantità di dati e per funzionare necessitano di almeno un algoritmo di generazione degli allarmi. Alcuni amministratori scelgono di ritenere anomalo tutto il traffico considerato non affidabile (politica chiusa), altri invece scelgono di ritenere affidabile tutto il traffico non considerato anomalo (politica aperta). Nella prima ipotesi il carico computazionale del NIDS sarà rilevante e verrà generato un alto numero di falsi allarmi detti falsi positivi che possono essere dovuti a:

* pacchetti generati da alcuni dispositivi di rete non riconosciuti dal NIDS;

* violazioni di protocolli non dovute ad attacchi ma ad implementazioni ambigue;

* circostanze normali ritenute pericolose dal NIDS, come per esempio la visualizzazione di una pagina web contenente il codice sorgente di un exploit.

Nella seconda ipotesi il numero di allarmi sarà notevolmente minore, ma si corre il rischio di non identificare il traffico anomalo che non trova alcuna corrispondenza con le regole impostate, generando falsi negativi che sono più difficili da rilevare e possono essere dovuti a:

* configurazioni non appropriate della rete;

* quantità di traffico elevata a tal punto da non essere supportata dal NIDS;

* traffico cifrato;

* firme errate o troppo generiche;

* attacchi 0-day dei quali non è stata ancora rilasciata la corrispettiva firma.

Gli IDS generalmente non intervengono sul traffico, ma si limitano a rispondere passivamente segnalando le anomalie tramite messaggi di testo, email, o telefonate. La modalità di segnalazione dell’allarme spesso dipende dalla gravità dello stesso.

Alcuni IDS, possono anche essere programmati per rispondere attivamente agli attacchi più seri, adottando una delle seguenti contromisure:

* inviando un pacchetto RST all’attaccante simulando che esso provenga dal sistema attaccato al fine di far credere che la vittima non sia raggiungibile;

* interagendo con un firewall di rete per bloccare temporaneamente o permanentemente le connessioni con la vittima;

* monitorando l’intero scambio di pacchetti;

* eseguendo un nslookup, un portscan o un traceroute verso il sistema attaccante per reperire maggiori informazioni.

Tuttavia, configurando l’IDS per rispondere attivamente ad attacchi, in caso di falsi positivi si rischierebbe il blocco delle connessioni che normalmente dovrebbero essere consentite causando un DoS.

Una delle attività maggiormente critiche nella configurazione e messa in opera di un IDS è il suo posizionamento all’interno della rete da monitorare. In base alla topologia della rete, possono presentarsi diversi casi. Quando in un segmento di rete gli host sono collegati da un hub, l’implementazione di un NIDS è relativamente semplice perché l’hub è una componente di rete che si occupa di replicare ogni singolo pacchetto su tutte le porte. In questo modo è sufficiente collegare il NIDS a una porta qualsiasi dell’hub per poter leggere tutto il traffico passante.

In presenza di uno switch, invece, la situazione è diversa e l’implementazione dei NIDS è maggiormente complicata. Gli switch, infatti, lavorano ad un livello superiore della pila ISO/OSI rispetto agli hub e quando devono inviare un pacchetto, lo inviano solo verso la relativa porta di destinazione. Una soluzione per poter leggere tutto il traffico del segmento di rete è il port mirroring che consiste nel monitorare una o più porte dello switch, copiandone il traffico su un’altra porta detta mirror port. Tale porta dovrà necessariamente avere una capacità di banda possibilmente pari alla somma della capacità di banda di tutte le porte monitorate. Solo in questo modo il traffico potrà essere gestito in modo opportuno.

Come detto, la scelta del posizionamento degli IDS è un’attività molto delicata che deve tener conto delle esigenze della rete e delle risorse di cui si dispone.

Un’altra variabile da considerare nel posizionamento di un IDS è la sua collocazione rispetto ad un firewall. Posizionando l’Intrusion Detection System all’esterno del firewall, si identificheranno tutte le attività anomale incluse quelle che non avranno accesso alla rete in quanto bloccate dal firewall. Un IDS disposto in questo modo sarà più esposto agli attacchi provenienti dall’esterno perché privo di protezione. Le risorse richieste sono ingenti in quanto la quantità di traffico analizzato e di log memorizzati sarà rilevante. Una soluzione più economica consiste nel posizionare l’IDS all’interno del firewall per monitorare solo il traffico che accede alla rete. In tal modo saranno generati meno allarmi e ci saranno meno log da analizzare.

Se invece, l’obiettivo dell’IDS è la protezione dei server, una valida alternativa è installare il sistema di intrusion detection nella Demilitarized Zone (DMZ). Tuttavia, gli altri segmenti di rete rimarrebbero privi di monitoraggio.

L’analisi dei log è di fondamentale importanza nel processo di intrusion detection sia nel caso ci siano stati dei tentativi di intrusione, che nel caso si sia verificato un incidente informatico.

I log memorizzano record contenenti informazioni sul timestamp, sul protocollo utilizzato, sull’indirizzo IP sorgente e di destinazione e sulle porte utilizzate da qualsiasi attività anomala monitorata. Possono anche essere contenuti dati aggiuntivi come una descrizione testuale dell’evento o il numero della regola che ha generato l’allarme.

Quando vengono generati log causati da eventi di una certa entità, è opportuno memorizzare anche il payload del pacchetto che ha generato l’allarme per avere maggiori dettagli sull’evento.

Facciamo un esempio considerando una richiesta DNS. In corrispondenza di questo evento, verrà generato un log dove sarà riportato che il potenziale attaccante con indirizzo IP 100.200.100.200 ha inviato un pacchetto UDP al destinatario 90.80.70.60, sulla porta 53. Ciò non sarà sufficiente a capire se la richiesta DNS è stata dannosa o meno. La situazione sarebbe differente nel caso in cui si potesse analizzare anche il payload del pacchetto.

Uno dei problemi maggiori nell’analisi dei log è l’eterogeneità intrinseca degli stessi, in quanto variano a seconda del firewall, del router o dell’IDS utilizzato. Non esistono tool che sincronizzano cronologicamente i log prodotti da sistemi differenti. Può talvolta capitare che la time zone differisca da sistema a sistema, rendendo ancora più complicata l’analisi; tuttavia, per sincronizzare sistemi diversi, possono essere usati protocolli come NTP.

Inoltre, di estrema importanza è la capacità di reazione di fronte ad un’intrusione. Intervenire tempestivamente quando si identifica un’intrusione, spesso è essenziale per evitare che l’attaccante possa alterare o eliminare i log. Gli amministratori di rete, tuttavia, dovrebbero prestare attenzione non solo alla possibile manipolazione dei log ma anche alle molteplici attività anomale che possono presentarsi, come quelle che si stanno per analizzare.

* Il calo delle performance della rete dovuto alla saturazione della banda, che si verifica perché spesso l’attaccante utilizza le macchine compromesse per archiviare programmi, mp3 e film da mettere illegalmente in condivisione con gli altri utenti della rete.

* Il traffico sospetto verso indirizzi IP sconosciuti o su protocolli non utilizzati comunemente. Se si rilevano connessioni in uscita provenienti da un server web, questo può significare che il server sia stato compromesso.

* Se si identificano pacchetti malformati, c’è il rischio che un attaccante sia alla ricerca di vulnerabilità sulle varie macchine del sistema o stia tentando di aggirare un firewall.

* La perdita di connettività, che potrebbe essere associata ad un attacco DoS.

* Un numero elevato di tentativi di login falliti, i quali sono comuni quando l’attaccante cerca di ottenere maggiori privilegi di quelli realmente concessi.

* Un’attività inusuale del modem, che potrebbe indicare la probabile presenza di dialer.

* Le ‘Scansioni’ verso le macchine della rete, che sono utilizzate dall’attaccante per raccogliere informazioni sui sistemi operativi installati, i servizi attivi, le porte aperte e la topologia della rete. Tali informazioni saranno poi usate per effettuare un attacco.

* L’alta quantità di traffico generata in orari non di lavoro, indice di utenti non autorizzati che stanno usufruendo della rete. Nel caso in cui nella rete attaccata fosse presente uno switch, una volta introdottosi, l’attaccante potrebbe intercettare il traffico utilizzando due attacchi.

* L’attacco ARP-POISONING, dove vengono alterate le tabelle ARP degli host appartenenti allo stesso segmento di rete, in modo che la macchina sul quale risiede lo sniffer veda anche il traffico generato dagli altri host.

* L’attacco DHCP-POISONING, dove l’attaccante fa in modo che un host della rete interna simuli di essere il server DHCP e invii delle risposte ad-hoc alle DHCP-REQUEST che gli arrivano, specificando l’indirizzo IP dell’attaccante come default gateway. In tal modo tutto il traffico, prima di arrivare all’esterno, passerà per la macchina controllata dall’attaccante.

Qualsiasi attività di monitoraggio della rete deve rispettare le normative in vigore nello stato in cui si trova il sistema informatico e le politiche interne aziendali. In caso contrario esiste il rischio di essere perseguiti penalmente per violazione della privacy degli utenti della rete e per intercettazione abusiva di comunicazione informatica. Non sarà, inoltre, possibile utilizzare i dati raccolti per intraprendere azioni legali nei confronti di un intruso.

È pertanto opportuno:

* informare gli utenti che la loro attività di rete sarà monitorata;

* indicare lo scopo del monitoraggio;

* specificare le tipologie di traffico monitorate;

* specificare il responsabile a cui saranno inviate le segnalazioni di eventuali compromissioni.

Dal punto di vista burocratico tali accorgimenti possono essere tradotti in una lettera informativa da far firmare a tutti gli utenti della rete per presa visione. Dal punto di vista tecnico è possibile implementare un “Message of the Day” (MOTD) che consiste in un messaggio iniziale che informa gli utenti dell’attività di logging della rete.

In caso di incidente informatico i log rappresentano prove preziose, ed in quanto tali, devono essere ottenute in modo conforme alla normativa vigente ed essere tali da poter illustrare dettagliatamente lo svolgimento dei fatti.

È pertanto opportuno fare in modo che la prova ottenuta sia:

* autentica ed inalterata anche in caso di spostamenti dei dispositivi che contengono la prova stessa;

* completa, in quanto non deve mostrare l’incidente dall’unica prospettiva riconducibile alle azioni compiute dall’attaccante, ma deve valutare anche prospettive che potrebbero dare adito a contraddizioni;

* comprensibile e credibile, ovvero rappresentata in un formato leggibile da chiunque e non ad uso esclusivo degli esperti del settore.

Per concludere questa panoramica, vengono discussi gli elementi da tenere in considerazione durante la scelta di un NIDS.

* Costo: deve, ovviamente, essere proporzionato alle risorse che si vogliono proteggere.

* Capacità del la banda supportata: è la quantità di traffico che il sensore può analizzare in un’unità di tempo. Si misura in Mb/s o in pacchetti/s.

* Aggiornamento delle firme: i NIDS da questo punto di vista funzionano esattamente come gli antivirus. Per poter identificare i nuovi attacchi devono avere nel loro database le firme recenti. Per questa ragione è di estrema importanza che gli aggiornamenti vengano rilasciati in modo tempestivo e venga data la possibilità di aggiornare il database in modo automatico. Importante è anche la possibilità di utilizzare firme personalizzate create ad-hoc per le proprie esigenze.

* Attività di logging: è opportuno verificare la chiarezza dei log e valutare se l’output viene salvato in formato standard o proprietario.