Capitolo: Gibson Cap 8 — Risk Management (Capturing Network Traffic) Concetti: nginx, WAF/ModSecurity, iptables LOG target, auth.log, tcpdump/Wireshark, log correlation
Obiettivo#
La topologia DMZ con Linux namespaces (wip.sh) è "finita" ma silenziosa: i listener netcat non producono log applicativi, e i firewall non loggano nulla. Questo lab la trasforma in un ambiente che produce log REALI da cinque fonti — firewall, nginx, WAF, auth, pcap — poi ti fa seguire UN SINGOLO evento attraverso tutte e cinque. È l'esercizio "leggi il pcap come leggi i log" di CARRIERA.md, applicato a un evento concreto.
Security angle: collega direttamente a Capturing Network Traffic (in scrittura) - packet capture, firewall log e WAF log sono esattamente i tool di questa sezione del capitolo.
Career correlation: è l'esercizio di observability/SIEM per eccellenza - correlare un evento attraverso log di rete, firewall e applicazione è quello che fa un detection engineer ogni giorno.
Ambiente#
- Kali (192.168.64.200): genera il traffico
- Ubuntu (192.168.64.3): ospita i namespace
ns-fw1/ns-sofia/ns-fw2/ns-giuliae il bridgebr-dmzda wip.sh
I namespace sono effimeri - se Ubuntu è stato riavviato dall'ultima sessione, ri-esegui wip.sh (e wip_kali.sh su Kali) prima di iniziare.
Parte 1 — Nginx reale in ns-sofia#
Obiettivo: sostituisci il listener netcat su ns-sofia con un nginx vero, in ascolto su 10.10.10.2:80, che serve una pagina qualsiasi (anche una index.html minima va benissimo - lo scenario è corsobitcoin.com). Da Kali, fai qualche richiesta con curl usando user-agent diversi.
Come sai che hai finito: ogni richiesta da Kali compare in access.log dentro ns-sofia, con IP sorgente, metodo, URL, status code e user-agent.
Parte 2 — WAF: ModSecurity + OWASP CRS davanti a nginx#
Obiettivo: aggiungi ModSecurity a nginx in ns-sofia. La configurazione di base è già scritta in [[[DONE] lab-dual-firewall-dmz-waf#Fase 4 — WAF nella DMZ (nginx + ModSecurity)|Fase 4 di lab-dual-firewall-dmz-waf]] - lì è pensata per un namespace ns-dmz separato che fa da proxy verso un backend. Qui adatta lo stesso principio (modsecurity on + modsecurity_rules_file + OWASP CRS) a ns-sofia, che serve il proprio contenuto direttamente — non serve proxy_pass. Parti in DetectionOnly, poi passa a On.
Da Kali manda tre richieste: una normale, una con payload SQLi (?id=1' OR '1'='1), una con payload XSS (?q=<script>alert(1)</script>).
Come sai che hai finito: in enforcement mode, le richieste SQLi/XSS ricevono 403, e il log di ModSecurity mostra QUALE regola CRS ha scattato per ciascuna (numeri di regola diversi per SQLi vs XSS).
Parte 3 — Firewall logging: cosa passa, cosa viene droppato#
Obiettivo: le regole iptables attuali di ns-fw1/ns-fw2 (da wip.sh) hanno solo target ACCEPT e una policy DROP finale - nessuna riga di log. Aggiungi regole con target LOG (con --log-prefix distinti) in modo da catturare SIA il traffico che viene accettato SIA quello che cade nella policy DROP di default.
Genera due tipi di traffico da Kali:
- traffico che
ns-fw1ACCETTA (es. la richiesta HTTP ans-sofiadella Parte 1/2) - traffico che viene DROPPATO (es. una richiesta diretta a
ns-giulia:3306- non è permessa dans-fw2perché la sorgente non èns-sofia)
Come sai che hai finito: trovi nei log del kernel (dove finiscono i messaggi LOG di iptables - scoprilo) due righe con prefissi diversi, una per il traffico accettato e una per quello droppato, e sai dire quale firewall (ns-fw1 o ns-fw2) ha generato ciascuna.
Parte 4 — Auth log sul jump host#
Obiettivo: Ubuntu (192.168.64.3) è anche il jump server da cui amministri il lab. Da Kali, genera alcuni tentativi SSH con credenziali sbagliate verso 192.168.64.3, poi un login riuscito.
Come sai che hai finito: in /var/log/auth.log (o journalctl -u ssh) distingui i tentativi falliti da quello riuscito, e identifichi l'IP sorgente (Kali) in entrambi i casi.
Parte 5 — Cattura con tcpdump/Wireshark#
Obiettivo: avvia una cattura su br-dmz (o sull'interfaccia veth più adatta) PRIMA di rifare la richiesta SQLi della Parte 2. Salva un .pcap. Aprilo (in Wireshark sul Mac via scp, o con tshark direttamente su Ubuntu) e trova il pacchetto/stream con il payload SQLi nell'URL.
Come sai che hai finito: isoli nel pcap il singolo stream TCP corrispondente alla richiesta SQLi, e vedi il payload (?id=1' OR '1'='1) in chiaro nel pacchetto HTTP.
Parte 6 — La correlazione: un evento, cinque fonti#
Obiettivo: prendi la STESSA richiesta SQLi e seguila attraverso tutte le fonti che hai costruito:
- pcap/Wireshark (Parte 5) - il pacchetto con il payload SQLi
- Firewall log di
ns-fw1(Parte 3) - la riga che mostra questo traffico ACCETTATO (porta 80, permessa) - ModSecurity log (Parte 2) - la riga con il 403 e la regola CRS che ha scattato
- nginx access/error log (Parte 1) - la riga corrispondente con status 403
Per ognuna annota: timestamp, IP/porta, e cosa quella fonte "vede" del payload SQLi (tutto? solo che è arrivato? solo che è stato bloccato?).
Come sai che hai finito: hai una tabella/timeline con 4 righe (una per fonte), stesso evento, e sai spiegare perché il firewall vede "traffico permesso verso porta 80" mentre il WAF vede "richiesta bloccata per SQLi" - stesso evento, livelli diversi. È la risposta concreta alla domanda "perché un IDS di rete e un WAF non vedono la stessa cosa" già toccata in [[[TODO] lab-nmap-footprinting-fingerprinting#Parte 4 — Lato difensore: cosa vede Ubuntu?|lab-nmap-footprinting-fingerprinting]].
Parte 7 (opzionale) — NetFlow: la versione "solo metadati"#
Obiettivo: installa softflowd su Ubuntu e avvialo sull'interfaccia br-dmz (o sul veth più adatto), per esportare record NetFlow verso un collector locale (nfcapd/nfdump, suite nfdump). Rigenera lo stesso traffico SQLi della Parte 2/5, poi leggi i record con nfdump.
Come sai che hai finito: nei record NetFlow vedi la 5-tuple (IP/porta sorgente e destinazione, protocollo), conteggio pacchetti/byte e durata del flow per la richiesta SQLi - ma NON vedi il payload: nessuna traccia di ?id=1' OR '1'='1. Confronta con il pcap della Parte 5: stesso traffico, due livelli di dettaglio completamente diversi - è la differenza descritta in NetFlow.
Nota:
ntopng(già nel piano del Mustache Project come collector NetFlow) è l'alternativa GUI anfdump- utile più avanti quando il resto dello stack (Wazuh/Suricata) sarà operativo.
Per andare oltre (opzionale)#
- DetectionOnly vs On: ripeti la Parte 2/6 in
DetectionOnly- il payload arriva ancora a nginx (e finisce in access.log con 200), ma ModSecurity lo segnala senza bloccare. Confronta i due comportamenti nei log. - Tcpreplay contro Suricata: quando Suricata sarà operativo (Mustache Fase 3-4), rispedisci il pcap della Parte 5 con
tcpreplaye verifica che generi un alert per la richiesta SQLi - vedi Triaging and Tcpdump. Se l'alert non scatta, è un test di regressione fallito sulla regola Suricata, non sul lab.
Collegato a#
- Capturing Network Traffic - la teoria di questo lab
- [[[DONE] lab-dual-firewall-dmz-waf|lab-dual-firewall-dmz-waf]] - configurazione nginx + ModSecurity di riferimento
- linux-namespaces-dmz - la topologia di base che questo lab espande
- [[[TODO] lab-nmap-footprinting-fingerprinting|lab-nmap-footprinting-fingerprinting]] - stesso tema "cosa vede ogni log", scenario diverso
