CCIE Study Notes

Let me start this section off by recommending the INE CCIE Security Advanced Technology videos for this topic. Like probably most of you, I come from an environment where firewalls are firewalls and routers are routers. This is for the firewall on a router scenario. Once again, I can just about guarantee a question on this somewhere on the Written test, but you will definitely have to know how to configure/troubleshoot this to pass your lab.

For this section, you have to understand the concept of Zones. Interfaces are assigned to zones and the inspection policy is applied to traffic moving between the zones. Firewall policies are configured using the CPL (Cisco Policy Language) which "employs a hierarchical structure to define inspection for network protocols and the grups of hosts to which the inspection will be applied." Note that the ZBFW (sometimes called ZFW) does not use the CBAC commands (ip inspect) of the previous section. You can use CBAC and ZBFW on the same router, but not on the same interface.

There are "steps" to configuring this, but the order is supposedly not important. However, some dependencies exist (so it's best to know this in order).

1. Define zones.
2. Define zone-pairs.
3. Define class-maps that describe traffic that must have policy applied as it crosses a zone-pair.
4. Define policy-maps to apply action to your class-maps' traffic.
5. Apply policy-maps to the zone-pairs.
6. Assign interfaces to zones.

Cisco's Zone-Based Policy Firewall Design and Application Guide is a good place to start for a really good review of these concepts and configurations.

You will want to know the "rules" for this:

* A zone must be configured before interfaces can be assigned to the zone.
* An interface can be assigned to only one security zone.
* All traffic to and from a given interface is implicitly blocked when the interface is assigned to a zone, except traffic to and from other interfaces in the same zone, and traffic to any interface on the router.
* Traffic is implicitly allowed to flow by default among interfaces that are members of the same zone.
* In order to permit traffic to and from a zone member interface, a policy allowing or inspecting traffic must be configured between that zone and any other zone.
* The self zone is the only exception to the default deny all policy. All traffic to any router interface is allowed until traffic is explicitly denied.
* Traffic cannot flow between a zone member interface and any interface that is not a zone member. Pass, inspect, and drop actions can only be applied between two zones.
* Interfaces that have not been assigned to a zone function as classical router ports and might still use classical stateful inspection/CBAC configuration.
* If it is required that an interface on the box not be part of the zoning/firewall policy. It might still be necessary to put that interface in a zone and configure a pass all policy (sort of a dummy policy) between that zone and any other zone to which traffic flow is desired.
* From the preceding it follows that, if traffic is to flow among all the interfaces in a router, all the interfaces must be part of the zoning model (each interface must be a member of one zone or another).
* The only exception to the preceding deny by default approach is the traffic to and from the router, which will be permitted by default. An explicit policy can be configured to restrict such traffic.

So let's start with defining zones and zone-pairs. It's pretty straightforward:

zone security zone-name

zone-pair security zone-pair-name source source-zone-name destination destination-zone-name

Don't forget - one of these zones could be the "self" zone (traffic to and from the device itself).

One of the examples of this from Cisco documentation:

zone security z1
description finance department networks
!
zone security z2
description engineering services network
!
zone-pair security zp source z1 destination z2
service-policy type inspect p1
!
interface ethernet0
zone-member security z1
!
interface ethernet1
zone-member security z2

The part that's missing from the above is the class-map which is used in the policy-map (p1) used in the service-policy above. That part is the same as all the other class-maps, policy-maps and service-policy configurations. Remember your "match any" versus "match all" for class maps.

Your policy map is going to use one of three actions:
Drop
Pass
Inspect

Also - with this you can use "parameter-map type inspect " command to create parameter-maps.

Parameter-maps specify inspection behavior for ZFW, for parameters such as DoS protection, TCP connection/UDP session timers, and audit-trail logging settings. Parameter-maps are also applied with Layer 7 class and policy-maps to define application-specific behavior, such as HTTP objects, POP3 and IMAP authentication requirements, and other application-specific information.

Application inspection introduces additional capability to ZFW. Cisco IOS Software ZFW offers application inspection and control on these application services:

HTTP
SMTP
POP3
IMAP
Sun RPC
P2P Application Traffic
IM Applications

Application inspection and control (AIC) varies in capability per service.
You may be given a snippet of configuration (like the one below) and asked to evaluate what it does or doesn't do - or to choose a correct configuration out of a couple of examples. So know your application inspection parameters and how they are configured.

!configure the layer-7 traffic characteristics:
class-map type inspect http match-any http-l7-cmap
match req-resp protocol-violation
match request body length gt 4096
!
!configure the action to be applied to the traffic
!matching the specific characteristics:
policy-map type inspect http http-l7-pmap
class type inspect http http-l7-cmap
reset
log

Out of the applications that can be inspected, I would focus on HTTP - which is the most likely to pop up. Also know that you may see Regex in some of the examples.

parameter-map type regex non_ascii_regex
pattern “[^\x00-\x80]”
class-map type inspect http non_ascii_cm
match req-resp header regex non_ascii_regex
policy-map type inspect http non_ascii_pm
class type inspect http non_ascii_cm
reset

Or

parameter-map type regex ref_regex
pattern “\.delfinproject\.com”
pattern “\.looksmart\.com”

parameter-map type regex host_regex
pattern “secure\.keenvalue\.com”
pattern “\.looksmart\.com”

parameter-map type regex usragnt_regex
pattern “Peer Points Manager”

class-map type inspect http spy_adwr_cm
match request header refer regex ref_regex
match request header host regex host_regex
match request header user-agent regex usragnt_regex

policy-map type inspect http spy_adwr_pm
class type inspect http spy_adwr_cm
reset

If you already know this information from previous sections, take a look at the examples in the design guide. Make sure you understand the examples.

Also understand the Self Zone. There are limitations (compared to regular zones).

* As was the case with classical stateful inspection, router-generated traffic is limited to TCP, UDP, ICMP, and complex-protocol inspection for H.323.
* Application Inspection is not available for self-zone policies.
* Session and rate limiting cannot be configured on self-zone policies.

You will want to know/understand the common/desirable access policies for the self zone as outlined in the design guide. Most of these are common sense. If I was going to create a question on this, I would ask something about a scenario based on the "rules" of ZFWs. A second question would be something on a HTTP inspection configuration. Note that 5.x is about 18% and 5.2 is one of 15 subtopics, so I wouldn't expect more than two questions on this section (unless you get something wrong - and then it will hammer you with this - remember "adaptive" testing). Also remember that the "steps" above would make a nice drag-and-drop question. Even though it says there is no specific order - really, there is an order.