Many types of access lists are available in Cisco IOS Software for many different protocols. See Table 9-1 for a complete list.
Table 9-1 Cisco IOS Software Access Lists
Protocol Range
IP 1—99, 1300—1999
Extended IP 100—199, 2000—2699
Ethernet type code 200—299
Ethernet address 700—799
Transparent bridging (protocol type) 200—299 Transparent bridging (vendor code) 700—799 Extended transparent bridging 1100—1199 DECnet and extended DECnet 300—399 Xerox Network Systems (XNS) 400—499
Extended XNS 500—599
AppleTalk 600—699
Source-route bridging (protocol type) 200—299 Source-route bridging (vendor code) 700—799
IPX 800—899
© 2011 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 245 for more details.
You are permitted one access list per protocol, per interface, per direction.
FIGURE 9-1
Access Control Lists One access list per protocol,
per direction, per interface
Inbound access list filters traffic before entering the router; an outbound access list filters traffic before it exits the router Server
fa 0/0
At the end of every access list is an implied deny-all-traffic access control entry (ACE). Therefore, if a packet does not match any of your criteria statements, it is blocked.
Remember that the order of access list statements is important! For example, if you create a criteria statement that explicitly permits all traffic, no statements added later are ever checked.
When you edit an access list and need to reorder entries, you should first delete the old list with the no access-list command. If you do not first delete the previous version of the access list, when you copy or type commands on your router, you append ad-ditional access control list (ACL) statements to the end of the existing access list.
The following ACLs are supported for IP:
n Standard access lists for filtering based on source address
n Extended access lists for filtering on source or destination address or port numbers
n Dynamic extended IP access lists that grant access per user to a specific source or destination host basis through a user authentication process
n Reflexive access lists that enable IP packets to be filtered based on session information To create a standard access list, use the following global configuration mode syntax:
access-list access-list-number {deny | permit} source [source-wildcard] [log]
The Cisco IOS Software can provide logging messages about packets permitted or denied by a standard IP access list. The first packet that triggers the access list causes an immediate logging message, and subsequent packets are collected over 5-minute intervals before they are displayed or logged. You can use the ip access-list log-update command to set the number of pack-ets that cause the system to generate a log message. If you enable Cisco Express Forwarding (CEF) and then create an access list that uses the log keyword, the packets that match the access list are not CEF switched.
To create an extended access list, use the following global configuration mode command:
access-list access-list-number {deny | permit} protocol source source-wildcard destination destination-wildcard [precedence precedence] [tos tos] [established] [log | log-input] [time-range time-range-name]
[fragments]
You can identify IP access lists with a name rather than a number. To create a standard access list, use the following command:
ip access-list standard name
To create an extended access list, use the following command:
ip access-list extended name
You can specify whether the system examines noninitial IP fragments of packets when applying an IP extended access list.
Before this option was added, nonfragmented packets and the initial fragment of a packet were processed by IP extended access lists, but noninitial fragments were permitted by default. The IP Extended Access Lists with Fragment Control feature enable more granularity of control over noninitial packets.
© 2011 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 245 for more details.
The optional fragments keyword is available with four IP access list commands (access-list [IP extended], deny [IP], dynamic, and permit [IP]). By specifying the fragments keyword in an access list entry, that particular access list entry applies only to noninitial fragments of packets; the fragment is either permitted or denied accordingly.
The Turbo Access Control Lists (Turbo ACL) feature processes access lists more expediently than conventional access lists.
To enable the Turbo ACL feature, use the following command:
access-list compiled
Use the show access-list compiled EXEC command to verify that the Turbo ACL feature has been successfully configured on your router.
You can implement access lists based on the time of day and week using the time-range global configuration command.
To do so, first define the name and times of the day and week of the time range and then reference the time range by name in an access list to apply restrictions to the access list.
To restrict access to a vty and the addresses in an access list, use the following command:
access-class access-list-number {in | out}
To restrict access to an interface, use the following command:
ip access-group {access-list-number | access-list-name}
{in | out}
Zone-Based Firewall
Traditionally, access control on a Cisco router is controlled through (ACLs. These ACLs would be configured as a list of access control entries (ACE), which spelled out exactly what traffic was permitted or denied. Furthermore, most ACLs would list a series of traffic that was allowed in an interface and deny everything else. They were often limited to IPs and ports. The Cisco Zone-Based Firewall abstracted the concept by creating zones. A zone is a group of interfaces that have a common security policy. Networks are broken into zones, and a policy is configured between the zones to enable traffic. Following are the three basic steps in configuring a zone based firewall:
1. Create the security zones
2. Create the policies between the zones 3. Assign interfaces to the zones
The first step is to configure a zone:
Router(config)# zone security <NAME>
Of these three steps, the creation of the policies is by far the most complicated and requires the most planning.
To configure a policy between the zones, the rules must be developed. Zone-based firewalls take advantage of the flexible policy/class map-based structure common in QoS. To create an inspect policy map:
Router(config)# policy-map type inspect <POLICY MAP NAME>
The policy map is filled with references to class-maps that define the traffic of interest:
Router(config-pmap)# class-type inspect <CLASS MAP NAME>
The specific policy is then applied to the traffic matched within the class-map. Following are the actions that can be taken:
* inspect: Traffic is enabled and inspected at the application layer using stateful inspection.
* drop: Traffic is dropped.
* pass: Traffic is permitted in one way but not entered in the state table.
* police: Traffic is policed using options. Must be used with inspect or pass options.
Router(config-pmap)# inspect|pass|drop|police
To create the class maps that match traffic using access-lists (access-group), individual protocols (protocol) or other class-maps (class-map):
Router(config)# class-map type inspect <CLASS MAP NAME>
Router(config-cmap)# match access-group | protocol | class-map
© 2011 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 245 for more details.
To assign an interface to a zone
Router(config-if)# zone-member security <ZONE NAME>
The policy map must be applied to the zones:
Router(config-)# service-policy type inspect <POLICY MAP NAME>
Unicast Reverse Path Forwarding
The Unicast Reverse Path Forwarding feature (Unicast RPF) helps the network guard against malformed or “spoofed” IP packets passing through a router. A spoofed IP address is one that is manipulated to have a forged IP source address. Unicast RPF enables the administrator to drop packets that lack a verifiable source IP address at the router. Note how similar this is to the Reverse Path Forwarding check with multicast traffic. In that case, traffic was dropped to avoid loops.
Unicast RPF is enabled on a router interface. When this feature is enabled, the router checks packets that arrive inbound on the interface to see whether the source address matches the receiving interface. Cisco Express Forwarding (CEF) is required on the router because the Forwarding Information Base (FIB) is the mechanism checked for the interface match.
Administrators can decide to drop packets that arrive on an interface without a return path to the source in the FIB, or they can just have counters increment in the global IP traffic statistics for Unicast RPF drops and in the interface statistics for Unicast RPF.
Whether packets that fail the Unicast RPF check are dropped is controlled by the use of an ACL with the ip verify unicast reverse-path command. If an ACL is specified in the command and a packet fails the Unicast RPF check, the ACL is checked to see whether the packet should be dropped or forwarded. If no ACL is specified in the Unicast RPF command, the router drops the unverifiable packet, and the counters are updated. You can use ACL logging to obtain the source address information.
Just be sure to specify the log option in the ACL used with the ip verify unicast reverse-path command.
To implement Unicast RPF, ensure that CEF is enabled on the router, and use the ip verify unicast reverse-path list interface configuration command.
© 2011 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 245 for more details.
Context-Based Access Control
Context-Based Access Control (CBAC) makes firewall-like stateful packet filtering a possibility on your Cisco IOS router (see Figure 9-2). This capability makes the Cisco IOS router act much like a Cisco PIX or Adaptive Security Appliance. Using CBAC, the router can permit TCP and User Datagram Protocol (UDP) connections from the “trusted” inside interface of the network to “untrusted” outside interfaces (for example, an Internet connection to an Internet service provider). The router then creates a stateful session table to monitor for the appropriate return traffic for these TCP and UDP sessions. Stateful packet filtering is much more powerful than traditional firewall packet filtering in that it can examine application layer information to ensure traffic is safe for entrance into the network. Traditional filtering was often limited to source address inspection, for example.
FIGURE 9-2 CBAC
Inspected TCP Connection
Permitted TCP Return Traffic
Internet
CBAC functions on a router as follows:
n Control traffic is inspected by an administrator-configured CBAC rule (for example, ip inspect name MYCBACRULE tcp).
n CBAC creates a dynamic ACL enabling return traffic through the router.
n Inspection continues with dynamic ACLs being created and removed as needed; application-specific attacks are also monitored for.
n Application termination is detected, or timeouts occur and dynamic ACLs are removed.
© 2011 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 245 for more details.
CBAC can be configured to support all TCP connections or all UDP sessions. You can also configure CBAC to inspect certain application layer protocols:
n FTP
n Simple Mail Transport Protocol (SMTP)
n HTTP
n ICMP
n Session Initiation Protocol (SIP)
Configuring CBAC on a router involves the following tasks:
n Determine whether CBAC will be configured on an internal or external interface.
n Ensure access lists configured for outbound traffic permit the CBAC-analyzed traffic, and ensure access lists configured for inbound traffic deny the CBAC-analyzed traffic.
n Configure global timeouts and thresholds:
ip inspect tcp synwait-time seconds ip inspect tcp finwait-time seconds n Define an inspection rule.
For an application layer protocol:
ip inspect name inspection-name protocol [alert {on | off}] [audit-trail {on | off}] [timeout seconds]
For an RPC application layer protocol:
ip inspect name inspection-name rpc program-number number [wait-time minutes] [alert {on | off}]
[audit-trail {on | off}] [timeout seconds]
For Java blocking:
ip inspect name inspection-name http [java-list access-list] [alert {on | off}] [audit-trail {on | off}] [timeout seconds]
For TCP and UDP inspection:
ip inspect name inspection-name tcp [alert {on | off}] [audit-trail {on | off}] [timeout seconds]
ip inspect name inspection-name udp [alert {on | off}] [audit-trail {on | off}] [timeout seconds]
n Apply the inspection rule to an interface:
ip inspect inspection-name {in | out}
n Configure audit trail messages:
ip inspect audit-trail