Network Traffic Control

• Network Access Management using AAA
  • Authentication
    • Local Authentication
    • Server-Based Authentication
    • Additional Authentication Security
  • Authorization
  • Accounting and Auditing
• Network Access Management using ACL
  • ACL Identifiers
  • ACE Wildcard Masks
  • Configuring ACLs
    • Creating
    • Modifying
    • Implementing
  • IPv6 ACLs
• Network Access Management using 802.1X
  • Authentication Protocol
  • Port Authorization States
  • Service Configuration
• Firewalls
  • Basic Security Zone Topology
  • Zone-Based Firewall Configuration
    • Zone Creation
    • Traffic Class Definition
    • Policy Action Configuration
    • Zone Pairing
    • Interface Assignment
    • Verify Configuration

Network Access Management using AAA

AAA network security services provide the primary framework to set up access control on a network device. Network and administrative AAA security in the Cisco environment has three functional components: Authentication, Authorization, and Accounting

Authentication

AAA Authentication can be used to authenticate users for administrative access or it can be used to authenticate users for remote network access. Authentication can be established using username and password combinations, challenge and response questions, token cards, and other methods.

Cisco provides two common methods of implementing AAA services:

Local Authentication

Local AAA uses a device's local database for authentication. This database is the same one that is required for establishing role-based CLI. Local AAA is ideal for small networks, as the system administrator must populate the local security database with profiles for each user that might log in.

This method is sometimes known as self-contained authentication.

Configuring Local AAA Authentication:

1. Add usernames and passwords to the local router database for users that need administrative access to the router, using the username name secret password global configuration command.
2. Enable AAA globally on the router aaa new-model command.
3. Configure AAA parameters on the router via the aaa authentication login list method(s) command.
4. Confirm and troubleshoot the AAA configuration.

When the aaa new-model command is first entered, an unseen “default” authentication, using the local database, is automatically applied to all lines except the console. For this reason, always configure a local database entry before enabling AAA.

R1(config)# username JR-ADMIN algorithm-type scrypt secret Str0ng5rPa55w0rd
R1(config)# username ADMIN algorithm-type scrypt secret Str0ng5rPa55w0rd  
R1(config)# aaa new-model
R1(config)# aaa authentication login default local
R1(config)#

The final portion of the aaa authentication login command identifies the type of methods that will be queried to authenticate the users. Up to four methods can be defined, providing fallback methods should one method not be available.

Cisco IOS software attempts authentication with a fallback method only when an error occurs trying the preceding method. If the authentication method denies the user access, the authentication process stops and no other authentication methods are allowed.

The following table displays common AAA authentication methods that can be specified:

Method	Description
enable	Uses the enable password for authentication.
local	Uses the local username database for authentication.
local-case	Uses case-sensitive local username authentication.
none	Uses no authentication.
group radius	Uses the list of all RADIUS servers for authentication.
group tacacs+	Uses the list of all TACACS+ servers for authentication.
group group-name	Uses a subset of RADIUS or TACACS+ servers for authentication as defined by the aaa group server radius or aaa group server tacacs+ command.

For security purposes, use the none keyword only when testing the AAA configuration.

For flexibility, different method lists can be applied to different interfaces and lines using the aaa authentication login list command.

R1(config)# aaa new-model
R1(config)# aaa authentication login SSH-LOGIN local-case
R1(config)# line vty 0 15
R1(config-line)# login authentication SSH-LOGIN
R1(config-line)# transport input ssh
R1(config-line)# 

If a line has a custom authentication method list applied to it, that method list overrides the default method list for that interface. When a custom authentication method list is applied to an interface, it is possible to return to the default method list by using the no authentication login command.

Server-Based Authentication

When configuring authenticaion for multiple routers and switches, server-based AAA is more appropriate. With the server-based method, the router accesses a central AAA server—which contains the usernames and password for all users—rather than relying on a local database. For increased redundancy, multiple servers can be implemented.

Client devices use either the Remote Authentication Dial-In User Service (RADIUS) or Terminal Access Controller Acces s Control System (TACACS+) protocols to communicate with the AAA server.

It is important to understand the many differences between the TACACS+ and RADIUS protocols:

Implementation	TACACS+	RADIUS
Functionality	Separates AAA according to the AAA architecture, allowing modularity of the security server implementation.	Combines authentication and authorization but separates accounting, allowing less flexibility in implementation than TACACS+.
Standard	Mostly Cisco supported	Open/RFC standard
Transport Protocol	TCP (port 49)	UDP
CHAP	Bidirectional challenge and response as used in Challenge Handshake Authentication Protocol (CHAP).	Unidirectional challenge and response from the RADIUS security server to the RADIUS client.
Confidentiality	Entire packet encrypted	Password encrypted
Customization	Provides authorization of router commands on a per-user or per-group basis	Has no option to authorize router commands on a per-user or per-group basis
Accounting	Limited	Extensive (includes 802.1X and SIP)

TACACS+ provides separate AAA services. Separating the AAA services provides flexibility in implementation because it is possible to use TACACS+ for authorization and accounting while using another method of authentication.

Configuring Server-Based AAA Authentication:

1. Enable AAA globally on the router aaa new-model command.
2. Configure the target server that will provide AAA services for the router via the {tacacs|radius} server name global configuration command and subsequent server-configuration-mode commands.
3. Configure the encryption key needed to encrypt the data transfer between the network device and AAA server via the key string command.
4. Configure the AAA authentication method list to refer to the TACACS+ or RADIUS server. For redundancy, it is possible to configure more than one server.

R1(config)# aaa new-model
R1(config)# 
R1(config)# tacacs server Server-T
R1(config-server-tacacs)# address ipv4 192.168.1.100
R1(config-server-tacacs)# single-connection
R1(config-server-tacacs)# key TACACS-Pa55w0rd
R1(config-server-tacacs)# exit
R1(config)# 
R1(config)# radius server SERVER-R
R1(config-radius-server)# address ipv4 192.168.1.101 auth-port 1812 acct-port 1813
R1(config-radius-server)# key RADIUS-Pa55w0rd 
R1(config-radius-server)# exit
R1(config)#
R1(config)# aaa authentication login default group tacacs+ group radius local-case
R1(config)# end

By default, TACACS+ establishes a new TCP session for every authorization request, which can lead to delays when users enter commands. To improve performance, AAA supports persistent TCP sessions that are configured with the single-connection tacacs server configuration command.

Additional Authentication Security

Additional security can be implemented on the line using the aaa local authentication attempts max-fail attempts global configuration command.

This command secures AAA user accounts by locking accounts that have been the subject of multiple failed attempts to log in. The locked out user account remains locked until it is manually cleared by an administrator, using the clear aaa local user lockout privileged EXEC mode command. To display a list of all locked-out users, use the show aaa local user lockout command.

R1# show aaa local user lockout
!
!       Local-user        Lock time
!       ADMIN             04:28:49 UTC Tue Feb 16 2021
!
R1# clear aaa local user lockout ADMIN
R1# 

Authorization

After the user is authenticated, authorization services determine which resources the user can access and which operations the user is allowed to perform. This is done through a set of attributes that describes the user’s access to the network.

Authorization attributes are compared to information contained within the AAA database, which then delivers restrictions for a given user to the local router where the user is connected.

Authorization is automatic and does not require users to perform additional steps after authentication.

AAA Authorization Configuration

To configure authorization, use the aaa authorization type list method(s) command:

R1(config)# aaa new-model 
R1(config)# aaa authentication login default group tacacs+
R1(config)# aaa authorization exec default group tacacs+ 
R1(config)# aaa authorization network default group tacacs+

The authorization-type keywords specify the types of commands or services to protect:

Type	Usage
network	For network services such as PPP and SLIP.
exec	For User EXEC terminal sessions.
commands level	Command authorization attempts authorization for all EXEC mode commands, including global configuration commands, associated with a specific privilege level.

Accounting and Auditing

AAA Accounting collects and reports usage data. This data can be used for such purposes as auditing or billing. The collected data might include the start and stop connection times, the commands executed, the number of packets, and the number of bytes.

Accounting is implemented using a AAA server. This service reports usage statistics back to the ACS server. These statistics can be extracted to create detailed reports about the configuration of the network.

AAA Acounting Configuration

To configure authorization, use the aaa accounting type list {start-stop | stop-only | none} [broadcast] method(s) command:

R1(config)# aaa new-model
R1(config)# aaa authentication login default group tacacs+
R1(config)# aaa authorization exec default group tacacs+
R1(config)# aaa accounting exec default start-stop group tacacs+
R1(config)# aaa authorization network default group tacacs+
R1(config)# aaa accounting network default start-stop group tacacs+

The accounting-type keywords specify the types of commands or services to report:

Type	Usage
network	Runs accounting for all network-related service requests, including PPP.
exec	Runs accounting for the EXEC shell session.
connection level	Runs accounting on all outbound connections such as SSH and Telnet.

The trigger-condition keyword is used to specify what actions cause accounting records to be updated:

Trigger	Meaning
start-stop	Sends a "start" accounting notice at the beginning of a process and a "stop" accounting notice at the end of the process.
stop-only	Sends a "stop" accounting record for all cases including authentication failures.
none level	Disables accounting services on a line or interface.

Auditing Accounts via AAA

Accounting provides additional security to the network, by keeping a detailed log of exactly what authenticated users do on managed devices. This information is useful when troubleshooting devices. It also provides leverage against individuals who perform malicious actions.

To display the attributes that are collected for one AAA session, use the show aaa user privileged EXEC command. This command only provides information for those users who have been authenticated or authorized using AAA, or whose sessions are being accounted for by the AAA module.

The show aaa sessions command can be used to show details about current and recent sessions.

Network Access Management using ACL

An Access Control List (ACL) is a network management service that is used to filter packets based on information found in the packet header. By default, a router does not have any ACLs configured. However, when an ACL is applied to an interface, the router performs the additional task of evaluating all network packets as they pass through the interface to determine if the packet can be forwarded.

An ACL uses a sequential list of permit or deny statements, known as Access Control Entries (ACEs), which are also sometimes referred to as "ACL Statements".

Several tasks performed by routers require the use of ACLs to identify and manage network traffic:

• Limiting network traffic to increase network performance.
• Providing traffic flow control.
• Providing basic security for network access.
• Filtering traffic based on traffic type.
• Screening hosts to permit or deny them access to network services.
• Providing priority to certain classes of network traffic.

An Inbound ACL filters packets before they are routed to the outbound interface. An inbound ACL is efficient because it saves the overhead of routing lookups if the packet is discarded. Inbound ACLs are most efficient when the permissions applied by the ACL are only relevant to one inbound interface.

An outbound ACL filters packets after they are routed to the outbound interface, no matter the inbound interface. Outbound ACLs are most efficient when the same filter will be applied to packets coming from multiple inbound interfaces before exiting the same outbound interface.

Outbound ACLs do not act on packets that originate from the device performing the filtering.

The last statement of an ACL is always an implicit deny that blocks all traffic. By default, this statement is implicitly applied to the end of an ACL, but will not displayed in the configuration.

An ACL must have at least one permit statement otherwise all traffic will be denied due to the implicit deny ACE statement.

Cisco routers support two types of ACLs:

1. Standard ACLs — ACLs only filter at OSI Layer 3 (Network) using the source IPv4 address from the packet header.
2. Extended ACLs — ACLs filter at Layer 3 (Network) using the source or destination IPv4 address. Extended ACLs also filter at Layer 4 (Transport) based on TCP and UDP ports, and optional protocol type information for finer control.

ACL Identifiers

Numbered ACLs
ACLs number 1-99 and 1300-1999 are standard ACLs while ACLs number 100-199 and 2000-2699 are extended ACLs:

R1(config)# access-list ?
!  <1-99>       IP standard access list
!  <100-199>    IP extended access list
!  <1100-1199>  Extended 48-bit MAC address access list
!  <1300-1999>  IP standard access list (expanded range)
!  <200-299>    Protocol type-code access list
!  <2000-2699>  IP extended access list (expanded range)
!  <700-799>    48-bit MAC address access list
!  rate-limit   Simple rate-limit specific access list
!  template     Enable IP template acls
R1(config)# access-list

Named ACLs
Named ACLs are preferred, to provide information about the purpose of the ACL.

The guidelines for named ACLs can be summarized as:

• Assign a name to identify the purpose of the ACL.
• Names can contain alphanumeric characters.
• Names cannot contain spaces or punctuation.
• Names should be written in CAPITAL LETTERS.

ACE Wildcard Masks

A wildcard masks is a 32-bit address string that looks like a subnet mask. However, where the subnet mask uses a high-bit to indicate a position that must be matched and a low-bit to indicate a wild position, the wildcard mask works in reverse:

• Wildcard mask bit 0 - Match the corresponding bit value in the rule's address
• Wildcard mask bit 1 - Ignore the corresponding bit value in the rule's address

In this way, ACE rules can be scaled to match an address range, or an entire subnet.
For example:

Wildcard Mask	Meaning
0.0.0.0	All octets of the packet address must exactly match the ACE's target address.
0.0.0.255	The first three octets must exactly match, while the final octet may have any value.
0.0.0.252	The first three octets must exactly match. The first six bits of the last octet may have any value. The final two bits must again match the target address!

The easiest way to match a range of addresses is to subtract the subnet mask of the range from the /32 mask (255.255.255.255).In other words, the entire range of addresses included in the subnet /28 mask (255.255.255.240) can be matched by subtracting /28 from /32: 0.0.0.15

Wildcard Mask Keywords

Cisco IOS provides two keywords to identify the most common uses of wildcard masking:

• host — This keyword substitutes for the 0.0.0.0 mask, and will require an exact match of the target address.
• any — This keyword substitutes for the 255.255.255.255 mask, and will match any address.

Wildcard keyword come before the target address. The following ACE statements would block the device at 192.168.10.10, while allowing all other traffic. ACLs of this type are referred to a "block-lists", because they only block traffic from specific addresses.

R1(config)# access-list EXAMPLE deny host 192.168.10.10
R1(config)# access-list EXAMPLE permit any
R1(config)#

Configuring ACLs

Creating

To create a new ACL, use the ip access-list {standard|extended} identifier global configuration command. This will enter ACL configuration mode.

To configure an Access Control Entry (ACE), i.e. a permit or deny instruction, use the access-list identifier {permit|deny} ip-address [mask] [log] configuration command. The access-list identifier prefix is not used when in ACL configuration mode.

To create a numbered ACL, skip the ip access-list command. A new, numbered ACL is automatically generated when an access-list identifier global configuration command indicates a numbered list that does not yet exist.

The options for this command are described below:

Paramter	Description
identifier	The name or number of the ACL that the new rule should be associated with.
deny	Deny access if the condition is matched.
permit	Permits access if the condition is matched.
ip-address	This identifies the source network or host address to filter.
mask	(Optional) This is a 32-bit wildcard mask that is applied to the source (see below). If omitted, a default 0.0.0.0 mask is assumed.
log	(Optional) This keyword generates an informational message whenever the ACE is matched. ACL logging seriously affects the performance of the device, and should only be used when an administrator is trying to thwart a network attack.

Extended Syntax IPv4 ACL entries provide additional options for configuration:
access-list identifier {permit|deny} protocol source-address [source-mask] [operator port(s)] destination-address [destination-mask] [operator port(s)] [log]

Note that, for Extended ACLs, the target ip-address attribute is split into separate source and destination parameters.

Several additional options available to the Extended ACL entries are descibed below:

Paramter	Description
protocol	Name or number of an internet protocol. Some common protocol keywords include ip, tcp, udp, and icmp. The ip keyword matches all IP protocols.
operator	(Optional) This compares the source or destination port to the listed port(s). Operators include lt (less than), gt (greater than), eq (equal), neq (not equal), and range (inclusive range).
port(s)	(Optional) Up to 10 numeric port numbers and/or common TCP/UDP port names (e.g. ftp, irc, and so on).
established	(Optional, applies to TCP protocol only) This is a 1st-generation stateful firewall feature. When configured, this ACE statement will only match if the returning TCP segment has the ACK or RST (reset) flag bits set.

Documentation can be added to the ACL configuration via the access-list identifier remark text ip-address configuration command. Each remark entry is limited to 100 characters.

ACE statements must indicate an IP address as a base for the rule to match. The ACE address must exactly match the source IP (for Standard ACLs) or destination IP (using Extended ACLs) of the incoming packet. However, ACE statements also employ a wildcard mask to indicate bits in the IP address that can be ignored.

R1(config)# access-list 120 permit tcp any 192.168.10.0 0.0.0.255 established
R1(config)# interface g0/0/0 
R1(config-if)# ip access-group 120 out 
R1(config-if)# end
R1# show access-lists 
Extended IP access list 110
     10 permit tcp 192.168.10.0 0.0.0.255 any eq www
     20 permit tcp 192.168.10.0 0.0.0.255 any eq 443 (657 matches)
Extended IP access list 120
     10 permit tcp any 192.168.10.0 0.0.0.255 established (1166 matches)
R1#

Modifying

ACL entries can be modified in one of two ways:

1. Replace the entire ACL — The entire ACL can be blown away using no access-list identifier, and then recreated using the corrected configuration.
2. Replace the specific ACE — The specific, offending ACE can be replaced from within the ACL Configuration mode (ip access-list type identifier) for the desired ACL. Once in ACL Configuration mode, use the no sequence-number command to remove a specific entry (use show access-lists to see each entry in an ACL). Write a new entry by prepending the same sequence-number to the correct ACE configuration command (e.g. 10 permit host 192.168.10.10).

Implementing

To apply an ACL to an interface, use the ip access-group identifier {in|out} interface configuration command. To apply the ACL to the console line, use ip access-class identifier {in|out}. The final segment of the command indicates whether the ACL should be applied to inbound or outbound traffic on that interface.

Additional useful notes:

• Only one ACL is allowed per interface, per protocol, per direction.
• Router-generated packets are not filtered by outbound ACLs.
• Place standard ACLs as close to the destination as possible.
• Place extended ACLs as close to the source as possible.

IPv6 ACLs

An IPv6 ACL contains an implicit deny ipv6 any any and two implicit permit rules to enable IPv6 neighbor discovery. If an administrator manually configures the deny ipv6 any any command without explicitly permitting neighbor discovery, then the IPv6 Neighbor Discovery Protocol (NDP) will be disabled.

Create an IPv6 ACL using the following command syntax:

Router(config)# ipv6 access-list <access-list-name>
Router(config-ipv6-acl)# deny | permit <protocol> {<source-ipv6-prefix>/<prefix-length> | any | host <source-ipv6-address>} [<operator> [<port-number>]] {<destination-ipv6-prefix>/<prefix-length> | any | host <destination-ipv6-address>} [<operator> [<port-number>]] [dscp <value>] [fragments] [log] [log-input] [sequence <value>] [time-range <name>]

Apply an IPv6 ACL to an interface with the ipv6 traffic-filter name command.

Several additional options available to IPv6 ACL entries, as descibed below:

Paramter	Description
dscp value	(Optional) Matches against the Traffic Class value field of the IPv6 packet header. The acceptable range is 0-63.
fragments	(Optional) Matches non-initial fragmented packets where the fragment extension header contains a non-zero fragment offset.
log input	(Optional) Provides the same function as the log keyword, except that the logging message also includes the input interface.
sequence value	(Optional) Specifies the sequence number value for the ACE. The acceptable range is 1-4294967295. This setting allows creation of the ACL in an arbitrary order.
time-range dname	(Optional) Specifies the time range that applies to the permit statement. The name of the time range and its restrictions are specified by the time-range command

Network Access Management using 802.1X

Authentication Protocol

The IEEE 802.1X standard defines a port-based access control and authentication protocol that restricts unauthorized workstations from connecting to a LAN through publicly accessible switch ports.

The 802.1x roles include:

• Supplicant (Client) - A device that requests access to LAN and switch services. The port that the client is attached to is the actual supplicant in the IEEE 802.1X specification.
• Authenticator (Switch) - The switch is the device that controls physical access to the network based on the authentication status of the client. It acts as a proxy (middleman) between the supplicant and the authentication server, requesting identifying information from the client, verifying that information with the authentication server, and relaying a response to the client.
• Authentication server - The server performs the actual authentication of the client. The authentication server validates the identity of the client and notifies the switch whether the client is authorized to access the LAN and switch services. Because the switch acts as the proxy, the authentication service is transparent to the client.

The switch uses a RADIUS software agent, which is responsible for encapsulating and de-encapsulating the EAP (Extensible Authentication Protocol) frames and interacting with the authentication server.

The RADIUS security system with EAP extensions is the only supported authentication server.

Port Authorization States

The switch port state determines whether the client is granted access to the network:

• When configured for 802.1X port-based authentication, the port starts in the unauthorized state. While in this state, the port disallows all ingress and egress traffic except for 802.1X protocol, STP, and CDP packets.

• When a client is successfully authenticated, the port transitions to the authorized state, allowing all traffic for the client to flow normally.

• If the switch requests the client identity (authenticator initiation) and the client does not support 802.1X, the port remains in the unauthorized state, and the client is not granted access to the network.

• When a client logs out, it sends an EAPOL-logout message, causing the switch port to transition to the unauthorized state.

When an 802.1X-enabled client connects to a port and the client initiates the authentication process (supplicant initiation) by sending the EAPOL-start frame to a switch that is not running the 802.1X protocol, the client will continue sending frames as if the port were in the authorized state.

to enable 802.1X on the port, use the authentication port-control auto interface configuration command.

It may sometimes be necessary to configure a switch port to override the 802.1X authentication process. To do this, use the authentication port-control {force-authorized|force-unauthorized} interface configuration command.

Service Configuration

Configuring 802.1X requires a few basic steps:

1. Enable AAA using the aaa new-model command.
2. Designate the RADIUS server using radius server name global configuration command. This will enter the radius-server subconfiguration mode.
3. Set the address and ports that are configured on the RADIUS server, using the address {ipv4|ipv6} ip-address auth-port port acct-port port radius-server sub-configuration command.
4. Create an 802.1X port-based authentication method list using the aaa authentication dot1x list group protocol global configuration command.
5. Globally enable 802.1X port-based authentication using the dot1x system-auth-control global configuration command.
6. Enable port-based authentication on the interface using the authentication port-control auto interface configuration command.
7. Enable 802.1X authentication on the interface using the dot1x pae authenticator interface command.
   
   

   The authenticator option sets the Port Access Entity (PAE) type so the interface acts only as an authenticator and will not respond to any messages meant for a supplicant.

Example:

S1(config)# aaa new-model
S1(config)# radius server NETSEC
S1(config-radius-server)# address ipv4 10.1.1.50 auth-port 1812 acct-port 1813 
S1(config-radius-server)# key RADIUS-Pa55w0rd
S1(config-radius-server)# exit 
S1(config)#
S1(config)# aaa authentication dot1x default group radius 
S1(config)# dot1x system-auth-control 
S1(config)#
S1(config)# interface F0/1
S1(config-if)# description Access Port 
S1(config-if)# switchport mode access 
S1(config-if)# authentication port-control auto
S1(config-if)# dot1x pae authenticator

Firewalls

There are two configuration models for Cisco IOS Firewall:

• Classic Firewall — The traditional configuration model in which firewall policy is applied on interfaces.
• Zone-based Policy Firewall (ZPF) — The configuration model in which interfaces are assigned to security zones, and firewall policy is applied to traffic moving between the zones.

Both configuration models can be enabled concurrently on a router, but not on a single interface.

Policies identify actions that the ZPF will perform on network traffic. There are three possible actions that can be configured:

• Inspect — This performs Cisco IOS stateful packet inspection.
• Drop — This is analogous to a deny statement in an ACL. A log option is available to log the rejected packets.
• Pass — This is analogous to a permit statement in an ACL. The pass action does not track the state of connection

Basic Security Zone Topology

The basic zone rules depend on the zones of the ingress and egress interfaces used by the inspected traffic:

• neither interface is in a zone — pass the traffic.
• both are in the same zone – pass the traffic.
• both are in unpaired zones — drop the traffic.
• both are in paired zones — inspect, allow, or drop as defined by the policy (if a policy exists).

Zone-Based Firewall Configuration

Zone-Based Policy Firewall (ZPF) configuration has five steps:

1. Create the zones.
2. Define class-maps used to identify traffic.
3. Define policy actions via policy-maps.
4. Associate zone pairs and apply policy-maps.
5. Assign interfaces to their appropriate zones.

Zone Creation

Create zones using the zone security name global configuration command.

Traffic Class Definition

Traffic classes are used to identify packets based on their contents. Once assigned to a traffic class, packets can be managed by firewall policies.

Configure traffic classes via the class-map type inspect {match-any|match-all} name global configuration command.

There are two packet-match modes used to determine class-eligibility:

• match-any — Packets must meet at least one match criterion.
• match-all — Packets must meet all match criteria.

The class-map command enters the class-map sub-configuration mode. There are three ways to filter for class-map matching:

• match access-group acl-identifier — matches packets that pass the indicated ACL policy.
• match protocol protocol-identifier — matches packets that use the indicated protocol.
• match class-map class-map-name — matches packets that are eligible for the indicated class.

Example:

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

Policy Action Configuration

Zone-based firewalls filter traffic based on the traffic classes assigned to the traffic. This is done through the use of policy maps, which define what action to take when inspected traffic belongs to a configured class-map.

There are three steps to configure a policy map:

1. Define a policy-map via the policy-map type inspect name global configuration command. This will enter the policy-map sub-configuration mode.
2. Assign traffic classes to be governed by the policy using class type inspect name. This will enter the policy-map class-action sub-configuration mode.
3. Declare an action to take for traffic of the current class via the {inspect|drop|pass} command. If the inspect action is chosen, then the router will maintain session information for TCP and UDP packets, in order to permit return traffic.

Similar to the implicit deny any at the end of every ACL, there is an explicit drop applied by the IOS to the end of every policy−map. It is listed as class class-default in the last section of any policy-map configuration.

Example:

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

Zone Pairing

To identify a zone-pair, use the zone-pair security zone-pair-name source {source-zone-name|self} destination {destination-zone-name|self} global configuration command. This will enter the zone-pair configuration mode. Apply a policy to the zone-pair traffic flow via the service-policy type inspect policy-map–name command.

Traffic to the Self Zone

The self zone is the router itself and includes all of the IP addresses assigned to the router interfaces. This zone is used for traffic that originates at the router or is addressed to a router interface, and should exclusively consist of device management traffic, such as SSH connections or traffic forwarding control packets.

Interface Assignment

Assigning an interface to a zone will immediately apply the service-policy that has been associated with that zone. If no service-policy has been configured for the zone, all transit traffic will be dropped.

To assign an interface to a zone, use the zone-member security zone-name interface configuration command.

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 a temporary interruption of service until the other zone-member is configured.

Verify Configuration

R1# show class-map type inspect
! Class Map type inspect match-any HTTP-TRAFFIC (id 1) 
!    Match protocol http 
!    Match protocol https 
!    Match protocol dns 
!  
R1# show zone security
! zone self 
! Description: System Defined Zone 
!  
! zone PRIVATE 
!  Member Interfaces: 
!  GigabitEthernet0/0 
!  
! zone PUBLIC 
!  Member Interfaces: 
!  Serial0/0/0 
!  
R1# show zone-pair security
! Zone-pair name PRIV-PUB 
!     Source-Zone PRIVATE  Destination-Zone PUBLIC 
!     service-policy PRIV-TO-PUB-POLICY 
!  
R1# show policy-map type inspect
! Policy Map type inspect PRIV-TO-PUB-POLICY 
!     Class HTTP-TRAFFIC 
!       Inspect 
!     Class class-default 
!       Drop
!
R1# show policy-map type inspect zone-pair sessions
! 
! policy exists on zp PRIV-PUB 
!   Zone-pair: PRIV-PUB 
!  
!   Service-policy inspect : PRIV-TO-PUB-POLICY 
!
! <...output truncated...>
!
R1# 

---

---