Perché confrontare le tecnologie firewall
In un SOC devi sapere cosa vede ogni dispositivo di controllo del traffico, perché la profondità dell’ispezione determina quali eventi finiscono nei log e nel SIEM. I firewall si sono evoluti da semplici filtri di pacchetti fino ai NGFW con NGIPS integrato, e ogni livello aggiunge contesto ma introduce anche punti ciechi.
Le quattro generazioni a confronto
| Tecnologia | Livello OSI | Cosa ispeziona | Limite principale |
|---|---|---|---|
| Packet-filtering (stateless) | L3-L4 | IP sorgente/destinazione, protocollo, porte, flag | Nessuna memoria dello stato: valuta ogni pacchetto isolato |
| Stateful firewall | L3-L4 (+ tracking) | Come sopra + state table delle connessioni | Non guarda il payload applicativo |
| Application/Proxy firewall | fino a L7 | Termina la sessione e ispeziona il protocollo (HTTP, FTP, DNS) | Alta latenza, un proxy per protocollo, scalabilità |
| NGFW / NGIPS | L3-L7 | DPI, application visibility (AVC), IPS signatures, URL filtering, reputation | Punto cieco sul traffico cifrato senza decryption |
Il packet-filtering con ACL consente/nega in base a header L3-L4: veloce ma facilmente aggirabile perché non sa se un pacchetto TCP appartiene a una sessione legittima. Lo stateful firewall mantiene una state table e ammette il traffico di ritorno solo se corrisponde a una connessione già stabilita (three-way handshake tracciato), bloccando pacchetti spoofati fuori sessione. L’application/proxy firewall agisce come intermediario: termina la connessione client, la ispeziona a L7 e ne apre una nuova verso il server, ottenendo visibilità profonda al costo di prestazioni e complessità.
Il ruolo del Deep Packet Inspection
Il NGFW (in Cisco Firepower/FTD gestito da FMC) unisce lo stateful firewalling al Deep Packet Inspection: non si ferma agli header ma legge il payload. Questo abilita:
- AVC (Application Visibility and Control) — riconosce l’applicazione reale (es. Facebook, BitTorrent) indipendentemente dalla porta, sconfiggendo l’evasion via porte non standard.
- NGIPS — motore Snort con signature per rilevare exploit, malware C2, anomalie di protocollo.
- URL filtering e Security Intelligence basati su reputation e feed di threat intelligence.
Il DPI è ciò che trasforma un flusso in evento investigabile: senza di esso il SOC vede solo tuple IP:porta.
Cosa erode la visibilità del monitoring
Diverse tecniche, legittime o malevole, riducono ciò che gli strumenti riescono a osservare:
- NAT/PAT — traduce molti host interni dietro un unico IP pubblico. Nei log esterni l’IP sorgente reale scompare: senza correlare le tabelle NAT non riesci ad attribuire un’azione all’host interno (attribution problem).
- Encryption — HTTPS/TLS, SSH, VPN cifrano il payload. Il DPI vede solo header IP/TCP e metadati; le signature IPS che cercano pattern nel contenuto diventano cieche.
- Tunneling — incapsulare un protocollo dentro un altro (es. traffico dati dentro DNS o ICMP, o dentro HTTPS) nasconde la natura reale del flusso e bypassa le ACL basate su porta.
- TOR — instrada il traffico attraverso relay cifrati a più hop: sorgente e destinazione reali sono offuscate, l’analisi si ferma all’entry/exit node.
- P2P — protocolli come BitTorrent usano porte dinamiche, crittografia ed encapsulation, rendendo difficile classificazione e attribuzione dei flussi.
Perché il traffico cifrato è il vero punto cieco
Un NGFW può fare tutto il DPI del mondo, ma su un flusso TLS vede solo il ciphertext: dominio SNI (se non ESNI/ECH), certificato, dimensioni e timing dei pacchetti — non il payload. Per ispezionare davvero il contenuto serve la TLS/SSL inspection (SSL decryption), in cui l’FTD agisce da proxy man-in-the-middle autorizzato: decifra, applica NGIPS/AVC/URL filtering, poi ri-cifra verso la destinazione. È la contromisura corretta quando lo scenario chiede di rilevare malware o C2 dentro HTTPS. Va però bilanciata con impatto su CPU, privacy e certificate pinning.
Trappole tipiche d’esame
- Il traffico è cifrato (HTTPS) e l’IPS non rileva la signature del malware → applicare TLS/SSL inspection (decryption), non “aumentare le signature”: senza decrypt il payload resta invisibile.
- Serve consentire il traffico di ritorno solo per sessioni iniziate dall’interno → stateful firewall (usa la state table), non un packet-filter stateless che valuta ogni pacchetto isolatamente.
- Un IP pubblico compare in mille sessioni e non riesci a identificare l’host interno → è l’effetto di NAT/PAT: correla le tabelle NAT per l’attribution, non è di per sé un attacco.
- Un’app usa porte dinamiche/non standard per eludere le ACL → serve NGFW con AVC/DPI che identifica l’applicazione a L7, non un filtro basato sul numero di porta.
- Traffico anomalo verso molti relay cifrati / uso di TOR o tunneling DNS → indicatore di offuscamento/exfiltration: la risposta corretta riconosce la perdita di visibilità, non “traffico normale perché la porta 53/443 è consentita”.