↓ Skip to main content
u-random
u-random
  1. Lab-blue/

[DONE] Lab - Suricata IPS inline (nfqueue): da IDS passivo a blocco attivo

·4 mins
intermedio
Network-Defense Threat-Hunting
Alessio Barnini
Author
Alessio Barnini
Table of Contents
[DONE] Lab - Suricata IPS inline (nfqueue): da IDS passivo a blocco attivo

Cosa fa
#

Trasforma Suricata da sensore passivo (vede il traffico, non lo blocca) a IPS inline (intercetta il traffico prima che arrivi al sistema). L'ingrediente chiave è iptables NFQUEUE: il kernel manda ogni pacchetto a Suricata, che decide accept o drop prima che il kernel lo consegni.

TL;DR
#

Kali (192.168.64.200) → attaccante: hping3 flood, nmap aggressivo
Ubuntu (192.168.64.3) → defender: Suricata in nfqueue, iptables NFQUEUE
Mac (192.168.64.1)    → osservatore: curl durante il flood per verificare il blocco

Differenza chiave:

  • IDS (af-packet): Suricata copia del traffico, logga, non può bloccare nulla
  • IPS (nfqueue): Suricata intercetta ogni pacchetto, decide, poi il kernel agisce

Obiettivo finale
#

Come sai che hai finito tutto:

  • hping3 -S --flood 192.168.64.3 da Kali → curl http://192.168.64.3 dal Mac → timeout durante il flood
  • nmap --min-rate 1000 -p 1-1000 192.168.64.3 → /var/log/suricata/fast.log mostra [Drop] con la regola custom
  • Dopo aver fermato il flood → curl dal Mac funziona di nuovo

Fase 0 — Installazione Suricata
#

  • Task 0 — Installa Suricata su Ubuntu
    • sudo apt update
sudo apt install suricata -y
suricata --version
    • Come sai che hai finito: suricata --version mostra la versione; /etc/suricata/suricata.yaml esiste

Fase 1 — Suricata IDS passivo (baseline)
#

  • Task 1 — Verifica che Suricata giri in af-packet (IDS)

    • systemctl status suricata — deve essere attivo
    • grep "af-packet" /etc/suricata/suricata.yaml — deve trovare la sezione abilitata
    • Come sai che hai finito: Suricata gira, nmap -sS 192.168.64.3 da Kali genera alert in fast.log ma il traffico non viene bloccato

  • Task 2 — Verifica che in modalità IDS il traffico NON venga bloccato

    • Da Kali: sudo hping3 -S --flood 192.168.64.3 per 5 secondi
    • Dal Mac: curl http://192.168.64.3 durante il flood
    • Come sai che hai finito: curl risponde normalmente anche durante il flood — Suricata vede ma non agisce

Fase 2 — Switch a IPS inline (nfqueue)
#

  • Task 3 — Modifica suricata.yaml: disabilita af-packet, abilita nfq

    • Commenta la sezione af-packet in /etc/suricata/suricata.yaml
    • Aggiungi/abilita la sezione nfq:
      nfq:
  mode: accept
  repeat-mark: 1
  repeat-mask: 1
  batchcount: 20
  fail-open: no
    • Come sai che hai finito: suricata -T -c /etc/suricata/suricata.yaml -v non dà errori

  • Task 4 — Modifica il servizio systemd per usare -q 0

    • systemctl edit suricata — aggiungi:
      [Service]
ExecStart=
ExecStart=/usr/bin/suricata -c /etc/suricata/suricata.yaml -q 0 --pidfile /run/suricata.pid
    • Come sai che hai finito: systemctl daemon-reload && systemctl restart suricata parte senza errori

  • Task 5 — Regola iptables: traffico in ingresso → NFQUEUE

    • sudo iptables -I INPUT -j NFQUEUE --queue-num 0
    • Come sai che hai finito: iptables -L INPUT -n mostra la regola NFQUEUE in prima posizione

Fase 3 — Regole custom con action drop
#

  • Task 6 — Crea file regole custom

    • Crea /etc/suricata/rules/local.rules con:
      drop tcp any any -> $HOME_NET any (msg:"IPS SYN Flood Drop"; flags:S; detection_filter:track by_src, count 100, seconds 1; sid:9000001; rev:1;)
drop tcp any any -> $HOME_NET any (msg:"IPS Aggressive Port Scan Drop"; flags:S; detection_filter:track by_src, count 20, seconds 1; sid:9000002; rev:1; classtype:network-scan;)
    • Aggiungi - local.rules in rule-files: dentro suricata.yaml
    • Come sai che hai finito: suricata -T -c /etc/suricata/suricata.yaml → "Configuration provided was successfully loaded"

  • Task 7 — Riavvia Suricata e verifica caricamento regole

    • systemctl restart suricata
    • grep "loaded" /var/log/suricata/suricata.log | tail -5
    • Come sai che hai finito: log mostra le regole caricate, inclusa la local.rules

Fase 4 — Test IPS in azione
#

  • Task 8 — SYN flood bloccato

    • Da Kali (terminal 1): sudo hping3 -S --flood 192.168.64.3
    • Dal Mac (terminal 2): curl --max-time 5 http://192.168.64.3
    • Come sai che hai finito: curl dà timeout durante il flood; dopo aver fermato hping3, curl funziona di nuovo

  • Task 9 — Port scan aggressivo bloccato

    • Da Kali: sudo nmap --min-rate 1000 -p 1-1000 192.168.64.3
    • Su Ubuntu: tail -f /var/log/suricata/fast.log
    • Come sai che hai finito: fast.log mostra [Drop] con il messaggio della regola 9000002; nmap vede molte porte come filtered

  • Task 10 — Confronta fast.log: IDS vs IPS

    • In IDS avevi [**] (alert). In IPS hai [Drop] (blocco effettivo).
    • Come sai che hai finito: sai rispondere — "perché in IDS il traffico arrivava comunque e in IPS no?"

Domande di verifica Security+
#

  1. Suricata in af-packet mode copia il traffico da un'interfaccia di rete. In nfqueue mode intercetta ogni pacchetto. Qual è il rischio operativo di nfqueue se Suricata si blocca?
  2. Un IDS genera un alert quando vede un port scan. Un IPS lo blocca. In quale scenario preferiresti un IDS a un IPS (hint: pensa ai falsi positivi)?
  3. La regola usa detection_filter:track by_src, count 20, seconds 1. Perché track by_src e non by_dst?
  4. fail-open: no significa che se Suricata si blocca, il traffico viene droppato (fail closed). fail-open: yes lo lascia passare. Quale è più sicuro? Quale è più disponibile?
  5. iptables NFQUEUE manda il pacchetto a Suricata prima di consegnarlo al kernel. Cosa succede alla latenza della connessione?

Collegato a
#

  • [[[TODO] lab-opencanary-honeypot|lab-opencanary-honeypot]] — detection complementare: honeypot rileva lateral movement che IPS non vede
  • [[[TODO] lab-router-acl-iptables|lab-router-acl-iptables]] — iptables base (prerequisito per NFQUEUE)
  • cap-04-securing-your-network — IDS vs IPS, signature-based vs anomaly-based, inline vs passive

Related