This article is the first part of Cisco Zone Based firewall configuration. It provides technology overview, configuration constructs and simple network configuration example. The part 2 will provide more complex examples with NAT, DMZ, VPNs and operation of self zone.
- Overview
- Stateful Firewall Technology
- Zones and Interfaces
- How to Control Traffic Between Zones
- Configuration Elements
- Practical Example
- Initial Connectivity Test
- Communication Between Zoned, Non-zoned Interfaces and Self Zone
- Communication Between Interfaces-Members of the Same Zone
- Default Zone
- Communication Between Zones: Inside To Outside
- Perform Traffic Classification: Access Lists
- Perform Traffic Classification: Class Maps
- Binding Everything Together with Policy Maps and Zone Pairs
- Coexistence with Access Lists Applied to the Interface
Overview
Cisco zone-based firewall (ZBF) is a feature of a Cisco router running IOS or IOS-XE. It is replacement for older CBAC (Context-Based Access Control) – “ip inspect” based configuration. Main difference is that ZBF uses zones with default “deny any” policy, and so called C3PL (Cisco Common Classification Policy Language) with class-maps and policy-maps constructs for classification and policy application.
Cisco feature navigator (www.cisco.com/go/fn) displays routers, software version and the licensing level required to enable firewall functionality, as shown in the screenshot below. The first software version with ZBFW support is IOS 12.4(6)T, and IOS-XE 16.10.1a.
Always check release notes and documentation for the specific platform, as licensing can change and this feature can be licensed separately. For example, at the time of writing ASR1000 requires additional feature license which is not part of any technology packages.
Stateful Firewall Technology
As the name implies, stateful firewall monitors the state of the session. In comparison with stateless packet filters, which require access rules to be applied bi-directionally, stateful firewall requires only initial direction of the session to be allowed in the rule. Return traffic is allowed by router being able to match it to the existing session.
Session can be a single TCP or UDP flow when only transport-protocol level specifics must be tracked. And in more complex scenarios, it can be several sessions, for example, control flow of FTP or SIP, where secondary communications channels are created as separate flows.
ZBF is stateful and can work with both simple transport-layer sessions and higher-level application protocols.
Zones and Interfaces
An administrator can designate parts of the network with different security requirements as security zones. A firewall or multiple firewalls are usually deployed on the boundary of the zones. For example, Internet, DMZ and LAN can represent 3 different security zones.
An interface or multiple interfaces can then be assigned to those zones. When traffic arrives on a interface, it is classified as sourced from the zone this interface belongs. Traffic between interfaces of the same zone is allowed and traffic between interfaces in different zones is implicitly denied.
There is a special zone called Self. It represents the router itself and by default the traffic to or from the router is implicitly allowed.
How to Control Traffic Between Zones
Now, let’s compare the difference between non-zone-based (such as ACLs, CBAC and even ASA) to zone-based approaches (Cisco ZBF).
Consider topology in the example below. In this sample topology, we want to apply our security policy, so DMZ can access Internet without any restrictions, however, only single SQL server on a single TCP port (MS SQL – 1433) on the LAN segment must be accessible.
Traditional ACL/CBAC
Without zones, you would apply an ACL in ingress direction to DMZ interface of the firewall. On the left side of the diagram you can see 3 entries displayed. Requirement to provide Internet access to DMZ network causes us to put “permit any” rule on the very bottom. This rule opens access to Trust network, so we now have to put explicit deny entry #2 for LAN IP range.
There are 2 potential issues with this configuration.
Let’s say that we provision another LAN network with IP address of 10.1.6.0/24. We will require to go back and adjust configuration, so the DMZ is prohibited to access to this new network. While there is a workaround, if we will replace line #2 with deny statement to entire RFC1918 range, it is still would be more convenient to be able to use “AND” statement with line #3, stating that rule applies only if the egress is Internet-facing interface (or zone).
The other issue, is that readability of the ruleset is not great, as we need to infer where each IP prefix is located.
Zone-based Approach
On the right side of the diagram, the same ruleset is encoded with zone-based approach. By being able to specify destination zone, we can now ensure that “permit any” rule doesn’t affect LAN or any other security zone that we can introduce in the future. It is also self-documenting, as we can clearly see direction of the traffic without having to look at the specific subnets. With larger ruleset this benefit is especially noticeable.
Cisco ZBF enforces that a dedicated policy to be created between exactly one source and one destination zone. Cisco uses term zone-pair to identify such relationship. Note that zone-pair is directional, i.e. two zones initiating traffic to each other will have two zone pairs.
Other vendor firewalls, such as Fortinet, Palo Alto Networks and Juniper, allow rules to contain multiple zones or even “any” keyword representing all zones in a single rule. However, it is up to administrator to either use this functionality or not to balance between number of rules and configuration readability.
Configuration Elements
C3PL (or Cisco Common Classification Policy Language) is similar to the way how QoS is configured on Cisco routers. The configuration is done using the following elements:
- Interfaces
- Zones
- Zone Pairs
- Service Policies
- Policy Maps
- Class Maps
- Access Lists
The diagram below shows how all the components interact with each other. Lines on the left with numbers display configuration order.
Practical Example
The diagram below shows topology that will be used in the next few examples. Static default route is configured on every spoke router.
Initial Connectivity Test
To confirm that there is connectivity prior to applying any rules, let’s ping all other routers from WEST.
! East is reachable WEST#ping 10.1.3.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.3.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms ! South is reachable WEST#ping 10.1.6.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.6.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms ! Firewall is reachable WEST#ping 10.1.9.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.9.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms ! North is reachable WEST#ping 10.1.12.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.12.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
Communication Between Zoned, Non-zoned Interfaces and Self Zone
The diagram below shows how such communication works by default.
Let’s now create a security zone called OUTSIDE and move WEST-facing interface to this zone.
FIREWALL(config)#zone security OUTSIDE
FIREWALL(config-sec-zone)#description OUTSIDE
FIREWALL(config-sec-zone)#exit
FIREWALL(config)#interface gi2.9
FIREWALL(config-subif)#zone-member security OUTSIDE
FIREWALL(config-subif)#end
! The command below shows summary of zones and interface assignment
FIREWALL#show zone security
zone self
Description: System defined zone
zone OUTSIDE
Description: OUTSIDE
Member Interfaces:
GigabitEthernet2.9
Tests Sourced From a Zoned Interface
In the next example some of the previous tests are re-launched to see how it affects traffic.
! We cannot reach any other spoke routers WEST#ping 10.1.3.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.3.2, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) ! We still can ping the firewall address WEST#ping 10.1.9.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.9.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Tests Sourced From a Non-Zoned Interface
And another set of tests to check how the configuration affected reachability from NORTH router.
! West, which is now part of OUTSIDE zone is not reachable NORTH#ping 10.1.9.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.9.2, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) ! East is still reachable NORTH#ping 10.1.3.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.3.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms ! South is still reachable NORTH#ping 10.1.6.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.6.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms ! The firewall is still reachable NORTH#ping 10.1.12.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.12.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
These examples demonstrate that network connected to an interface that belongs to a zone, by default, cannot communicate to networks connected to interfaces that are not assigned to any zones.
We can also see that communication to the router itself is reachable from both zoned and non-zoned interfaces.
Communication Between Interfaces-Members of the Same Zone
The following diagram shows how this communication works.
In the following example we will assign NORTH-facing interface to OUTSIDE zone, so both WEST and NORTH routers are in the same zone.
FIREWALL(config)#interface gi2.12
FIREWALL(config-subif)#zone-member security OUTSIDE
FIREWALL(config-subif)#end
FIREWALL#show zone security
zone self
Description: System defined zone
zone OUTSIDE
Description: OUTSIDE
Member Interfaces:
GigabitEthernet2.9
GigabitEthernet2.12
Both North and West can now ping each other, as shown in the example below.
NORTH#ping 10.1.9.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.9.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms WEST#ping 10.1.12.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.12.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
Note that it’s possible to apply rules for intra-zone traffic by using zone-pairs with the same source and destination zones.
Default Zone
The default zone is a construct that allows you to implicitly assign “no-zone” interfaces to a default zone. Then you can use default zone in zone-pairs. As the result, you can override no-communication rule between zoned and non-zoned interfaces.
FIREWALL(config)#zone security default
FIREWALL(config-sec-zone)#end
FIREWALL#show zone security
zone self
Description: System defined zone
zone OUTSIDE
Description: OUTSIDE
Member Interfaces:
GigabitEthernet2.9
GigabitEthernet2.12
zone default
Description: System level zone. Interface without zone membership is in this zone automatically
Communication Between Zones: Inside To Outside
Communications between zones is denied by default.
First, we will create INSIDE zone and move NORTH-facing interface of the FIREWALL to this new zone and confirm that there is no communication.
FIREWALL(config)#zone security INSIDE
FIREWALL(config-sec-zone)#exit
FIREWALL(config)#int gi2.12
FIREWALL(config-subif)#zone-member security INSIDE
FIREWALL(config-subif)#end
FIREWALL#show zone security
zone self
Description: System defined zone
zone OUTSIDE
Description: OUTSIDE
Member Interfaces:
GigabitEthernet2.9
zone default
Description: System level zone. Interface without zone membership is in this zone automatically
zone INSIDE
Member Interfaces:
GigabitEthernet2.12
Perform Traffic Classification: Access Lists
Let’s implement the following simple rules for the example network:
- Allow ICMP from INSIDE to OUTSIDE for all hosts
- Allow HTTP and HTTPS from INSIDE to OUTSIDE for a single internal workstation
The diagram below shows what we will implement in this section.
The configuration of new interface on NORTH and additional static route on the FIREWALL is straightforward and shown here only for completeness:
NORTH(config)#int gi3 NORTH(config-if)#ip address 172.16.2.1 255.255.255.0 NORTH(config-if)#no shut FIREWALL(config)#ip route 172.16.2.0 255.255.255.0 10.1.12.2
ICMP traffic doesn’t have any IP restrictions in our scenario, so we will not be defining ACL for it.
For VM’s HTTP and HTTPS traffic, we can write several types of ACLs with broad classification on the top and very granular on the bottom, as shown in the examples below:
!Option 1 FIREWALL(config)#ip access-list extended VM-TO-ANY FIREWALL(config-ext-nacl)# permit ip host 172.16.2.50 any !Option 2 FIREWALL(config)#ip access-list extended VM-TO-ANY-HTTP-HTTPS FIREWALL(config-ext-nacl)# permit tcp host 172.16.2.50 any eq www FIREWALL(config-ext-nacl)# permit tcp host 172.16.2.50 any eq 443 !Option 3 FIREWALL(config)#ip access-list extended VM-TO-ANY-HTTP FIREWALL(config-ext-nacl)# permit tcp host 172.16.2.50 any eq www FIREWALL(config)#ip access-list extended VM-TO-ANY-HTTPS FIREWALL(config-ext-nacl)# permit tcp host 172.16.2.50 any eq 443
All of 3 options can be used to achieve the same result when used in class-map in combination with protocol matching.
First option is highly reusable, so if you need to define protocol inspection for multiple protocols, you can use the same ACL for all class-maps. However, if you omit “match protocol” statement in class-map, VM will have unrestricted access due to the fact that there is no filtering done on ACL level.
The last option defines every single protocol that is being allowed as a separate ACL. The configuration is self-documenting, however, it can grow to very large list of statements which may be difficult to support.
The second option is balanced by grouping all access requirements for a single host, or group of hosts under the same access list, ensuring that ACL, even when applied without “match protocol” statement, provides only required access for the host.
Perform Traffic Classification: Class Maps
The next step is to create associated class-maps. Let’s define class for ICMP first:
FIREWALL(config)#class-map type inspect match-all ICMP FIREWALL(config-cmap)#match protocol icmp
For HTTP/HTTPS traffic let’s use generic version of access list from the previous section.
FIREWALL(config)#ip access-list extended VM-TO-ANY FIREWALL(config-ext-nacl)# permit ip host 172.16.2.50 any
Class-maps can use Boolean AND logic with match-all keyword or Boolean OR logic when match-any keyword is used. In our case, we want both ACL and protocol to match. However, between protocols we want OR logic, as traffic cannot match 2 different protocols at the same time.
One option is to use two different class-maps, as shown in the example below.
FIREWALL(config)#class-map type inspect match-all VM-HTTP-TRAFFIC FIREWALL(config-cmap)#match access-group name VM-TO-ANY FIREWALL(config-cmap)#match protocol http FIREWALL(config-cmap)#exit FIREWALL(config)#class-map type inspect match-all VM-HTTPS-TRAFFIC FIREWALL(config-cmap)#match access-group name VM-TO-ANY FIREWALL(config-cmap)#match protocol https FIREWALL(config-cmap)#exit
More efficient approach is to use a nested class-map which will either match HTTP or HTTPS (Boolean OR). It will be then used in the parent class-map which will look for matching both IP access list and the child class-map (Boolean AND).
! This class-map matches either HTTP or HTTPS due to match-any keyword FIREWALL(config)#class-map type inspect match-any VM-ALLOWED-PROTOCOLS FIREWALL(config-cmap)#match protocol http FIREWALL(config-cmap)#match protocol https FIREWALL(config-cmap)#exit ! This class-map matches both VM-TO-ANY ACL and VM-ALLOWED-PROTOCOLS Class-map FIREWALL(config)#class-map type inspect match-all VM-ALLOWED-TRAFFIC FIREWALL(config-cmap)#match access-group name VM-TO-ANY FIREWALL(config-cmap)#match class-map VM-ALLOWED-PROTOCOLS FIREWALL(config-cmap)#exit
Note that order of “match protocol” statements is important. Always insert protocol-specific statements above generic match protocol tcp or udp statements. For example, FTP matches both application-level and TCP-level inspection, however, if FTP is treated as generic TCP protocol, firewall will not inspect and allow connectivity for the secondary channel.
Binding Everything Together with Policy Maps and Zone Pairs
Now we know what traffic we want to permit, it’s time to apply individual policy actions to classes and bind the configuration to directional zone-pair.
FIREWALL(config)#policy-map type inspect INSIDE-TO-OUTSIDE FIREWALL(config-pmap)# class type inspect ICMP FIREWALL(config-pmap-c)#inspect FIREWALL(config-pmap-c)#exit FIREWALL(config-pmap)#class type inspect VM-ALLOWED-TRAFFIC FIREWALL(config-pmap-c)#inspect FIREWALL(config-pmap-c)#exit FIREWALL(config-pmap)#exit FIREWALL(config)#zone-pair security ZONE-PAIR-INSIDE-TO-OUTSIDE source INSIDE destination OUTSIDE FIREWALL(config-sec-zone-pair)#service-policy type inspect INSIDE-TO-OUTSIDE
To perform testing HTTP and HTTPS services are enabled on WEST router:
WEST(config)#ip http server WEST(config)#ip http secure-server
From a test workstation, let’s perform tests and then use show commands to see the results.
All data plane tests are successful.
The following command displays detailed statistics about each protocol.
FIREWALL#show policy-map type inspect zone-pair ZONE-PAIR-INSIDE-TO-OUTSIDE
Zone-pair: ZONE-PAIR-INSIDE-TO-OUTSIDE
Service-policy inspect : INSIDE-TO-OUTSIDE
Class-map: ICMP (match-all)
Match: protocol icmp
Inspect
Packet inspection statistics [process switch:fast switch]
icmp packets: [0:22]
Session creations since subsystem startup or last reset 2
Current session counts (estab/half-open/terminating) [0:0:0]
Maxever session counts (estab/half-open/terminating) [1:0:0]
Last session created 00:07:40
Last statistic reset never
Last session creation rate 0
Last half-open session total 0
Class-map: VM-ALLOWED-TRAFFIC (match-all)
Match: access-group name VM-TO-ANY
Match: class-map match-any VM-ALLOWED-PROTOCOLS
Match: protocol http
Match: protocol https
Inspect
Packet inspection statistics [process switch:fast switch]
tcp packets: [0:2014]
http packets: [0:1279]
Session creations since subsystem startup or last reset 256
Current session counts (estab/half-open/terminating) [0:0:0]
Maxever session counts (estab/half-open/terminating) [3:1:0]
Last session created 00:00:06
Last statistic reset never
Last session creation rate 97
Last half-open session total 0
Class-map: class-default (match-any)
Match: any
Drop (default action)
6 packets, 576 bytes
To display list of sessions use the following command:
FIREWALL#show policy-firewall sessions platform --show platform hardware qfp active feature firewall datapath scb any any any any any all any -- s=session i=imprecise channel c=control channel d=data channel Session ID:0x00000159 172.16.2.50 49499 10.1.9.2 443 proto 6 (0:0) [sd] Session ID:0x00000157 172.16.2.50 8 10.1.9.2 1 proto 1 (0:0) [sc] Session ID:0x00000158 172.16.2.50 49498 10.1.9.2 443 proto 6 (0:0) [sd]
Coexistence with Access Lists Applied to the Interface
Let’s block ICMP traffic input on the interface level while allowing everything else on NORTH-facing interface, which is part of security zone.
FIREWALL(config)#ip access-list extended DENY_ICMP FIREWALL(config-ext-nacl)#deny icmp any any FIREWALL(config-ext-nacl)#permit ip any any FIREWALL(config-ext-nacl)#end FIREWALL(config)#int gi2.12 FIREWALL(config-subif)#ip access-group DENY_ICMP in
Ping no longer works, as shown in the screenshot below, meaning that inbound ACLs are being evaluated first, and as result must either not be used or have more permissive settings that zone-based configuration.
