SNMP e altri protocolli di monitoraggio

Abbiamo già trattato in altri articoli cosa sia SNMP, quindi saremo brevi. SNMP (Simple Network Management Protocol) è in circolazione da molto tempo. La prima versione è stata pubblicata come RFC nel 1988. Con questo vantaggio temporale, è naturale che SNMP sia diventato lo standard de facto per il monitoraggio e la configurazione delle reti.

Il concetto di trap, ovvero notifiche asincrone da agente a manager, ha avuto grande successo. SNMP ha anche reso popolare l’idea di un protocollo basato su agenti. Definito dalla IETF (Internet Engineering Task Force), SNMP ha attraversato tre versioni principali. La seconda è ancora molto utilizzata, nonostante sia meno affidabile e sicura della terza.

Il protocollo funziona tramite il concetto di manager e agenti: il manager colleziona le metriche dai vari agenti. Questi possono o inviare le informazioni di diagnostica da soli, in modo event-driven, o usando le SNMP traps, o aspettando di essere interrogate dal manager. In questo caso, il manager emette un comando SNMP Get per chiedere informazioni ad uno o piú agenti presenti nella rete. SNMP usa UDP in ogni caso, la porta 161 per Get e la 162 per le traps.

Per quel che riguarda la sicurezza, SNMP non é il protocollo piú robusto. Inizialmente solo "community strings", stringhe preestabilite che agivano come password, furono implementate. Queste venivano mandate in chiaro sulla rete, causando piú di una preoccupazione sulla loro sicurezza. La seconda versione del protocollo SNMP ha introdotto un'autenticazione base con username/password che aiuta ad assicurare che la comunicazione avvenga tra il giusto agente e manager. Questo ha fatto poco peró per migliorare la sicurezza dei dati stessi, che sono largamente trasmessi comunque in chiaro, a meno che non si usi l'ultima versione di SNMP, che usa sia l'autenticazione che la crittografia.

La principale forza di SNMP é nella larga scelta di dati che gli agenti raccolgono dai device in cui sono presenti. Le variabili accessibili tramite SNMP sono organizzate in gerarchie, che possono essere personalizzate. Queste gerarchie sono definite come MIB (Management Information Base), e descrivono la struttura dei dati in un sistema. Questi dati sono composti di vari OID (Object Identifiers), ognuno una variabile che puó essere letta e inviata dagli agenti SNMP. Gli OID non sono specifici di SNMP, ma un modalitá standard internazionale di definire qualsiasi oggetto o concetto in informatica.

Il principale vantaggio di SNMP é nella sua ubiquitá. É molto piú facile monitorare dispositivi che non richiedono nulla da installare, che supportano giá il protocollo. Con gli altri protocolli di monitoraggio questo é raramente il caso, con alcuni che funzionano solo su certi sistemi operativi o che non sono pre-installati dai produttori nei loro dispositivi. SNMP é il piú semplice da settare in molti casi grazie al supporto delle vari compagnie sui loro dispositivi di rete.

Le SNMP traps probabilmente sono la modalitá piú conosciuta, ma in pratica é il monitoraggio basato su interrogazioni (polling), il get, che é il piú utilizzato in SNMP. Entrambi hanno il loro caso di uso, ovviamente, e differenti vantaggi.

SNMP permette agli amministratori di ottenere ed essere notificati sul metriche come il raffreddamento, il voltaggio, la temperatura e altre che non sono spesso riportate da altri protocolli di monitoraggio. Nel monitoraggio dei server conoscere lo stato di salute dell'hardware é vitale per mantenere un'infrastruttura funzionante.

Piú comunemente, SNMP consente un flusso costante di metriche da raccogliere da vari host. Queste metriche possono essere centralizzate e poi analizzate, o controllate in quasi tempo reale da uno strumento di monitoraggio che supporta SNMP. Grazie alla sua completezza, SNMP é di frequente la prima scelta degli amministratori di rete quando iniziano a monitorare la loro rete.

Lo scopo principale di Syslog é di raccogliere log nei sistemi Unix-like. Diversamente da molti altri protocolli in questo articolo, Syslog é specifico di una piattaforma.

Syslog é diventato lo standard per la raccolta dei log da applicazioni e dispositivi su Unix e i suoi discendenti. Non é nato per farlo peró, ma fu sviluppato da Eric Allman agli inizi degli anni 1980 come sistema di log solo per il server e-mail Sendmail. Funzionó cosí bene che altre applicazioni Unix iniziarono a supportarlo, e il dominio su quei sistemi di Syslog inizió.

Oggigiorno é presente su molti sistemi Unix-like in una delle sue evoluzioni (Rsyslog, syslog-ng). Negli ultimi anni sta peró venendo lentamente sostituito dal journal di systemD.

Syslog trasmette log. Prende una fonte e una destinazione, entrambe configurabili, e invia quel che riceve da servizi e applicazioni dalla prima alla seconda. In pratica, crea un messaggio di log (definito su RFC3164) contenente due parti: il TAG e il CONTENT. Questo é stato successivamente modificato separando la parte TAG in multiple, ma il concetto centrale é che il TAG contiene il nome del processo o del programma che genera il messaggio, e il CONTENT i dettagli dello stesso.

Syslog non passa soltanto log, ma é anche un sistema per categorizzare e analizzare i log. Syslog ha introdotto un codice numerico da 0 a 23 chiamato "facility" che é attaccato ad ogni log e identifica la sua origine. 0 é un messaggio di livello kernel, 1 sono i messaggi utente, 2 vengono dai sistemi mail e cosí via. Questo consente agli amministratori di facilmente filtrare i log e trovare quel che gli interessa piú velocemente.

Un altro codice numerico, questa volta che va da 0 a 7, rappresenta la criticitá. Zero é il maggiormente critico, etichettato come "emergency", mentre sette é utilizzato per messaggi di debug.

Il filtraggio dei log, anche se rudimentario, é anche internamente supportato da Syslog. Le espressioni regolari possono essere utilizzate per estrarre solo quel che é strettamente necessario per il monitoraggio.

Syslog si occupa dei log, che spesso includono un grosso spettro di dati e sono di default ordinati cronologicamente. É quindi piú potente di molti altri protocolli di monitoraggio di rete. Quando vi é bisogno di una visualizzazione storica, ricca di dettagli, un sistema di gestione dei log come Syslog é perfetto.

Tali log possono essere ricevuti da molti diversi processi e inviati a varie destinazioni. Generalmente o un file locale o un server Syslog remoto. Per un debug locale, una console é una destinazione possibile. Sviluppatori e amministratori insieme utilizzano tale possibilitá per determinare rapidamente la causa del malfunzionamento di un servizio o di un'applicazione.

Analizzare specifici servizi leggendo i loro log é uno dei compiti principali degli amministratori. Syslog crea uno spazio dove questi log possono essere facilmente raccolti e analizzati.

Non é tutto rosa e fiori peró. Essendo Syslog nato per supportare una singola applicazione inizialmente, e molte altre avendo iniziato a supportarlo autonomamente, senza uno standard da seguire, di conseguenza molte applicazioni generano log che deviano dal formato originale. Le diverse modalitá con cui le applicazioni creano i log é il piú grande difetto di Syslog. É complesso analizzare log che sono tutti formattati leggermente differentemente gli uni dagli altri. 

Questo non rende Syslog inutile, tuttavia. Rende solo piú complesso trovare le informazioni necessarie per monitorare con esso. Diverse implementazioni hanno fatto seguito all'originale, cercando di correggere problemi e migliorando il protocollo. Ad oggi Syslog sta lentamente diventando obsoleto su molti sistemi Linux e viene sostituito dalle funzionalitá del journal di systemD.

ICMP é un protocollo sviluppato nel 1981 e utilizzato per scambiare informazioni sullo stato e gli errori in una rete IP, o controllare lo stato della connessione ad una destinazione IP (ping).

É parte integrale del piú vasto protocollo IP, e opera a livello rete nello stack OSI.

ICMP utilizza IP come base di comunicazione, interpretandosi come un protocollo di livello superiore. Questo significa che i pacchetti ICMP sono incapsulati all'interno di pacchetti IP.

Il tipo del pacchetto ICMP è specificato come un numero a 8 bit all'inizio dell'intestazione ICMP. Successivamente viene specificato il codice ICMP tramite il campo code, anch’esso lungo 8 bit. La combinazione di tipo e codice classifica il pacchetto ICMP. In teoria potrebbero esserci 256 pacchetti ICMP distinti, ma la maggior parte è obsoleta o non assegnata. Attualmente ne sono classificati 43. Di questi, solo poche combinazioni di tipo e codice sono comunemente utilizzate.

Quelle più diffuse sono il tipo 8, codice 0 (Echo Request) e il tipo 0, codice 0 (Echo Reply). Sono comunemente utilizzate dall’utility “ping”, e vengono semplicemente chiamate “ping”. Costituiscono un metodo per verificare se un host di rete è attivo e risponde, oppure se è spento o non risponde. Il messaggio Echo Request viene inviato in un pacchetto ICMP a un indirizzo IP. Se quell’indirizzo è attivo e configurato per rispondere a questo tipo di richieste (spesso sono bloccate a livello firewall), la risposta sarà un ICMP Echo Reply. Quindi tutto funziona. Se non si riceve risposta, di solito l’host è inattivo oppure le richieste ICMP vengono bloccate da un firewall.

Se, lungo il percorso verso un indirizzo, un host non riesce a trovare un path per raggiungerlo, risponde con un messaggio ICMP Destination Unreachable, tipo 3, codice 1. Esistono altri 15 codici all’interno dei messaggi ICMP di tipo 3, ognuno dei quali specifica il motivo per cui un host non risponde. Analizzando questo codice, è possibile effettuare un monitoraggio di rete di base tramite ICMP.

Un’altra importante utilità di ICMP è lo strumento da riga di comando “traceroute” (o “tracert” nei sistemi Windows). Questo consente di tracciare il percorso da una sorgente a una destinazione utilizzando pacchetti ICMP specifici. Ogni host incontrato prima della destinazione desiderata decrementa un numero, impostato da traceroute a 1, in un campo dell’intestazione IP (il TTL, Time-To-Live), e quando questo numero arriva a 0, il percorso è considerato interrotto o troppo lungo. Con questo metodo si possono ottenere informazioni su quali nodi sono stati attraversati, il tempo di risposta di ciascuno e se determinati router non sono stati raggiunti. Problemi come questi o loop di rete possono quindi essere identificati.

Da quanto sopra esposto, si può facilmente comprendere un caso d’uso principale: ICMP viene utilizzato per eseguire il ping degli host all’interno di una rete e, in base alla loro risposta, è possibile individuare eventuali problemi. Per quanto riguarda il monitoraggio delle reti, questo è l’uso principale di ICMP.

In secondo luogo, ma non meno importante, l’utility traceroute utilizza ICMP per identificare il percorso più breve verso una destinazione, conoscere la latenza necessaria per raggiungerla e individuare problemi di routing.

ICMP, tramite ping e traceroute, rappresenta quindi un metodo semplice ma potente per scoprire in modo rapido ed efficiente cosa nella rete funziona e cosa no. I colli di bottiglia dell’infrastruttura possono essere individuati tramite il comando traceroute, poiché un host congestionato potrebbe non essere in grado di rispondere correttamente a una richiesta ICMP. Il problema può emergere in pochi secondi con un solo comando.

Una delle limitazioni di ICMP è che il “perché” di un problema di rete è spesso solo implicito, e non chiaramente espresso. Il protocollo non è complesso come altri, ed è più orientato alla diagnosi rapida che alla raccolta estensiva di metriche. È quindi necessario approfondire ulteriormente per comprendere le cause di un malfunzionamento. Nonostante ciò, ICMP resta una fonte di informazioni preziosa per qualsiasi amministratore di rete.

NetFlow è una tecnologia di monitoraggio di rete relativamente datata, sviluppata internamente da Cisco nel 1996. Raccoglie il traffico IP in entrata e in uscita da un’interfaccia. Come SNMP, è un protocollo pensato specificamente per il monitoraggio di rete.

Fino alla versione 5, il protocollo era limitato ai dispositivi Cisco. Oggi è presente anche su router e switch di molti altri produttori di rete, che ne hanno realizzato implementazioni proprie. Queste versioni seguono in linea di massima l’implementazione originale di Cisco, ma con nomi differenti (Jflow, NetStream, Cflowd, Rflow e altri). NetFlow può in parte sostituire SNMP, in quanto è largamente diffuso su molti dispositivi di rete come router e switch, anche se ha un ambito di applicazione diverso.

L’architettura di NetFlow si basa sull’assunto che esista un “collector” incaricato di ricevere le informazioni dai vari dispositivi e analizzarle. Questo collector è solitamente un server in esecuzione nella rete in cui sono presenti router e switch abilitati a NetFlow. Un “exporter”, tipicamente un agente installato su un host di rete, si occupa di aggregare i pacchetti affinché il collector possa raccoglierli successivamente. Un terzo elemento, l’applicazione di analisi, ha il compito di analizzare il flusso di dati raccolto dal collector.

NetFlow definisce un flusso come una sequenza di pacchetti correlati, da una sorgente a una destinazione. Ogni flusso è descritto da sette valori: gli indirizzi IP sorgente e destinazione, la versione del protocollo IP utilizzata, le porte sorgente e destinazione (per TCP e UDP) e il Type of Service IP. Questi flussi costituiscono quindi un riepilogo di una connessione, un flusso di dati da un punto a un altro. Raccogliendo e analizzando tali flussi, un amministratore di rete può individuare colli di bottiglia, anomalie e problemi più estesi all’interno della rete.

sFlow sta per “sampled flow” (flusso campionato), e il nome stesso riflette ciò che il protocollo fa. Si tratta di un protocollo standard industriale per l’esportazione di pacchetti al livello 2 del modello OSI.

Originariamente sviluppato da InMon Corp, sFlow è oggi mantenuto dal consorzio sFlow.org, che continua a svilupparne le specifiche. Attualmente, il protocollo è supportato da numerosi produttori di dispositivi di rete, con l’eccezione dei fornitori di software per la gestione delle reti.

A differenza di NetFlow, e nonostante il nome, sFlow non ha il concetto di “flussi”, ma funziona campionando i pacchetti ricevuti su un dispositivo del livello 2 del modello OSI (come uno switch o un router con un agente sFlow installato) o su livelli superiori. sFlow opera quindi su un’immagine parziale del traffico, mentre NetFlow raccoglie quasi tutto.

Quello che sFlow fa in pratica è eseguire due tipi di campionamento. Il primo consiste nel campionamento casuale dei pacchetti o delle operazioni a livello applicativo, il secondo è un campionamento basato sul tempo e su contatori. Questi sono chiamati rispettivamente campioni di flusso (flow samples) e campioni di contatore (counter samples).

Il campionamento vero e proprio avviene nel seguente modo: ogni volta che un pacchetto arriva su un’interfaccia, l’agente sFlow decide se campionarlo o meno. La decisione si basa su un contatore che viene decrementato a ogni pacchetto. Quando il contatore arriva a 0, il campione viene prelevato e inviato a un server centrale sotto forma di datagramma sFlow da analizzare. Questo è il collector sFlow, equivalente a quello di NetFlow.

La frequenza di campionamento dei pacchetti è definita dall’amministratore. A seconda del livello di accuratezza desiderato, si può configurare un rapporto più elevato di pacchetti campionati. Questo comporta ovviamente un aumento del traffico generato, in cambio di un livello di dettaglio maggiore.

I dati sFlow vengono inviati come pacchetti UDP sulla porta 6343. L’eventuale perdita di dati dovuta all’uso dei datagrammi UDP al posto dei pacchetti TCP è considerata accettabile.

IPFIX (Internet Protocol Flow Information eXport) è il successore diretto di NetFlow. È nato dall’esigenza di disporre di un protocollo aperto per esportare le informazioni sui flussi dai dispositivi supportati. NetFlow è di proprietà di Cisco e, sebbene molti altri produttori lo abbiano implementato, rimane un protocollo proprietario. IPFIX è stato standardizzato dallo IETF sulla base della versione 9 del protocollo NetFlow, rendendoli strettamente correlati.

IPFIX è uno standard che definisce come devono essere formattate e trasferite le informazioni sui flussi IP dall’exporter al collector.

IPFIX funziona in modo simile a NetFlow, ma prevede alcuni passaggi aggiuntivi. Una serie di Metering Processes è presente in uno o più Observation Points, simili ai collector di NetFlow. Questi processi aggregano e filtrano le informazioni sui pacchetti osservati, creando i flussi. Un Exporter raccoglie ciascuno degli Observation Points in un dominio di osservazione più ampio e invia i flussi tramite IPFIX a un Collector. Il collector, infine, si occupa di analizzare i flussi raccolti.

Non ci sono limiti al numero di exporter e collector presenti né a come siano interconnessi tra loro. Più exporter possono inviare dati a un singolo collector, oppure un singolo exporter può trasmettere a un pool di collector.

In IPFIX, ogni mittente invia periodicamente messaggi IPFIX ai destinatari configurati. A differenza di altri “protocolli basati sui flussi”, IPFIX può utilizzare sia TCP che UDP, ma preferisce SCTP (Stream Control Transmission Protocol), un protocollo di trasporto affidabile con supporto integrato per il multiplexing e il multi-streaming.

IPFIX ha introdotto la formattazione dei flussi tramite l’uso di Template. Il protocollo è estensibile e consente all’utente di definire tipi di dati personalizzati da includere nei messaggi IPFIX. I Template sono particolarmente utili quando si ha a che fare con implementazioni del protocollo da parte di fornitori diversi.

SSH sta per “Secure Shell Protocol”, con l’intento principale già chiaro dal nome. Nel 1995 è stato sviluppato per fornire un’alternativa sicura a protocolli di login come rlogin, Telnet e FTP. Questi funzionavano bene ma non avevano alcun concetto di sicurezza, creando rischi che, sebbene inizialmente considerati trascurabili, si sono dimostrati insostenibili. Lo scopo di SSH non era il monitoraggio dei dispositivi, ma l’accesso a essi, con il monitoraggio come possibile attività da svolgere dopo il login.

SSH è stato rapidamente adottato su tutti i principali sistemi operativi, inclusi sistemi embedded e dispositivi di rete. Essendo un protocollo aperto sotto l’IETF, ha dato origine a una serie di derivati, come SCP (per la copia di file), SFTP (un FTP più sicuro), FASP (per il trasferimento dati) e altri.

Il compito principale di SSH è consentire l’accesso a una risorsa remota in modo sicuro. Viene supportata una serie di metodi di autenticazione per garantire all’amministratore i privilegi su un host remoto.

L’autenticazione semplice tramite nome utente/password è supportata ed è il metodo più facile, ma meno sicuro. Più comunemente, i login SSH sono autenticati tramite l’uso dell’autenticazione a chiave pubblica: una coppia di chiavi crittografiche viene generata localmente e inviata al server SSH. Al momento del login, le chiavi vengono scambiate e, se corrispondenti, l’accesso viene concesso.

Analogamente, l’autenticazione basata sull’host utilizza anch’essa chiavi crittografiche, ma a livello di host anziché di utente. I metodi di autenticazione tramite tastiera e challenge-response utilizzano un singolo processo di challenge-response che richiede all’utente di inserire interattivamente una password. Le macchine abilitate a Kerberos possono essere accessibili tramite SSH usando l’autenticazione GSSAPI. Qualsiasi di questi metodi può essere abilitato o disabilitato nel file di configurazione sul server. È consigliabile lasciare abilitati solo quelli strettamente necessari, per ridurre le possibilità di intrusioni.

Una volta concesso l’accesso, viene aperta una shell sulla risorsa remota che può essere utilizzata come se fosse locale, con privilegi dipendenti dal ruolo dell’utente sul server.

SSH, a differenza dei protocolli di monitoraggio, non raccoglie dati per te. Fornisce solo un modo sicuro per accedere a risorse remote, concedendo un alto livello di privilegi. Pertanto, SSH non è un protocollo di monitoraggio di rete, ma è comunque estremamente utile nella risoluzione dei problemi di sistema.

L’accesso con privilegi completi a un host che presenta malfunzionamenti permette all’amministratore di avere il pieno controllo su quell’host, analizzando cosa sta accadendo al suo interno da un punto di osservazione non limitato dalle capacità di un protocollo. Poiché tutto ciò che può essere accessibile sul dispositivo remoto può essere raggiunto tramite SSH con privilegi sufficienti, operazioni come la riconfigurazione di un database guasto, il reset di un firewall o la correzione di un’installazione errata possono essere effettuate efficacemente.

SSH conferisce grandi poteri all’amministratore. Pur essendo un protocollo per lo più manuale, in cui non esistono operazioni come polling, campionamento o analisi automatica, SSH va usato quando si vuole approfondire a fondo l’interno di un dispositivo.

A grandi poteri corrispondono grandi responsabilità, come ben noto. E SSH non fa eccezione alla regola. Essere completamente responsabili dei dispositivi remoti significa che una cattiva configurazione è un errore facile da commettere. Altri protocolli di monitoraggio come SNMP o quelli basati su flow sono meno soggetti a questi errori. SSH richiede inoltre un tempo di configurazione più lungo prima di poter funzionare. Le chiavi devono essere scambiate, gli account utente creati e altro ancora. Installare SSH è facile e ben supportato su tutti i principali sistemi operativi, ma la sua configurazione non è veloce come quella di un protocollo di monitoraggio basato su agenti.

WMI sta per Windows Management Instrumentation ed è un’estensione del Windows Driver Model. Fornisce un’interfaccia per raccogliere informazioni su un host Windows, oltre a un’API per estenderlo e controllarlo tramite linguaggi di scripting (VBScript e PowerShell).

È l’implementazione Microsoft dello standard Web-Based Enterprise Management (WBEM). WMI appartiene quindi a una famiglia di implementazioni che funzionano su vari sistemi operativi, ma WMI stesso è specifico per Windows.

WMI opera in modo logicamente simile ad altre soluzioni di monitoraggio basate su agenti. Un componente gestisce gli spazi dei nomi e fornisce informazioni ai consumatori WMI, molto simile a come un server interroga un agente installato da remoto. I componenti WMI sono presenti su tutti i sistemi Windows dal 2000 e possono essere installati sulle versioni precedenti.

WMI deve essere configurato sul lato componente. Questo richiede l’apertura di molteplici porte sull’host da monitorare. Poiché dipende da altri servizi Windows come NetBios, SMB e RPC che devono essere aperti, tutte le porte relative devono essere accessibili dal consumatore WMI. WMI stesso utilizza un intervallo dinamico di porte, che può variare tra 1025 e 5000 (su Windows 2000, XP e Server 2003) o tra 49152 e 65535 (su Windows 2008, Vista e versioni successive). Può comunque essere configurato per usare una porta fissa.

Una volta che tutto è configurato, WMI fornisce un’infrastruttura per scoprire ed eseguire attività di gestione. È un protocollo di gestione, non solo di monitoraggio. I dati da WMI sono ottenuti tramite l’uso di script o applicazioni complete, usando vari linguaggi (ActiveX, PowerShell, Visual Basic, C++, C# e altri). Queste applicazioni si connettono al provider WMI e vengono poi interrogate tramite PowerShell o con WQL (WMI Query Language), un sottoinsieme di SQL specifico per WMI.

RMON (Remote Network Monitoring) è un’estensione di SNMP, originariamente sviluppata dall’IETF, per monitorare le informazioni dei livelli 1 e 2 OSI sulle reti Ethernet e Token Ring. Questi livelli non erano supportati dallo SNMP stesso. Versioni successive di RMON lo hanno esteso per includere il monitoraggio dei livelli di rete e applicazione. Una versione simile di RMON chiamata SMON (Switch Monitoring) supporta le reti switchate. Per le reti ad alta capacità, HCRMON è un’estensione del protocollo RMON di base.

RMON è presente su molti switch e router di fascia alta come protocollo aggiuntivo accanto all’agente SNMP.

RMON non è particolarmente diverso da SNMP. Gli agenti sotto RMON sono chiamati “probe” e agiscono come server, raccogliendo e analizzando le informazioni da inviare alle applicazioni di gestione della rete che supportano il protocollo. Queste agiscono come client in una relazione server/client.

Spesso i dispositivi abilitati a SNMP richiedono solo l’installazione di un software per diventare anche abilitati a RMON, mentre altri possono richiedere un modulo hardware chiamato “hosted probe” da implementare fisicamente.

Tuttavia, quando RMON è abilitato, funziona monitorando il traffico che passa attraverso il dispositivo di rete su cui è installato, controllando congestione, pacchetti persi e collisioni eccessive. In generale, una probe RMON è presente su un solo dispositivo per subnet. I dati raccolti dalla probe possono essere utilizzati da un agente SNMP o possono attivare una trap SNMP quando vengono soddisfatte condizioni specifiche. Ci sono in totale nove gruppi di elementi di monitoraggio RMON che coprono vari aspetti del traffico che RMON può monitorare. Questi gruppi vanno dalle statistiche di rete, alla frequenza di campionamento dei dati, agli indirizzi, fino alla classificazione degli host in base alla dimensione e all’uso del traffico.

Suricata è un sistema open-source di rilevamento (IDS) e prevenzione (IPS) delle intrusioni sviluppato dalla Open Information Security Foundation (OISF). La prima versione è stata rilasciata nel 2010 ed è disponibile per tutti i principali sistemi operativi.

Un sistema di rilevamento delle intrusioni individua e segnala possibili minacce a un sistema. Un sistema di prevenzione delle intrusioni agisce anche, ad esempio bloccando il traffico che potrebbe rappresentare una minaccia. Suricata include entrambe le funzionalità.

Suricata monitora i pacchetti sulle interfacce di rete. Una volta installato su un host che può essere soggetto a qualsiasi tipo di minaccia, inizia a catturare i pacchetti per l’analisi. Questi vengono confrontati con una lista di firme, chiamate anche regole. Ogni regola è un semplice file contenente un’intestazione (che definisce protocollo, indirizzi IP, porte e direzione della regola), un insieme di opzioni e un’azione da eseguire quando la firma corrisponde.

Le azioni sono simili a quelle di un firewall: un pacchetto corrispondente può essere scartato, rifiutato, lasciato passare, generare un avviso e così via.

Suricata include numerosi set di regole per iniziare subito senza dover creare le proprie da zero. Le regole sono il cuore di Suricata e funzionano sia come sistema di rilevamento che di prevenzione delle intrusioni.