Context-Based Access Control

CBAC

CBAC Characteristics

Context-based access control (CBAC) is a solution available within the Cisco IOS Firewall.

CBAC intelligently filters TCP and UDP packets based on Application Layer protocol session information.
It provides stateful Application Layer filtering, including protocols that are specific to unique applications, as well as multimedia applications and protocols that require multiple channels for communication, such as FTP and H.323. CBAC can also examine supported connections for embedded NAT and PAT information and perform the necessary address translations. CBAC can block peer-to-peer (P2P) connections, such as those used by the Gnutella and KaZaA applications. Instant messaging traffic can be blocked, such as Yahoo!, AOL, and MSN.

CBAC Functions

CBAC performs four main functions:

Traffic filtering Traffic inspection Intrusion detection Generation of audits and alerts.

Traffic Filtering

CBAC can be configured to permit specified TCP and UDP return traffic through a firewall when the connection is initiated from within the network. It accomplishes this by creating temporary openings in an ACL that would otherwise deny the traffic.

CBAC can inspect traffic for sessions that originate from either side of the firewall.
It can also be used for intranet, extranet, and Internet perimeters of the network.

Traffic Filtering contd

CBAC examines not only Network Layer and Transport Layer information but also examines the Application Layer protocol information (such as FTP connection information) to learn about the state of the session. This allows support of protocols that involve multiple channels created as a result of negotiations in the control channel. Most of the multimedia protocols as well as some other protocols (such as FTP, RPC, and SQL*Net) involve multiple channels.

Traffic Inspection

Because CBAC inspects packets at the Application Layer and maintains TCP and UDP session information, it can detect and prevent certain types of network attacks such as SYN-flooding. A SYN-flood attack occurs when a network attacker floods a server with a barrage of connection requests and does not complete the connection. The resulting volume of half-open connections (embryonic) overwhelms the server, causing it to deny service to valid requests. CBAC also helps to protect against DoS attacks in other ways. It inspects packet sequence numbers in TCP connections to see if they are within expected ranges and drops any suspicious packets. CBAC can also be configured to drop half-open connections, which require firewall processing and memory resources to maintain.
6

Intrusion Detection

CBAC provides a limited amount of intrusion detection to protect against specific SMTP attacks. With intrusion detection, syslog messages are reviewed and monitored for specific attack signatures. Certain types of network attacks have specific characteristics or signatures. When CBAC detects an attack based on those specific characteristics, it resets the offending connections and sends syslog information to the syslog server.

Alert and Audit Generation

CBAC also generates real-time alerts and audit trails.

Enhanced audit trail features use syslog to track all network transactions and record timestamps, source and destination hosts, ports used, and the total number of transmitted bytes for advanced session-based reporting. Real-time alerts send syslog error messages to central management consoles upon detecting suspicious activity.

Traffic Filtering from CBAC

CBAC Characteristics contd

The first CBAC commands were introduced to Cisco IOS software in 1997.

CBAC is a dramatic improvement over the TCP established and reflexive ACL firewall options in several fundamental ways:

Monitors TCP connection setup Maintains UDP session information Tracks TCP sequence numbers Inspects DNS queries and replies Inspects common ICMP message types Supports applications that rely on multiple connections Inspects embedded addresses Inspects Application Layer information

10

CBAC Characteristics contd

It is important to note that CBAC only provides filtering for those protocols that are specified by an administrator.

If a protocol is not specified, the existing ACLs determine how that protocol is filtered, and no temporary opening is created.
Additionally, CBAC only detects and protects against attacks that travel through the firewall. It does not typically protect against attacks originating from within the protected network unless that traffic travels through an internal router with the Cisco IOS Firewall enabled. While there is no such thing as a perfect defense, CBAC detects and prevents most of the popular attacks on a network. However, since there is no impenetrable defense, determined and skilled attackers can still find ways to launch effective attacks.

11

12

13

14

15

16

17

18

CBAC Operation

Without CBAC, traffic filtering is limited to ACL implementations that examine packets at the Network Layer or, at most, the Transport Layer. CBAC relies on a stateful packet filter that is applicationaware. This means that the filter is able to recognize all sessions of a dynamic application. CBAC examines not only Network Layer and Transport Layer information but also examines Application Layer protocol information (such as FTP connection information) to learn about the state of the session.

19

CBAC Stateful Traffic Inspection

The state table tracks the sessions and inspects all packets that pass through the stateful packet filter firewall. CBAC then uses the state table to build dynamic ACL entries that permit returning traffic through the perimeter router or firewall.

20

How Does CBAC Work?

CBAC creates openings in ACLs at firewall interfaces by adding a temporary ACL entry for a specific session.

These openings are created when specified traffic exits the internal protected network through the firewall.
The temporary openings allow returning traffic that would normally be blocked and additional data channels to enter the internal network back through the firewall. The traffic is allowed back through the firewall only if it is part of the same session and has the expected properties as the original traffic that triggered CBAC when exiting through the firewall. Without this temporary ACL entry, this traffic would be denied by the pre-existing ACL. The state table dynamically changes and adapts with the traffic flow.
21

CBAC Operation

CBAC is flexible in its configuration, especially in choosing which direction to inspect traffic. In a typical setup, CBAC is used on the perimeter router or firewall to allow returning traffic into the network. CBAC can also be configured to inspect traffic in two directions - in and out. This is useful when protecting two parts of a network, where both sides initiate certain connections and allow the returning traffic to reach its source. Assume that a user initiates an outbound connection, such as Telnet, from a protected network to an external network, and CBAC is enabled to inspect Telnet traffic. Also assume that an ACL is applied on the external interface preventing Telnet traffic from entering the protected network. This connection goes through a multistep operation.
22

5.

When the session terminates, the dynamic information from the state table and the dynamic ACL entry are removed.

4.

3. The connection traffic is firstis comparedas it passes through the 1. When the information generated, the Cisco IOS software 2. Based on the inspection rules for CBAC, to entries in the state table. If a new entry is added, a dynamic ACL entry is added on the external interface in the If the router, the ACL isnot currently exist, theis not inspected,If it mightconnection does processed first trafficinbound ACL is applied. inspect the connection. If Telnet if an entry is added. the inbound direction (from the external network to the internal protected network). This allows does exist, ACLidle timer fortype connection isconnection, the packet If the the denies this the of outbound reset. packet is allowed through, and no other information is gathered. the returning Telnet traffic, that is, packets that are part of the same Telnet connection is dropped. If the ACL permits this outbound Otherwise, the connection goes to the next step. connection, the previously established with the outbound packet, back into the network. This temporary CBAC inspection rules are examined. opening is only active for as long as the session is open. These dynamic ACL entries are not saved to NVRAM.
23

CBAC TCP Handling

Recall that TCP uses a three-way handshake. The first packet contains a random sequence number and sets the TCP SYN flag. When the first packet from a TCP flow with the TCP SYN flag is received by the router, the inbound ACL on the inside secured interface is checked. If the packet is permitted, a dynamic session entry is created. The session is described by endpoint addresses, port numbers, sequence numbers, and flags. All subsequent packets belonging to this session are checked against the current state and discarded if the packets are invalid.

How does CBAC determine if a packet is a subsequent packet belonging to an already established session?

24

CBAC TCP Handling

When the TCP SYN packet is transmitted, the second packet contains a random sequence number that the responding host generates, as well as an acknowledgment sequence number (the received sequence number incremented by one), and the TCP SYN and ACK flags are set. The third packet acknowledges the received packet by incrementing the packet sequence number in the acknowledgment sequence, raising the sequence number by the appropriate number of transmitted octets, and setting the ACK flag. All subsequent segments increment their sequence numbers by the number of transmitted octets and acknowledge the last received segment by an increment of one, according to the TCP state machine. After the three-way handshake, all packets have the ACK flag set until the session is terminated. The router determines which session each packet belongs to by tracking sequence numbers and flags.

25

26

CBAC UDP Handling

With UDP, the router cannot track the sequence numbers and flags. There is no three-way handshake and no teardown process. If the first packet from a UDP flow is permitted through the router, a UDP entry is created in the connection table. The endpoint addresses and port numbers describe the UDP connection entry. When no data is exchanged within the connection for a configurable UDP timeout, the connection description is deleted from the connection table.

27

28

CBAC Handling Other Protocols

Stateful firewalls do not usually track other protocols, such as GRE and IPsec, but handle protocols in a stateless manner, similar to how a classic packet filter handles these protocols.

If stateful support is provided for other protocols, the support is usually similar to the support for UDP. When a protocol flow is initially permitted, all packets matching the flow are permitted until an idle timer expires.
Dynamic applications, such as FTP, SQLnet, and many protocols that are used for voice and video signaling and media transfer, open a channel on a well-known port and then negotiate additional channels through the initial session. Stateful firewalls support these dynamic applications through application inspection features. The stateful packet filter snoops the initial session and parses the application data to learn about the additional negotiated channels. Then the stateful packet filter enforces the policy that if the initial session was permitted, any additional channels of that application should be permitted as well.
29

CBAC Operations Inspection Rules

With CBAC, the protocols to inspect are specified in an inspection rule.

An inspection rule is applied to an interface in a direction (in or out) where the inspection applies. The firewall engine inspects only the specified protocol packets if they first pass the inbound ACL that is applied to the inside interface. If a packet is denied by the ACL, the packet is dropped and not inspected by the firewall.
Packets that match the inspection rule generate a dynamic ACL entry that allows return traffic back through the firewall. The firewall creates and removes ACLs as required by the applications. When the application terminates, CBAC removes all dynamic ACLs for that session.

30

CBAC Operations Inspection Rules

The Cisco IOS Firewall engine can recognize application-specific commands such as illegal SMTP commands in the control channel and detect and prevent certain Application Layer attacks. When an attack is detected, the firewall can take several actions:

Generate alert messages Protect system resources that could impede performance Block packets from suspected attackers

31

CBAC Operations Inspection Rules

The timeout and threshold values are used to manage connection state information. These values help determine when to drop connections that do not become fully established or that time out. Cisco IOS Firewall provides three thresholds against TCP-based DoS attacks:

Total number of half-opened TCP sessions Number of half-opened sessions in a time interval Number of half-opened TCP sessions per host

32

CBAC Operations Inspection Rules

If a threshold for the number of half-opened TCP sessions is exceeded, the firewall has two options:

It sends a reset message to the endpoints of the oldest halfopened session, making resources available to service newly arriving SYN packets. It blocks all SYN packets temporarily for the duration that the threshold value is configured. When the router blocks a SYN packet, the TCP three-way handshake is never initiated, which prevents the router from using memory and processing resources that valid connections need.

33

34

Configuring CBAC

There are four steps to configure CBAC:

Step 1. Pick an interface - internal or external. Step 2. Configure IP ACLs at the interface. Step 3. Define inspection rules. Step 4. Apply an inspection rule to an interface.

35

Step 1 Pick an Interface

First determine the internal and external interfaces for applying inspection. With CBAC, internal and external refers to the direction of conversation. The interface in which sessions can be initiated must be selected as the internal interface. Sessions that originate from the external interface will be blocked.

36

Two Interface

In a typical two-interface scenario in which one interface connects to the external network and the other connects to the protected network, CBAC prevents the specified protocol traffic from entering the firewall and the internal network, unless the traffic is part of a session initiated from within the internal network.

37

Three Interface

In a three-interface scenario in which the first interface connects to the external network, the second interface connects to a network in a DMZ, and the third interface connects to the internal protected network, the firewall can permit external traffic to resources within the DMZ, such as DNS and web services. The same firewall can then prevent specified protocol traffic from entering the internal network unless the traffic is part of a session initiated from within the internal network.

38

CBAC Two Directions

CBAC can also be configured in two directions at one or more interfaces. Configure the firewall in two directions when the networks on both sides of the firewall require protection, such as with extranet or intranet configurations, and for protection against DoS attacks. If configuring CBAC in two directions, configure one direction first, using the appropriate internal and external interface designations. When configuring CBAC in the other direction, the interface designations must be swapped

39

Step 2 Configure IP ACLs at the Interface

For Cisco IOS Firewall to work properly, an administrator must configure IP ACLs at the inside, outside, and DMZ interfaces.

To provide the security benefits of ACLs, an administrator should, at a minimum, configure ACLs on border routers situated at the edge of the network between the internal and external networks.
ACLs can also be used on a router positioned between two internal parts of a network to control traffic flow. ACLs can be configured on an interface to filter inbound traffic, outbound traffic, or both. The administrator must define ACLs for each protocol enabled on an interface to control traffic flow for that protocol. Use ACLs to determine what types of traffic to forward or block at the router interfaces.

40

Guidelines for IOS Firewall ACLs

Start with a basic configuration. A basic initial configuration allows all network traffic to flow from protected networks to unprotected networks while blocking network traffic from unprotected networks. Permit traffic that the Cisco IOS Firewall is to inspect. For example, if the firewall is set to inspect Telnet, Telnet traffic should be permitted on all ACLs that apply to the initial Telnet flow. Use extended ACLs to filter traffic that enters the router from unprotected networks. For a Cisco IOS Firewall to dynamically create temporary openings, the ACL for the return traffic must be an extended ACL. If the firewall only has two connections, one to the internal network and one to the external network, applying ACLs inbound on both interfaces works well because packets are stopped before they have a chance to affect the router.

41

Guidelines for IOS Firewall ACLs

Set up antispoofing protection by denying any inbound traffic (incoming on an external interface) from a source address that matches an address on the protected network. Antispoofing protection prevents traffic from an unprotected network from assuming the identity of a device on the protected network. Deny broadcast messages with a source address of 255.255.255.255. This entry helps prevent broadcast attacks. REMEMBER: the last entry in an ACL is an implicit denial of all IP traffic that is not specifically allowed by other entries in the ACL. Optionally, an administrator can add an entry to the ACL that denies IP traffic with any source or destination address, thus making the denial rule explicit. Adding this entry is especially useful if it is necessary to log information about the denied packets.

42

43

Step 3 Define Inspection Rules

You must define inspection rules to specify which Application Layer protocols to inspect at an interface. Normally, it is only necessary to define one inspection rule. The only exception occurs if it is necessary to enable the firewall engine in two directions at a single firewall interface. In this instance, you can configure two rules, one for each direction. An inspection rule should specify each desired Application Layer protocol to inspect, as well as generic TCP, UDP, or ICMP, if desired.

Generic TCP and UDP inspection dynamically permits return traffic of active sessions.
ICMP inspection allows ICMP echo reply packets forwarded as a response to previously seen ICMP echo messages.

The inspection rule consists of a series of statements, each listing a protocol and specifying the same inspection rule name. Inspection rules include options for controlling alert and audit trail messages.

44

Inspection Rules Configuration

Inspection rules are configured in global configuration.

Router(config)# ip inspect name inspection_name protocol [alert {on | off}] [audit-trail {on | off}] [timeout seconds]

Example 1

In this example, the IP inspection rule is named FWRULE. FWRULE inspects extended SMTP and FTP with alert and audit trails enabled. FWRULE has an idle timeout of 300 seconds.
ip inspect name FWRULE smtp alert on audit-trail on timeout 300 ip inspect name FWRULE ftp alert on audit-trail on timeout 300

45

Inspection Rules Configuration

Example 2

In this example, the PERMIT_JAVA rule allows all users permitted by standard ACL 10 to download Java applets.
ip inspect name PERMIT_JAVA http java-list 10 access-list 10 permit 10.224.10.0 0.0.0.255

46

Inspection Rules Configuration

Example 3

In this example, a list of protocols, including generic TCP with an idle timeout of 12 hours (normally 1 hour), is defined for the Cisco IOS Firewall to inspect.
ip inspect name in2out rcmd ip inspect name in2out ftp ip inspect name in2out tftp ip inspect name in2out tcp timeout 43200 ip inspect name in2out http ip inspect name in2out udp

47

48

Step 4 Apply an Inspection Rule to an Interface

The last step for configuring CBAC is to apply an inspection rule to an interface. This is the command syntax used to activate an inspection rule on an interface.
Router(config-if)# ip inspect inspection_name {in | out}

49

Step 4 Apply an Inspection Rule to an Interface

For the Cisco IOS Firewall to be effective, both inspection rules and ACLs must be strategically applied to all router interfaces. There are two guiding principles for applying inspection rules and ACLs on the router: 1. On the interface where traffic initiates, apply the ACL in the inward direction that permits only wanted traffic and apply the rule in the inward direction that inspects wanted traffic. 2. On all other interfaces, apply the ACL in the inward direction that denies all traffic, except traffic that has not been inspected by the firewall, such as GRE and ICMP traffic that is not related to echo and echo reply messages.

50

CBAC Configuration Example

An administrator needs to permit inside users to initiate TCP, UDP, and ICMP traffic with all external sources. Outside clients are allowed to communicate with the SMTP server (209.165.201.1) and HTTP server (209.165.201.2) that are located in the enterprise DMZ. It is also necessary to permit certain ICMP messages to all interfaces. All other traffic from the external network is denied. For this example, first create an ACL that allows TCP, UDP, and ICMP sessions and denies all other traffic.
R1(config)# R1(config)# R1(config)# R1(config)# access-list 101 permit tcp 10.10.10.0 0.0.0.255 any access-list 101 permit udp 10.10.10.0 0.0.0.255 any access-list 101 permit icmp 10.10.10.0 0.0.0.255 any access-list 101 deny ip any any

51

CBAC Configuration Example

This ACL is applied to the internal interface in the inbound direction. The ACL processes traffic initiating from the internal network prior to leaving the network.
R1(config)# interface Fa0/0 R1(config-if)# ip access-group 101 in

52

CBAC Configuration Example

Next, create an extended ACL in which SMTP and HTTP traffic is permitted from the external network to the DMZ network only, and all other traffic is denied.
R1(config)# R1(config)# R1(config)# R1(config)# R1(config)# R1(config)# R1(config)# R1(config)# R1(config)# access-list 102 permit tcp any host 209.165.201.1 eq www access-list 102 permit tcp any host 209.165.201.2 eq smtp access-list 102 permit icmp any any echo-reply access-list 102 permit icmp any any unreachable access-list 102 permit icmp any any administratively-prohibited access-list 102 permit icmp any any packet-too-big access-list 102 permit icmp any any echo access-list 102 permit icmp any any time-exceeded access-list 102 deny ip any any

53

CBAC Configuration Example

This ACL is applied to the interface connecting to the external network in the inbound direction.
R1(config)# interface S0/0/0 R1(config-if)# ip access-group 102 in

54

CBAC Configuration Example

If the configuration stopped here, all returning traffic, with the exception of ICMP messages, is denied because of the external ACL. Next, create inspection rules for TCP inspection and UDP inspection.
R1(config)# ip inspect name MYSITE tcp R1(config)# ip inspect name MYSITE udp

55

CBAC Configuration Example

These inspection rules are applied to the internal interface in the inbound direction.
R1(config)# interface Fa0/0 R1(config-if)# ip inspect MYSITE in

56

CBAC Configuration Example

The inspection list automatically creates temporary ACL statements in the inbound ACL applied to the external interface for TCP and UDP connections. This permits TCP and UDP traffic that is in response to requests generated from the internal network. To remove CBAC from the router, use the global no ip inspect command.
Router(config)# no ip inspect

This command removes all CBAC commands, the state table, and all temporary ACL entries created by CBAC. It also resets all timeout and threshold values to their factory defaults.

After CBAC is removed, all inspection processes are no longer available, and the router uses only the current ACL implementations for filtering.
57

58

Audits

Auditing keeps track of the connections that CBAC inspects, including valid and invalid access attempts.

59

Show Commands

60

Debug Commands

61

Zone-Based Firewalls

62

What is a Zone???

Zones are simple enough. You create them to group interfaces together that you want to have common firewall rules on. You could have internal interfaces in an zone called Inside, and external facing interfaces in one called Outside. You apply a policy map in one direction between the two zones, which specifies what traffic is to be inspected (in that direction only), and what's to be done with it.

Without a policy to say differently, traffic between zones is denied by default.

The self zone is a zone created by default by the router. It has a permit policy by default, and it used to manage traffic directed to or generated by the router, NOT traffic that just travels through it. If you wanted to apply firewall rules to traffic directed to the router itself, you'd have to make a zone pair of the self zone and the zone the traffic is coming from, and apply a policy to the pair.
63

What is a Zone Pair???

A zone-pair allows you to specify a unidirectional firewall policy between two security zones. To define a zone-pair, use the zone-pair security command. The direction of the traffic is specified by specifying a source and destination zone. The source and destination zones of a zone-pair must be security zones. The same zone cannot be defined as both the source and the destination. If desired, you can select the default self zone as either the source or the destination zone. The self zone is a system-defined zone. It does not have any interfaces as members. A zone-pair that includes the self zone, along with the associated policy, applies to traffic directed to the router or traffic generated by the router. It does not apply to traffic through the router. The most common usage of firewalls is to apply them to traffic through a router, so you usually need at least two zones (that is, you cannot use the self zone).

64

ZBF

In 2006, Cisco Systems introduced the zone-based policy firewall configuration model with Cisco IOS Release 12.4(6)T. Interfaces are assigned to zones and then an inspection policy is applied to traffic moving between the zones. A zone-based firewall allows different inspection policies to be applied to multiple host groups connected to the same router interface. It also has the ability to prohibit traffic via a default deny-all policy between firewall zones.

65

ZBF

The zone-based policy firewall (ZPF or ZBF or ZFW) inspection interface supports previous firewall features, including stateful packet inspection, application inspection, URL filtering, and DoS mitigation. Firewall policies are configured using the Cisco Common Classification Policy Language (C3PL), which uses a hierarchical structure to define network protocol inspection and allows hosts to be grouped under one inspection policy.

66

67

Zone-Based Policy Firewall Characteristics

The primary motivations for network security professionals to migrate to the ZPF model are structure and ease of use.

The structured approach is useful for documentation and communication. The ease of use makes network security implementations more accessible to a larger community of security professionals.

Implementing CBAC is complex and can be overwhelming. Unlike ZPF, CBAC does not utilize any dedicated hierarchical data structures to modularize the implementation. CBAC has these limitations:

Multiple inspection policies and ACLs on several interfaces on a router make it difficult to correlate the policies for traffic between multiple interfaces. Policies cannot be tied to a host group or subnet with an ACL. All traffic through a given interface is subject to the same inspection. The process relies too heavily on ACLs.
68

Zone-Based Policy Firewall Characteristics

Zones establish the security borders of a network. The zone itself defines a boundary where traffic is subjected to policy restrictions as it crosses over into another region of a network. The default policy between zones is deny all. If no policy is explicitly configured, all traffic moving between zones is blocked. This is a significant departure from the CBAC model in which traffic was implicitly allowed until it was explicitly blocked with an ACL. While many ZPF commands appear similar to CBAC commands, they are not the same. A second significant change is the introduction of Cisco Common Classification Policy Language (C3PL). This new configuration policy language allows a modular approach to firewall implementation.
69

Zone-Based Policy Firewall Characteristics

Some of the benefits of ZPF include the following:

Not dependent on ACLs. The router security posture is to block unless explicitly allowed. Policies are easy to read and troubleshoot with C3PL. One policy affects any given traffic, instead of needing multiple ACLs and inspection actions.

70

71

Designing Zone-Based Firewall Step 1

Determine the Zones - The internetworking infrastructure under consideration must be split into separate zones with various security levels. In this step, the administrator does not consider physical implementation of the firewall (number of devices, defense depth, redundancy, etc.), but focuses instead on the separation of the infrastructure into zones. For example, the public network to which the internal network is connected is one zone.

72

Designing Zone-Based Firewall Step 2

Establish policies between zones - For each pair of "sourcedestination" zones (for example, from inside network to Internet), define the sessions that clients in the source zones can request from servers in destination zones. These sessions are most commonly TCP and UDP sessions, but also ICMP sessions such as ICMP echo.

For traffic that is not based on the concept of sessions, such as IPsec Encapsulating Security Payload [ESP], the administrator must define unidirectional traffic flows from source to destination and vice versa. As in Step 1, this step is about the traffic requirements between zones, not the physical setup.

73

Designing Zone-Based Firewall Step 3

Design the physical infrastructure - After the zones have been identified and the traffic requirements between them documented, the administrator must design the physical infrastructure, taking into account security and availability requirements. This includes stating the number of devices between most-secure and least-secure zones and determining redundant devices.

74

Designing Zone-Based Firewall Step 4

Identify subset within zones and merge traffic requirements - For each firewall device in the design, the administrator must identify zone subsets connected to its interfaces and merge the traffic requirements for those zones. For example, multiple zones might be indirectly attached to a single interface of a firewall, resulting in a device-specific inter-zone policy.

75

Common ZPF Designs

LAN to - Internet

76

Common ZPF Designs

Public Servers

77

Common ZPF Designs

Redundant Firewalls

78

Common ZPF Designs

Complex Firewalls

79

Common ZPF Designs

Complex Firewall Simplified with Zones

80

Zone-Based Policy Firewall Actions

The Cisco IOS zone-based policy firewall can take three possible actions:

Inspect - Configures Cisco IOS stateful packet inspection. This action is equivalent to the CBAC ip inspect command. It automatically allows for return traffic and potential ICMP messages. For protocols requiring multiple parallel signaling and data sessions (for example, FTP or H.323), the inspect action also handles the proper establishment of data sessions.
Drop - Similar to a deny statement in an ACL. A log option is available to log the rejected packets. Pass - Similar to a permit statement in an ACL. The pass action does not track the state of connections or sessions within the traffic. Pass allows the traffic only in one direction. A corresponding policy must be applied to allow return traffic to pass in the opposite direction.

81

Zone-Based Policy Firewall Operation

The membership of the router network interfaces in zones is subject to several rules governing interface behavior, as is the traffic moving between zone member interfaces:

A zone must be configured before an administrator can assign interfaces to the zone.
If traffic is to flow between all interfaces in a router, each interface must be a member of a zone.

An administrator can assign an interface to only one security zone.

Traffic is implicitly allowed to flow by default among interfaces that are members of the same zone. 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.

82

Zone-Based Policy Firewall Operation contd

The membership of the router network interfaces in zones is subject to several rules governing interface behavior, as is the traffic moving between zone member interfaces:

Traffic cannot flow between a zone member interface and any interface that is not a zone member. An administrator can apply pass, inspect, and drop actions only between two zones. Interfaces that have not been assigned to a zone function can still use a CBAC stateful packet inspection configuration. If an administrator does not want an interface on the router to be part of the zone-based firewall policy, it might still be necessary to put that interface in a zone and configure a pass-all policy (also known as a dummy policy) between that zone and any other zone to which traffic flow is desired.

83

Zone-Based Policy Firewall Operation

84

Zone-Based Policy Firewall Operation

The rules for a zone-based policy firewall are different when the router is involved in the traffic flow. In addition, the rules depend on whether the router is the source or the destination of the traffic. When an interface is configured to be a zone member, the hosts that are connected to the interface are included in the zone, but traffic flowing to and from the interfaces of the router is not controlled by the zone policies. Instead, all the IP interfaces on the router are automatically made part of the self zone. To limit IP traffic moving to the IP addresses of the router from the various zones on a router, policies must be applied. The policies can be set to block, allow, or inspect traffic between the zone and the self zone of the router, and vice versa. If there are no policies between a zone and the self zone, all traffic is permitted to the interfaces of the router without being inspected.

85

Zone-Based Policy Firewall Operation

A policy can be defined using the self zone as either the source or the destination zone. Remember the self zone is a system-defined zone. It does not require any interfaces to be configured as members. A zone-pair that includes the self zone, along with the associated policy, applies to traffic that is directed to the router or traffic that the router generates. It does not apply to traffic traversing the router.

86

Zone-Based Policy Firewall Operation

When the router is involved in the traffic flow, additional rules for zonebased policy firewalls govern interface behaviour:

All traffic to and from a given interface is implicitly blocked when the interface is assigned to a zone, except traffic to or from other interfaces in the same zone and traffic to any interface on the router.
All the IP interfaces on the router are automatically made part of the self zone when ZPF is configured. 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.

The only exception to the deny-by-default approach is the traffic to and from the router itself. This traffic is permitted by default. An explicit policy can be configured to restrict such traffic.

87

Zone-Based Policy Firewall Operation

88

Configuring ZPF with the CLI

There are several steps for configuring ZPF with the CLI:

Step 1. Create the zones for the firewall with the zone security command. Step 2. Define traffic classes with the class-map type inspect command. Step 3. Specify firewall policies with the policy-map type inspect command. Step 4. Apply firewall policies to pairs of source and destination zones using the zone-pair security command. Step 5. Assign router interfaces to zones using the zone-member security interface command.

89

Configuring ZPF with the CLI

When configuring ZPF with the CLI, there are several factors to consider:

Only policy maps defined with type inspect can be used in the zone-pair security command. Only class maps defined with type inspect can be used in policy maps with type inspect. There can be no name overlap with other types of class maps or policy maps. There cannot be a quality-of-service class map and an inspect class map with the same name. A zone must be configured with the zone security global command before it can be used in the zone-member security interface configuration command.

An interface cannot belong to multiple zones. To create a union of security zones, specify a new zone and appropriate policy map and zone pairs.

90

Configuring ZPF with the CLI

When configuring ZPF with the CLI, there are several factors to consider:

The zone-based policy firewall feature is a replacement for CBAC. Remove the ip inspect interface configuration command before applying the zone-member security command. The zone-based policy firewall can coexist with CBAC. The ip inspect command can still be used on interfaces that are not members of security zones. Traffic can never flow between an interface assigned to a zone and an interface without a zone assignment. Applying the zone-member configuration command always results in temporary interruption of service. The default inter-zone policy is to drop all traffic unless specified otherwise in the zone-pair configuration command. The router never filters the traffic between interfaces in the same zone. The zone-member command does not protect the router itself (traffic to and from the router is not affected) unless the zone pairs are configured using the predefined self zone.
91

Step 1 Create the Zones

The administrator creates the zones for the firewall with the zone security command. An optional description is recommended.
Router(config)# zone security zone-name Router(config-sec-zone)# description line-of-description

92

Step 2 Define Traffic Classes

ZPF traffic classes enables you to define traffic flows in as granular a fashion as desired.

This is the syntax for creating ZPF traffic classes:

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

For Layer 3 and Layer 4, top-level class maps, the match-any option is the default behavior.
Router(config)# class-map type inspect protocol-name [match-any | match-all] class-map-name

For Layer 7, application-specific class maps, see www.cisco.com for construction details.

93

Step 2 Define Traffic Classes

The syntax for referencing access lists from within the class map is:
Router(config-cmap)# match access-group {access-group | name accessgroup-name}

Protocols are matched from within the class map with the syntax:
Router(config-cmap)# match protocol protocol-name

Nested class maps can be configured as well using the syntax:

Router(config-cmap)# match class-map class-map-name

The ability to create a hierarchy of classes and policies by nesting is one of the reasons that ZPF is such a powerful approach to creating Cisco IOS firewalls.

94

Step 2 Define Traffic Classes

95

Step 3 Define Firewall Policies

Similar to other modular CLI constructs with Cisco IOS software, the administrator has to specify what to do with the traffic matching the desired traffic class. The options are pass, inspect, drop, and police.

This is the syntax for creating ZPF policy maps.

Router(config)# policy-map type inspect policy-map-name

Traffic classes on which an action must be performed are specified within the policy map.
Router(config-pmap)# class type inspect class-name

The default class (matching all remaining traffic) is specified using this command.
Router(config-pmap)# class class-default

Finally, the action to take on the traffic is specified.

Router(config-pmap-c)# pass | inspect | drop [log]| police
96

Step 3 Define Firewall Policies

97

Assign Policy Maps to Zone Pairs

After the firewall policy has been configured, you must apply it to traffic between a pair of zones using the zone-pair security command. To apply a policy, a zone pair must first be created. Specify the source zone, the destination zone, and the policy for handling the traffic between them.
Router(config)# zone-pair security zone-pair-name [source source-zone-name | self] destination [self | destination-zone-name]

Use the service-policy type inspect policy-map-name command to attach a policy-map and its associated actions to a zone-pair. Enter the command after entering the zone-pair security command.

98

Assign Policy Maps to Zone Pairs contd

Deep-packet inspection (attaching a Layer 7 policy map to a toplevel policy map) can also be configured. This is the syntax used with Cisco IOS Release 12.4(20)T.
Router(config-pmap-c)# service-policy {h323 | http | im | imap | p2p | pop3 | sip | smtp | sunrpc | urlfilter} policy-map

The policy map is the name of the Layer 7 policy map being applied to the top-level Layer 3 or Layer 4 policy map.

99

Step 5 Assign Interfaces to the Zones

Finally, the administrator must assign interfaces to the appropriate security zones using the zone-member interface command.
Router(config-if)# zone-member security zone-name

The zone-member security command puts an interface into a security zone. When an interface is in a security zone, all traffic to and from that interface (except traffic going to the router or initiated by the router) is dropped by default. To permit traffic through an interface that is a zone member, the zone must be part of a zone pair to which a policy is applied. If the policy permits traffic (via inspect or pass actions), traffic can flow through the interface. ZPF configuration can also be done with the SDM

100

101

Resource material for PowerPoints from:

102