Cisco Zone-Based Policy Firewall Fundamentals

Cisco Zone-Based Policy Firewall Fundamentals

The last section examines the configuration of a static packet-filtering firewall using interface ACLs. In this section, we leverage on Cisco’s Zone-Based Policy Firewall (ZPF) to create a dynamic packet-filtering firewall. ZPF is not Cisco’s first foray into dynamic packet filtering technology. Before ZPF, Cisco offered Context-Based Access Control (CBAC, pronounced “see-back”), later changing its name to IOS Classic Firewall. As we know, “classic” infers that it is older, so if you want the latest and greatest dynamic packet-filtering firewall technology, you will want to master the Cisco Zone-Based Policy Firewall.

NOTE
We will implement a stateful packet inspection and application layer firewall by leveraging on the Cisco IOS Zone-Based Policy Firewall. If you already understand the fundamentals of both, go ahead and read this section. If you don’t, and you have skipped the earlier section, “Examining and Defining Firewall Technologies,” now is the time to go back and carefully read it through. You have been warned!

As we have seen, when you only have a few interfaces on the firewall, configuring ACLs on a static packet-filtering firewall isn’t an enormous task. However, even with a pair of interfaces, by the time you have sorted all the permutations and combinations of pairing reply traffic with requests, rule order logic, and inbound versus outbound, the need for a disciplined configuration management approach as well as much testing is crucial.

Now imagine that you had five interfaces on the firewall (see Figure 5.14). The number of permutations with just the choice of applying ACLs inbound vs. outbound on 5 interfaces = 2 5 = 32 possible interactions to troubleshoot.

This is one of the reasons for the Cisco Zone-Based Policy Firewall (ZPF). ZPF enables you to group interfaces into security zones and design rules using the Cisco Common Classification Policy Language (C3PL) for traffic moving between the different zones.

FIGURE 5.14 ZPF conceptual overview.

NOTE
C3PL is not to be confused with his distant cousin, C3PO, of Star Wars fame!

For example, using ZPF for access rules by grouping DMZ1 and DMZ2 into a DMZ zone, Inside1 and Inside2 into a INSIDE zone, and the Internet uplink into its own INTERNET zone, you could create and troubleshoot rule interaction between three different security zones equally as easily as you would use ACLs on a three-interface firewall. C3PL is the language that is used to classify (or differentiate) traffic that flows between the different zones and take different security, and QoS actions on the flows. Of course, this is a security course, so you know that the focus will be on security policies for the traffic!
It’s not too early to look at a general overview of the workflow in configuring for ZPF. The following list is a high-level overview of the concepts, while trying to avoid Cisco terminology as much as possible:

1. Create zones. For example, DMZ, INSIDE, and INTERNET.
2. Assign interfaces to a zone. Vlan1 and Vlan2 in INSIDE zone; Vlan 3 and Vlan 4 in DMZ zone; FastEthernet 4 in INTERNET zone.
3. Define pairs of zones called “zone pairs.” inbound-to-dmz, inboundto-inside; outbound-to-internet.
4. Classify traffic. Classify traffic into flows.
5. Inter-zone pair inspection policy. Create an inspection policy for the classified traffic traveling between the zones in the zone pair.

NOTE
By grouping interfaces into zones, it makes it simple to add or remove interfaces because once an interface is associated to a zone, the security policy is immediately enforced without worrying about the extra abstraction and complexity of creating and applying ACLs and inspection (ip inspect) rules. That was the way that it used to be done with the legacy Cisco IOS Stateful Inspection called Context-Based Access Control (CBAC) firewall.

Advantages of ZPF

There are six main advantages of the ZPF, as follows:

• Grouping. Physical and virtual interfaces are grouped into zones.
• Zone Traversal. Firewall policies are applied to traffic traversing zones.
• Simplicity. Adding and removing interfaces into zones automatically integrates them into the firewall policy.
• ACL Independence. ZPF is not dependent on ACLs (see the following note).
• Troubleshooting. C3PL makes policies easier to visualize.
• Security Posture. ZPF turns the IOS router into a “deny unless explicitly permitted” firewall (reverse of the logic of the legacy stateful inspection model).

The other advantage is conceptual. Because ZPF is so visual, especially when using the Cisco SDM, it aids in learning how stateful firewalls operate and applying the rules in an intuitive fashion.

NOTE
Interface ACLs are still relevant and can be used to complement ZPF policies.

• Inbound ACL. Applied before ZPF policies.
• Outbound ACL. Applied after ZPF policies

Features of ZPF

The six main supported features of ZPF are as follows:

• Stateful (Dynamic) packet inspection
• Application layer firewall
• URL filtering
• Transparent firewall
• Per-policy parameter
• Virtual Routing and Forwarding (VRF)-aware firewall

ZPF Actions

There are three main categories of actions that the ZPF can take on traffic:

• Inspect. Stateful inspection. Monitor outbound traffic and statefully inspect the return traffic to ensure that it matches session table entries.
• Drop. Analogous to a deny ACE in an ACL.
• Pass. Analogous to a permit ACE in an ACL (not stateful as is the inspect action).

Zone Behavior

Refer to Figure 5.15. Note that the network zone topology has changed from Figure 5.14. Interfaces Vlan2 and Vlan4 are no longer members of zones. Vlan5 has been added to the INSIDE zone. This is just the kind of situation that will drive you crazy! Perhaps the INSIDE, DMZ, and INTERNET zones were configured previously and you have just added two interfaces without yet putting them in zones. If you let your intuition guide you (and remembering that the firewall will err on the side of caution), you could probably figure this out for yourself, but let’s look at the possible combinations of results.

Traffic Flowing Through the Router

What will happen to traffic that would be routed between two interfaces when ZPF is fully or partially configured? Here are the possible results with examples:

• Vlan2 to Vlan4. Inter-interface traffic is permitted (normally routed) if neither interface is a member of a zone.
• Vlan1 to Vlan3. If the interfaces are in two different zones, and there is a ZPF policy configured for that zone-pair, the policy actions (inspect, drop, or pass) will dictate what to do with the traffic.

If the interfaces are in two different zones, and there is no ZPF policy configured, the traffic will be dropped. (The firewall errs on the side of caution!)

• Vlan2 to FastEthernet4. If one interface is in a zone and the other one isn’t, the traffic is dropped.
• Vlan1 to Vlan5. If the interfaces are in the same zone (zone-pair is therefore not applicable) the traffic is passed.

Traffic Originating from the Router and Destined to the Router

What about traffic that either originates from or is destined to the router itself? By default, this traffic is permitted. The exception is where the traffic flows in a zone-pair in which the router’s zone is a member (see note about the “self” zone below). In this latter case, the traffic either from or to the router will be subject to the actions (inspect, drop, or pass) specified in the ZPF policy. Figure 5.16 illustrates the self zone.

FIGURE 5.16 The ZPF self-zone.

NOTE
The router is automatically put in a special zone called the “self” zone when ZPF is configured. Figure 5.16 illustrates this.

Using the Cisco SDM Basic Firewall Wizard to Configure ZPF

A basic firewall is essentially a firewall that has two zones: inside (trusted) and outside (untrusted). The Cisco SDM Basic Firewall wizard enables you to do the following:

• Create a stateful firewall policy between these zones, inspecting outbound TCP, UDP, and router-generated ICMP traffic.
• Block all IM (MSN, AOL, and Yahoo!) whether its tunneled in HTTP or not.
• Deny traffic from outside to inside zones.

Follow these steps to configure ZPF using the Cisco SDM Basic Firewall Wizard. Starting from the Cisco SDM home page:

1. Select Configure->Firewall and ACL.
2. Ensure that the Basic Firewall radio button is selected and then push the Launch the selected task button.
3. The Basic Firewall Configuration Wizard window appears. Click Next.
4. Select the interface(s) that will be in the outside zone and the inside zone.
   At least one interface must be in each zone in order to continue. Check the Allow secure SDM access from outside interfaces check box if you will be accessing the SDM from an interface in the untrusted zone.
   Figure 5.17 illustrates the Basic Firewall Interface Configuration window in the Firewall Wizard.
5. Click Next.
6. If you have selected the Allow secure SDM access from outside interfaces check box in the previous step, you will be prompted to set a policy for which range of IP addresses will be allowed to access the SDM from the outside zone. (Sound like a zone-pair that includes the self zone?) In the Type drop-down box, choose either Network address, Host IP address, or any. This dialog is illustrated in Figure 5.18.
   
   FIGURE 5.18 Configuring firewall for remote access.
7. Click Next. An Information window appears, indicating that the SDM connection will be dropped when the configuration is delivered to the firewall. Click OK on this window.
8. The Basic Firewall Security Configuration window appears. A slider control gives you a choice of applying either a high, medium, or low security policy. The default is high security. Click Next to accept the default.
9. The Basic Firewall Domain Name Server Configuration window appears, as illustrated in Figure 5.19. DNS is needed for application security, mainly because the domain names for IM services have to be resolved and the High Security policy (per the last step) will block IM. Fill in at least the Primary DNS Server and click Next.

   FIGURE 5.19 Basic Firewall Domain Name Service Configuration window.

10. The Firewall Configuration Summary window appears. This window presents a summary of the ZPF rules that will be applied to the router.The following is an example of the information in the Firewall Configuration Summary window. Refer to Figures 5.14 and 5.15 because the interfaces and zones in this summary match up with that example.This is not a preview of the CLI commands per se; it is just a summary of the policies that will be applied when the wizard is finished:

    Note: Do not select the interface through which you accessed SDM as the outside (untrusted) interface. If you do, you will not be able to launch
    SDM from that interface after you complete the Firewall Wizard.
    
    Inside(trusted) Interfaces:
    Vlan1 (10.10.10.1)
    Outside(untrusted) Interface:
    FastEthernet4 (192.168.99.218)
    Service Policy Configuration:
    In-zone -> Out-zone:
    Inspect TCP,UDP,H323,SIP,SCCP and other protocols
    Deny packets with invalid ip address as source
    Application Inspection for HTTP:
    Block HTTP port-misuse for IP,P2P
    Block HTTP protocol violation
    Block HTTP request methods other than post,head,get
    Block http request response containing non-ascii characters
    Application Inspection for Instant Messaging:
    Block all services of msn,yahoo,aol with log action
    Application Inspection for P2P:
    Block file transfer over edonkey,fasttrack,gnutella and kazaa2
    Block text-chat over edonkey
    Application Inspection for Email:
    Block invalid command for imap,pop3
    Block SMTP session with data length over 5 MB
    Self -> Out-zone:
    Inspect router generated ICMP traffic
    Out-zone -> Self:
    Permit secure SDM Access to router (HTTP,SSH,RCP) from specified
    source.
    Deny all other traffic.
    DNS Configuration:
    Primary DNS:192.168.99.130
    Secondary DNS:206.248.154.22

11. Click Finish. The SDM delivers the configuration to the router. This is illustrated in Figure 5.20.

    FIGURE 5.20 Cisco SDM commands delivery status.

    Recall Step 4. If you were accessing the SDM from the outside (untrusted) zone, you will lose the connection. Reconnect to the router using a secure http connection.

12. Navigate to the home page of the Cisco SDM and verify that the ZPF has been applied by looking for a green check mark beside the Firewall Policies menu. Expand the menu with the down arrow on the right-hand side. This is illustrated in Figure 5.21.
    
    FIGURE 5.21 Cisco SDM home page with active Firewall Policies.
13. Navigate to Configure->Firewall and ACL->Edit Firewall Policy to see a visual representation of the rule flow, as indicated in the bottom of the window illustrated in Figure 5.22.

FIGURE 5.22 Cisco SDM firewall policy with rule flow diagram.

The following CLI commands match the preceding example of using the SDM Basic Firewall Wizard.

!——————————
!1. CREATE CLASS MAPS
!——————————
class-map type inspect smtp match-any sdm-app-smtp
match data-length gt 5000000
class-map type inspect match-any SDM_HTTPS
match access-group name SDM_HTTPS
class-map type inspect match-any SDM_SSH
match access-group name SDM_SSH
class-map type inspect match-any SDM_SHELL
match access-group name SDM_SHELL
class-map type inspect match-any sdm-cls-access
match class-map SDM_HTTPS
match class-map SDM_SSH
match class-map SDM_SHELL
class-map type inspect http match-any sdm-app-nonascii
match req-resp header regex sdm-regex-nonascii
class-map type inspect imap match-any sdm-app-imap
match invalid-command
class-map type inspect match-any sdm-cls-protocol-p2p
match protocol edonkey signature
match protocol gnutella signature
match protocol kazaa2 signature
match protocol fasttrack signature
match protocol bittorrent signature
class-map type inspect match-any SDM_OSPF
match access-group name SDM_OSPF
class-map type inspect match-any sdm-cls-insp-traffic
match protocol dns
match protocol https
match protocol icmp
match protocol imap
match protocol pop3
match protocol tcp
match protocol udp
class-map type inspect match-all sdm-insp-traffic
match class-map sdm-cls-insp-traffic
class-map type inspect match-any SDM-Voice-permit
match protocol h323
match protocol skinny
match protocol sip
class-map type inspect match-any SDM_OSPF_TRAFFIC
match class-map SDM_OSPF
class-map type inspect match-all sdm-protocol-pop3
match protocol pop3
class-map type inspect match-any sdm-cls-icmp-access
match protocol icmp
match protocol tcp
match protocol udp
class-map type inspect match-any sdm-cls-protocol-im
match protocol ymsgr yahoo-servers
match protocol msnmsgr msn-servers
match protocol aol aol-servers
class-map type inspect pop3 match-any sdm-app-pop3
match invalid-command
class-map type inspect match-all sdm-access
match class-map sdm-cls-access
match access-group 101
class-map type inspect match-all SDM_OSPF_PT
match class-map SDM_OSPF_TRAFFIC
class-map type inspect match-all sdm-protocol-p2p
match class-map sdm-cls-protocol-p2p
class-map type inspect http match-any sdm-http-blockparam
match request port-misuse im
match request port-misuse p2p
match request port-misuse tunneling
match req-resp protocol-violation
class-map type inspect match-all sdm-protocol-im
match class-map sdm-cls-protocol-im
class-map type inspect match-all sdm-icmp-access
match class-map sdm-cls-icmp-access
class-map type inspect match-all sdm-invalid-src
match access-group 100
class-map type inspect http match-any sdm-app-httpmethods
match request method bcopy
match request method bdelete
match request method bmove
match request method bpropfind
match request method bproppatch
match request method connect
match request method copy
match request method delete
match request method edit
match request method getattribute
match request method getattributenames
match request method getproperties
match request method index
match request method lock
match request method mkcol
match request method mkdir
match request method move
match request method notify
match request method options
match request method poll
match request method post
match request method propfind
match request method proppatch
match
 request method put
match request method revadd
match request method revlabel
match request method revlog
match request method revnum
match request method save
match request method search
match request method setattribute
match request method startrev
match request method stoprev
match request method subscribe
match request method trace
match request method unedit
match request method unlock
match request method unsubscribe
class-map type inspect match-all sdm-protocol-http
match protocol http
class-map type inspect match-all sdm-protocol-smtp
match protocol smtp
class-map type inspect match-all sdm-protocol-imap
match protocol imap
!
!———————————
!2. CREATE POLICY MAPS
!———————————
policy-map type inspect sdm-permit-icmpreply
class type inspect sdm-icmp-access
inspect
class class-default
pass
policy-map type inspect http sdm-action-app-http
class type inspect http sdm-http-blockparam
log
reset
class type inspect http sdm-app-httpmethods
log
reset
class type inspect http sdm-app-nonascii
log
reset
class class-default
policy-map type inspect smtp sdm-action-smtp
class type inspect smtp sdm-app-smtp
reset
class class-default
policy-map type inspect imap sdm-action-imap
class type inspect imap sdm-app-imap
log
reset
class class-default
policy-map type inspect pop3 sdm-action-pop3
class type inspect pop3 sdm-app-pop3
log
reset
class class-default
policy-map type inspect sdm-inspect
class type inspect sdm-invalid-src
drop log
class type inspect sdm-protocol-http
inspect
service-policy http sdm-action-app-http
class type inspect sdm-protocol-smtp
inspect
service-policy smtp sdm-action-smtp
class type inspect sdm-protocol-imap
inspect
service-policy imap sdm-action-imap
class type inspect sdm-protocol-pop3
inspect
service-policy pop3 sdm-action-pop3
class type inspect sdm-protocol-p2p
drop log
class type inspect sdm-protocol-im
drop log
class type inspect sdm-insp-traffic
inspect
class type inspect SDM-Voice-permit
inspect
class class-default
pass
policy-map type inspect sdm-permit
class type inspect sdm-access
inspect
class type inspect SDM_OSPF_PT
pass
class class-default
!
!————————————
!3. CREATE SECURITY ZONES
!————————————
zone security out-zone
zone security in-zone
!————————————
!4. CREATE ZONE PAIRS
!————————————-
zone-pair security sdm-zp-self-out source self destination out-zone
service-policy type inspect sdm-permit-icmpreply
zone-pair security sdm-zp-out-self source out-zone destination self
service-policy type inspect sdm-permit
zone-pair security sdm-zp-in-out source in-zone destination out-zone
service-policy type inspect sdm-inspect
!
!—————————————————
!5. ASSOCIATE INTERFACES WITH ZONES
!—————————————————
interface FastEthernet4
zone-member security out-zone
!
interface Vlan1
zone-member security in-zone

Manually Configuring ZPF with the Cisco SDM

To configure ZPF manually, here are the four basic steps:

1. Create zones.
2. Create class maps.
3. Create policy maps (and actions: inspect, drop, or pass).
4. Create zone pairs and assign policy maps to zone pairs.

These steps are summarized in Figure 5.23 and are covered in more detail in the following sections through an example of manually configuring ZPF with the Cisco SDM. Refer to Figure 5.14 for the network diagram that this example follows.

FIGURE 5.23 Summary: Manually configuring ZPF.

Step 1: Create Zones

Follow these steps to create a zone:

1. Select Configure->Additional Tasks->Zones.
2. Click Add to create a new zone in the Zone panel, which is illustrated in Figure 5.24.
3. Enter a zone name in the Zone Name field of the Add a Zone window.
4. Select the interfaces that will be associated with that zone name by placing a check mark in the check box beside the interface name. Physical interfaces can be placed in only one zone, whereas virtual interfaces (such as dialer interfaces or bridged virtual interfaces) can be in multiple zones.
5. Click OK on the next two dialogs to create the zone and deliver the commands to the router.

NOTE
Be mindful of zone behavior per the earlier “Zone Behavior” section, because the policies have not been configured nor applied to the zone pairs yet!

Step 2: Create Class Maps

The next step to creating a ZPF policy is to define a Layer 3-4 class map. The class map will identify traffic that will have actions applied to it by policy maps (next step). For example, you might want all TCP traffic to be statefully inspected from the INSIDE zone to the INTERNET zone, with additional deep packet inspection (see the following note) applied to HTTP to ensure that it is both protocol-compliant and that IM traffic isn’t tunneled inside it. In Figure 5.25, a class map is created that will eventually be used to 1) identify, then 2) inspect outbound traffic (that is, from the INSIDE zone to the INTERNET zone) for IM protocols MSN, Yahoo, and AOL as well as for miscellaneous P2P (Peer to Peer) traffic such as BitTorrent and Kazaa. Remember, the class map doesn’t do anything but identify the traffic.

In order to identify the traffic, one or more distinguishing characteristics must be determined and based on the following criteria:

• Access-group. An ACL (standard or extended) can be applied to a class map.
• Protocol. TCP, UDP, ICMP, and application layer protocols such as HTTP, SMTP, IM, and P2P can be used as distinguishing characteristics. Any protocol (either user-defined or well-known) understood by Port-toApplication Mapping (PAM) can be specified.
• Class-map. Class maps can be nested inside another class map to provide additional match criteria.

NOTE
ZPF also supports advanced layer 7 application inspection. This is not covered in the Cisco Introduction to IOS Network Security v1.0 course, on which this Exam Cram is based.

Step 3: Create Policy Maps

Once the class maps are created, create policy maps and associate class maps to them along with actions (inspect, drop, or pass). See Figure 5.26 for the steps in the Cisco SDM.

FIGURE 5.26 Creating a policy map and associating class map(s) and action(s) to the policy map.

When you are done, Figure 5.27 shows what your policy map should look like when class maps and actions are associated to it. In this example, the policy map has two class maps associated to it with Drop/Log and Inspect actions, respectively.

FIGURE 5.27 Example of policy map with two class maps and actions applied.

Step 4: Create Zone Pairs

Create a zone pair to which the policy map will be assigned. Assign the policy map to the zone pair in the same dialog, as illustrated in Figure 5.28.

Monitoring ZPF

Zone-Based Policy Firewall can be monitored using either the CLI or the Cisco SDM. To monitor ZPF with the Cisco SDM, choose Monitor->Firewall Status. Select the firewall policy from the list of policies and choose either: Active Sessions, Dropped Packets, or Allowed Packets, from the list on the left-hand side, as illustrated in Figure 5.29.

The equivalent CLI command is show policy-map type inspect zone-pair session. The output of this command is shown a little later. See if you can identify these items:

• The zone pair name.
• The service policy that was applied to the zone pair.
• The class maps that are associated to the service policy.
• The actions that the policy map takes for each class map.

NOTE
Hint: The command’s output is indented to show objects nested within others. Shading has been added to the output of the show policy-map type inspect zone-pair session command later to make it easier for you to identify the items in the previous list.

Not so fast! Before issuing the show policy-map type inspect zone-pair session command, first verify that the zones are set up per Figure 5.14:

CiscoISR#show zone security INSIDE
zone INSIDE
Member Interfaces:
Vlan1
Vlan2
CiscoISR#show zone security INTERNET
zone INTERNET
Member Interfaces:
FastEthernet4
CiscoISR#show zone security DMZ
zone DMZ
Member Interfaces:
Vlan3
Vlan4

Now, look at the CLI output of the show policy-map type inspect zone-pair session command for detail of the traffic that was inspected, dropped, or passed by the policy map IM-P2P-and-General-Purpose_Traffic that was applied to the zone pair INSIDE_TO_INTERNET.

• Traffic that matches on class-map IM_and_P2P_Traffic will be dropped. Thus, IM (MSN Messenger) and P2P traffic (BitTorrent) will be dropped.
• Traffic that matches on class-map GP_Stateful will be inspected. Thus, TCP and UDP traffic will be statefully inspected.
• Traffic that matches on class-map class-default will be dropped. Thus, all other traffic will be dropped.

Note that some of the output was omitted to ensure comprehension:

CiscoISR#show policy-map type inspect zone-pair session
Zone-pair: INSIDE_TO_INTERNET
Service-policy inspect : IM-P2P-and-General-Purpose_Traffic
Class-map: IM_and_P2P_Traffic (match-any)
Match: protocol msnmsgr
3 packets, 84 bytes
30 second rate 0 bps
Match: protocol bittorrent
1 packets, 28 bytes
30 second rate 0 bps
Drop
4 packets, 112 bytes
Class-map: GP_Stateful (match-any)
Match: protocol tcp
127 packets, 3916 bytes
30 second rate 0 bps
Match: protocol udp
390 packets, 29217 bytes
30 second rate 2000 bps
Inspect
Established Sessions
Session 8394B708 (192.168.0.101:5762)=>(72.247.244.32:80) tcp
SIS_OPEN
Created 00:01:39, Last heard 00:00:49
Bytes sent (initiator:responder) [4661:3726]
Session 83944270 (192.168.0.101:5757)=>(72.247.244.32:80) tcp
SIS_OPEN
Created 00:01:39, Last heard 00:00:37
Bytes sent (initiator:responder) [5734:3299]
Session 839472C8
(192.168.0.101:50454)=>(68.40.182.79:19313) udp SIS_OPENING
Created 00:00:09, Last heard 00:00:09
Bytes sent (initiator:responder) [67:0]
Class-map: class-default (match-any)
Match: any
Drop (default action)
0 packets, 0 bytes

• CCNA Security Study Notes