OPNsense Suricata Custom Rules: Eigene IDS/IPS-Signaturen schreiben und optimieren

Die mitgelieferten Rulesets von ET Open oder Abuse.ch decken bekannte Bedrohungen ab, kennen aber die eigene Infrastruktur nicht. Ein Angreifer, der über eine Custom-Webanwendung auf Port 8443 eindringt, bleibt unentdeckt, wenn keine passende Signatur existiert. Mit Suricata Custom Rules auf OPNsense schließen Sie diese Lücke und erstellen Signaturen, die genau auf Ihre Umgebung zugeschnitten sind.

Grundlagen: Suricata Rule Syntax

Jede Suricata-Regel folgt einem festen Schema aus Action, Header und Options:

action protocol source_ip source_port -> dest_ip dest_port (options)

Action

Die Action bestimmt, was bei einem Match passiert:

Action	Beschreibung
alert	Warnung generieren, Traffic durchlassen
drop	Paket verwerfen (nur im IPS-Modus)
reject	Paket verwerfen und RST/ICMP senden
pass	Regel explizit ignorieren (Whitelist)

Header

Der Header definiert das Protokoll und die Netzwerkrichtung:

alert tcp $HOME_NET any -> $EXTERNAL_NET 443 (...)

• Protokoll: tcp, udp, icmp, ip, http, dns, tls, ssh
• Richtung: -> (unidirektional) oder <> (bidirektional)
• Variablen: $HOME_NET, $EXTERNAL_NET, $HTTP_SERVERS, $DNS_SERVERS

Options

Die Options sind das Herzstück jeder Regel. Sie stehen in Klammern und werden durch Semikolons getrennt:

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CUSTOM Suspicious User-Agent detected";
    flow:established,to_server;
    http.user_agent; content:"BadBot/1.0";
    classtype:web-application-attack;
    sid:9000001; rev:1;
)

Wichtige Options:

• msg: Beschreibung der Regel (erscheint im Alert)
• flow: Verbindungsstatus (established, to_server, to_client)
• content: Byte-Pattern im Payload
• pcre: Regulärer Ausdruck für komplexe Muster
• sid: Eindeutige Signatur-ID (Custom: ab 9000000)
• rev: Revisionsnummer der Regel
• classtype: Klassifizierung (z. B. trojan-activity, web-application-attack)

Signaturen für eigene Services erstellen

Beispiel 1: Brute-Force-Erkennung auf Custom-Webportal

Ein internes Portal auf Port 8443 soll vor Brute-Force-Angriffen geschützt werden:

alert http $EXTERNAL_NET any -> $HOME_NET 8443 (
    msg:"CUSTOM Brute-force attempt on internal portal";
    flow:established,to_server;
    http.method; content:"POST";
    http.uri; content:"/api/auth/login";
    threshold:type both, track by_src, count 10, seconds 60;
    classtype:attempted-user;
    sid:9000010; rev:1;
)

Diese Regel löst aus, wenn ein einzelner Client innerhalb von 60 Sekunden mehr als 10 POST-Requests an /api/auth/login sendet. Die threshold-Option verhindert Alert-Fluten.

Beispiel 2: Erkennung von Datenexfiltration über DNS

DNS-Tunneling nutzt lange Subdomains, um Daten auszuschleusen:

alert dns $HOME_NET any -> any 53 (
    msg:"CUSTOM Possible DNS tunneling - long subdomain";
    dns.query; content:"."; offset:50;
    threshold:type both, track by_src, count 5, seconds 120;
    classtype:bad-unknown;
    sid:9000020; rev:1;
)

Wenn die DNS-Query einen Punkt (.) erst nach Offset 50 enthält, deutet das auf eine ungewöhnlich lange Subdomain hin — ein typisches Zeichen für DNS-Tunneling.

Beispiel 3: Unerlaubte SSH-Verbindungen erkennen

SSH-Zugriffe sollen nur von bestimmten Management-IPs erlaubt sein:

alert ssh !$MANAGEMENT_NET any -> $HOME_NET 22 (
    msg:"CUSTOM SSH access from unauthorized network";
    flow:established,to_server;
    classtype:policy-violation;
    sid:9000030; rev:1;
)

Dazu definieren Sie $MANAGEMENT_NET in der Suricata-Konfiguration:

vars:
  address-groups:
    MANAGEMENT_NET: "[10.10.1.0/24,10.10.2.0/24]"

Beispiel 4: TLS-Zertifikat-Anomalien erkennen

Selbstsignierte oder verdächtige TLS-Zertifikate im ausgehenden Traffic:

alert tls $HOME_NET any -> $EXTERNAL_NET 443 (
    msg:"CUSTOM Self-signed TLS certificate detected";
    flow:established,to_client;
    tls.cert_issuer; content:"O="; content:"CN=";
    tls.cert_subject; content:"O="; content:"CN=";
    tls_cert_notbefore:<-30d;
    classtype:bad-unknown;
    sid:9000040; rev:1;
)

Beispiel 5: Erkennung unverschlüsselter Credentials

Klartext-Passwörter in HTTP-POST-Requests:

alert http $HOME_NET any -> any any (
    msg:"CUSTOM Cleartext password in HTTP POST";
    flow:established,to_server;
    http.method; content:"POST";
    http.request_body; content:"password=";
    classtype:policy-violation;
    sid:9000050; rev:2;
)

Custom Rules auf OPNsense einrichten

Regel-Dateien erstellen

OPNsense erwartet Custom Rules in einem definierten Verzeichnis:

# Custom Rules-Datei anlegen
vi /usr/local/etc/suricata/rules/custom.rules

Alternativ nutzen Sie die OPNsense-Weboberfläche: Services > Intrusion Detection > Administration > User defined > Rules.

Rules aktivieren

1. Navigieren Sie zu Services > Intrusion Detection > Administration
2. Wechseln Sie zum Tab Rules
3. Filtern Sie nach Ihrem Custom-Ruleset
4. Aktivieren Sie die gewünschten Regeln
5. Klicken Sie Apply und starten Sie Suricata neu

Variablen definieren

Unter Services > Intrusion Detection > Administration > User defined > General definieren Sie benutzerdefinierte Variablen:

HOME_NET:       [10.0.0.0/8,172.16.0.0/12,192.168.0.0/16]
EXTERNAL_NET:   !$HOME_NET
HTTP_SERVERS:   [10.10.5.10,10.10.5.11]
DNS_SERVERS:    [10.10.1.1,10.10.1.2]
MANAGEMENT_NET: [10.10.1.0/24]

Performance-Tuning

Suricata auf OPNsense muss den gesamten Netzwerk-Traffic in Echtzeit analysieren. Ohne Optimierung kann die Firewall zum Flaschenhals werden.

Regelset-Reduktion

Nicht jede Regel ist für jede Umgebung relevant. Deaktivieren Sie Regeln, die nicht auf Ihre Infrastruktur passen:

# Regelstatistik anzeigen
suricatasc -c "ruleset-stats"

Typische Kandidaten zum Deaktivieren:

• SMTP-Regeln wenn kein Mailserver im Netz steht
• MSSQL-Regeln wenn keine Microsoft-Datenbanken existieren
• Multimedia-Regeln in reinen Server-Umgebungen
• P2P-Regeln in Unternehmensnetzen mit Proxy

Multi-Threading konfigurieren

Suricata nutzt Workers, die jeweils einen CPU-Kern belegen. Auf einer OPNsense-Appliance mit 8 Kernen:

# /usr/local/etc/suricata/suricata.yaml (Auszug)
threading:
  set-cpu-affinity: yes
  detect-thread-ratio: 1.0

af-packet:
  - interface: igb0
    threads: 4
    cluster-type: cluster_flow
    defrag: yes

cluster_flow stellt sicher, dass alle Pakete einer Verbindung vom selben Thread verarbeitet werden — wichtig für die korrekte Zustandsverfolgung.

Stream-Engine optimieren

Die Stream-Engine reassembliert TCP-Streams. Passen Sie die Puffer an Ihre Bandbreite an:

stream:
  memcap: 512mb
  reassembly:
    memcap: 1gb
    depth: 1mb
    toserver-chunk-size: 2560
    toclient-chunk-size: 2560

Suppress-Lists: False Positives unterdrücken

Keine Signatur ist perfekt. Suppress-Lists unterdrücken bekannte False Positives, ohne die Regel komplett zu deaktivieren:

# /usr/local/etc/suricata/rules/suppress.rules

# Suppress: Backup-Server löst SSH-Brute-Force-Alert aus (normales Verhalten)
suppress gen_id 1, sig_id 9000030, track by_src, ip 10.10.1.50

# Suppress: Monitoring-Server erzeugt viele DNS-Queries
suppress gen_id 1, sig_id 9000020, track by_src, ip 10.10.1.10

# Suppress: Bekannte False Positive in ET-Ruleset
suppress gen_id 1, sig_id 2024897, track by_dst, ip 10.10.5.0/24

Suppress vs. Disable

• Suppress: Regel bleibt aktiv, aber bestimmte IPs/Netze werden ausgenommen
• Disable: Regel wird komplett deaktiviert

Bevorzugen Sie Suppress über Disable — so bleiben Sie geschützt, wenn ein neuer Client im Netz auftaucht.

EVE JSON Logging

Suricatas EVE-JSON-Format liefert strukturierte Logs, die sich hervorragend in SIEM-Systeme integrieren lassen:

# /usr/local/etc/suricata/suricata.yaml
outputs:
  - eve-log:
      enabled: yes
      filetype: regular
      filename: eve.json
      types:
        - alert:
            tagged-packets: yes
            payload: yes
            payload-printable: yes
            http-body: yes
            http-body-printable: yes
        - http:
            extended: yes
        - dns:
            query: yes
            answer: yes
        - tls:
            extended: yes
        - files:
            force-magic: yes

EVE-JSON analysieren

# Alerts der letzten Stunde anzeigen
cat /var/log/suricata/eve.json | \
  jq 'select(.event_type=="alert") | {timestamp, src_ip, dest_ip, alert: .alert.signature}'

# Top-10 ausgelöste Regeln
cat /var/log/suricata/eve.json | \
  jq -r 'select(.event_type=="alert") | .alert.signature' | \
  sort | uniq -c | sort -rn | head -10

Syslog-Weiterleitung

Für die Integration in ein zentrales SIEM leiten Sie EVE-JSON per Syslog weiter:

# OPNsense: System > Settings > Logging / targets
Target:     siem.example.com:5514
Transport:  TLS
Format:     JSON (EVE)

Regelentwicklungs-Workflow

Ein strukturierter Workflow für die Entwicklung und Pflege von Custom Rules:

1. Identifizieren: Bedrohung oder Policy-Anforderung erkennen
2. Entwickeln: Regel schreiben und in einer Testumgebung validieren
3. Testen: Regel im Alert-Only-Modus (alert) deployen
4. Beobachten: 1–2 Wochen auf False Positives prüfen
5. Tuning: Schwellenwerte und Suppress-Einträge anpassen
6. Aktivieren: Regel in den IPS-Modus (drop) umschalten
7. Dokumentieren: Regel-Zweck, Autor und Datum in der msg-Option festhalten

Testing mit replay

Testen Sie Regeln mit aufgezeichnetem Traffic:

# PCAP-Datei durch Suricata laufen lassen
suricata -r /tmp/test-traffic.pcap -l /tmp/suricata-test/ -S /tmp/custom.rules

# Ergebnisse prüfen
cat /tmp/suricata-test/eve.json | jq 'select(.event_type=="alert")'

Fazit

Custom Rules erweitern Suricata auf OPNsense von einem generischen IDS zu einem maßgeschneiderten Sicherheitswerkzeug. Der Schlüssel liegt in der Balance zwischen Erkennung und Performance: Schreiben Sie präzise Regeln mit engen Filtern, nutzen Sie Suppress-Lists statt Regeln zu deaktivieren, und testen Sie jede Änderung gründlich im Alert-Modus, bevor Sie Pakete droppen.