Building Blocks for a Cisco Zone-based Firewall policy

This post briefly discusses class-maps and policy-maps (the main components of a ZFW policy) and their relevant attributes. If you are familiar with QoS configuration on Cisco IOS routers, you will quickly detect the similarities between the Class-based Policy Language (CPL) and the MQC (Modular QoS CLI). One important difference to be highlighted is that ZFW employs type inspect class-maps and policy-maps (and not the regular maps used within the QoS domain).

A class-map type inspect is used to identify groups of packets that have some property in common. Two simple examples are the group of HTTP packets (classified by means of a match protocol statement) and packets that travel from network A to network B (classified with the aid of an access-list bound to a match access-group statement).

A policy-map type inspect is employed to assign actions for classes previously defined with class-map type inspect commands. The available actions for packets that meet the selection criteria for a certain class are inspect, pass, police and drop. A brief description of each of these actions follows:

  • inspect: used to detect connection requests and provide the appropriate openings for return traffic. (Similar to what is achieved with the ip inspect command within a CBAC environment).
  • pass: this unidirectional action is equivalent to a permit statement inside an ACL and is not capable of handling return traffic. The pass action fits well for dealing with stateless flows such as traffic encrypted with Encapsulating Security Payload (ESP) protocol.
  • drop: corresponding to the ACL deny statements, this action is used to block undesired traffic trying to cross the firewall. The policy-maps of type inspect include a reserved class named class-default, which typically provides an easy way of discarding packets that did not fall in any of the previous classes (within the policy-map).
  • police: designed to provide rate-limiting functionality for classified traffic that is subject to the inspect action. (Not available for the special purpose class called class-default).

The Class-based Policy Language (CPL) provides a very structured and logical way of building firewall policies. You normally start by defining classification criteria for flows (by using class-maps) and refer to these classes within a policy-map (sequence of actions applied to classified packets).

The next step is to employ zone security statements to establish the domains of trust in a given topology (‘zones’) and rely on zone-pair security commands to define the source and destination zones to which the ZFW policy will apply. It is important to observe that:

–  The policy-map is attached to the zone-pair security using a service-policy type inspect command.

– The service-policy type inspect is activated when you assign router interfaces to zones (by using ‘zone-member security‘ commands at the interface level).

– You can have a set of predefined policy-maps that are applied on demand to an existent zone-pair. This is useful, for instance,  if you have a situation in which policy may change during the working hours or for troubleshooting purposes. (It is very helpful to think about your possible policies and their building blocks before you need to deploy them…)

– If you assign two interfaces to different zones without defining a zone-pair security, there will be no traffic flowing between these zones (and, consequently, no connectivity between the interfaces belonging to them).

The relationships between the elements of ZFW policy are summarized in the following figure.

Building Blocks for a ZFW Policy

** Related Posts:

 

Leave a comment

Filed under English, Firewalls, Security

Comments are closed.