In die IOS-Version 12.4.(6)T wurde eine neue Möglichkeit der Firewall-Konfiguration eingebaut, die Zonen-basierte Konfiguration. Diese Konfiguration erinnert dabei mehr an die Konfiguration der PIXv7 und ist auch angelehnt an die QoS-Konfiguration im IOS.
Funktion dieses Features:
Alle beteiligten Interfaces werden den konfigurierten Zoenen zugewiesen. Wenn mehrere Interfaces in einer Zone sind kann zwischen diesen Netzen ohne Einschränkung kommuniziert werden. Traffic zwsichen unterschiedlichen Zonen ist standardmäßig verboten und muß explizit erlaubt werden.
Der Beispiel-Router:
Für dieses recht einfache Beispiel habe ich einen Cisco 1802W verwendet, der zwei interne Interfaces (Vlan1, Dot11Radio0) und ein externes Interface zum Internet (Dialer0) hat.
KI-R#sh ver
Cisco IOS Software, C180X Software (C180X-ADVIPSERVICESK9-M), Version 12.4(9)TDie Anforderung:
Zwischen den zwei internen Interfacen soll frei kommuniziert werden können, der gesamte Traffic ins Internet soll per statefull Inspection überprüft werden, kein Traffic soll vom Internet in das interne LAN gelassen werden. Im letzten Schritt wird noch ein WAN-Interface hinzugefügt.
Die Konfiguration:
Anlegen der Zonen. In diesem Beispiel werden zwei Zonen benötigt, Intern und Extern:
KI-R(config)#zone ?
security Security zone
KI-R(config)#zone security ?
WORD Name of security zone
KI-R(config)#zone security Extern
KI-R(config-sec-zone)#?
Zone configuration commands:
description Zone description
exit Exit from zone configuration mode
no Negate or set default values of a command
KI-R(config-sec-zone)#description All Interfaces facing to the Internet
KI-R(config-sec-zone)#zone security Intern
KI-R(config-sec-zone)#description All Interfaces facing to the internal LAN
KI-R(config-sec-zone)#exitDie Interface werden in einem späteren Schritt den Zonen zugewiesen.
Die Zonen, die miteinander kommunizieren sollen werden zu Zonen-Paaren verbunden. Es müssen immer nur Zonen-Paare für die initiierenden Verbindungen konfiguriert werden, der Rückweg wird von der Statefull Inspection automatisch erlaubt
KI-R(config)#zone-pair ?
security Zone-pair name
KI-R(config)#zone-pair security ?
WORD Name of zone-pair
KI-R(config)#zone-pair security Intern-Extern ?
source Source zone
KI-R(config)#zone-pair security Intern-Extern source ?
WORD Name of source zone
self Self zone
KI-R(config)#zone-pair security Intern-Extern source Intern ?
destination Destination zone
KI-R(config)#zone-pair security Intern-Extern source Intern destination Extern
KI-R(config-sec-zone-pair)#?
Zone configuration commands:
description Zone description
exit Exit from zone pair configuration mode
no Negate or set default values of a command
service-policy Configure CBAC Service Policy
KI-R(config-sec-zone-pair)#
KI-R(config-sec-zone-pair)#description Access from internal LAN to Internet
KI-R(config-sec-zone-pair)#exitHierbei wurde also ein Zonenpaar konfiguriert, bei dem der Traffic in der Zone Intern initiiert wird und in die Zone Extern gesendet wird. Man sieht auch, daß die einzige Funktion im Zonen-Paar eine Service-Policy ist, diese muß aber später erst noch konfiguriert werden.
Als nächstes wird bestimmt welche Interfaces zu welcher Zone gehören:
KI-R(config)#interface vlan 1
KI-R(config-if)#zone-member ?
security Security zone
KI-R(config-if)#zone-member security ?
WORD Name of zone defined
KI-R(config-if)#zone-member security Intern
KI-R(config-if)#interface dot11Radio 0
KI-R(config-if)#zone-member security Intern
KI-R(config-if)#
KI-R(config-if)#int dialer 0
KI-R(config-if)#zone-member security Extern
Die Interfaces Vlan1 und Dot11Radio0 gehören jetzt also zu einer gemeinsamen Zone und sollten miteinander kommunizieren können:
C:Documents and SettingsKarsten>ipconfig
Windows IP Configuration
Ethernet adapter Local Area Connection 2:
Connection-specific DNS Suffix . : iwen.local
IP Address. . . . . . . . . . . . : 10.255.255.131
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.255.255.1
C:Documents and SettingsKarsten>ping 10.255.254.151
Pinging 10.255.254.151 with 32 bytes of data:
Reply from 10.255.254.151: bytes=32 time=65ms TTL=127
Reply from 10.255.254.151: bytes=32 time=85ms TTL=127
Reply from 10.255.254.151: bytes=32 time=110ms TTL=127
Reply from 10.255.254.151: bytes=32 time=133ms TTL=127
Ping statistics for 10.255.254.151:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 65ms, Maximum = 133ms, Average = 98ms
Der PC 10.255.255.131 steht im Netz Vlan1, der PC 10.255.254.151 im wireless LAN hinter dem Interface Dot11Radio0. Die PCs können sich also erreichen.
Von Intern nach Extern soll natürlich auch kommuniziert werden können:
C:Documents and SettingsKarsten>ping 217.160.219.88
Pinging 217.160.219.88 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 217.160.219.88:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:Documents and SettingsKarsten>
Erwartungsgemäß geht das noch nicht, da Traffic zwischen den Zonen exlizit erlaubt werden muß. Dafür wird also eine Policy geschrieben. Bei dieser darf das Netz 10.255.252.0/22 auf das Internet zugreifen. Dieses Netz wird in einer Class-Map vom Typ inspect konfiguriert; die für die Firewall-Konfiguration neu eingeführt wurden:
KI-R(config)#ip access-list sta InternalNetworks
KI-R(config-std-nacl)#permit 10.255.252.0 0.0.3.255
KI-R(config-std-nacl)#exit
KI-R(config)#class-map type inspect AnyInternalTraffic
KI-R(config-cmap)#match access-group name InternalNetworks
KI-R(config-cmap)#
KI-R(config-cmap)#exit
Ähnlich wie im MQC (Modular QoS CLI) wird diese Klasse in einer Policy-Map verwendet und mit einer Funktion versehen. Auch diese Policy-Map ist vom Typ inspect:
KI-R(config)#policy-map type inspect Intern-Extern
KI-R(config-pmap)#?
Policy-map configuration commands:
class policy criteria
description Policy-Map description
exit Exit from policy-map configuration mode
no Negate or set default values of a command
rename Rename this policy-map
KI-R(config-pmap)#class ?
WORD class-map name
class-default System default class matching otherwise unclassified packets
type type of the class-map
KI-R(config-pmap)#class type inspect AnyInternalTraffic
KI-R(config-pmap-c)#?
Policy-map class configuration commands:
drop Drop the packet
exit Exit from class action configuration mode
inspect Context-based Access Control Engine
no Negate or set default values of a command
pass Pass the packet
police Police
service-policy Deep Packet Inspection Engine
urlfilter URL Filtering Engine
Im letzten Punkt ist zu sehen was mit dem in der Class-Map beschriebenen Traffic gemacht werden kann:
- drop: Der beschriebene Traffic wird verworfen. Das ist auch das Standardverhalten für Traffic, der nicht weiter in einer Class-Map beschrieben ist.
- inspect: Die Stateful Inspection wird angewendet, also das, was auch schon im CBAC (Context Based Access Control) gemacht wurde.
- pass: Der beschriebene Traffic wird einfach ohne weitere Behandlung durchgelassen.
- police: Die Datenrate des Traffics wird auf einen konfigurierten Wert begrenzt.
- service-policy: Eine Inspizierung bin in den Layer7 wird für den in der Class-Map beschriebenen Traffic konfiguriert (Application-Firewall).
- urlfilter: Ein URL-filtering Server (z.B. Wensense oder N2H2) wird abgefragt, ob die vom User angeforderte URL erlaubt ist.
Für dieses Beispiel soll der Traffic einfach inspiziert werden:
KI-R(config-pmap-c)#inspect
%No specific protocol configured in class AnyInternalTraffic for inspection.
All protocols will be inspected
KI-R(config-pmap-c)#exit
KI-R(config-pmap)#exit
KI-R(config)#
Diese Service-Policy wird jetzt in dem konfigurierten Zonen-Paar verwendet:
KI-R(config)#zone-pair security Intern-Extern
KI-R(config-sec-zone-pair)#service-policy ?
type Service Policy type
KI-R(config-sec-zone-pair)#service-policy type ?
inspect Configure CBAC Service Policy type inspect
KI-R(config-sec-zone-pair)#service-policy type inspect ?
WORD policy-map name
KI-R(config-sec-zone-pair)#service-policy type inspect Intern-Extern
KI-R(config-sec-zone-pair)#exit
KI-R(config)#
Die erzeugte Konfiguration sieht jetzt folgendermaßen aus:
!
class-map type inspect match-all AnyInternalTraffic
match access-group name InternalNetworks
!
policy-map type inspect Intern-Extern
class type inspect AnyInternalTraffic
inspect
class class-default
!
zone security Intern
description All Interfaces facing to the internal LAN
zone security Extern
description All Interfaces facing to the Internet
zone-pair security Intern-Extern source Intern destination Extern
description Access from internal LAN to Internet
service-policy type inspect Intern-Extern
!
interface Dot11Radio0
zone-member security Intern
!
interface Vlan1
zone-member security Intern
!
interface Dialer0
zone-member security Extern
!
ip access-list standard InternalNetworks
permit 10.255.252.0 0.0.3.255
Ein paar show-Befehle um die Konfiguration zu analysieren:
- Anzeigen der Zonen:
KI-R#show zone security zone self Description: System defined zone zone Intern Description: All Interfaces facing to the internal LAN Member Interfaces: Vlan1 Dot11Radio0 Virtual-Dot11Radio1 zone Extern Description: All Interfaces facing to the Internet Member Interfaces: Dialer0 KI-R# - die Zonen-Paare:
KI-R#show zone-pair security Zone-pair name Intern-Extern Description: Access from internal LAN to Internet Source-Zone Intern Destination-Zone Extern service-policy Intern-Extern KI-R# - die Class-Map:
KI-R#show class-map type inspect Class Map type inspect match-all AnyInternalTraffic (id 5) Match access-group name InternalNetworks KI-R# - die Policy-Map:
KI-R#show policy-map type inspect Policy Map type inspect Intern-Extern Class AnyInternalTraffic Inspect Class class-default KI-R#
Ein Test der Verbindung ins Internet:
C:Documents and SettingsKarsten>ping security-planet.de
Pinging security-planet.de [217.160.219.88] with 32 bytes of data:
Reply from 217.160.219.88: bytes=32 time=35ms TTL=54
Reply from 217.160.219.88: bytes=32 time=34ms TTL=54
Reply from 217.160.219.88: bytes=32 time=35ms TTL=54
Reply from 217.160.219.88: bytes=32 time=34ms TTL=54
Ping statistics for 217.160.219.88:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 34ms, Maximum = 35ms, Average = 34ms
Jetzt kann aus der internen Zone in die externe Zone kommuniziert werden, die Antwortpakete kommen dank statefull Inspection zurück.
Natürlich kann man sich auch anschauen was die Firewall so gemacht hat (davor habe ich noch ein wenig mehr Traffic erzeugt):
KI-R#show policy-map type inspect zone-pair
Zone-pair: Intern-Extern
Service-policy inspect : Intern-Extern
Class-map: AnyInternalTraffic (match-all)
Match: access-group name InternalNetworks
Inspect
Packet inspection statistics [process switch:fast switch]
tcp packets: [54:679]
udp packets: [46:154]
icmp packets: [0:24]
smtp packets: [0:160]
dns packets: [14:0]
Session creations since subsystem startup or last reset 136
Current session counts (estab/half-open/terminating) [1:0:0]
Maxever session counts (estab/half-open/terminating) [37:25:1]
Last session created 00:00:22
Last statistic reset never
Last session creation rate 2
Last half-open session total 0
Class-map: class-default (match-any)
Match: any
Drop (default action)
1407 packets, 45481 bytes
KI-R#
Testweise soll der Router aus dem Internet heraus angesprochen werden:
KI-R#sh ip int brief | i Dialer0
Dialer0 87.122.158.202 YES IPCP up up
karsten@urania:~$ ping 87.122.158.202
PING 87.122.158.202 (87.122.158.202): 56 data bytes
64 bytes from 87.122.158.202: icmp_seq=0 ttl=246 time=36.6 ms
64 bytes from 87.122.158.202: icmp_seq=1 ttl=246 time=34.8 ms
64 bytes from 87.122.158.202: icmp_seq=2 ttl=246 time=34.3 ms
64 bytes from 87.122.158.202: icmp_seq=3 ttl=246 time=34.2 ms
--- 87.122.158.202 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 34.2/34.9/36.6 ms
karsten@urania:~$
Man sieht, daß der Router vom Internet aus erreichbar ist. Die bisherigen Konfiguration bezog sich nur auf Traffic, der zwischen den Zonen läuft, und auf dem externen Interface (Dialer0) befindet sich keine ACL:
KI-R#show ip access-lists interface dialer 0
KI-R#
ACLs werden in dieser Konfiguration vor dem inter-Zonen-Traffic verarbeitet, daher können ACLs nicht mehr wie beim “ip inspect” angewendet werden. Für die Kontrolle des Traffics vom oder zum Router gibt es die Zone “self”, für die auch Policies konfiguriert werden können.
KI-R(config)#ip access-list extended Extern2Router
KI-R(config-ext-nacl)#permit esp any any
KI-R(config-ext-nacl)#permit udp any any eq isakmp non500-isakmp
KI-R(config-ext-nacl)#permit tcp any any eq 22
KI-R(config-ext-nacl)#exit
KI-R(config)#
KI-R(config)#class-map type inspect RouterTraffic
KI-R(config-cmap)#match access-group name Extern2Router
KI-R(config-cmap)#exit
KI-R(config)#policy-map type inspect RouterTraffic
KI-R(config-pmap)#class type inspect RouterTraffic
KI-R(config-pmap-c)#inspect
In der Access-List wird der Traffic für IPSec-VPNs und SSH erlaubt. Diese ACL wird in eine Class-Map eingebunden, diese wird widerum in einer Policy-Map eingebunden. Wie vorher auch schon wird die Policy-Map also Service-Policy auf ein Zonen-Paar angewendet:
KI-R(config)#zone-pair security Extern-Router source Extern destination self
KI-R(config-sec-zone-pair)#service-policy type inspect RouterTraffic
KI-R(config-sec-zone-pair)#
Dieses neue Zonen-Paar hat als Sourse die Zone Extern, die Destionation ist “self”, das ist der Router selbst.
Ein erneuter Ping-Test zeigt, daß jetzt der Traffic nicht mehr von dem Router verarbeitet wird:
karsten@urania:~$ ping 87.122.158.202
PING 87.122.158.202 (87.122.158.202): 56 data bytes
--- 87.122.158.202 ping statistics ---
6 packets transmitted, 0 packets received, 100% packet loss
karsten@urania:~$
Bedingt durch diese Einschränkung werden Antwortpakete für Traffic, der vom Router selbst initiiert ist, auch verworfen. Wir benötigen also noch eine Policy, in der der Traffic vom Router ins Internet inspiziert wird um die Antwortpakete zu erlauben. Auch das geht wieder mit der Zone “self”, die diesmal aber als Source auftaucht:
KI-R(config)#policy-map type inspect Router2Extern
KI-R(config-pmap)#class class-default
KI-R(config-pmap-c)#inspect
KI-R(config-pmap-c)#exit
KI-R(config-pmap)#exit
KI-R(config)#zone-pair security Router-Extern source self destination Extern
KI-R(config-sec-zone-pair)#service-policy type inspect Router2Extern
KI-R(config-sec-zone-pair)#^Z
KI-R#
Ein erneuter Test zeigt, daß der ausgehende Ping jetzt funktioniert:
KI-R#ping 217.160.219.88
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 217.160.219.88, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/34/36 ms
KI-R#
Und so sieht die gesamte Konfig jetzt aus:
class-map type inspect match-all AnyInternalTraffic
match access-group name InternalNetworks
class-map type inspect match-all RouterTraffic
match access-group name RouterTraffic
!
policy-map type inspect Router2Extern
class class-default
inspect
policy-map type inspect Intern-Extern
class type inspect AnyInternalTraffic
inspect
class class-default
policy-map type inspect RouterTraffic
class type inspect RouterTraffic
inspect
class class-default
!
zone security Intern
description All Interfaces facing to the internal LAN
zone security Extern
description All Interfaces facing to the Internet
zone-pair security Intern-Extern source Intern destination Extern
description Access from internal LAN to Internet
service-policy type inspect Intern-Extern
zone-pair security Extern-Router source Extern destination self
description Access from Internet to Router
service-policy type inspect RouterTraffic
zone-pair security Router-Extern source self destination Extern
description Traffic from Router to Internet
service-policy type inspect Router2Extern
!
interface Dot11Radio0
zone-member security Intern
!
interface Vlan1
zone-member security Intern
!
interface Dialer0
zone-member security Extern
!
ip access-list standard InternalNetworks
permit 10.255.252.0 0.0.3.255
ip access-list extended Extern2Router
permit esp any any
permit udp any any eq isakmp non500-isakmp
permit tcp any any eq 22
Jetzt soll die Konfig noch um ein WAN-Interface erweitert werden. Vom internen LAN zum WAN soll der gesamte Traffic erlaubt und inspiziert werden, aus dem WAN ins interne LAN nur ICMP, HTTP(S) und HTTP zum Cisco Secure ACS:
Die zusätzliche Zone:
zone WAN
Description: Interface to LAB ans SI
Member Interfaces:
Tunnel10
Die Class-Map und ACL für den ACS-Traffic:
class-map type inspect match-all ICMP-Traffic
match protocol icmp
class-map type inspect match-any HTTP-Traffic
match protocol http
match protocol https
match access-group name ACS-Traffic
ip access-list extended ACS-Traffic
permit tcp any host 10.255.255.12 eq 2002
permit tcp any host 10.255.255.12 range 4444 4455
Die Policy-Map:
policy-map type inspect WAN2Intern
class type inspect HTTP-Traffic
inspect
class type inspect ICMP-Traffic
inspect
class class-default
policy-map type inspect Intern2WAN
class class-default
inspect
Die Zonen-Paare:
zone-pair security Internal2WAN source Intern destination WAN
description Access internal Networks to WAN (Lab/SI)
service-policy type inspect Intern2WAN
zone-pair security WAN2Intern source WAN destination Intern
description Access from Lab/SI to internal Network
service-policy type inspect WAN2Intern
Insgesammt ist diese Art der Konfiguration sehr leistungsfähig. In diesem Beispiel war die Konfiguration dabei noch recht übersichtlich, da die Inspections sehr allgemein gehalten waren. In einem späteren Beispiel werde ich das nochmal verfeinern. Weiterhin sollte eine EasyVPN-Config auf virtuelle Tunnel-Interface umgestellt werden, damit diese auch einer Zone hinzugefügt werden können.
Noch nicht so leistungsfähig wie beim “ip inspect” sind die debug-Fähigkeiten. Da ist vermutlich etliches noch nicht fertig implementiert. Ich warte daher auf die nächsten neuen T-Releases und hoffe, daß dieses Feature weiter ausgebaut wird.
Hallo Karsten,
kennst Du eine Lektüre die das Thema IOS Firewall ausführlicher behandelt. Alles was ich dazu bisher finden konnte, waren ehr Bücher bzw. Onlineartikel die das Thema in einem Nebenkapitel oder nur sehr oberflächlich mit 2-3 Seiten anriss. Leider scheint das Thema ehr nebenbei von Cisco behandelt zu werden.
Zwei Fragen die sich mir vor kurzdem dazu gestellt haben:
Als Beispiel empfielt Cisco für die IOS Zone-Based Firewall mittels ACLs nur noch IP Adressen zu filtern und zum filtern nach Protokollen/Ports auf die “match protocol” Funktion in der class-map zurückzugreifen. Wie sieht die Empfehlung diesbezüglich aus, wenn viele nicht-standart Ports mit herstellereigenen Protokollen ins Spiel kommen (z.B. SAP, Branchensoftware fuer Krankenhäuser, etc.).
Als zweites Beispiel, wie sieht es mit dem nachträglichen verändern einer policy-map aus. Also dem neuordnen der class-maps bzw. dem einfügen einer class-map zwischen vorhanden?
VG Tim
Klasse Artikel, den ich durch Zufalle entdeckt habe, es gelang mir nie dies durchzuführen, nun werde ich es noch einmal in Angriff nehmen, hoffe es klappt nun…
Hallo Karsten,
es geht um den Teil mit dem Ping vom Router ins Internet:
Zumindest in IOS Version 15.1(3)T lässt sich das inspect nicht mehr im class-default konfigurieren. Abhilfe schafft hier ebenfalls eine class-map.
class-map type inspect Router2Extern
match protocol icmp
! match protocol
policy-map type inspect Router2Extern
class type inspect Router2Extern
inspect
class class-default
drop
zone-pair security Router-Extern source self destination Extern
service-policy type inspect Router2Extern
VG Hannes
EDIT:
class-map type inspect Router2Extern
match protocol icmp
! match protocol (weitere Protokolle z. B. DNS, NTP, etc.)
Ja, auch bei mir geht das nicht mehr. Wobei ich mir jetzt nicht bewusst bin, wann das geändert wurde, oder ob das nur ein Bug ist. In der Doku finde ich zu der Einschränkung gerade nichts.