Questo sito utilizza cookie per raccogliere informazioni sull'utilizzo. Cliccando su questo banner o navigando il sito, acconsenti all'uso dei cookie. Leggi la nostra cookie policy.OK

Intrusion detection, ecco come funzionano gli IDS

pittogramma Zerouno

Sicurezza

Intrusion detection, ecco come funzionano gli IDS

21 Mar 2007

di redazione TechTarget da Digital4

Attraverso l’analisi dei pacchetti che transitano nella rete, questi sistemi avvisano preventivamente di possibili attività maligne.

Sul mercato sono presenti diversi sistemi di intrusion detection (IDS) che spaziano dalle soluzioni di livello enterprise per il monitoring delle reti ai semplici sistemi per la gestione dei log in all’host. Sottolineiamo poi che c’è una certa differenza fra un sistema di intrusion prevention (IPS) e un IDS: il primo si comporta meglio con un attacco già attivo e prova a bloccarlo, mentre un IDS tenta di registrare l’attacco e, in alcuni casi, informa un addetto al fine di attivare un piano di risposta all’incidente specifico.

Il beneficio che apporta un IDS è che possiamo vedere cosa passa attraverso la rete e quindi tentare di isolare qualsiasi traffico che sembra maligno. Questo è un aspetto importante, poiché si tratta di una funzione che manca in molti firewall (a eccezione di quelli con il supporto layer-7, ovvero i firewall dello strato dell’applicazione).

Da quando i firewall funzionano sugli strati più bassi della comunicazione di rete, le loro regole di filtraggio sono generalmente limitate agli indirizzi IP, alle porte, all’ora del giorno e soltanto ad alcuni altri criteri. Con firewall che non esaminano le informazioni contenute in un pacchetto e prendono decisioni basandosi soltanto sugli header del pacchetto stesso, risulta evidente che viene consentito il passaggio di un certo traffico maligno.

Il ruolo dei nostri IDS è di controllare in modo approfondito questi pacchetti, guardare i dati contenuti al loro interno e rispondere a domande come: “Assomiglia al worm Code Red ?”, “È un tentativo di portare al buffer overflow il server che spedisce le email?” oppure “Uno dei nostri utenti ha appena attivato l’ultimo exploit WMF?” È abbastanza importante per un amministratore essere informato di tutti i pacchetti che attivano questi segnali di pericolo all’interno degli IDS. Anche se gli avvertimenti sono spesso falsi allarmi, possiamo usare queste informazioni per esaminare ulteriormente lo stato della nostra rete al fine di scoprire se abbiamo a che fare con problema rilevante. Possiamo pensare a un IDS come a un allarme preventivo che avvisa quando transita qualcosa che potrebbe richiedere la nostra attenzione. Quando tentiamo di proteggere la nostra rete.

Gli IDS possono poi essere suddivisi in NIDS o HIDS: la differenza è che i primi controllano la rete e i secondi monitorano l’host. Questo aspetto risulta importante quando si sceglie un IDS, in quanto dobbiamo essere sicuri di cosa vogliamo controllare esattamente. Per esempio, molti amministratori non impiegheranno un HIDS su macchine Windows o Unix considerando la loro capacità built-in di produrre log dettagliati (event logs/syslog) e quindi preferiscono controllare il traffico sulla rete per individuare eventuali segnali di comportamenti maligni. Questa modalità può anche essere più affidabile dell’host monitoring, perché i log di un host compromesso non risultano ovviamente attendibili.

Nel caso di IPCop, abbiamo un NIDS built-in nel firewall, preconfigurato e pronto per essere usato con la configurazione minima assoluta: si tratta del sistema di intrusion detection Snort.

Snort è l’IDS incluso in IPCop ed è uno degli sniffer più conosciuti e più usati tra quelli disponibili oggi (è utilizzato nelle reti grandi e piccole in tutto il mondo). Aggiorna continuamente le “signature” di un grande numero di vulnerabilità, gestisce molteplici utenti, offre supporto commerciale e online e su carta rende disponibile un’eccellente documentazione. Inizialmente usato come sniffer, Snort era abbastanza valido ed era collegato al suo parente più anziano TCPDUMP. Successivamente, Snort è stato ampliato e ha assunto il ruolo di NIDS più che di sniffer (molti degli utenti di Snort non ne conoscono assolutamente le capacità di sniffing e lo usano esclusivamente come NIDS).

Quando Snort è diventato molto popolare, il suo creatore Martin Roesch ha deciso di fondare un’azienda attorno a Snort per offrire servizi di sicurezza basati sull’esperienza maturata come sviluppatore di Snort. Questo ha portato alla nascita di Sourcefire, che fornisce supporto commerciale e altri servizi inerenti Snort. Benché oggi in Sourcefire ci siano sviluppatori che lavorano a tempo pieno su Snort, questo rimane un prodotto open source e quindi può essere fornito con IPCop: la sua interfaccia può infatti includere una serie di semplici opzioni per la gestione di un sistema Snort preconfigurato.

Come funziona un IDS?

In generale gli NIDS, e Snort nello specifico, sono fatti girare su dispositivi che hanno la capacità di controllare quanto è più possibile della rete, solitamente sopra o vicino a un gateway (come nel caso di IPCop) o su una sorta di porta di controllo su uno switch (SPAN/Mirror port).

L’ NIDS configura la scheda di rete o le schede sul dispositivo per funzionare in modo “promiscuo”, il che significa che saranno fatti passare i pacchetti attraverso lo stack di rete indipendentemente dal fatto che siano o meno indirizzati a una particolare macchina. Ciò è importante perché, oltre a se stesso, un NIDS controllerà spesso le varie macchine. L’NIDS sull’host prenderà tali pacchetti e ne verificherà il contenuto informativo (e a volte anche gli header) per stabilire che non siano presenti tracce di codice maligno. Questa modalità operativa può ricordare quella dell’intelligenza artificiale, dato che l’NIDS analizza i pacchetti che gli transitano vicino; in realtà agisce in un modo molto più semplice.

Gli exploit, i virus, i worm, lo spyware e altro software maligno generano traffico di rete e questo traffico mostra spesso pattern specifici relativamente al software in uso, una specifica stringa in un exploit, specifici host che contatta e specifiche opzioni negli header del TCP/IP. Ci sono molti tecnici che controllano le loro reti e quando notano qualcosa di strano, la annotano e generalmente si informano presso i propri colleghi per vedere se qualcuno ha notato qualcosa di simile. Successivamente, se viene rilevata l’attività maligna, qualcuno produrrà una “signature” per il loro IDS preferito e in molti casi per alcuni IDS nello stesso tempo. Sulla base di queste signature, il motore di rilevazione dell’IDS deciderà se contrassegnare un pacchetto come potenzialmente maligno.

Questo metodo raramente offre un’accuratezza del 100% perché possono essere forniti falsi positivi o negativi. La rilevazione è progettata come strato supplementare di difesa e non può dire con certezza se una rete è stata o meno compromessa. Quello che può fare è avvisare un amministratore che qualcosa sta succedendo. All’interno di un IPCop, Snort è disposto in un’eccellente posizione per poter avvisare di qualsiasi traffico maligno che tenti di passare dal firewall alle interfacce protette – o persino fra le interfacce protette.

Usare Snort con IPCop

La configurazione di Snort con IPCop è un processo rapido. Sourcefire richiede agli utenti di registrarsi se desiderano scaricare le signature aggiornate. L’aggiornamento delle regole è un processo fondamentale, per cui consigliamo assolutamente di registrarsi.

Una volta registrati, selezioniamo ogni interfaccia che desideriamo controllare contrassegnando il checkbox corrispondente. Suggeriamo di controllare tutte le interfacce a questo punto e di effettuare il filtraggio successivamente, quando si controllano i log. Dovremmo anche scegliere le regole di Sourcefire VRT per gli utenti registrati a meno che non abbiamo sottoscritto un abbonamento che ci permetta di accedere a tali regole. Digitiamo quindi il codice Oink ottenuto dal sito Web di Snort e scarichiamo le regole più aggiornate. L’operazione è conclusa. Compilato un semplice form, configuriamo l’NIDS per la nostra rete.

redazione TechTarget da Digital4

Articolo 1 di 5