Difesa on u-random

Il Kernel Sospende il Giudizio

Fri, 29 May 2026 00:00:00 +0000

TL;DR

IDS (af-packet): copia del traffico → Suricata vede tutto, non può bloccare niente → [**] in fast.log
IPS (nfqueue): traffico originale trattenuto → il kernel aspetta il verdetto → [Drop] in fast.log
iptables -I INPUT -j NFQUEUE --queue-num 0 è la singola regola che trasforma il sistema
fail-open: no = fail-closed: se Suricata muore, tutto il traffico viene droppato
Il Docker bridge (br-XXXX) bypassa NFQUEUE - la SYN-ACK di ritorno viene bloccata e Wazuh si disconnette
La persistenza al reboot richiede un systemd service dedicato (non iptables-persistent, che rimuove UFW)

▶ $ history

suricata -T -c /etc/suricata/suricata.yaml -v
suricata-update
iptables -I INPUT 1 -j NFQUEUE --queue-num 0
iptables -L INPUT -n -v --line-numbers
nmap --min-rate 1000 -p 1-1000 192.168.64.3
hping3 -S --flood 192.168.64.3
cat /proc/net/tcp

Voglio vedere cosa succede quando Suricata non si limita a guardare il traffico, ma lo blocca davvero.

Il Fantasma nella Rete

Tue, 19 May 2026 00:00:00 +0000

TL;DR

Un honeypot è un sistema esca - qualsiasi connessione ricevuta è per definizione sospetta
La ricognizione interna (lateral movement iniziale) lascia tracce nei log prima che l'attaccante agisca
Analizzare chi ha contattato il honeypot rivela quali host sono compromessi o controllati da un attaccante
IDS/IPS signature-based non rileva zero-day - il comportamento anomalo verso risorse inesistenti lo fa

▶ $ history

tshark -r capture.pcap -Y "ip.dst == 192.168.10.99" -T fields -e ip.src -e tcp.dstport
dig -x 192.168.10.99

Sono le 14:33. Il SIEM ha flaggato una connessione TCP verso 192.168.10.99. Il problema: a quell'IP non c'è nessun server. Non c'è nessun servizio. Non c'è nessun device registrato nell'inventario.

Il Postino Lavora di Notte

Tue, 19 May 2026 00:00:00 +0000

TL;DR

SMTP consegna le email, IMAP/POP3 le recuperano - protocolli separati con porte e ruoli distinti
Una workstation che apre connessioni dirette sulla porta 25 è anomala: quel traffico spetta al mail server aziendale
base64 negli allegati non è cifratura: su SMTP senza TLS, qualsiasi allegato è estraibile dal pcap in chiaro
SPF, DKIM e DMARC sono i tre record DNS che distinguono un dominio difeso da uno esposto allo spoofing

▶ $ history

tshark -r capture.pcap -Y "smtp" -T fields -e ip.src -e ip.dst -e smtp.req.command -e smtp.req.parameter
dig MX dominio.com
dig TXT _dmarc.dominio.com