Suricata 8.0.7: IDS-Alerts vor und nach dem Update prüfen

Ein erfolgreicher Konfigurationstest mit suricata -T sagt nichts darüber aus, ob eine IDS-Regel bei aufgezeichnetem Verkehr noch anschlägt. Das zeigt erst ein Replay. Für Suricata 8.0.7 halte ich den Vergleich mit demselben PCAP-Mitschnitt für das maßgebliche Abnahmekriterium, weil fehlende und zusätzliche Treffer vor einem Einsatz im IPS-Modus untersucht werden müssen.

Was prüft der Konfigurationstest nicht?

-T prüft, ob Suricata die Konfiguration einschließlich der eingebundenen Signaturen akzeptiert. Netzwerkverkehr verarbeitet der Test nicht. Eine gültige Regel kann bei einem bestimmten Request trotzdem keinen Alert erzeugen, etwa wenn Suricata den zugehörigen TCP-Stream nicht wie erwartet zusammensetzt.

Für die Prüfung der PostgreSQL-Inspektion reicht ein einzelner Request nicht. Enthält der Mitschnitt keine weiteren Requests im selben Flow, zeigt er nicht, ob Suricata diese ebenfalls untersucht. Der PostgreSQL-Parser muss aktiviert sein, und für einen späteren Request muss eine passende Signatur einen Treffer erwarten lassen.

Vor dem Update gehören die verwendete Version, der Regelstand und die EVE-JSON-Ausgabe zusammen in eine Baseline. Sonst lässt sich ein späterer Unterschied nicht eindeutig einer Änderung zuordnen. Der Vergleich beginnt deshalb mit zwei getrennten Replay-Läufen unter dokumentierten Bedingungen.

Wie lassen sich beide Versionen mit derselben PCAP-Datei testen?

Beide Versionen brauchen die Konfiguration, mit der sie tatsächlich betrieben werden sollen. Bei einem Wechsel von Suricata 7 auf 8 können sich Konfiguration und Regelkompatibilität ändern. Im Beispiel stehen BIN_ALT und BIN_NEU für die ausführbaren Dateien, CFG_ALT und CFG_NEU für ihre Konfigurationen. Diese Variablen sind vor dem Lauf zu setzen; EVE-JSON muss in beiden Konfigurationen aktiviert sein.

set -eu
 test ! -e ./vergleich
 mkdir -p ./vergleich/alt ./vergleich/neu
 "$BIN_ALT" -V > ./vergleich/alt/version.txt
 "$BIN_NEU" -V > ./vergleich/neu/version.txt
 "$BIN_ALT" -T -c "$CFG_ALT"
 "$BIN_NEU" -T -c "$CFG_NEU"
 sha256sum ./probe.pcap > ./vergleich/pcap.sha256
 "$BIN_ALT" -c "$CFG_ALT" -r ./probe.pcap -l ./vergleich/alt
 sha256sum -c ./vergleich/pcap.sha256
 "$BIN_NEU" -c "$CFG_NEU" -r ./probe.pcap -l ./vergleich/neu
 sha256sum -c ./vergleich/pcap.sha256

Die Befehle setzen ein noch nicht vorhandenes Verzeichnis ./vergleich voraus. So geraten keine alten Ereignisse in die Auswertung. Mit -r liest Suricata die PCAP-Datei; -l setzt das Log-Verzeichnis für den jeweiligen Lauf. Die Hash-Prüfung nach jedem Replay bestätigt, dass die Datei zwischen den Läufen unverändert blieb. Gibt die EVE-Konfiguration einen absoluten Ausgabepfad vor, müssen auch diese Pfade getrennt werden: -l allein genügt dann nicht.

Für einen Vergleich der Engine sollten beide Versionen denselben Regelstand verwenden, sofern sie ihn akzeptieren. Abweichungen bei aktivierten Regeln, Thresholding, Stream-Einstellungen oder EVE-Ausgaben gehören ins Testprotokoll. Soll eine TCP-Signatur geprüft werden, muss der Mitschnitt die für den betreffenden Stream benötigten Pakete enthalten. Erst mit diesen Angaben bekommen Unterschiede zwischen den beiden EVE-Dateien einen belastbaren Kontext.

Welche IDS-Alerts unterscheiden sich im EVE-JSON?

Die Gesamtzahl der Alerts kann gegenläufige Änderungen verdecken: Ein fehlender Treffer und ein zusätzlicher Treffer gleichen sich rechnerisch aus. Aussagekräftiger sind die Generator-ID (gid), die Signatur-ID (signature_id), die Revision und die Verbindungsdaten jedes Alert-Ereignisses. Quell- und Zieladresse sowie Ports zeigen, zu welchem Verkehr ein Treffer gehört.

jq erstellt aus jeder EVE-Datei eine sortierte Liste der Alert-Ereignisse. Mehrfachtreffer bleiben erhalten, denn eine veränderte Häufigkeit kann auf eine andere Verarbeitung desselben Flows hinweisen.

for lauf in alt neu; do
  test -s "./vergleich/$lauf/eve.json" || exit 1
  jq -r 'select(.event_type == "alert") |
    [.alert.gid, .alert.signature_id, .alert.rev,
     .proto, .src_ip, .src_port, .dest_ip, .dest_port] | @tsv' \
    "./vergleich/$lauf/eve.json" |
    LC_ALL=C sort > "./vergleich/$lauf/alerts.tsv"
done
diff -u ./vergleich/alt/alerts.tsv ./vergleich/neu/alerts.tsv

Ein leeres Diff bedeutet nur, dass diese Felder und ihre Trefferhäufigkeit übereinstimmen. Ob die zuvor festgelegten Positivfälle überhaupt erkannt wurden, muss ebenfalls geprüft werden. Fehlt ein erwarteter Treffer, kommen die Signatur, der aufgezeichnete Flow, die Parser-Einstellungen und Thresholding als Ursachen infrage. Bei einem zusätzlichen Treffer zeigt der Abgleich mit dem PCAP-Inhalt, ob die Regel nun einen gewünschten Request erkennt oder auf festgelegten Negativverkehr reagiert.

Bei einem Wechsel von Suricata 7 auf 8 können auch Änderungen an der TCP-Stream-Verarbeitung oder an den Einstellungen das Ergebnis beeinflussen. Ein neuer Alert belegt für sich genommen keine Änderung der Signatur. Wer EVE-Ereignisse dauerhaft zentral auswertet, findet das verwandte Thema bei den Monitoring- und Logging-Schulungen. Das Replay beantwortet die Frage nach den Alerts; für eine IPS-Freigabe fehlt noch der Test der tatsächlichen Blockierwirkung.

Wann ist ein Test im IPS-Modus sinnvoll?

Ein Replay mit -r zeigt Alerts für aufgezeichnete Pakete. Ob eine Inline-Anbindung später Pakete wie vorgesehen verwirft, bleibt offen. Ein geeigneter Testsatz enthält deshalb bestätigte Positivfälle und Verkehr, bei dem die betreffende Regel nicht auslösen soll. Die erwarteten Signatur-IDs stehen vor der Auswertung für beide Gruppen fest.

Fehlende Positivtreffer sprechen gegen die Freigabe der betroffenen Erkennung. Zusätzliche Treffer auf Negativverkehr können beim Blocking legitime Verbindungen unterbrechen. Sind die Unterschiede untersucht, folgt ein separater Test in einer isolierten Inline-Umgebung: Dort lassen sich die konfigurierte Regelaktion und die tatsächlich weitergeleiteten oder verworfenen Pakete vergleichen.

Der Unterschied zwischen einer IDS-Meldung und einem IPS-Eingriff betrifft auch andere IT-Security-Themen. Für Suricata 8.0.7 bleibt der Inline-Test ein eigener Schritt, der erst nach der Untersuchung ungeklärter Alert-Differenzen sinnvoll ist.

Fazit

Ein archivierter Replay-Vergleich zeigt auch nach späteren Regeländerungen, welche Version mit welchem Regelstand einen bestimmten Treffer erzeugt hat. Diese Nachvollziehbarkeit zählt mehr als ein erfolgreicher Start der Engine. Lege für das nächste Update einen PCAP-Mitschnitt mit bestätigten Positiv- und Negativfällen samt erwarteten Signatur-IDs ab.