# Module 16: Zone-Based Policy Firewalls

:::success
Here is a cheat sheet generated from the course content using ChatGPT. It recaps the main concepts of each module, definitions and examples. At the end of (almost) each part, you will find a link to online related flashcards.
:::

### 16.1 ZPF Overview

#### 16.1.1 Benefits of a ZPF

**Firewall Configuration Models**
- **Classic Firewall**: Applies firewall policies directly to interfaces.
- **Zone-based Policy Firewall (ZPF)**: Assigns interfaces to security zones, and policies are applied to traffic between zones.

**Advantages of ZPF**
- Not dependent on ACLs for configuration.
- Default posture: Block all traffic unless explicitly allowed.
- Uses Cisco Common Classification Policy Language (C3PL):
- Policies are structured with events, conditions, and actions.
- Scalable: One policy affects all matching traffic types.
- Allows grouping of virtual and physical interfaces into zones.
- Policies are applied to unidirectional traffic between zones.

**Key Notes**
- Both Classic Firewall and ZPF models can run concurrently on a router.
- A single interface cannot use both models simultaneously (e.g., cannot be a security zone member and configured for IP inspection).

---

#### 16.1.2 ZPF Design

**Step 1: Determine the Zones**
- Define security borders by separating the network into zones.
- Examples of zones:
- Public network (e.g., Internet).
- Internal network (e.g., private LAN).

**Step 2: Establish Policies Between Zones**
- Define permitted sessions between source and destination zones.
- Specify unidirectional traffic flows based on:
- TCP and UDP sessions.
- ICMP sessions (e.g., echo requests).
- Use zone pairs to define policies between zones (e.g., inside → outside).

**Step 3: Design the Physical Infrastructure**
- Account for security and availability requirements.
- Determine the number of devices between most-secure and least-secure zones.
- Consider redundant devices for high availability.

**Step 4: Identify Subsets Within Zones and Merge Traffic Requirements**
- Identify zone subsets connected to firewall interfaces.
- Merge traffic requirements to define device-specific interzone policies.
- Note: Implementing zone subsets is beyond the scope of this curriculum.

**Common ZPF Design Examples**
1. **LAN-to-Internet**
- Firewall separates inside network from outside (Internet).
2. **Firewall with Public Servers (Design 1)**
- Public servers (e.g., web/mail servers) are placed in a perimeter zone.
3. **Firewall with Public Servers (Design 2)**
- Public servers are placed between two firewalls separating inside and outside networks.
4. **Redundant Firewalls**
- Double firewalls with public servers between them, ensuring redundancy.
5. **Complex Firewall Design**
- Multiple VLANs and devices connect to a firewall on one side of the perimeter, with another firewall separating the perimeter from the outside network.
- Includes e-commerce, VPN users, VPN offices, and web/mail servers in the setup.

>[!Warning]Recap
>The IOS ZPF provides a flexible and powerful replacement for the older Classic IOS Firewall. It provides a new configuration mode in which interfaces are assigned to security zones and firewall policies are applied to traffic moving between the zones. The ZPF provides a structured and simplified method of designing and implementing network security on routers that are performing a firewall function.

### 16.2 ZPF Operation

---

#### 16.2.1 ZPF Actions

Zone-based Policy Firewalls (ZPFs) can perform three actions on network traffic. These actions are defined by the policies applied to protocol, source, destination zones (zone pairs), and other criteria:

1. **Inspect**:
- Performs Cisco IOS stateful packet inspection.
- Tracks the state of connections or sessions.

2. **Drop**:
- Similar to a `deny` statement in an ACL.
- The `log` option is available to record the dropped packets.

3. **Pass**:
- Equivalent to a `permit` statement in an ACL.
- Does not track the state of connections or sessions.

---

#### 16.2.2 Rules for Transit Traffic

The behavior of transit traffic depends on the zone memberships of the ingress and egress interfaces. Below are the rules governing this behavior:

- **If neither interface is a member of any zone**: The action is `PASS`.
- **If both interfaces are members of the same zone**: The action is `PASS`.
- **If one interface is a member of a zone and the other is not**: The action is `DROP`.
- **If both interfaces are members of the same zone-pair, and a policy exists**: The action is determined by the policy (`INSPECT`, `ALLOW`, or `DROP`).

**Rules Summary:**

| Source Interface Member of Zone? | Destination Interface Member of Zone? | Zone-Pair Exists? | Policy Exists? | Result |
|----------------------------------|----------------------------------------|-------------------|----------------|----------|
| NO | NO | N/A | N/A | PASS |
| YES | NO | N/A | N/A | DROP |
| NO | YES | N/A | N/A | DROP |
| YES (private) | YES (private) | N/A | N/A | PASS |
| YES (private) | YES (public) | NO | N/A | DROP |
| YES (private) | YES (public) | YES | NO | PASS |
| YES (private) | YES (public) | YES | YES | INSPECT |

---

#### 16.2.3 Rules for Traffic to the Self Zone

The self zone refers to traffic destined to or originating from the router itself. It includes all IP addresses assigned to router interfaces. This traffic typically involves device management (e.g., SSH) or routing protocol traffic.

**Rules for Traffic to and from the Self Zone**:
- If the router is either the source or the destination, all traffic is permitted.
- If a zone-pair with a specific service policy exists, the policy is applied to the traffic.

**Rules Summary:**

| Source Interface Member of Zone? | Destination Interface Member of Zone? | Zone-Pair Exists? | Policy Exists? | Result |
|----------------------------------|----------------------------------------|-------------------|----------------|----------|
| YES (self zone) | YES | NO | N/A | PASS |
| YES (self zone) | YES | YES | NO | PASS |
| YES (self zone) | YES | YES | YES | INSPECT |
| YES | YES (self zone) | N/A | N/A | PASS |
| YES | YES (self zone) | NO | N/A | PASS |
| YES | YES (self zone) | YES | NO | PASS |
| YES | YES (self zone) | YES | YES | INSPECT |

>[!Warning]Recap
>ZPFs use user-defined policies to act on specific traffic that is travelling from a source zone to a destination zone. Three actions can be specified:
>- **Inspect** - The ZPF performs stateful packet inspection.
>- **Drop** - The traffic is not permitted to travel to the destination. The rejected packets can be logged.
>- **Pass** - The traffic is permitted to travel to the destination zone. This does not track the state of connections or sessions.
>
>Default rules are applied to transit traffic based on the configuration of the ingress and egress interfaces and the existence of policies. For example, if neither ingress or egress interface is defined as member of a zone, traffic is permitted to exit the egress interface. Similarly, if both interfaces are members of the same zone, then traffic is allowed to pass. However, if one interface is a member of a zone and the other is not, traffic will be dropped. It is important to understand these and the other rules covered in the module.
>
>A special zone exists that is known as the self zone. The self zone is the router itself. In the self zone, the router interfaces serve as either the source or destination of the traffic. Self zone traffic is either for management of the device, or for traffic forwarding control. Similar to the rules for transit traffic, rules exist for how traffic in the self zone will be handled.

### 16.3 Configure a ZPF

---

#### 16.3.1 Configure a ZPF
1. **Steps to Configure a ZPF:**
- Step 1: Create the zones.
- Step 2: Identify traffic with a class-map.
- Step 3: Define an action with a policy-map.
- Step 4: Identify a zone pair and match it to a policy-map.
- Step 5: Assign zones to the appropriate interfaces.

2. **Zone-Based Policy Firewall Configuration:**
- Example topology includes a private zone and a public zone.
- Traffic specifics:
- HTTP traffic allowed from the private zone to the public zone.
- HTTP return traffic allowed from the public zone to the private zone.
- Any other traffic is denied.

---

#### 16.3.2 Step 1: Create the Zones
1. **Questions Before Creation:**
- Which interfaces should be included in the zones?
- What will be the name for each zone?
- What traffic is necessary between the zones and in which direction?

2. **Command to Create Zones:**

   Router(config)# zone security <zone-name>

Example:

   R1(config)# zone security PRIVATE
   R1(config-sec-zone)# exit
   R1(config)# zone security PUBLIC
   R1(config-sec-zone)# exit

---

#### 16.3.3 Step 2: Identify Traffic
1. **Traffic Identification with Class-Maps:**
- Class-maps are used to identify sets of packets based on contents using “match” conditions.

2. **Command Syntax for Class-Maps:**

   Router(config)# class-map type inspect [match-any | match-all] <class-map-name>

**Parameters:**
| Parameter | Description |
|----------------|-------------|
| match-any | Packets must meet one of the match criteria. |
| match-all | Packets must meet all of the match criteria. |
| class-map-name | Name of the class-map. |

**Matching Criteria Syntax:**

   Router(config-cmap)# match access-group {acl-# | acl-name}
   Router(config-cmap)# match protocol <protocol-name>
   Router(config-cmap)# match class-map <class-map-name>

**Parameters:**
| Parameter | Description |
|----------------------|-------------|
| match access-group | Matches traffic to an ACL number or name. |
| match protocol | Matches traffic to a specific protocol. |
| match class-map | Uses another class-map to identify traffic. |

3. **Example:**
- Allow HTTP, HTTPS, and DNS traffic:

   R1(config)# class-map type inspect match-any HTTP-TRAFFIC
   R1(config-cmap)# match protocol http
   R1(config-cmap)# match protocol https
   R1(config-cmap)# match protocol dns

---

#### 16.3.4 Step 3: Define an Action
1. **Define Actions with Policy-Maps:**
- Actions such as `inspect`, `drop`, or `pass` are associated with class-maps.

2. **Command Syntax for Policy-Maps:**

   Router(config)# policy-map type inspect <policy-map-name>
   Router(config-pmap)# class type inspect <class-map-name>
   Router(config-pmap-c)# {inspect | drop | pass}

**Parameters:**
| Parameter | Description |
|-----------|-------------|
| inspect | Maintains session state for TCP/UDP traffic. |
| drop | Discards traffic silently. |
| pass | Allows traffic without tracking session state. |

3. **Example Policy-Map:**

   R1(config)# policy-map type inspect PRIV-TO-PUB-POLICY
   R1(config-pmap)# class type inspect HTTP-TRAFFIC
   R1(config-pmap-c)# inspect

---

#### 16.3.5 Step 4: Identify a Zone-Pair and Match to a Policy
1. **Command Syntax for Zone-Pairs:**

   Router(config)# zone-pair security <zone-pair-name> source <source-zone> destination <destination-zone>
   Router(config-sec-zone-pair)# service-policy type inspect <policy-map-name>

**Parameters:**
| Parameter | Description |
|---------------------|-------------|
| source-zone-name | Name of the source zone. |
| destination-zone-name | Name of the destination zone. |
| self | Indicates traffic to/from the router itself. |

2. **Example Zone-Pair:**

   R1(config)# zone-pair security PRIV-PUB source PRIVATE destination PUBLIC
   R1(config-sec-zone-pair)# service-policy type inspect PRIV-TO-PUB-POLICY

---

#### 16.3.6 Step 5: Assign Zones to Interfaces
1. **Command to Assign Zones:**

   Router(config-if)# zone-member security <zone-name>

2. **Example:**

   R1(config)# interface GigabitEthernet 0/0
   R1(config-if)# zone-member security PRIVATE
   R1(config-if)# interface Serial 0/0/0
   R1(config-if)# zone-member security PUBLIC

---

#### 16.3.7 Verify a ZPF Configuration
1. **Verification Commands:**
- `show run | begin class-map`
- `show class-map type inspect`
- `show zone security`
- `show zone-pair security`
- `show policy-map type inspect`

2. **Example Output:**

   R1# show policy-map type inspect zone-pair sessions
   ...
   Zone-pair: PRIV-PUB
   Service-policy inspect: PRIV-TO-PUB-POLICY
      Class-map: HTTP-TRAFFIC
         Match: protocol http
         Inspect
         ...
      Class-map: class-default
         Drop

---

#### 16.3.9 ZPF Configuration Considerations
1. Key considerations include:
- No filtering between interfaces in the same zone.
- Interfaces cannot belong to multiple zones.
- ZPF can coexist with Classic Firewall but not on the same interface.
- Default inter-zone policy is to drop all traffic unless allowed by a service-policy.

>[!Warning]Recap
>There are five steps in the process of configuring a ZPF. First the zones are created. Next, one or more class maps are created to specify the traffic which should be associated with a policy. Then, policies are created that associate the class-map traffic with the pass, drop, or inspect actions. It is then necessary to create zone pairs that will be associated with policy maps. Finally interfaces are associated with zones. At this point, the ZPF policy is active.