Suricata IDS/IPS pe Linux: Ghid 2026

Q: Cum îmi actualizez regulile Suricata automat?

Programează suricata-update cu un timer systemd la 6 ore și apoi suricatasc -c reload-rules pentru reîncărcare fără restart. În pipeline-uri CI/CD, versionează disable.conf / enable.conf într-un repo Git și declanșează validarea pe capturi PCAP la fiecare PR pentru a preveni regresii.

Actualizat: 18 septembrie 2026

Suricata este un motor open-source de detectare și prevenire a intruziunilor de rețea (NIDS/NIPS) care inspectează traficul în timp real, decodează protocoale la nivel aplicație (HTTP, TLS, DNS, SMB, QUIC) și emite alerte structurate în format JSON, gata pentru orice pipeline SIEM. În 2026, versiunea stabilă recomandată este Suricata 8.0.6 (7 iulie 2026), cu runtime plugins, opt protocoale noi, fingerprinting JA4 și parseri LibHTP mutați în Rust. Ghidul de față arată cum îl instalez și îl operez într-un flux DevSecOps: instalare, reguli ET Open, mod IDS pasiv cu AF_PACKET, mod IPS in-line cu NFQUEUE, tuning multi-thread și trimiterea EVE JSON către Wazuh sau OpenSearch.

Suricata 8.0.6, lansat pe 7 iulie 2026, aduce plugins runtime, JA4, opt protocoale noi și parseri Rust; ramura 7.0 rămâne LTS până la 7.0.17.
Modul IDS folosește AF_PACKET pentru captură pasivă zero-copy. Modul IPS folosește NFQUEUE cu nftables pentru a bloca pachete in-line.
Regulile publice provin din ET Open (Emerging Threats) și se gestionează cu suricata-update. Regulile Snort Talos rămân doar plătite după 2024.
EVE JSON este ieșirea unificată, o singură linie pe eveniment, ingerată direct de Wazuh, Filebeat sau Vector, fără parsere personalizate.
Pe hardware modern de 8 core, Suricata atinge ~6,5 Gbps cu ~30.000 de reguli active. Ajustarea threading.yaml și RSS pe placa de rețea contează mai mult decât CPU-ul brut.
CVE-2026-45764 (RCE prin trafic de rețea) a fost publicat în mai 2026. Instalările sub 8.0.5 sau 7.0.16 trebuie actualizate imediat.

Pentru ce este folosit Suricata?

Suricata este folosit pentru trei sarcini distincte care se activează din același binar prin flag-uri: detectarea intruziunilor de rețea (IDS), prevenirea in-line a acestora (IPS) și monitorizarea rețelei pentru vizibilitate (NSM). În mod IDS, procesul citește pachete pasiv dintr-un port mirror sau tap SPAN și emite alerte când traficul se potrivește cu semnături. În mod IPS, se așează între două interfețe sau primește pachete prin NFQUEUE și le dropează în timp real. În mod NSM, produce fluxuri și tranzacții protocolare (HTTP, TLS, DNS, files) care alimentează instrumente de threat hunting precum documentația Zeek sau OpenSearch.

În 2026, Suricata acoperă un set larg de protocoale: HTTP/1.1, HTTP/2, HTTP/3 (QUIC), TLS 1.3, SMB2/3, Kerberos, MQTT, DHCP, DCERPC și cele opt protocoale adăugate în 8.0 (POP3, IMAP, LDAP, SIP, RDP-lite, MODBUS variant, ENIP, extra CANopen). Amprentarea JA4 înlocuiește JA3 cu un identificator mai stabil pentru clienți TLS, foarte util în detectarea malware-ului care rotește certificatele dar păstrează stiva TLS. Sincer, pentru echipa mea DevSecOps, Suricata este senzorul care umple golul dintre firewall (blochează prin porturi și CIDR) și HIDS-uri precum Wazuh (văd doar ce se întâmplă pe host). Vede protocolul, nu doar tuple 5-tuple, și de aceea prinde command-and-control care tunelează prin DNS sau HTTPS pe porturi permise.

Suricata vs Snort vs Zeek: care este diferența?

Alegerea între Suricata, Snort și Zeek e întrebarea zero pentru orice echipă care evaluează IDS-uri open-source. Cele trei nu sunt echivalente funcțional: Snort și Suricata sunt motoare bazate pe semnături care emit alerte discrete, în timp ce Zeek (fostul Bro) este un analizor de trafic bazat pe scripturi care produce jurnale bogate pentru investigații. Tabelul de mai jos rezumă dimensiunile care contează în producție în 2026:

Dimensiune	Suricata 8.0	Snort 3	Zeek 6
Model detecție	Semnături + scripturi Lua + JA4	Semnături	Scripturi bazate pe evenimente
Threading	Multi-thread nativ, N workeri pe RSS queue	Multi-thread (Snort 3), still limitat	Multi-proces (cluster), un thread per worker
Mod IPS in-line	Da (NFQUEUE, AF_PACKET IPS, DPDK)	Da (DAQ inline)	Nu (doar pasiv)
Throughput pe 8 core, ~30k reguli	~6,5 Gbps	~3,5 Gbps	N/A (măsurat diferit)
Ieșire structurată	EVE JSON unificat	u2spewfoo → JSON manual	Log-uri per protocol (conn, dns, http, ssl)
Reguli comunitare	ET Open (gratuit), ET Pro (comercial)	Snort Registered / Talos (plătit din 2024)	Nu are reguli; ai scripturi
Curbă de învățare	Medie	Redusă spre medie	Ridicată (Zeek scripting)
Licență	GPL-2	GPL-2	BSD-3-Clause

În practică, dacă ai deja Wazuh sau ELK, Suricata e cel mai simplu de conectat pentru că EVE JSON este first-class citizen. Zeek strălucește la threat hunting pe date normalizate (fluxuri complete, tranzacții HTTP cu toate anteturile), dar necesită Python/Zeek scripting și un pipeline separat. Snort 3 rămâne o opțiune validă mai ales pe cutii mici, deși feed-ul Talos gratuit a devenit „Registered”-only. În echipa mea am migrat integral pe Suricata + ET Open din motive de licențiere și throughput. „Suricata îți spune ce s-a stricat; Zeek îți spune tot ce s-a întâmplat înainte”, iar combinarea celor două în modul pipeline paralel este pattern-ul recomandat de documentația oficială Suricata.

Cum instalez Suricata 8.0 pe Ubuntu și Debian?

Pachetele oficiale sunt menținute de OISF în PPA-ul ppa:oisf/suricata-stable pentru Ubuntu. Pentru Debian sunt disponibile în backports, dar recomandarea mea (după ce am ars vreo două după-amiezi la asta) este să compilezi din surse când vrei să activezi DPDK sau AF_XDP. Flag-urile default din pachet sunt echilibrate pentru captură AF_PACKET pe NIC-uri obișnuite. Pentru cele mai multe echipe, PPA-ul e suficient și oferă upgrade rapid pentru vulnerabilități, cum a fost CVE-2026-45764 patch-ul din mai 2026.

# Ubuntu 24.04 LTS și 26.04 LTS
sudo add-apt-repository ppa:oisf/suricata-stable
sudo apt update
sudo apt install -y suricata suricata-update jq

# Verifică versiunea și capabilitățile compilate
suricata --build-info | head -30
suricata --version   # așteaptă 8.0.6 sau mai nou

# Directoare importante
ls -la /etc/suricata/       # suricata.yaml, threshold.config
ls -la /var/lib/suricata/rules/   # reguli descărcate de suricata-update
ls -la /var/log/suricata/   # eve.json, fast.log, stats.log

La primul pornit, procesul rulează ca suricata/suricata (nu ca root) și capătă capabilitățile CAP_NET_RAW și CAP_NET_ADMIN prin unitatea systemd. Verifică imediat că unitatea a pornit fără erori și că interfața de captură este listată corect în suricata.yaml. În laboratoare, un test rapid e să generezi trafic curator cu curl http://testmynids.org/uid/index.html. Regula ET Open 2100498 se declanșează și o vezi în /var/log/suricata/fast.log.

Configurarea modului IDS cu AF_PACKET

Modul IDS este cel mai frecvent în producție pentru că nu introduce latență și nu poate cădea circuit. Suricata folosește AF_PACKET cu socket-uri PACKET_MMAP și balansare pe hash-uri pentru a distribui pachete la worker threads. Configurația canonică pentru o placă cu 4 cozi RSS arată așa (fragment din /etc/suricata/suricata.yaml):

af-packet:
  - interface: ens5f0
    threads: 4                # = numărul de cozi RSS active
    cluster-id: 99
    cluster-type: cluster_flow   # hash pe (src,dst,proto)
    defrag: yes
    use-mmap: yes
    ring-size: 200000
    block-size: 1048576
    tpacket-v3: yes
    checksum-checks: kernel   # lasă kernel-ul să valideze checksums
    copy-mode: none           # 'none' = pur pasiv IDS

Pentru balansare corectă a fluxurilor pe workeri, activez RSS pe placa de rețea și fixez numărul de cozi la numărul de workeri Suricata:

# Verifică suportul RSS
ethtool -x ens5f0

# Setează 4 cozi RSS și dezactivează offload-urile care rup DPI
sudo ethtool -L ens5f0 combined 4
for feat in tso gso gro lro; do
  sudo ethtool -K ens5f0 $feat off
done

# Pornește Suricata cu interfața specifică
sudo systemctl edit --full suricata.service
# Modifică ExecStart să includă:
#   ExecStart=/usr/bin/suricata -c /etc/suricata/suricata.yaml --af-packet=ens5f0
sudo systemctl daemon-reload
sudo systemctl restart suricata

Dezactivarea offload-urilor pare contraintuitivă (parcă pierzi performanță), dar TSO/GSO reasamblează pachete în kernel și livrează segmente „false” care încurcă parserii TCP/HTTP. Regula mea: TSO/GSO/GRO/LRO off pe interfața de captură, on pe cea de management. Odată pornit, verifici că workerii încarcă echilibrat cu suricatasc -c iface-stat și că numărul de drop-uri de kernel rămâne aproape de zero. Pierderi peste 0,1% înseamnă că ring-size este prea mic sau că CPU-urile sunt saturate.

Trecerea în mod IPS cu NFQUEUE și nftables

Modul IPS in-line pune Suricata pe drumul pachetelor. Cea mai simplă abordare pe Linux modern este NFQUEUE cu nftables: nftables redirecționează pachetele către o coadă în user-space, Suricata le inspectează și emite verdicte (ACCEPT/DROP). Această schemă e preferată pentru servere Linux fără plăci dedicate. Pentru echipamente cu multe zeci de Gbps se folosește DPDK sau AF_XDP, dar complexitatea crește semnificativ.

# /etc/nftables.conf — trimite pachete FORWARD către NFQUEUE 0..3
table inet filter {
  chain forward {
    type filter hook forward priority 0; policy drop;

    ct state established,related accept
    ct state invalid drop

    # Trimite restul la Suricata (balansat pe 4 cozi)
    counter queue num 0-3 fanout bypass
  }
}

Opțiunea fanout distribuie pachete pe cele patru cozi în funcție de hash-ul fluxului. Opțiunea bypass lasă pachetele să treacă dacă Suricata nu este pornit (fail-open). În suricata.yaml activez modul NFQUEUE:

nfq:
  mode: repeat           # 'repeat' = verdict + set mark pt. restul lanțului
  repeat-mark: 1
  repeat-mask: 1
  route-queue: 2
  batchcount: 20         # câte pachete pe iterație
  fail-open: yes         # ACCEPT dacă coada e plină

# Pornește ca IPS pe cozile 0..3
# /usr/bin/suricata -c /etc/suricata/suricata.yaml -q 0 -q 1 -q 2 -q 3

Ca să blochezi efectiv, regulile trebuie să folosească acțiunea drop, nu alert. Multe reguli ET Open sunt de tip alert; le convertesc selectiv cu suricata-update enable-source et/open și un fișier modify.conf care rescrie prefixele pentru clase specifice de amenințări (ex. exploit-uri cunoscute), lăsând alertele curioase în alert-only. Din experiență, transformi în drop doar 5–10% dintre reguli; restul rămâne în tap mode pentru vizibilitate.

Reguli ET Open și suricata-update

Regulile sunt inima Suricata. Există trei mari surse: ET Open (gratuit, ~40.000 de reguli, actualizat zilnic), ET Pro (comercial, ~70.000, feed prioritar) și fragmente contribuite de comunitate. Snort Talos, gratuit până în 2024, este acum „Registered”-only și necesită oink code pentru download. Utilitarul suricata-update este cel oficial de gestionare: descarcă, verifică semnături, dezactivează selectiv reguli și generează fișierul unificat /var/lib/suricata/rules/suricata.rules.

# Listează sursele configurate
suricata-update list-sources

# Activează ET Open (deja activat implicit)
suricata-update enable-source et/open

# Descarcă și compilează regulile
sudo suricata-update

# Dezactivează reguli zgomotoase (ex. false-positive pe update-urile Windows)
echo '2013504' | sudo tee -a /etc/suricata/disable.conf
sudo suricata-update

# Reîncarcă regulile fără restart (rulling reload)
sudo suricatasc -c reload-rules

Ajustarea regulilor este 80% din munca DevSecOps pe Suricata. În pipeline-uri productive, țin un repo Git cu disable.conf, enable.conf, modify.conf și drop.conf. Fiecare PR de tuning trece printr-o suită de teste care rulează Suricata offline pe capturi PCAP salvate (traficul propriu al aplicațiilor plus PCAP-uri publice de la Malware-Traffic-Analysis.net) și verifică că regulile relevante încă se declanșează. Este singurul mod fiabil de a-ți evita alert fatigue.

EVE JSON și integrare cu Wazuh sau OpenSearch

EVE JSON e ieșirea unificată, o linie per eveniment, cu câmpuri normalizate (timestamp, flow_id, src_ip, dst_ip, event_type, tx_id). Toate parserele emit în același format: alert, flow, http, tls, dns, fileinfo, anomaly. Fișierul /var/log/suricata/eve.json este ingerat direct de aproape orice SIEM. În ghidul meu pentru instalarea Wazuh pentru detectarea intruziunilor arăt pipeline-ul complet. Aici mă rezum la partea Suricata.

# /etc/suricata/suricata.yaml — activează EVE JSON cu rotire pe timp
outputs:
  - eve-log:
      enabled: yes
      filetype: regular
      filename: /var/log/suricata/eve.json
      rotate-interval: hour
      types:
        - alert:
            payload: yes
            payload-printable: yes
            packet: yes
            metadata: yes
        - http:
            extended: yes
        - dns:
            query: yes
            answer: yes
        - tls:
            extended: yes
            ja4: yes         # nou în 8.0
        - flow
        - anomaly
        - stats:
            totals: yes
            threads: no
            deltas: no

Pentru Wazuh, agentul deja știe să citească EVE JSON dacă activezi decodorul suricata:

<!-- /var/ossec/etc/ossec.conf pe agent -->
<localfile>
  <log_format>json</log_format>
  <location>/var/log/suricata/eve.json</location>
</localfile>

Pentru OpenSearch/ELK folosesc Vector pentru că e mai eficient decât Filebeat pentru volume mari și permite enrichment local (GeoIP, MISP lookup, dropping de câmpuri sensibile). Ce nu recomand: să scrii un parser propriu. EVE este stabil, iar orice tool serios îl acceptă nativ. Dacă vrei corelații mai complexe (host + rețea), împrietenesc Suricata cu CrowdSec ca IPS comunitar. CrowdSec preia alertele EVE ca sursă și adaugă blocklist-ul comunitar deasupra.

Tuning multi-thread, RSS și performanță

Suricata scalează liniar cu numărul de cozi RSS ale plăcii de rețea dacă threading-ul este corect configurat. Cheia este ca fiecare worker thread să fie pinned pe același core NUMA cu coada RSS care îi livrează pachete; altfel plătești cache miss-uri și pierzi 30–40% din throughput. Reglez threading în threading.yaml:

threading:
  set-cpu-affinity: yes
  cpu-affinity:
    - management-cpu-set:
        cpu: [ 0 ]                  # ține managementul departe
    - receive-cpu-set:
        cpu: [ 1 ]
    - worker-cpu-set:
        cpu: [ 2, 3, 4, 5 ]         # 4 workeri pentru 4 cozi RSS
        mode: exclusive
        prio:
          low: [ 0 ]
          medium: [ 1 ]
          high: [ 2, 3, 4, 5 ]
          default: high
  detect-thread-ratio: 1.0          # 1 thread detect per worker

Pentru volume peste 5 Gbps activez hyperscan ca motor de pattern matching (mult mai rapid decât Aho-Corasick) și cresc ring-size la 500.000. Măsor cu suricatasc -c iface-stat și cu Prometheus prin exporterul suricata_exporter. Metricile pe care le urmăresc: capture.kernel_drops (trebuie ≈ 0), tcp.reassembly_gap, flow.memcap și detect.alert. Când memcap se lovește, mărește flow.memcap la 4 GB sau reduce flow.emergency-recovery.

Pipeline CI/CD: validare reguli și rulări canary

Am promis pipeline-first, așa că iată snippet-ul CI-ready pentru validarea regulilor Suricata înainte de deploy. Fiecare PR care modifică disable.conf, enable.conf sau adaugă reguli custom rulează un job GitHub Actions care compilează regulile, verifică syntaxa și rulează suita de PCAP-uri de regresie. Falsi pozitivi noi sau reguli care nu se declanșează pe capturile de atac blochează merge-ul.

# .github/workflows/suricata-rules.yml
name: suricata-rules
on: [pull_request]

jobs:
  validate:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4

      - name: Install Suricata 8.0
        run: |
          sudo add-apt-repository -y ppa:oisf/suricata-stable
          sudo apt-get update
          sudo apt-get install -y suricata suricata-update jq

      - name: Build ruleset with tuning
        run: |
          sudo cp rules/disable.conf /etc/suricata/
          sudo cp rules/enable.conf /etc/suricata/
          sudo cp rules/modify.conf /etc/suricata/
          sudo suricata-update --no-test

      - name: Syntax check
        run: sudo suricata -T -c /etc/suricata/suricata.yaml -v

      - name: Regression run on saved PCAPs
        run: |
          mkdir -p out
          for pcap in tests/pcaps/*.pcap; do
            name=$(basename "$pcap" .pcap)
            sudo suricata -r "$pcap" -l "out/$name" \
              -c /etc/suricata/suricata.yaml --set outputs.1.eve-log.enabled=yes
            jq -r '.alert.signature_id // empty' "out/$name/eve.json" \
              | sort -u > "out/$name.sids"
          done
          diff -u tests/expected/ out/*.sids

Pentru rulările canary în producție, folosesc două instanțe Suricata pe aceeași sursă de trafic: instanța „stable” aplică politica curentă, iar cea „candidate” aplică regulile din PR. Compar alert.signature_id-urile emise de fiecare pe 24 de ore. Dacă instanța candidate crește false-positive-urile peste un prag (spun 10%), promoția eșuează. Pattern-ul e similar cu ce descriu în ghidul Falco cu eBPF pentru runtime security pentru securitatea runtime pe host. Ideea de „shadow deployment” pentru reguli de securitate reduce dramatic incidentele (am prins așa un fals-pozitiv într-un roll-out care ar fi tăiat două aplicații interne).

Întrebări frecvente

Este Suricata IDS sau IPS?

Suricata este ambele. Același binar rulează în mod IDS (pasiv, cu AF_PACKET pe port mirror sau tap SPAN, emite doar alerte) sau în mod IPS (in-line, prin NFQUEUE cu nftables sau prin DPDK, dropează pachete pe verdict de regulă). Alegerea se face prin flag-uri de pornire și tipul acțiunilor din reguli (alert vs drop).

Cât RAM și CPU consumă Suricata în producție?

Pentru ~30.000 de reguli active și trafic 1 Gbps, alocă minim 4 GB RAM și 4 core-uri. La 10 Gbps, planifică 16 GB RAM și 8–16 core-uri, cu hyperscan activat. Memoria consumată depinde mai mult de flow.memcap și stream.memcap decât de reguli. Reglează aceste plafoane pentru a evita drop-urile de reasamblare.

Este Suricata mai bun decât Snort?

Pentru cele mai multe deployment-uri noi în 2026, da. Suricata are multi-threading matur, ieșire EVE JSON unificată, JA4 fingerprinting și acces liber la ET Open, în timp ce feed-ul Talos al Snort este acum „Registered”-only. Snort 3 rămâne o opțiune validă pe hardware mic și pentru echipele deja familiarizate.

Cum îmi actualizez regulile Suricata automat?

Programează suricata-update cu un timer systemd la 6 ore și apoi suricatasc -c reload-rules pentru reîncărcare fără restart. În pipeline-uri CI/CD, versionează disable.conf/enable.conf într-un repo Git și declanșează validarea pe capturi PCAP la fiecare PR pentru a preveni regresii.

Suricata poate inspecta trafic TLS 1.3 criptat?

Suricata extrage metadate din handshake-ul TLS 1.3 (SNI, ALPN, JA4, versiune, cifruri) și poate declanșa alerte pe aceste câmpuri, dar nu descifrează payload-ul fără terminare TLS anterioară. Pentru inspecția payload-ului cripta, cuplează Suricata cu un proxy TLS-terminating (mitmproxy, HAProxy cu ssl bump) sau folosește ETA/JA4 pentru clasificare comportamentală.