NGFW e NGIPS: capacità a confronto
Nel mondo Cisco Secure Firewall convivono due paradigmi complementari. Un Next-Generation Firewall (NGFW) parte dal firewall stateful classico e aggiunge intelligenza applicativa; un Next-Generation IPS (NGIPS) si concentra sull’ispezione profonda del traffico per bloccare exploit e intrusioni. Capire dove finisce uno e comincia l’altro è il cuore di molte domande d’esame.
Cosa fa un NGFW
Un NGFW combina in un unico dispositivo diverse funzioni:
- Stateful inspection: tiene traccia dello stato delle connessioni (la connection table) e permette il traffico di ritorno solo se coerente con un flusso iniziato dall’interno.
- Application Visibility and Control (AVC): riconosce l’applicazione a Layer 7 indipendentemente dalla porta. Distingue Facebook da Facebook-chat, o consente HTTP ma blocca un file-transfer applicativo, cosa che un firewall port-based non può fare.
- URL Filtering: classifica gli URL per categoria e reputazione, bloccando ad esempio la categoria “gambling” o siti a bassa reputazione, con dati aggiornati dal cloud Talos.
- AMP (Advanced Malware Protection / Secure Endpoint): analisi dei file in transito con file reputation, e sandboxing (Threat Grid / Secure Malware Analytics) per i verdetti sconosciuti; supporta la retrospective detection, cioè il ri-verdetto di un file già passato quando la sua reputazione cambia.
Cosa fa un NGIPS
Il NGIPS esegue deep packet inspection e prevenzione delle intrusioni tramite il motore Snort. Confronta il traffico con set di regole/firme (le SNORT rules aggiornate da Talos) per rilevare exploit noti, tentativi di buffer overflow, C2 di malware, evasion. Opera inline (bloccante, mode drop) o in IDS/passive (solo detection). Include tecnologie come Security Intelligence (blacklist IP/URL/DNS reputation-based) e la Firepower discovery per il context (host, OS, app) che alimenta le recommended rules.
Il punto chiave: un NGIPS “puro” non è progettato per fare policy di firewalling. Non gestisce NAT, non termina VPN, non applica regole di access-control basate su zone/interfacce nello stesso modo di un firewall. È un motore di ispezione, non il perimetro.
FTD: l’unione di ASA e Firepower
Cisco Secure Firewall Threat Defense (FTD) è l’immagine software unificata che fonde le funzioni di routing/firewalling ereditate da ASA con le funzioni NGIPS/AVC/AMP/URL di Firepower. Un solo sistema operativo, un solo data plane, che offre sia stateful firewall + NAT + VPN sia l’ispezione avanzata Snort. FTD gira su appliance della serie Firepower 1000/2100/3100/4200, su ASA hardware compatibile e su FTDv in ambienti virtuali/cloud.
FMC vs FDM: i due modelli di gestione
| Aspetto | FDM (Firepower Device Manager) | FMC (Firepower/Secure Firewall Management Center) |
|---|---|---|
| Tipo | On-box, integrato nel singolo FTD | Off-box, appliance/VM centralizzata |
| Scala | Un dispositivo alla volta | Molti FTD gestiti insieme, policy condivise |
| Funzioni avanzate | Sottoinsieme delle feature | Correlazione eventi, reporting, HA, feature complete |
| Uso tipico | Deployment piccolo/singolo | Enterprise, molti sensori |
FMC è anche il punto di raccolta degli eventi di intrusione e la console dove si costruiscono le Access Control Policy con le regole che invocano l’Intrusion Policy e la File Policy.
Snort 2 vs Snort 3
FTD ha migrato dal motore Snort 2 al Snort 3. Differenze rilevanti: Snort 3 è multi-thread (Snort 2 era sostanzialmente single-thread per processo), offre performance superiori, sintassi delle regole più moderna e flessibile, e supporto migliore per l’ispezione. Dalle versioni recenti Snort 3 è il motore di default sui nuovi deploy FTD; la scelta del motore si fa a livello di device in FMC/FDM.
Trappole tipiche d’esame
- Scenario: serve controllo applicativo L7, URL filtering e blocco malware sui file → risposta: NGFW/FTD, non un IPS puro. L’IPS ispeziona per intrusioni ma non è la sede naturale di AVC+URL+AMP come policy perimetrale.
- Scenario: serve NAT, VPN site-to-site/RA e routing sul dispositivo di sicurezza → FTD (eredità ASA). Un NGIPS “puro” non termina VPN né fa NAT.
- Scenario: gestione centralizzata di molti firewall con reporting/correlazione e HA → FMC; un singolo FTD stand-alone senza esigenze di scala → FDM on-box. Non confondere i due manager.
- Scenario: il file era “clean” ieri, oggi risulta malevolo e va rilevato a posteriori → AMP retrospective detection, funzione dell’engine malware, non delle firme Snort.
- Scenario: serve massimizzare le performance di ispezione con multi-threading → Snort 3 (Snort 2 è la versione legacy, prevalentemente single-thread).