Zone Based Firewall By Cisco

In this post I will talk about Cisco Zone Based Firewall (ZBF) which is a new approach to configure access control in the IOS firewall. I will first make an introduction to ZBF and then I will demonstrate how to configure it.

To illustrate the different examples in this post I will use the following topology:

  

IGP: EIGRP AS 10

 Platform/IOS: Cisco 2691/12.4(15)T11 Adv IP services.

 Side note: As I am using IOS 12.4(15)T I will only talk about ZBF rules for this IOS release. Some improvements and rules changes have been made in the last IOS releases (IOS 15.X).

 IP addressing: All routers in the topology are configured with loopback IP in the format X.X.X.X /32 where X is the router number.

Introduction to ZBF
 Before this feature, firewalling in IOS was configured using a combination of ACLs and inspection rules (CBAC), both applied directly to interfaces which may poorly reflect organization´s security policy. With Zone Based Firewall (ZBF) different interfaces are grouped into zones, sharing the same security attributes, the same level of trust. The router itself is in a zone per default called the self zone. Here are the important facts about ZBF: (for IOS 12.4(15)T):

     Interfaces in the same zone can communicate with each other
    Interfaces in different zones cannot communicate with each other by default
    Traffic from and to the self zone to any other zone is allowed by default to allow for control plane and management traffic
    ZBF implements the same set of features as CBAC
    ZBF configuration uses a configuration framework called Cisco Policy Language (CPL) similar to MQC used for configuring QoS for example
    ZBF can inspect, pass, drop or rate limit traffic
    Class-map type inspect are used to match the traffic that the Firewall should inspect, pass, drop or rate-limit
    Policy-map type inspect are used to set an action (pass, inspect, rate-limit or drop) on the traffic matched in the class-map
    Zone-pair are used to define the traffic flow direction.
    If the inspect keyword is used in a policy-map then the class-map must have at least one “match protocol” statement to specify the protocols for inspection. Otherwise all protocols will be inspected
    If a policy is applied for traffic from a zone to self zone, traffic from self zone to the other zone will be permitted but returning traffic may me blocked
    Stateful inspection router-generated traffic is limited to TCP, UDP and ICMP and H.323. Application inspection (HTTP,FTP,Telnet, etc.) is not available for self-zone policies.
    Rate-limiting cannot be configured on self-zone policies
    Stateful inspection support for multicast traffic is not supported between any zones, including the self zone

ZBF Configuration
 Let´s assign each interface to a zone as illustrated by the topology. To demonstrate that interface in the same zone can communicate with each other’s I will assign R2 and R4 in the zone inside. To test will ping from R2 to R4: 

Now Come on ping:

Great! Let us check by assigning R4 to zone outside and ping one more time:

Alright, that demonstrates that interfaces in different zone cannot communicate with each other´s.

The router itself is a member of the self zone and by default this zone is not limited from communicating with other zones. Although we cannot ping anymore from R2 to R4 as they are in different zones, the router can still ping to zone inside and outside: 

 

Now check by assigning R3 to the DMZ zone:

Great! So now let´s define the following security policy:

1) R1 should only be managed from the outside zone using the following protocols: Telnet, SSH and HTTP. Furthermore ICMP to R1 coming from the outside should be allowed.

2) Only Inside user 2.2.2.2 (represented in this example by the loopback of R2) is allowed to surf the Internet (represented by R4) using HTTP and to send DNS request to the Internet. Telnet and SSH to the Internet should also be allowed

3) Outside user (represented by R4 loopback) is allowed to reach the DMZ server (represented by R3) on port 80 as well as ping it

4) ICMP and telnet originated by the router itself should be permitted to any zone

Let´s start by implementing the 1 policy requirement which is about the self zone and the outside zone. The flow direction is from outside to self. Only Telnet, SSH, HTTP and ICMP are allowed. So let´s configure the following:

ZBF policy 1

So let´s test to SSH to R1 from R4:

 

On R1 we can see that the ZBF is matching SSH packets and pass them:

But what happen if we telnet from R1 to R4:

So R1 is blocking the returning traffic when originated from R1 itself. So if we wanted to allow returning traffic we could create a new policy inspecting TCP, UDP and ICMP (as self zone does not allow for advanced application inspection) from self zone to outside zone. As we are only passing traffic in our example there is no inspection.

Side note: Please not that although we are passing traffic from out to self the returning traffic from the router is automatically allowed back as we have not configured any zone-pair from self to outside.

Side note 2: Another point here is that we didn´t explicitly allowed EIGRP traffic in the policy but the neighbor relationship between R1 and R4 is still up and running. I guess that may be an issue related to the IOS version I am using or maybe related to GNS3.

ZBF policy 2

Perfect! Let´s implement policy number 2. The policy states that inside user (2.2.2.2 -> R2 loopback) is allowed to surf the internet (represented by R4), send DNS query to the outside as well as using telnet and SSH. Let´s configure the following to reflect this policy:

In the above configuration we are using class-map nesting in order to achieve an advanced matching. Here in the ACL we used permit ip but we could have been more specific by only allowing TCP,UDP and ICMP. But as we are only inspecting certain type of traffic it is alright.

So let´s try to make a DNS request. R4 is configured as the DNS server:

So R4 is resolving the DNS query and R2 can then telnet to R4. R1 is allowing both the DNS query and the telnet session as we are inspecting these two protocols in our policy:

The output above confirm that R1 is inspecting both sessions (DNS and TELNET), allowing return traffic from outside to inside zone.

ZBF policy 3

Let´s implement policy number 3 which states that outside user (represented by R4 loopback 4.4.4.4/32) is allowed to reach a DMZ server via TCP on port 80 as well as ping it. All other traffic from this user towards the DNS or the INSIDE zone should be denied. So let´s configure the following to reflect this policy:

Again here we are nesting a class-map in another in order to achieve our goal. The ACL only allowed TCP traffic and ICMP from R4 to R3 and we are only inspecting HTTP and ICMP traffic which means that traffic which is TCP but not HTTP will be dropped by the class-default. Let´s test it:

To test we just copy the running-config of R3 located in flash to null via HTTP:

So we can see that HTTP traffic is being inspected and it is allowed from outside to the DMZ zone. However as we inspect only HTTP traffic, a telnet to R3 will not work as it is not seen as HTTP traffic even if it is TCP traffic:

Let´s ping:

ZBF policy 4
 So let´s implement the last policy which concerns telnet and ping traffic originated from the router itself should be allowed to any zone. So let´s configure the following to reflect this policy:

Here basically as self zone can only inspect on ICMP, TCP, UDP and H,323 we are forced to use a combination of ACL and inspection on TCP and ICMP. If traffic is permitted by the ACL (telnet and ICMP) and the protocol is ICMP or TCP, let the traffic through and inspect TCP and ICMP sessions. So here we are doing basic inspection traffic. Let´s test:

The same will work for telnet but not SSH for example:

The SSH session is effectively dropped as only telnet is inspected.

So now we have implemented our security policy so let´s see what other features ZBF offers:

ZBF Rate Limiting

Let´s see some facts about ZBF rate-limiting first:

    Rate-limiting applies only for traffic moving between zones and not out/in of a single interface
    Use the syntax police rate <RATE> <BURST> under a policy-map
    Traffic exceeding is dropped
    ZBF also supports rate-limiting for limiting the max number/rate of half-open connections for UDP/TCP sessions. This configuration is achieved using a parameter-map which you apply to the inspected traffic for a specific class
    Not supported for zone self

Here I will just demonstrate how to configure ZBF for rate-limiting between security zones.

For example we could limit the amount of ICMP traffic sent from the OUTISDE zone to the DMZ zone. So let´s say that no more than 128 Kbit/s of ICMP traffic should be allowed from the OUTSIDE zone to the DMZ zone.

From the earlier configuration tasks we have already defined the following policy-map for traffic flowing from the OUTSIDE zone the the DMZ zone:

So we just modify the above configuration and add the following line:

So let´s test the above configuration:

Another feature of ZBF is to be able to do application inspection (Level 7 of the OSI models) which I will not develop in this post. Thanks to this feature you can do granular inspection filtering for example on GET/POST for HTTP or filter HTTP GET requesting a file called image.jpg. Application inspection uses a special type of class-map and policy-map in the format: class-map type inspect <PROTOCOL NAME>. The same apply to policy-map. This special type of policy-map must call the special type of class-map and be nested as a child policy under the normal inspect policy map.