La Open Information Security Foundation (OISF) ha rilasciato Suricata 1.0 il 19 luglio 2010, un motore di intrusion detection scritto in C con architettura multi-thread e compatibile con il formato di regole di Snort. È il primo IDS open source di una certa diffusione progettato fin dall’inizio per distribuire l’analisi su più core, dopo oltre due anni di sviluppo e i contributi di più di venticinque persone.

Contesto

Per l’intrusion detection open source il riferimento è Snort, che gira dalla fine degli anni Novanta. Il suo motore esegue cattura, decodifica, riassemblaggio dei flussi e matching delle firme in un solo thread. Su una macchina mono-core questo non era un limite; su hardware a quattro o otto core, un processo single-thread satura un core solo e lascia gli altri fermi mentre il traffico cresce.

La OISF è un’organizzazione no-profit nata per costruire un motore IDS/IPS di nuova generazione. Il finanziamento iniziale arriva dallo US Department of Homeland Security, dallo Space and Naval Warfare Systems Command (SPAWAR) della US Navy e da alcune aziende private del consorzio OISF, tra cui Endace, NitroSecurity ed Everis. Il progetto fa parte del programma Homeland Open Security Technology (HOST) del DHS. Una prima beta era uscita a cavallo tra il 31 dicembre 2009 e il 1 gennaio 2010; la 1.0 è la prima versione dichiarata stabile.

Il codice esce sotto licenza GPLv2, e così pure la libreria HTP che il motore usa per analizzare il traffico HTTP.

Architettura

L’idea di fondo è spezzare la pipeline di analisi in moduli che girano come thread distinti e comunicano tramite code. Lo stesso pacchetto attraversa una sequenza di fasi:

  • cattura dei pacchetti dall’interfaccia di rete;
  • decodifica dei livelli inferiori dello stack;
  • stream engine, che riassembla i segmenti TCP in flussi;
  • detection, dove avviene il matching delle regole;
  • output, che scrive alert e log.

Dato che i thread di detection sono più d’uno, flussi diversi si ispezionano in parallelo su core diversi. Cattura, decodifica e matching non si contendono più lo stesso thread, e su hardware multi-core commodity il throughput sostenibile cresce. Come distribuire i moduli sui thread è configurabile, perché il punto ottimale dipende dal numero di core e dal profilo di traffico.

Il secondo elemento dell’architettura è il riconoscimento automatico del protocollo applicativo. Suricata ispeziona l’inizio di un flusso per capire quale protocollo trasporti, a prescindere dalla porta numerica su cui viaggia. Una sessione HTTP su una porta non standard viene riconosciuta come HTTP e analizzata con le regole HTTP, cosa che un sistema legato alla porta 80 non farebbe. Questo riconoscimento alimenta i parser di livello applicativo, in particolare l’analisi HTTP affidata alla libreria HTP scritta da Ivan Ristic, autore di ModSecurity.

Punto critico

La compatibilità con il formato di regole di Snort è la scelta che rende Suricata adottabile senza riscrivere il patrimonio di firme esistente. Suricata interpreta la sintassi delle regole Snort VRT, gestisce le opzioni del linguaggio delle regole e il logging in formato unified. Chi ha già un set di firme calibrato — comprese le raccolte pubbliche di Emerging Threats — le fa girare sul nuovo motore e ne confronta il comportamento, senza buttare via il lavoro di tuning.

Sullo stesso terreno la compatibilità è anche il vincolo principale. Adottare il linguaggio di Snort vuol dire ereditarne i limiti di espressività: una regola è quasi sempre un pattern su byte, con scarsa capacità di descrivere relazioni tra eventi distinti nel tempo. Suricata comincia a superare questo confine con la famiglia di keyword flowbits, che lascia a una firma il compito di impostare uno stato sul flusso e a un’altra quello di leggerlo, così da costruire una detection a più passi. È un primo passo verso regole che esprimono logica e non solo corrispondenze di stringhe, ma resta agganciato a una sintassi nata per un altro motore.

Implicazioni

Il riconoscimento di protocollo indipendente dalla porta cambia il modo di scrivere e di ragionare le firme. Finché la detection resta legata alla porta, un attaccante che sposta un servizio su una porta non convenzionale sfugge alle regole che danno per scontata la corrispondenza porta-protocollo. Spostando la decisione dal numero di porta al contenuto del flusso, Suricata riduce questa categoria di evasioni e rende possibili regole che ragionano sulla semantica del protocollo invece che sulla sua collocazione.

Un parser HTTP dedicato, che normalizza il flusso prima del matching, ha lo stesso effetto sulle evasioni applicative: le tecniche di offuscamento che spezzano un pattern con codifiche o frammentazioni vengono ricondotte a una forma canonica prima del confronto con le regole. La normalizzazione è il punto in cui un IDS guadagna o perde robustezza, e isolarla in una libreria HTTP separata e mantenuta è una scelta d’ingegneria da seguire nel tempo.

Sul piano operativo, l’architettura multi-thread sposta il collo di bottiglia. Con un motore single-thread il limite pratico è la frequenza di clock di un core; distribuendo su più thread il limite si avvicina alla capacità complessiva della macchina e alla qualità del bilanciamento tra i thread di detection. Per questo prima di concludere conviene misurare su hardware reale: il guadagno dipende da quanto bene il traffico si distribuisce sui flussi.

Limiti

Suricata 1.0 è una prima release stabile, e va misurata come tale. La compatibilità con Snort è dichiarata sul formato delle regole e sul logging unified, ma la parità di comportamento regola per regola va verificata sul proprio set, non data per scontata. Il riconoscimento di protocollo copre i protocolli implementati nei parser di questa versione, non un insieme arbitrario. E un’architettura multi-thread porta con sé un costo di coordinamento — code, sincronizzazione, contesa — che su carichi modesti può non ripagare rispetto a un motore più semplice. Il modo giusto di affrontare questa versione è installarla accanto a un sensore Snort già in piedi, darle lo stesso traffico e le stesse firme, e leggere i numeri.

Immagine di copertina: Schermata di una console IDS Snort in un browser Internet Explorer: tabelle con conteggi di alert per firma, sorgenti, destinazioni e… — logo di CJS ULE~commonswiki, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:Snort_ids_console.gif