|
|
This chapter consists of these sections:
ACLs can provide the following network security features:
An access list is a sequential collection of permit and deny conditions that apply to addresses. The Cisco IOS software tests addresses against the conditions in an access list one by one. The first match determines whether the software accepts or rejects the address. Because the software stops testing conditions after the first match, the order of the conditions is critical. If no conditions match, the software rejects the address.
The software supports the following styles of access lists for IP:
IOS ACLs defined on the router VLAN interfaces can access control routed traffic between VLANs.
Standard and extended IOS ACLs are used as a packet classification mechanism. Classified packets can be subject to a number of features such as access control (security), policy-based routing, and so on. Packets can either enter the VLAN through a switch port or through a router port after being routed.
You can configure IOS ACLs on Layer 3 VLAN interfaces and on physical Layer 3 interfaces. An ACL can provide access control and consists of an ordered set of access control entries (ACEs). See the "ACEs Supported in Hardware" section for information about the ACEs. Many other features in IOS also use ACLs for filtering. For example, Web Cache Redirect (WCCP) uses ACLs to filter HTTP flows that can be redirected to a Web cache engine.
Most IOS ACLs are applied on interfaces for specific directions (inbound or outbound). Some features use ACLs globally. For such features, ACLs are applied on all interfaces for a given direction. As an example, TCP intercept uses a global ACL that is applied on all interfaces for outbound direction.
One ACL can be used with multiple features for a given interface and one feature can use multiple ACLs. In IOS, when a single ACL is used by multiple features, it is examined multiple times.
IOS examines ACLs associated with features configured on a given interface and a direction. As packets enter the Catalyst 6000 family switch on a given interface, ACLs associated with all inbound features configured on that interface are examined for the following:
After packets are routed and before they are forwarded out to the next hop, all ACLs associated with outbound features configured on the egress interface are examined as follows:
An ACL contains an ordered list of ACEs. Each ACE contains a number of fields that are matched against the contents of a packet. Each field can have an associated bit mask to indicate which bits are relevant. An action is associated with each ACE that describes what the system should do with the packet when a match occurs. The action is feature dependent. Catalyst 6000 family switches support three types of ACEs in hardware:
Refer to the Security Configuration Guide and the Security Command Reference for more information about ACEs.
When a feature is configured on the Catalyst 6000 family switch to process traffic (such as NAT), the IOS ACL associated with the feature determines the specific traffic that is bridged to the switch instead of being Layer 3 switched. The switch then applies the feature and routes the packet normally. Some exceptions to this process are described in the "Hardware and Software Handling of IOS ACLs" section.
 | Caution By default, the Catalyst 6000 family switch sends Internet Control Message Protocol (ICMP) unreachables when a packet is denied by an access group; these access-group denied packets are not dropped in hardware but are bridged to the switch so that it can generate the ICMP-unreachable message. To drop access-group denied packets in hardware, you must disable ICMP unreachables using the no ip unreachables interface configuration command. Note that the ip unreachables command is enabled by default. |
This section lists supported ACLs and indicates if the ACL is handled by hardware or software. ACL feature implementation (processing) requires forwarding some flows to the software. The forwarding rate for software-forwarded flows is substantially less than for hardware-forwarded flows. Flows that require logging as specified by the ACL, are handled in software without impacting non-log flow forwarding in hardware.
The supported ACLs are as follows and are described in the following sections:
Security ACLs function as follows:
Up to 512 simultaneous reflexive sessions are supported in the hardware.
TCP-intercept required flows are handled in software without impacting non-TCP intercept flow forwarding in hardware.
Policy routing-required flows are handled in software without impacting non-policy routed flow forwarding in hardware. When a route map contains multiple "match" clauses, all conditions imposed by these match clauses must be met before a packet is policy routed. However, for route maps containing both "match ip address" and "match length," all traffic matching the ACL in the "match ip address" clause is forwarded to the software regardless of the match length criteria. For route maps that only contain match length clauses, all packets received on the interface are forwarded to the software.
When you enable hardware policy routing using the mls ip pbr global command, all policy routing occurs in hardware.
| Caution If you use the mls ip pbr command to enable policy routing, policy routing is applied in hardware for all interfaces regardless of which interface was configured for policy routing. |
HTTP requests subject to Web Cache Communication Protocol (WCCP) redirection are handled in software. HTTP replies from the server and the cache engine are handled in hardware.
Network Address Translation (NAT)-required flows are handled in software without impacting non-NAT flow forwarding in hardware.
Unicast reverse path forwarding (RPF) check is supported by forwarding all incoming Layer 3 unicast traffic in software that is received on the RPF-configured interface.
IOS bridge-group ACLs are handled in software.
This section lists ACL-related features that are not supported or have limited support on the Catalyst 6000 family switches.
This section summarizes how to create IP access lists and how to apply them.
An access list is a sequential collection of permit and deny conditions that apply to addresses. The Cisco IOS software tests addresses against the conditions in an access list one by one. The first match determines whether the software accepts or rejects the address. Because the software stops testing conditions after the first match, the order of the conditions is critical. If no conditions match, the software rejects the address.
The two steps involved in using access lists are as follows:
1. Create an access list by specifying an access list number or name and access conditions.
2. Apply the access list to interfaces or terminal lines.
These steps are described in the next sections.
The software supports the following styles of access lists for IP:
The number you use to denote your access list determines the type of access list you create. Table 15-1 list the access list number and corresponding access list type.
| Access List Number | Type |
|---|---|
1-99 | IP standard access list |
100-199 | IP extended access list |
1000-1099 | IPX SAP access list |
1100-1199 | Extended 48-bit MAC address access list |
1200-1299 | IPX summary 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) |
300-399 | DECnet access list |
400-499 | XNS standard access list |
500-599 | XNS extended access list |
600-699 | AppleTalk access list |
700-799 | 48-bit MAC address access list |
800-899 | IPX standard access list |
900-999 | IPX extended access list |
All access lists numbered 1 through 99 are IP standard access lists, and access lists numbered 1000 through 1099 are IPX SAP access lists.
To create a standard access list, perform this task:
| Command | Purpose |
|---|---|
Router(config)# access-list access-list-number {deny | permit} source [source-wildcard] [log] | Define a standard IP access list using a source address and wildcard. |
Router(config)# access-list access-list-number {deny | permit} any [log] | Define a standard IP access list using an abbreviation for the source and source mask of 0.0.0.0 255.255.255.255. |
This example shows how to create a standard access list to deny access to IP host 171.69.198.102 and permit any others:
Router(config)# access-list 2 deny host 171.69.198.102 Router(config)# access-list 2 permit any
To display the access list configuration, perform this task:
| Command | Purpose |
|---|---|
Router# show access-lists [number | name] | Show the access list configuration. |
This example shows how to display an access list used to deny access to host 171.69.198.102 and permit any others:
Router# show access-lists
Standard IP access list 2
deny 171.69.198.102
permit any
Router#
IOS software can provide logging messages about packets permitted or denied by a standard IP access list. That is, any packet that matches the access list will cause an informational logging message about the packet to be sent to the console. The level of messages logged to the console is controlled by the logging console command. This capability was previously only available in extended IP access lists.
The first packet that triggers the access list causes a logging message right away, and subsequent packets are collected over 5-minute intervals before they are displayed or logged. The logging message includes the access list number, whether the packet was permitted or denied, the source IP address of the packet, and the number of packets from that source permitted or denied in the prior 5-minute interval.
To create an extended access list, perform one of these tasks:
| Command | Purpose |
|---|---|
Router(config)# access-list access-list-number {deny | permit} protocol source source-wildcard destination destination-wildcard [precedence precedence] [tos tos] [established] [log] | Define an extended IP access list number and the access conditions. Use the log keyword to get access list logging messages, including violations. |
Router(config)# access-list access-list-number {deny | permit} protocol any any | Define an extended IP access list using an abbreviation for a source and source wildcard of 0.0.0.0 255.255.255.255 and an abbreviation for a destination and destination wildcard of 0.0.0.0 255.255.255.255. |
Router(config)# access-list access-list-number {deny | permit} protocol host source host destination | Define an extended IP access list using an abbreviation for a source and source wildcard of source 0.0.0.0 and an abbreviation for a destination and destination wildcard of destination 0.0.0.0. |
Router(config)# access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny | permit} protocol source source-wildcard destination destination-wildcard [precedence precedence] [tos tos] [established] [log] | Define a dynamic access list. For information about lock-and-key access, refer to the "Configuring Traffic Filters" chapter in the Security Configuration Guide. |
This example shows how to create an extended access list to deny Telnet access to any host from network 171.69.198.0 to network 172.20.52.0 and permit any others:
Router(config)# access-list 102 deny tcp 171.69.198.0 0.0.0.255 eq telnet 172.20.52.0 0.0.0.255 Router(config)# access-list 102 permit tcp any any
To display the access list configuration, perform this task:
| Command | Purpose |
|---|---|
Router# show access-lists [number|name] | Display the access list configuration. |
This example shows how to display an access list used to deny Telnet access to any host from network 171.69.198.0 to network 172.20.52.0 and permit any others:
Router# show access-lists
Extended IP access list 102
deny tcp 171.69.198.0 0.0.0.255 eq telnet 172.20.52.0 0.0.0.255
permit tcp any any
Router#
After an access list is created initially, any subsequent additions (possibly entered from the terminal) are placed at the end of the list. You cannot selectively add or remove access list command lines from a specific access list.
After creating an access list, you must apply it to a line or interface, as shown in the "Applying the Access List to an Interface or Terminal Line" section.
You can identify IP access lists with an alphanumeric string (a name) rather than a number. Named access lists allow you to configure more IP access lists in a router than if you were to use numbered access lists. If you identify your access list with a name rather than a number, the mode and command syntax are slightly different. Currently, only packet and route filters can use a named list.
Consider the following before configuring named access lists:
To create a standard access list, perform this task:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| Router(config)# ip access-list standard name | Define a standard IP access list using a name. | ||
| Router(config-std-nacl)# deny {source [source-wildcard] | any}[log] or Router(config-std-nacl)# permit {source [source-wildcard] | any}[log] | In access-list configuration mode, specify one or more conditions allowed or denied. This determines whether the packet is passed or dropped. | ||
| Router(config-std-nacl)# exit | Exit access-list configuration mode. |
To create an extended access list, perform this task:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| Router(config)# ip access-list extended name | Define an extended IP access list using a name. | ||
| Router(config-ext-nacl)# {deny | permit} protocol source source-wildcard destination destination-wildcard [precedence precedence] [tos tos] [established] [log] | In access-list configuration mode, specify the conditions allowed or denied. Use the log keyword to get access list logging messages, including violations. | ||
|
| or | ||
| Router(config-ext-nacl)# {deny | permit} protocol any any | Define an extended IP access list using an abbreviation for a source and source wildcard of 0.0.0.0 255.255.255.255 and an abbreviation for a destination and destination wildcard of 0.0.0.0 255.255.255.255. | ||
|
| or | ||
| Router(config-ext-nacl)# {deny | permit} protocol host source host destination | Define an extended IP access list using an abbreviation for a source and source wildcard of source 0.0.0.0 and an abbreviation for a destination and destination wildcard of destination 0.0.0.0. | ||
|
| or | ||
| Define a dynamic access list. For information about lock-and-key access, refer to the "Configuring Traffic Filters" chapter in the Security Configuration Guide. |
After you initially create an access list, place any subsequent additions at the end of the list. You cannot selectively add access list command lines to a specific access list. However, you can use no permit and no deny commands to remove entries from a named access list.
After creating an access list, you must apply it to a line or interface, as shown in the next section, "Apply the Access List to an Interface or Terminal Line."
After you create an access list, you can apply it to one or more interfaces. Access lists can be applied on either outbound or inbound interfaces. This section describes how to accomplish this task for both terminal lines and network interfaces. Remember the following:
Only numbered access lists can be applied to lines. Set identical restrictions on all the virtual terminal lines, because a user can attempt to connect to any of them.
To restrict incoming and outgoing connections between a virtual terminal line and the addresses in an access list, perform this task:
| Command | Purpose |
|---|---|
Router(config-line)# access-class access-list-number {in | out} | Restrict incoming and outgoing connections between a particular virtual terminal line (into a device) and the addresses in an access list. |
To control access to an interface, perform this task:
| Command | Purpose |
|---|---|
Router(config-if)# ip access-group {access-list-number | name} {in | out} | Control access to an interface. |
This example shows how to configure an access list on Gigabit Ethernet interface 1/2 to filter packets entering on the interface:
Router(config)# interface gigabit 1/2 Router(config-if)# ip access-group 2 in
For inbound access lists, after receiving a packet, the IOS software checks the source address of the packet against the access list. If the access list permits the address, the software continues to process the packet. If the access list rejects the address, the software discards the packet and returns an ICMP Host Unreachable message.
For outbound access lists, after receiving and routing a packet to a controlled interface, the software checks the source address of the packet against the access list. If the access list permits the address, the software transmits the packet. If the access list rejects the address, the software discards the packet and returns an ICMP Host Unreachable message.
When you apply an access list that has not yet been defined to an interface, the software acts as if the access list has not been applied to the interface and accepts all packets. Remember this behavior if you use undefined access lists as a means of security in your network.
To display the access list configuration for an interface, perform this task:
| Command | Purpose |
|---|---|
Router# show running-config | Display the access list configuration. |
This example shows how to display the access list configuration of Gigabit Ethernet interface 1/2 and the configuration of access list 2:
Router# show running-config Building configuration... Current configuration: ! (Information Deleted) ! interface GigabitEthernet1/2 ip address 172.20.52.18 255.255.255.224 ip access-group 2 in no ip directed-broadcast no ip mroute-cache no mop enabled ! (Information Deleted) ! access-list 2 deny 171.69.198.102 access-list 2 permit any !
For detailed information about compiling access lists, refer to the IOS Security Configuration Guide.
These sections describe how to use TACACS+ authentication on the Catalyst 6000 family switches:
TACACS+ controls access to network devices by exchanging Network Access Server (NAS) information between a network device and a centralized database to determine the identity of a user or entity. TACACS+ is an enhanced version of TACACS, a User Datagram Protocol (UDP)-based access-control protocol specified by RFC 1492. TACACS+ uses TCP to ensure reliable delivery and encrypt all traffic between the TACACS+ server and the TACACS+ daemon on a network device.
TACACS+ works with many authentication types, including fixed password, one-time password, and challenge-response authentication. TACACS+ authentication usually occurs in these instances:
When you request privileged or restricted services, TACACS+ encrypts your user password information using the MD5 encryption algorithm and adds a TACACS+ packet header. This header information identifies the packet type being sent (for example, an authentication packet), the packet sequence number, the encryption type used, and the total packet length. The TACACS+ protocol then forwards the packet to the TACACS+ server.
A TACACS+ server can provide authentication, authorization, and accounting functions. These services, while all part of TACACS+, are independent of one another, so that a given TACACS+ configuration can use any or all of the three services. On the Catalyst 6000 family switches, only the authentication feature is supported.
When the TACACS+ server receives the packet, it does the following:
You can configure a TACACS+ key on a Catalyst 6000 family switch. This key, which must be the same as the one configured on the server daemon, encrypts packets transmitted to the server. If you do not configure a TACACS+ key, packets are not encrypted.
If local password authentication is enabled and TACACS+ password authentication fails, the local password authentication is invoked. Disabling TACACS+ authentication automatically reenables local authentication.
You can configure these TACACS+ parameters on a Catalyst 6000 family switch:
Table 15-2 shows the default TACACS+ authentication configuration.
| Feature | Default Value |
|---|---|
Local login authentication | Enabled |
Local enable authentication | Enabled |
TACACS+ login authentication | Disabled |
TACACS+ enable authentication | Disabled |
TACACS+ key | None specified |
TACACS+ login attempts | 3 |
TACACS+ server timeout | 5 seconds |
TACACS+ directed request | Disabled |
To configure your router to support TACACS+, you must perform the following tasks:
For detailed TACACS+ configuration information, refer to the IOS Security Configuration Guide.
Posted: Wed Mar 22 16:47:40 PST 2000
Copyright 1989 - 2000©Cisco Systems Inc.