suricata

Motore open-source IDS/IPS/NSM di rete per l'ispezione del traffico in tempo reale, rilevamento e prevenzione delle intrusioni, analisi dei protocolli e caccia alle minacce basata su regole.

Suricata è un software complesso che gestisce input in gran parte non attendibili. Una gestione errata di questi input può avere serie conseguenze:

• in modalità IPS un crash può mandare offline una rete
• in modalità passiva una compromissione dell'IDS può portare alla perdita di dati critici e riservati
• una mancata rilevazione può portare a una compromissione non rilevata della rete

In altre parole, riteniamo che la posta in gioco sia piuttosto alta, soprattutto perché in molti casi comuni l'IDS/IPS sarà direttamente raggiungibile da un attaccante.

Per questo motivo, abbiamo sviluppato un processo di QA piuttosto esteso. Una conseguenza è che contribuire a Suricata può essere un processo abbastanza lungo.

A grandi linee, i passaggi sono:

1. Controlli basati su GitHub-CI. Vengono eseguiti automaticamente quando viene aperta una pull request.
2. Revisione da parte degli sviluppatori del team e della community
3. Esecuzioni di QA da configurazioni QA private. Sono private per la natura del traffico di test.

Panoramica dei passaggi di QA di Suricata

I membri del team OISF possono inviare build alla nostra configurazione QA privata. Eseguirà una serie di test di build e una suite di regressione per confermare che nessuna funzionalità esistente si rompa.

L'esecuzione finale di QA richiede almeno alcune ore e generalmente viene eseguita durante la notte. Attualmente esegue:

• test di build estesi su diversi sistemi operativi, compilatori, livelli di ottimizzazione, funzionalità di configure
• analisi statica del codice con cppcheck, scan-build
• analisi dinamica del codice con valgrind, AddressSanitizer, LeakSanitizer
• test di regressione per bug passati
• validazione dell'output dei log
• test della unix socket
• fuzz testing basato su pcap usando ASAN e LSAN
• test IDS e IPS basati su replay del traffico

Oltre a questi test, in base al tipo di modifica del codice possono essere eseguiti manualmente ulteriori test:

• test di replay del traffico (multi-gigabit)
• elaborazione di grandi raccolte di pcap (multi-terabyte)
• fuzz testing (può richiedere diversi giorni o addirittura settimane)
• test delle prestazioni basati su pcap
• test delle prestazioni su traffico live
• vari altri test manuali basati sulla valutazione delle modifiche proposte

È importante comprendere che quasi tutti i test sopra elencati vengono usati come test di accettazione. Se qualcosa fallisce, sta a te risolvere il problema nel tuo codice.

Uno dei passaggi di QA viene attualmente eseguito dopo il merge. Inviamo le build al programma Coverity Scan. A causa delle limitazioni di questo servizio (gratuito), possiamo inviarlo al massimo una volta al giorno. Naturalmente può accadere che dopo il merge la community trovi problemi. In entrambi i casi ti chiediamo di aiutare a risolvere i problemi quando dovessero emergere.

FAQ

D: Accetterete la mia PR?

R: Dipende da una serie di fattori, inclusa la qualità del codice. Con le nuove funzionalità dipende anche da se il team e/o la community ritengono che la funzionalità sia utile, da quanto incide su altro codice e altre funzionalità, dal rischio di regressioni delle prestazioni, ecc.

D: Quando verrà unita la mia PR?

R: Dipende: se si tratta di una funzionalità importante o di una modifica considerata ad alto rischio, probabilmente entrerà nella prossima versione major.

D: Perché la mia PR è stata chiusa?

R: Come documentato nel flusso di lavoro GitHub di Suricata, ci aspettiamo una nuova pull request per ogni modifica.

Normalmente, il team (o la community) fornirà feedback su una pull request, dopo il quale ci si aspetta che venga sostituita da una PR migliorata. Quindi guarda i commenti. Se non sei d'accordo con i commenti, possiamo comunque discuterne nella PR chiusa.

Se la PR è stata chiusa senza commenti, probabilmente è dovuto a un fallimento della QA. Se i controlli GitHub-CI sono falliti, la PR dovrebbe essere corretta immediatamente. Non c'è bisogno di una discussione al riguardo, a meno che tu non ritenga che il fallimento della QA sia errato.

D: Il compilatore/analizzatore di codice/strumento ha torto, e ora?

R: Per supportare l'automazione della QA, non accettiamo che warning o errori rimangano. In alcuni casi questo può significare che aggiungiamo una soppressione se lo strumento la supporta (ad es. valgrind, DrMemory). Alcuni warning possono essere disabilitati. In alcuni casi eccezionali l'unica "soluzione" è rifattorizzare il codice per aggirare un falso positivo del controllo statico. Anche se frustrante, preferiamo questo piuttosto che lasciare warning nell'output. I warning tendono a essere ignorati e quindi aumentano il rischio di nascondere altri warning.

D: Penso che il vostro test di QA sia sbagliato

R: Se pensi davvero che lo sia, possiamo discutere su come migliorarlo. Ma non trarre questa conclusione troppo in fretta: più spesso è il codice a rivelarsi sbagliato.

D: Richiedete la firma di un accordo di licenza per i contributori?

R: Sì, lo facciamo per mantenere la proprietà di Suricata in un'unica mano: la Open Information Security Foundation. Vedi http://suricata.io/about/open-source/ e http://suricata.io/about/contribution-agreement/