Config Router

You are here: Home / CCNA / Cisco Zone-Based Policy Firewall Fundamentals

Cisco Zone-Based Policy Firewall Fundamentals

by Leave a Comment

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.

Cisco Zone-Based Policy Firewall Fundamentalsfig5.14

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.

Cisco Zone-Based Policy Firewall Fundamentalsfig5.15

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.

Cisco Zone-Based Policy Firewall Fundamentalsfig5.16

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.Cisco Zone-Based Policy Firewall Fundamentalsfig5.17
  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.
    Cisco Zone-Based Policy Firewall Fundamentalsfig5.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.Cisco Zone-Based Policy Firewall Fundamentalsfig5.19

    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:

  11. Click Finish. The SDM delivers the configuration to the router. This is illustrated in Figure 5.20.Cisco Zone-Based Policy Firewall Fundamentalsfig5.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.
    Cisco Zone-Based Policy Firewall Fundamentalsfig5.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.

Cisco Zone-Based Policy Firewall Fundamentalsfig5.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.

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.

Cisco Zone-Based Policy Firewall Fundamentalsfig5.23

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.Cisco Zone-Based Policy Firewall Fundamentalsfig5.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.

Cisco Zone-Based Policy Firewall Fundamentalsfig5.25

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.

Cisco Zone-Based Policy Firewall Fundamentalsfig5.26

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.

Cisco Zone-Based Policy Firewall Fundamentalsfig5.27

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.

Cisco Zone-Based Policy Firewall Fundamentalsfig5.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.

Cisco Zone-Based Policy Firewall Fundamentalsfig5.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:

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:

Leave a Reply

Your email address will not be published. Required fields are marked *