Suricata

Introduzione

Suricata è un motore IDS, IPS e NSM di rete sviluppato da OISF e dalla community di Suricata.

Risorse

Contribuire

Accettiamo volentieri patch e altri contributi. Consulta il nostro Processo di contribuzione per sapere come iniziare.

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:

Controlli basati su GitHub-CI. Vengono eseguiti automaticamente quando viene aperta una pull request.
Revisione da parte degli sviluppatori del team e della community
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/

suricata suricata-8.0.7

Categorie