IOS-XE Zone Based Firewall

Cisco Zone-Based Firewall (ZBFW) is a stateful firewall supported on Cisco IOS/IOS-XE routers. The routers interfaces are assigned to zones, inspection policies are applied for traffic moving between the zones, with traffic permitted or denied according to the policy. With a stateful firewall, you do not have to explicitly permit the return traffic. When traffic traverses the router, ZBFW creates an entry in the connection table. This connection table is checked and if matched, the return traffic is automatically permitted.

Realistically ZBFW is no substitute to a dedicated firewall as it does not have the NGFW features supported by most vendors. If used ZBFW would be suitable for small branch site deployments. This post provides an overview of the commands used to configure a ZBFW.

Restrictions/Limitations

The following is an overview of the restrictions using ZBFW, as of IOS-XE version 16.5.

  • Stateful inspection support for multicast traffic is not supported between any zone, use Control Plane Policing.
  • Access Control Lists (ACL) in class-maps are supported, but ACL based packet count is disabled by default.
  • ZBFW cannot inspect traffic when NAT NVI is enabled on the device.
  • HTTP application inspection functionality (as described in the ZBFW design guide in the reference section below) appears to have been removed in later IOS-XE 16.X versions.
  • The service policies cannot be re-ordered, you must delete the policy and re-add in the correct order.

Further information on ZBFW restrictions can be found here https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_zbf/configuration/xe-16-5/sec-data-zbf-xe-16-5-book/sec-zone-pol-fw.html#reference_5C11EE02A2454210A9FC354BCC86329F

Components

The following components are used when configuring ZBFW:

Class maps

  • Are used to identify the traffic, by matching against either an Access Control List, layer 4 protocol (TCP, UDP and ICMP), Security/Scalable Group Tags (SGTs), subordinate class-maps or NBAR.
  • They are commonly referred to as Top-level class-maps or layer 3/layer 4 class maps.
  • Packets are checked against the match criteria of the class map to determine if the packet belongs to that class.
  • Class maps can apply to “match-any” or “match-all” operators. If “match-any” is specified, traffic must meet one criterion in the class map. If “match-all” is specified, traffic must match all of the criteria.

The example below uses an ACL to identify the destination IP address. This ACL is then referenced in the class-map, which also matches on http protocol. Using “match-all” ensures that only traffic to the destination defined IP address AND using http protocol is allowed. If only one matches, traffic is dropped.

ip access-list extended OUTSIDE-IN-HTTP
 permit ip any host 192.168.10.5
!
class-map type inspect match-all OUTSIDE-IN-HTTP
 match protocol http
 match access-group name OUTSIDE-IN-HTTP

Policy maps

  • Define the actions to take on the traffic identified in the class map.
  • The actions include: –
    • Inspect – once classified, a firewall session is created in the connection table and the packet content is examined.
    • Pass – the packet is classified and allowed to pass without further inspection.
    • Drop – the packet is classified and dropped.

The example below represents traffic from outside to inside to access a webserver. The Policy Map inspects traffic defined in the specified class-map, traffic not matching will be dropped.

policy-map type inspect OUTSIDE-IN
 class type inspect OUTSIDE-IN-HTTP
  inspect
 class class-default
  drop log 

Zones

  • Router Interfaces are assigned to a Security Zone, interfaces that have similar functions (multiple inside interfaces) can be grouped into the same Security Zone.
  • By default, traffic between interfaces in the same zone is always allowed.
  • Once an interface is configured in a security zone, all traffic between an interface that interface and another interface in a different zone is dropped by default. The exception is for traffic to/from the device itself.
  • To permit traffic to/from a zone, a zone pair must be configured.
  • An interface can be a member of only one security zone.
  • All interfaces associated in a zone, must be in the same VRF.
  • The self zone is the device itself and applies to traffic to or generated by the router.
  • The default zone is applicable to interfaces without a security zone defined.

Below is an example of the commands used to create Security Zones. The names INSIDE and OUTSIDE could be anything descriptive.

zone security OUTSIDE
zone security INSIDE

The Security Zones are then assigned to each interface

interface GigabitEthernet1
 description ## Internet Connection ##
 ip address 1.1.1.2 255.255.255.0
 zone-member security OUTSIDE
!
interface GigabitEthernet3
 ip address 192.168.101.2 255.255.255.0
 description ## Internal LAN ##
 zone-member security INSIDE

Zone Pairs

  • Allows you to specify a unidirectional firewall policy between two security zones.
  • The direction of the traffic is specified by the source and destination zones.
  • A firewall policy map is attached to a zone using a service-policy.
  • If a policy is not configured between zone pairs, then traffic is dropped.
  • If a policy inspects traffic and there is no zone-pair and service policy for the return traffic, the return traffic is inspected and permitted.
  • If a policy passes traffic and there is no zone-pair and service policy for the return traffic, the return traffic is dropped.
  • A zone-based firewall drops a packet if not explicitly allowed by a rule.

 

The Zone-pair example below defines the direction of the traffic flow, from outside to inside, referencing the policy map defined above.

zone-pair security OUTSIDE-IN source OUTSIDE destination INSIDE
 service-policy type inspect OUTSIDE-IN

Another zone pair would be required for traffic initiated from inside.

zone-pair security INSIDE-OUT source INSIDE destination OUTSIDE
 service-policy type inspect INSIDE-OUT

Self-Zone

The “self” zone is a system defined zone on the router is used to control traffic “to” and “from” the routers control plane. Traffic from inside to outside (or vice versa) is considered as “through” traffic.

  • By default, no policies for the self-zone exist, so traffic to/from the router will be permitted.
  • As soon as you create a zone-pair referencing the “self” zone, traffic will be filtered. You will therefore need to take care when creating a policy.
  • The “self” zone does not have any interface members.
  • Traffic to and from the self-zone would include management protocols (Telnet, SSH, SNMP etc), Routing Protocols (EIGRP, OSPF, BGP etc), IPSec, ESP, GRE etc

Parameter Maps

A parameter map allows you to specify parameters that control behaviour actions, such as connection settings, session maximums/rate/packets, TCP/UDP idle or half-open timers etc.

  • Parameter Maps are optional
  • Individual/Unique Parameter maps can be applied to each action under a policy-map
  • If no parameter map is configured, settings are inherited from the default.

The example below represents illustrates how to configure the parameter map with a maximum session and apply under the class-map.

parameter-map type inspect SSH-PMAP
 sessions maximum 1
 log dropped-packets
!
policy-map type inspect OUTSIDE-IN
 class type inspect OUTSIDE-IN-SSH
 inspect SSH-PMAP

The figure below represents the configurable options under the parameter-map.

The command show policy-firewall config displays the overall ZBFW configuration, including the parameter maps, if applied. From the output of the show policy-firewall config command below, we can confirm the zone-pair, the zone names, the member interfaces, the service-policy and the specific configuration. We can determine the class-map OUTSIDE-IN-SSH uses a custom parameter map called SSH-PMAP, whereas the rest of the class-maps utilise the default.

In our example we permit a maximum of 1 SSH connection, attempt to connect from 2 computer results in only 1 connection. On the router CLI, we observe the output below, which confirms exceeds the configured maximum value 1.

Running the command show platform qfp active statistics drop the drop reason FirewallNonsession apparently relates to the max session limit being reached.

Logging

Logging can be enabled globally using the global parameter map

parameter-map type inspect-global
 log dropped-packets

Useful commands

platform inspect disable-all – disables the zone-based firewall configurations applied to interfaces.
show policy-map type inspect zone-pair <ZONE-PAIR-NAME> sessions ­– displays the active firewall sessions, per zone-pair per class-map.

The output below confirms, 2 active http sessions (albeit from the same source), but to 2 unique destination IP addresses) and another active ssh session.

show policy-firewall sessions platform all – displays a summary of the active firewall sessions

The output below represents the same connections as per the previous screenshot but represented as a summary.

Reference

The following external links are useful guides when configuring Zone-Based Firewall on a Cisco IOS/IOS-XE router.

https://www.cisco.com/c/en/us/support/docs/security/ios-firewall/98628-zone-design-guide.html
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_zbf/configuration/xe-16-5/sec-data-zbf-xe-16-5-book/fw-stateful-icmp.html

Templates

A basic Zone-Based Firewall template is provided in the templates section of this site.