oisf/suricataOpen-Source-Netzwerk-IDS/IPS/NSM-Engine für Echtzeit-Datenverkehrsinspektion, Eindringungserkennung und -verhinderung, Protokollanalyse und regelbasiertes Threat Hunting.
Suricata ist eine Netzwerk-IDS-, IPS- und NSM-Engine, die von der OISF und der Suricata-Community entwickelt wird.
Wir nehmen gerne Patches und andere Beiträge an. Bitte lesen Sie unseren Beitragsprozess für den Einstieg.
Suricata ist eine komplexe Software, die sich hauptsächlich mit nicht vertrauenswürdigen Eingaben befasst. Eine fehlerhafte Verarbeitung dieser Eingaben kann schwerwiegende Folgen haben:
Mit anderen Worten: Wir halten die Einsätze für ziemlich hoch, insbesondere da die IDS/IPS in vielen häufigen Fällen für einen Angreifer direkt erreichbar ist.
Aus diesem Grund haben wir einen recht umfangreichen QA-Prozess entwickelt. Eine Konsequenz davon ist, dass ein Beitrag zu Suricata ein etwas langwieriger Prozess sein kann.
Auf hoher Ebene sind die Schritte:
OISF-Teammitglieder können Builds an unser privates QA-Setup übermitteln. Es führt eine Reihe von Build-Tests und eine Regressionssuite durch, um zu bestätigen, dass keine vorhandenen Funktionen brechen.
Der abschließende QA-Lauf dauert mindestens einige Stunden und läuft in der Regel über Nacht. Derzeit umfasst er:
Zusätzlich zu diesen Tests können je nach Art der Codeänderung weitere Tests manuell ausgeführt werden:
Es ist wichtig zu verstehen, dass fast alle oben genannten Tests als Abnahmetests verwendet werden. Wenn etwas fehlschlägt, liegt es an Ihnen, dies in Ihrem Code zu beheben.
Ein Schritt der QA wird derzeit nach dem Merge ausgeführt. Wir übermitteln Builds an das Coverity-Scan-Programm. Aufgrund der Einschränkungen dieses (kostenlosen) Dienstes können wir maximal einmal pro Tag übermitteln. Natürlich kann es vorkommen, dass die Community nach dem Merge Probleme findet. In beiden Fällen bitten wir Sie, bei der Behebung der Probleme zu helfen, falls sie auftreten.
F: Wird mein PR angenommen?
A: Das hängt von mehreren Dingen ab, einschließlich der Codequalität. Bei neuen Funktionen hängt es auch davon ab, ob das Team und/oder die Community die Funktion für nützlich halten, wie stark sie anderen Code und andere Funktionen beeinflusst, das Risiko von Leistungsrückgängen usw.
F: Wann wird mein PR gemerged?
A: Das hängt davon ab. Wenn es sich um eine wichtige Funktion oder eine als risikoreich eingestufte Änderung handelt, wird sie wahrscheinlich in die nächste Hauptversion aufgenommen.
F: Warum wurde mein PR geschlossen?
A: Wie im Suricata-GitHub-Workflow dokumentiert, erwarten wir für jede Änderung einen neuen Pull Request.
Normalerweise gibt das Team (oder die Community) Feedback zu einem Pull Request, wonach erwartet wird, dass er durch einen verbesserten PR ersetzt wird. Schauen Sie sich also die Kommentare an. Wenn Sie mit den Kommentaren nicht einverstanden sind, können wir sie immer noch im geschlossenen PR diskutieren.
Wenn der PR ohne Kommentare geschlossen wurde, liegt dies wahrscheinlich an einem QA-Fehler. Wenn die GitHub-CI-Prüfungen fehlgeschlagen sind, sollte der PR sofort behoben werden. Eine Diskussion darüber ist nicht erforderlich, es sei denn, Sie glauben, dass der QA-Fehler falsch ist.
F: Der Compiler/Code-Analysator/das Tool liegt falsch, was nun?
A: Um die Automatisierung der QA zu unterstützen, akzeptieren wir keine verbleibenden Warnungen oder Fehler. In einigen Fällen kann dies bedeuten, dass wir eine Unterdrückung hinzufügen, wenn das Tool dies unterstützt (z. B. valgrind, DrMemory). Einige Warnungen können deaktiviert werden. In einigen Ausnahmefällen ist die einzige „Lösung“, den Code umzugestalten, um eine Fehlmeldung (False Positive) eines statischen Code-Checkers zu umgehen. Das ist zwar frustrierend, aber wir bevorzugen dies gegenüber verbleibenden Warnungen in der Ausgabe. Warnungen werden tendenziell ignoriert und erhöhen dann das Risiko, andere Warnungen zu verbergen.
F: Ich denke, Ihr QA-Test ist falsch
A: Wenn Sie wirklich der Meinung sind, dass er falsch ist, können wir darüber diskutieren, wie wir ihn verbessern können. Aber ziehen Sie diese Schlussfolgerung nicht zu schnell; häufiger erweist sich der Code als falsch.
F: Ist die Unterzeichnung einer Contributor License Agreement erforderlich?
A: Ja, wir tun dies, um das Eigentum an Suricata in einer Hand zu behalten: der Open Information Security Foundation. Siehe http://suricata.io/about/open-source/ und http://suricata.io/about/contribution-agreement/
