Cisco Zone-Based Policy Firewall

A metà degli anni ’90, quando le grandi reti aziendali iniziarono ad essere collegate alle reti pubbliche (per definizione meno sicure), gli amministratori di rete attenti alla sicurezza iniziarono immediatamente a sentire la necessità di proteggere le proprie infrastrutture interne dai potenziali intrusi. I vendor di soluzioni e apparati di networking risposero prontamente con vari meccanismi di filtraggio, più comunemente implementati come Packet Filter. Quindi soluzioni di filtri di pacchetti che accettano o rifiutano i pacchetti in entrata o in uscita in base agli indirizzi, protocolli di trasporto (TCP o UDP ad esempio…) o numeri di porta. Uno strumento semplice che ragiona sul singolo pacchetto e non su un contesto complessivo di connessione tra le parti. Un esempio della politica packet filter è l’access-list della IOS Cisco. Ben presto divenne ovvio che per fronteggiare i pericoli in maniera più efficace questa prima soluzione non era sufficiente. Si ebbe bisogno di un meccanismo più strutturato. Nacquero cosi le prime soluzioni firewall, che lavoravano su una logica “statefull” guardando cioè all’intera connessione anziché al singolo pacchetto. In aggiunta, queste soluzioni, iniziarono ad entrare nel merito dei livelli superiori dello stack protocollare fino ad analizzare il livello sessione. Queste soluzioni furono le prime implementazioni Firewall. Cisco concepì da prima alcune soluzioni di access-list evolute come le reflexive ACL. Successivamente elaborò il firewall CBAC, per poi introdurre zone-based firewall che introdurremo in questo post.

Procediamo per capire con un caso pratico l’implementazione di Zone-Based Policy in ambiente Cisco IOS:

Di seguito si implementeranno progressivamente i comandi di configurazione Cisco IOS che consentono di tradurre una politica firewall in una configurazione del router funzionante. Il tutto verrà applicato alla struttura di rete in figura (LAN-to-Internet). Come si può vedere nel diagramma, la LAN interna sta usando lo spazio di indirizzo privato 10.0.0.0/24 che è tradotto usando il Network Address Translation (NAT) di Cisco IOS nello spazio di indirizzamento pubblico assegnato dal provider 172.16.10.32/28. Poiché lo spazio di indirizzamento pubblico copre le esigenze dei client interni, non viene utilizzato la NAT Overload. L’ISP fornisce servizi di posta (SMTP e POP3) su smtp.isp.com e servizi DNS e Web su dns.isp.com. I devices client accederanno a un server Web di terze parti www.web.com.
Il Listato seguente mostra la configurazione iniziale del router con indirizzo IP di base e NAT:

hostname fw
!
service finger
!
ip dhcp pool LAN
network 10.0.0.0 255.255.255.0
!
interface Loopback1
ip address 172.16.10.33 255.255.255.240
!
interface FastEthernet0/0
ip address 10.0.0.1 255.255.255.0
ip nat inside
!
interface Serial0/0/0
no ip address
encapsulation frame-relay
!
interface Serial0/0/0.100 point-to-point
description Link to the Internet
ip address 192.168.201.6 255.255.255.252
ip nat outside
frame-relay interface-dlci 100
!
ip route 0.0.0.0 0.0.0.0 Serial0/0/0.100
!
!
ip http server
no ip http secure-server
ip nat pool Internet 172.16.10.34 172.16.10.46 prefix-length 28
ip nat source list InternalHosts pool Internet
ip nat inside source list InternalHosts pool Internet
!
ip access-list standard InternalHosts
permit 10.0.0.0 0.0.0.255
!
end

La configurazione sembra abbastanza sicura, perché la NAT dovrebbe essere in grado di nascondere la rete interna da potenziali intrusi. Una scansione iniziale delle porte fatta dall’esterno (i risultati sono mostrati di seguito) sembra confermare questa ipotesi, perché il potenziale intruso può raggiungere solo un host IP (il router stesso). Attenzione però che considerare oggi la NAT una funzione anche utile nell’ambito della sicurezza è un grande errore!!!

External$ nmap –system-dns 172.16.10.32/28
(The 1671 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
23/tcp open telnet
79/tcp open finger
80/tcp open http
Nmap finished: 16 IP addresses (1 host up) scanned in 23.473 seconds

Tuttavia, dopo che un client interno ha stabilito una sessione attraverso il router firewall, il suo indirizzo IP diventa disponibile per mondo esterno. Poiché il router non offre alcuna protezione aggiuntiva oltre alla traduzione degli indirizzi, gli intrusi sono abilitati all’accesso agli host interni, come documentato nel Listato di seguito:

External$ nmap –system-dns 172.16.10.32/28
Interesting ports on 172.16.10.33:
(The 1671 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
23/tcp open telnet
79/tcp open finger
80/tcp open http
Interesting ports on 172.16.10.34:
(The 1668 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
3389/tcp open ms-term-serv
5800/tcp open vnc-http
5900/tcp open vnc
Nmap finished: 16 IP addresses (2 hosts up) scanned in 44.083 seconds

Ovviamente, è necessaria una protezione aggiuntiva per cambiare la configurazione iniziale in un vero firewall! Lo zone-based policy firewall in Cisco IOS è configurato in modo modulare attraverso questi passaggi:
1) Definire le zone che fanno capo al tuo firewall attraverso il comando zone security;
2) Opzionale – Utilizza il comando class-map type inspect per definire le classi di traffico adatte alle esigenze rilevate. Il traffic class è un modo per identificare  una serie di pacchetti basandosi sul loro contenuto;
3) Utilizza il comando policy-map type inspect per specificare la politica del firewall da applicare sulle classi di traffico specificate in precedenza (con i comandi di tipo class-map inspect);
4) Utilizza il comando zone-pair security per applicare i criteri stabiliti tra 2 zone (source e destination);
5) Dopo aver configurato le policy, assegnare le interfacce del router alle varie zone di sicurezza definite utilizzando il comando zone-member security a livello di interfaccia;

Configuriamo le zone security:
Il nostro esempio ha due zone di sicurezza: inside e outside. Di seguito mostrati i comandi di configurazione usati per creare le zone. Per aiutare gli operatori a capire meglio la configurazione del router, è possibile assegnare una descrizione a ciascuna zona con il comando description zone:

zone security Inside
description Inside network
zone security Outside
description Outside network

Configuriamo le policy:
La politica firewall rispetto alla struttura della rete analizzata è molto semplice: tutto il traffico è permesso dalla zona interna alla zona esterna, quindi possiamo utilizzare la class-default match-all nella policy-map. Siamo chiamati a specificare quale azione è da applicare al traffico che corrisponde ai criteri stabiliti. Abbiamo le seguenti opzioni:
Pass:
Questa azione è equivalente all’istruzione access-list permit delle ACL. Tale azione è unidirezionale e non prevede nessun traffico di ritorno. Quindi sarà necessario specificare manualmente il traffico di ritorno. Quasta opzione è particolarmente adatta con i protocolli come l’IPsec-encrypted
Drop:
Questa azione è equivalente all’istruzione access-list deny delle ACL. Usando l’opzione log è possibile tracciare i pacchetti droppati.
Inspect:
Questa azione è equivalente all’istruzione ip inspect della tecnologia CBAC. Questo comando abilita e legittima dinamicamente il traffico di ritorno (risposta) a condizione che l’inizio del flusso parta dalla zona source. Tale azione è applicabile al traffico TCP, UDP, ICMP ma anche al traffico che presenta delle specificità come FTP e H.323 e altri tipologie che necessitano di aprire altri canali di comunicazioni tra le parti.
Police:
Può essere utilizzato esclusivamente in congiunzione con inspect e pass. Questo comando permette di applicare il rate-limits qualora serva.

Dopo aver configurato le policy, è possibile applicarle al traffico tra una coppia di zone utilizzando il comando zone-pair security. Con questo comando, si specifica la zona di origine (in cui risiedono i client), la destinazione zona (dove sono i server) e la politica per gestire il traffico tra queste entità. Ovviamente si specifica la presenza dei client e dei server nelle zone a solo scopo di esempio esemplificativo.
Ecco di seguito i comandi necessari:

policy-map type inspect InsideToOutside
class class-default
inspect
!
zone-pair security InsideToOutside source Inside destination Outside
service-policy type inspect InsideToOutside

CORSI CORRELATI:

• Corso Cyber Security;
• Corso CCNP Security SCOR;
• Corsi CCNP Security;
• Corso Penetration test;
• Corso Cisco CCNA;
• Corso Fortinet NSE4;
• Corso Fortinet NSE5;
• Corso Check Point CCSA;
• Corso Check Point CCSE;

Consulta il nostro Catalogo Corsi per Tecnologia oppure fai una Ricerca per Vendor o ancora trova uno specifico corso attraverso il motore di ricerca interno: Ricerca Corsi. Contattaci ora al Numero Verde 800-177596, il nostro team saprà supportarti nella scelta del percorso formativo più adatto alla tue esigenze.

Una volta completate la politiche del firewall, è possibile assegnare singole interfacce alle zone di sicurezza con il comando zone-member security, Di seguito la configurazione necessaria:

policy-map type inspect InsideToOutside
class class-default
inspect
!
zone security Inside
description Inside network
zone security Outside
description Outside network
zone-pair security InsideToOutside source Inside destination Outside
service-policy type inspect InsideToOutside
!
interface FastEthernet0/0
zone-member security Inside
!
interface Serial0/0/0.100 point-to-point
zone-member security Outside

Testiamo la configurazione:
I primi risultati della scansione delle porte dall’esterno sono incoraggianti; dopo che il criterio firewall è stato configurato, gli host della rete interna non sono più visibili alle scansioni delle porte dall’esterno, come mostrato di seguito. Tuttavia, è ovvio che il router stesso è ancora vulnerabile:

External$ nmap –system-dns 172.16.10.32/28
Starting Nmap 4.03 ( http://www.insecure.org/nmap ) at 2006-07-29 23:41
Interesting ports on 172.16.10.33:
(The 1671 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
23/tcp open telnet
79/tcp open finger
80/tcp open http
Nmap finished: 16 IP addresses (1 host up) scanned in 64.964 seconds
Raw packets sent: 2581 (112.944KB) | Rcvd: 1677 (77.142KB)

Di seguito possiamo vedere come la rete interna possa raggiungere tutte le destinazioni esterne:

Inside$ nmap -v –system-dns web.com
Interesting ports on web.com (172.18.25.10):
(The 1663 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
21/tcp open ftp
25/tcp open smtp
80/tcp open http
135/tcp open msrpc
139/tcp open netbios-ssn
443/tcp open https
445/tcp open microsoft-ds
1026/tcp open LSA-or-nterm
3389/tcp open ms-term-serv
5800/tcp open vnc-http
5900/tcp open vnc
Nmap finished: 1 IP address (1 host up) scanned in 277.339 seconds
Raw packets sent: 1958 (86.132KB) | Rcvd: 1685 (77.510KB)

Implementare zone-based firewall porta con se altri aspetti positivi, come il fatto che un port scanning scateni dei log di alert molto utili per monitorare cosa stia succedendo:

Un resoconto dei comandi utilizzati in questa prima parte della trattazione:
zone security name –> Creates a new security zone.
description text –> Optionally assigns a description to the selected security zone.
policy-map type inspect name Creates a new policy map or starts configuration of the existing policy map. The type inspect keywords are mandatory.
class name –> Within a policy map, starts configuring firewall actions for the specified traffic class.
class class-default –> Within a policy map, starts configuring firewall actions for all unclassified traffic. The class class-default command should be the last class specification in the policy map.
inspect –> Within a traffic class configuration, permits traffic and requests packet inspection to establish automatic conduits for return traffic equivalent to the ip inspect command of Cisco IOS Firewall stateful inspection).
pass –> Within a traffic class configuration, permits traffic. You have to make manual provisions for return traffic handling.
drop [log] –> Drops the packets of the selected traffic class with optional logging to the router’s log.
police rate bps burst burst-size –> Rate-limits traffic within the specified traffic class to the specified bits-per-second rate with a specified maximum burst size.

Nella precedente trattazione è stato analizzato un caso molto semplice da regolamentare. Ora aggiungiamo un livello di complessità per capire meglio le potenzialità di questo strumento. Riproponiamo la stessa topologia e pensiamo di regolamentare il traffico che dalla rete interna possa raggiungere internet e, rispetto ad un certo traffico, limitare le direttrici a soli alcuni server legittimi:
Permettere il traffico HTTP, HTTPS, FTP, ICMP verso qualsiasi direttrice su internet.
Permettere il traffico DNS, SMTP, POP3 ma solo rispetto ai server dell’ISP 172.16.0.1, 172.16.0.2.

class-map type inspect match-any InternetTraffic
match protocol http
match protocol ftp
match protocol icmp
match protocol https
class-map type inspect match-any ISPTraffic
match protocol dns
match protocol smtp
match protocol pop3
!
class-map type inspect match-all ToISP
match class-map ISPTraffic
match access-group name ISPServers
!
ip access-list extended ISPServers
permit ip any host 172.16.0.1
permit ip any host 172.16.0.2

Abbiamo creato 3 class-map:
La prima “InternetTraffic” specifica il traffico che i client appartenenti alla rete inside possono raggiungere su internet. Notare la keyword match-any, che equivale all’operatore logico “OR”.
Dello stesso tipo è la class-map “ISPTraffic”, che elenca i protocolli concessi ai client verso i server dell’ISP. Attenzione questa class-map non rappresenta una soluzione finale, ma è funzionale alla costruzione della class-map “ToISP”. Infatti quest’ultima class-map è formata da una class-map “ISPTraffic” e l’access-list “ISPServers” uniti dall’operatore logico “AND” (match-all). Da questo pezzo di configurazione si evince la possibilità di nidificare le class-map e di congiungerle con le access-list per colpire il traffico in modo granulare. Infine uniamo il tutto in maniera sequenziale nel costrutto policy-map:

class-map type inspect match-any ISPTraffic
match protocol dns
match protocol smtp
match protocol pop3
class-map type inspect match-all ToISP
match class-map ISPTraffic
match access-group name ISPServers
class-map type inspect match-any InternetTraffic
match protocol http
match protocol ftp
match protocol icmp
match protocol https
!
!
policy-map type inspect InsideToOutside
class type inspect ToISP
inspect
class type inspect InternetTraffic
inspect
class class-default
drop log
!
zone security Inside
description Inside network
zone security Outside
description Outside network
zone-pair security InsideToOutside source Inside destination Outside
service-policy type inspect InsideToOutside
!
interface FastEthernet0/0
ip address 10.0.0.1 255.255.255.0
ip nat inside
zone-member security Inside
!
interface Serial0/0/0.100 point-to-point
description Link to the Internet
ip address 192.168.201.6 255.255.255.252
ip nat outside
zone-member security Outside
!
ip access-list extended ISPServers
permit ip any host 172.16.0.1
permit ip any host 172.16.0.2

Per verificare il corretto funzionamento della configurazione, è possibile scansionare le porte da un host interno. Come si vede di seguito, i servizi Internet (FTP, HTTP) sono concessi verso tutte le direttrici mentre i protocolli SMTP, POP3, DNS sono concessi solo verso gli IP dei server ISP:

Inside$ nmap –system-dns 172.16.0.0/28
Interesting ports on dns.isp.com (172.16.0.1):
(The 1669 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE
21/tcp open ftp
53/tcp open domain
80/tcp open http
Interesting ports on smtp.isp.com (172.16.0.2):
(The 1669 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE
25/tcp open smtp
53/tcp open domain
110/tcp open pop3
Nmap finished: 16 IP addresses (2 hosts up) scanned in 82.939 seconds

Inside$ nmap –system-dns www.web.com
Interesting ports on web.com (172.18.25.10):
(The 1671 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE
21/tcp open ftp
80/tcp open http
443/tcp open https
Nmap finished: 1 IP address (1 host up) scanned in 26.047 seconds

01:06:13: %FW-6-DROP_PKT: Dropping tcp pkt 172.16.10.34:35860 => 172.16.0.1:535
01:07:44: %FW-6-DROP_PKT: Dropping rtsp pkt 172.16.10.34:58360 => 172.16.0.1:554
01:08:14: %FW-6-DROP_PKT: Dropping tcp pkt 172.16.10.34:58360 => 172.16.0.2:895

Adesso vediamo come regolamentare il traffico da e per il router/firewall stesso, in altre parole considerando il router/firewall non come oggetto intermediario rispetto al traffico che lo attraversa, ma come entità finale di destinazione o di partenza del traffico stesso (end device). Per far ciò si introduce il concetto di “self” zone. Una zona che rappresenta il router/firewall. Diventa importante dare alcune definizioni per meglio comprendere le dinamiche della zona “self” rispetto alle normali zone già trattate:

1) Tutti gli indirizzi IP configurati sul router appartengono alla zona self, indipendentemente dall’appartenenza delle rispettive interfacce ad altre zone;
2) Se non diversamente configurato, il traffico da e per la zona self non ha restrizioni;
3) Nel momento in cui si configura la zona self in una zone pair, si deve concludere il tutto regolamentando anche il rapporto contrario. Ad esempio, se si definisce una zone pair dalla zona inside verso la zona self, si deve definire una zona pair tra la zona self e la zona inside;
4) Quando si configurano le restrizioni per il traffico in entrata, si deve considerare il traffico in uscita necessario (incluso i protocolli di routing e di management);

Applichiamo di seguito alcuni minimi criteri di sicurezza rispetto al router/firewall stesso:
1) Nessun accesso esterno al router/firewall, tranne ping (icmp echo) e protocolli di routing (se necessario);
2) Nessun accesso a Internet dal router/firewall;
3) Accesso dalla rete interna limitato alle azioni di management (ad esempio, ping, Telnet o SSH, SNMP, HTTP e HTTP / HTTPS);
4) Pieno accesso dal router/firewall alla rete interna;

Ecco la configurazione per realizzare quanto ipotizzato sulla topologia presa in considerazione:

ip access-list extended ICMPEcho
permit icmp any any echo
!
class-map type inspect match-any ping
match access-group name ICMPEcho
!
policy-map type inspect OutsideToRouter
class type inspect ping
inspect
class class-default
drop log
!
zone-pair security OutsideToRouter source Outside destination self
service-policy type inspect OutsideToRouter
!
ip access-list extended ManagementProtocols
permit tcp any any eq telnet
permit tcp any any eq 22
permit tcp any any eq www
permit tcp any any eq 443 ! https
permit icmp any any echo
!
class-map type inspect match-any RouterManagement
match access-group name ManagementProtocols
!
policy-map type inspect InsideToRouter
class type inspect RouterManagement
inspect
class class-default
!
policy-map type inspect RouterToInside
class class-default
inspect
!
zone-pair security InsideToRouter source Inside destination self
service-policy type inspect InsideToRouter
zone-pair security RouterToInside source self destination Inside
service-policy type inspect RouterToInside

Procedendo ad una rapida scansione delle porte del router/firewall dalla rete inside, come dalla rete outside, si verifica che la configurazione ha sortito l’effetto desiderato. Infatti gli host appartenenti alla rete inside possono solo accedere ai servizi di management dell’apparato come specificato nella access-list “RouterManagement“. Mentre dalla rete outside l’accesso al router/firewall è del tutto inibito:

Inside$ nmap –system-dns 10.0.0.1
Interesting ports on fw (10.0.0.1):
(The 1671 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE
23/tcp open telnet
80/tcp open http
443/tcp closed https
Nmap finished: 1 IP address (1 host up) scanned in 22.552 seconds

External$ nmap –system-dns 172.16.10.33
All 1674 scanned ports on 172.16.10.33 are: filtered
Nmap finished: 1 IP address (1 host up) scanned in 71.533 seconds