Cisco have always re-invented the access-list. From standard to extended, introducing the 'established' TCP SYN 'catch'. Then Reflexive, context based (inspection) and now...the ZFW or Zone Based Firewall (why isn't it ZBF? I have no idea). Since 12.4(6)T we've had a new kid on the block which when I saw it felt very ScreenOS borrowing something from PixOS. The idea is that instead of an interface associated access-list we instead associate the interface with a zone type e.g. inside and outside. Each interface is in a zone and they can share access rules with interfaces in the same zone including state.
One big shift is the introduction of the C3PL or Cisco Policy Language (Cisco Common Classification = C3) which was done to assist reading the security rules and troubleshooting. However just like the IOS access-list the default action if not permitted is DENY.
Right so how does it function? If you imagine the PIX of FWSM where you have a number of interfaces each with a security level (a number between 0 and 100) we had the 'water can't flow uphill rule. This was where interfaces in a higher security level (highest is 100) could not be reached from a lower security level (e.g. 99) without having an access-list rule to allow it. Traffic from a higher security level to a lower one however was permitted unless specifically denied. Well the ZFW allows nothing from everywhere, access requires permission, the default is deny with one exception, the 'zone-less interface'. If the ingress and egress interfaces are both not placed into a zone then traffic will flow as if in a normal router. If one of the interfaces is in a zone then the traffic will not flow...pretty tight really.
To sum up the ZFW is a logical security profile which *can* be added across multiple interfaces. The picture below should help to demonstrate the point
- Traffic can flow freely between F1/0 and F2/0 because the are members of the same zone (OUTSIDE)
- Without policies to allow the traffic it is not flowing between the other interfaces e.g. Fa0/0 to Fa2/0 or Fa0/0 to Fa1/0.
- Traffic between Fa0/0 and Fa1/0 or Fa2/0 cannot flow without a policy allowing it from zone INSIDE to zone OUTSIDE
- Traffic will NEVER flow between Fa3/0 and the other interfaces because it is not part of any zone
The flow of traffic between zones is made using a 'zone-pair'. The zone pair is a unidirectional relationship form a source to a destination and does not imply a bi-directional relationship. So how do we configure the ZFW
1. Define the zones
2. Define the traffic policies (using class-maps)
3. Define the policy actions (using policy-maps)
4. Define the zone pairs
5. Apply the policy map to the zone pair using the service policy
6. Assign the interfaces into the zonesThe Rules
The interfaces themselves can only be assigned to ONE zone.
Traffic to and from a zone is BLOCKED except traffic directed TO the router (i.e. the interface IP) OR traffic sent between interfaces in the same zone.
Traffic sent TO the router (e.g. the IP address of the interface rather than traffic flowing through
the router. This is known as the SELF ZONE.
Unless we have a policy on the SELF ZONE traffic is allowed by default.
For traffic to flow between zones there MUST be a policy to permit it (the default is DENY)
A zone member and a non-zone member traffic will be DENIED
Other interfaces not in a zone can use other security policies such as access-lists, CBAC etc.
If we want to pass traffic to/from other zones on that firewall we need to add them to a zone with a 'Pass ALL' policy.Three types of Traffic
PASS traffic is allowed to travel uni-directionally (stateless)
INSPECT traffic (very much like the IOS firewall) allows return traffic (stateful)
DROP traffic denied either denied by intention, accident or default (zone-zoneless)
A fourth type, the URLFILTER is used inside the service-policy to affect URL matching.Configuration
For our example I've chosen something I hope we can all relate to. We'll have a bastion router protecting our corporate network from the big bad Internet. So how would we normally do this? Well maybe we'd have an extended access list allowing protocols out by port number for example HTTP or whatever. Then to make sure our outbound traffic could come back in again we'd use the established keyword to pick up on the SYN flag in the packets...but we can spoof those right so maybe it's not so safe. OK well we've got reflexive ACLs...thats pretty good. We can track established sessions with that but it's not so flexible. We can use inspection ACL's with CBAC...now thats better.
This article is all about ZFW though so lets cut to the chase. We are going to use a router with two interfaces (fa0/0 and fa0/1). Each interface will be placed into the dirty internet and the other pointing back at our private network. ZFW will be used to track protocols using CBAC and it will inspect traffic to allow us to manage the stateful nature of the traffic (outbound is recorded and matched inbound).
Lets go through the plan as we know:
Define the zones. We'll have ZONE_INSIDE and ZONE_OUTSIDE.
If we don't then we'll see this error when we try to configure the zone-pair.
Now lets define the class-map to match the traffic. We're going to look at our common web protocols like HTTP/S, TELNET and SSH...oh and FTP. It's a 'match-any' type so it can will match for any of these protocols....it;s the default type anyway right.
Now the class-map is done we need to build the policy map. Again it's an inspect type.
Now lets define the zone-pair....which way is the traffic going to be inspected. Remember this is uni-directionally significant with a source and destination.
Final step is to apply it to the interfaces....
and we're done!
I hope you found this brief introduction to ZFW interesting. It's a big topic and has grown in popularity for exams since it was introduced for the new CCNA Security track. You can read the Cisco website tutorial for more detail around this great feature for IOS - click here
Good luck with your studies.