-
- IP Access List Features Roadmap
- IP Access List Overview
- Creating an IP Access List and Applying It to an Interface
- Creating an IP Access List to Filter IP Options TCP Flags Noncontiguous Ports or TTL Values
- Refining an IP Access List
- Displaying and Clearing IP Access List Data Using ACL Manageability
- Controlling Access to a Virtual Terminal Line
- Access List-Based RBSCP
- ACL IP Options Selective Drop
- ACL Authentication of Incoming rsh and rcp Requests
- Configuring Lock-and-Key Security for Dynamic Access Lists
- Configuring IP Session Filtering of Reflexive Access Lists
- Configuring TCP Intercept and Preventing Denial-of-Service Attacks
-
- Configuring Context-based Access Control
- Application Firewall - Instant Message Traffic Enforcement
- Cisco IOS Firewall MIB
- Cisco IOS Firewall Performance Improvements
- Cisco IOS Firewall Stateful Failover
- Cisco IOS Firewall Support for TRP
- Email Inspection Engine
- ESMTP Support for Cisco IOS Firewall
- Firewall ACL Bypass
- Firewall N2H2 Support
- Firewall Stateful Inspection of ICMP
- Firewall Support for SIP
- Firewall Support of Skinny Client Control Protocol
- Firewall Websense URL Filtering
- Granular Protocol Inspection
- HTTP Inspection Engine
- Inspection of Router-Generated Traffic
- TCP Out-of-Order Packet Support for Cisco IOS Firewall and Cisco IOS IPS
- Transparent Cisco IOS Firewall
- Virtual Fragmentation Reassembly
- VRF Aware Cisco IOS Firewall
- Configuring Port to Application Mapping
- Configuring Cisco IOS Intrusion Prevention System (IPS)
- Configuring IP Security Options
- Finding Feature Information
- Contents
- Prerequisites for Creating an IP Access List and Applying It to an Interface
- Information About Creating an IP Access List and Applying It to an Interface
- How to Create an IP Access List and Apply It to an Interface
- Example: Filtering on Source Address (Hosts)
- Example: Filtering on Source Address (Subnet)
- Example: Filtering on Source Address, Destination Address, and IP Protocols
- Example: Filtering on Source Address (Host and Subnets) Using a Numbered Access List
- Example: Preventing Telnet Access to a Subnet
- Example: Filtering on TCP and ICMP Using Port Numbers
- Example: Allowing SMTP (E-mail) and Established TCP Connections
- Example: Preventing Access to the Web By Filtering on Port Name
- Example: Filtering on Source Address and Logging the Packets Permitted and Denied
- Example: Limiting Debug Output
Creating an IP Access List and Applying It to an Interface
IP access lists provide many benefits for securing a network and achieving nonsecurity goals, such as determining quality of service (QoS) factors or limiting debug command output. This module describes how to create standard, extended, named, and numbered IP access lists. An access list can be referenced by a name or a number. Standard access lists filter on only the source address in IP packets. Extended access lists can filter on source address, destination address, and other fields in an IP packet.
After you create an access list, you must apply it to something in order for it to have any effect. This module describes how to apply an access list to an interface. However, there are many other uses for an access list, which are referenced in this module and described in other modules and in other configuration guides for various technologies.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for Creating an IP Access List and Applying It to an Interface" section.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•Prerequisites for Creating an IP Access List and Applying It to an Interface
•Information About Creating an IP Access List and Applying It to an Interface
•How to Create an IP Access List and Apply It to an Interface
•Configuration Examples for Creating an IP Access List and Applying It to an Interface
•Feature Information for Creating an IP Access List and Applying It to an Interface
Prerequisites for Creating an IP Access List and Applying It to an Interface
Before you create or apply an IP access list, you should understand the concepts in the "IP Access List Overview" module. You should also have IP running in your network.
Information About Creating an IP Access List and Applying It to an Interface
•Helpful Hints for Creating IP Access Lists
•Additional IP Access List Features
Helpful Hints for Creating IP Access Lists
The following tips will help you avoid unintended consequences and help you create more efficient access lists.
•Create the access list before applying it to an interface (or elsewhere), because if you apply a nonexistent access list to an interface and then proceed to configure the access list, the first statement is put into effect, and the implicit deny statement that follows could cause you immediate access problems.
•Another reason to configure an access list before applying it is because an interface with an empty access list applied to it permits all traffic.
•All access lists need at least one permit statement; otherwise, all packets are denied and no traffic passes.
•Because the software stops testing conditions after it encounters the first match (to either a permit or deny statement), you will reduce processing time and resources if you put the statements that packets are most likely to match at the beginning of the access list. Place more frequently occurring conditions before less frequent conditions.
•Organize your access list so that more specific references in a network or subnet appear before more general ones.
•Use the statement permit any any if you want to allow all other packets not already denied. Using the statement permit any any in effect avoids denying all other packets with the implicit deny statement at the end of an access list. Do not make your first access list entry permit any any because all traffic will get through; no packets will reach the subsequent testing. In fact, once you specify permit any any, all traffic not already denied will get through.
•Although all access lists end with an implicit deny statement, we recommend use of an explicit deny statement (for example, deny ip any any). On most platforms, you can display the count of packets denied by issuing the show access-list command, thus finding out more information about who your access list is disallowing. Only packets denied by explicit deny statements are counted, which is why the explicit deny statement will yield more complete data for you.
•While you are creating an access list or after it is created, you might want to delete an entry.
–You cannot delete an entry from a numbered access list; trying to do so will delete the entire access list. If you need to delete an entry, you need to delete the entire access list and start over.
–You can delete an entry from a named access list. Use the no permit or no deny command to delete the appropriate entry.
•In order to make the purpose of individual statements more scannable and easily understood at a glance, you can write a helpful remark before or after any statement by using the remark command.
•If you want to deny access to a particular host or network and find out if someone from that network or host is attempting to gain access, include the log keyword with the corresponding deny statement so that the packets denied from that source are logged for you.
•This hint applies to the placement of your access list. When trying to save resources, remember that an inbound access list applies the filter conditions before the routing table lookup. An outbound access list applies the filter conditions after the routing table lookup.
Access List Remarks
You can include comments (remarks) about entries in a named IP access list. An access list remark is an optional comment before or after an access list entry that describes the entry for you at a glance, so you do not have to interpret the purpose of the entry by its command syntax. Each remark is limited to 100 characters.
The remark can go before or after a permit or deny statement. You should be consistent about where you put your remarks so that it is clear which remark describes which statement. It could be confusing to have some remarks before the associated permit or deny statements and some remarks after the associated statements.
The following example of a remark is a user-friendly description of what the subsequent deny statement does.
ip access-list extended telnetting
remark Do not allow host1 subnet to telnet out
deny tcp host 172.69.2.88 any eq telnet
Additional IP Access List Features
Beyond the basic steps to create a standard or extended access list, you can enhance your access lists as mentioned below. Each of these methods is described completely in the module entitled "Refining an Access List."
•You can impose dates and times when permit or deny statements in an extended access list are in effect, making your access list more granular and specific to an absolute or periodic time period.
•After you create a named or numbered access list, you might want to add entries or change the order of the entries, known as resequencing an access list.
•You can achieve finer granularity when filtering packets by filtering on noninitial fragments of packets.
How to Create an IP Access List and Apply It to an Interface
This section describes the general ways to create a standard or extended access list using either a name or a number. Access lists are very flexible; the tasks simply illustrate one permit command and one deny command to provide you the command syntax of each. Only you can determine how many permit and deny commands you need and their order.
Note The first two tasks in this module create an access list; you must apply the access list in order for it to function. If you want to apply the access list to an interface, perform the task "Applying the Access List to an Interface" section.
If you don't intend to apply the access list to an interface, see the "Where to Go Next" section for pointers to modules that describe other ways to apply access lists.
•Creating a Standard Access List to Filter on Source Address
•Creating an Extended Access List
•Applying the Access List to an Interface
Creating a Standard Access List to Filter on Source Address
If you want to filter on source address only, a standard access list is simple and sufficient. There are two alternative types of standard access list: named and numbered. Named access lists allow you to identify your access lists with a more intuitive name rather than a number, and they also support more features than numbered access lists.
•Creating a Named Access List to Filter on Source Address
•Creating a Numbered Access List to Filter on Source Address
Creating a Named Access List to Filter on Source Address
Use a standard, named access list if you need to filter on source address only. This task illustrates one permit statement and one deny statement, but the actual statements you use and their order depend on what you want to filter or allow. Define your permit and deny statements in the order that achieves your filtering goals.
SUMMARY STEPS
1. enable
2. configure terminal
3. ip access-list standard name
4. remark remark
5. deny {source [source-wildcard] | any} [log]
6. remark remark
7. permit {source [source-wildcard] | any} [log]
8. Repeat some combination of Steps 4 through 7 until you have specified the source networks and hosts on which you want to base your access list.
9. end
10. show ip access-list
DETAILED STEPS
What to Do Next
The access list you created is not in effect until you apply it to an interface, a vty line, or reference it from a command that uses an access list. See the "Applying the Access List to an Interface" section or the "Where to Go Next" section for pointers to modules that describe other ways to use access lists.
Creating a Numbered Access List to Filter on Source Address
Configure a standard, numbered access list if you need to filter on source address only and you prefer not to use a named access list.
IP standard access lists are numbered 1 to 99 or 1300 to 1999. This task illustrates one permit statement and one deny statement, but the actual statements you use and their order depend on what you want to filter or allow. Define your permit and deny statements in the order that achieves your filtering goals.
SUMMARY STEPS
1. enable
2. configure terminal
3. access-list access-list-number remark remark
4. access-list access-list-number permit {source [source-wildcard] | any} [log]
5. access-list access-list-number remark remark
6. access-list access-list-number deny {source [source-wildcard] | any} [log]
7. Repeat some combination of Steps 3 through 6 until you have specified the sources on which you want to base your access list.
8. end
9. show ip access-list
DETAILED STEPS
What to Do Next
The access list you created is not in effect until you apply it to an interface, a vty line, or reference it from a command that uses an access list. See the "Applying the Access List to an Interface" section or the "Where to Go Next" section for pointers to modules that describe other ways to use access lists.
Creating an Extended Access List
If you want to filter on anything other than source address, you need to create an extended access list. There are two alternative types of extended access list: named and numbered. Named access lists allow you to identify your access lists with a more intuitive name rather than a number, and they also support more features.
For details on how to filter something other than source or destination address, see the syntax descriptions in the command reference documentation.
•Creating a Named Extended Access List
•Creating a Numbered Extended Access List
Creating a Named Extended Access List
Create a named extended access list if you want to filter on source and destination address, or a combination of addresses and other IP fields.
SUMMARY STEPS
1. enable
2. configure terminal
3. ip access-list extended name
4. remark remark
5. deny protocol source [source-wildcard] destination [destination-wildcard] [option option-name] [precedence precedence] [tos tos] [established] [log | log-input] [time-range time-range-name] [fragments]
6. remark remark
7. permit protocol source [source-wildcard] destination [destination-wildcard]] [option option-name] [precedence precedence] [tos tos] [established] [log | log-input] [time-range time-range-name] [fragments]
8. Repeat some combination of Steps 4 through 7 until you have specified the fields and values on which you want to base your access list.
9. end
10. show ip access-list
DETAILED STEPS
What to Do Next
The access list you created is not in effect until you apply it to an interface, a vty line, or reference it from a command that uses an access list. See the "Applying the Access List to an Interface" section or the "Where to Go Next" section for pointers to modules that describe other ways to use access lists.
Creating a Numbered Extended Access List
Create a numbered extended access list if you want to filter on source and destination address, or a combination of addresses and other IP fields, and you prefer not to use a name. Extended IP access lists are numbered 100 to 199 or 2000 to 2699.
SUMMARY STEPS
1. enable
2. configure terminal
3. access-list access-list-number remark remark
4. access-list access-list-number permit protocol {source [source-wildcard] | any} {destination [destination-wildcard] | any} [precedence precedence] [tos tos] [established] [log | log-input] [time-range time-range-name] [fragments]
5. access-list access-list-number remark remark
6. access-list access-list-number deny protocol {source [source-wildcard] | any} {destination [destination-wildcard] | any} [precedence precedence] [tos tos] [established] [log | log-input] [time-range time-range-name] [fragments]
7. Repeat some combination of Steps 3 through 6 until you have specified the fields and values on which you want to base your access list.
8. end
9. show ip access-list
DETAILED STEPS
Applying the Access List to an Interface
Perform this task to apply an access list to an interface.
SUMMARY STEPS
1. enable
2. configure terminal
3. interface type number
4. ip access-group {access-list-number | access-list-name} {in | out}
DETAILED STEPS
What to Do Next
The access list you created is not in effect until you apply it to an interface, a vty line, or reference it from a command that uses an access list. See the "Applying the Access List to an Interface" section or the "Where to Go Next" section for pointers to modules that describe other ways to use access lists.
Configuration Examples for Creating an IP Access List and Applying It to an Interface
•Example: Filtering on Source Address (Hosts)
•Example: Filtering on Source Address (Subnet)
•Example: Filtering on Source Address, Destination Address, and IP Protocols
•Example: Filtering on Source Address (Host and Subnets) Using a Numbered Access List
•Example: Preventing Telnet Access to a Subnet
•Example: Filtering on TCP and ICMP Using Port Numbers
•Example: Allowing SMTP (E-mail) and Established TCP Connections
•Example: Preventing Access to the Web By Filtering on Port Name
•Example: Filtering on Source Address and Logging the Packets Permitted and Denied
•Example: Limiting Debug Output
Example: Filtering on Source Address (Hosts)
In the following example, the workstation belonging to Jones is allowed access to Ethernet interface 0 and the workstation belonging to Smith is not allowed access:
interface ethernet 0
ip access-group workstations in
!
ip access-list standard workstations
remark Permit only Jones workstation through
permit 172.16.2.88
remark Do not allow Smith workstation through
deny 172.16.3.13
Example: Filtering on Source Address (Subnet)
In the following example, the Jones subnet is not allowed access to Ethernet interface 0, but the Main subnet is allowed access:
interface ethernet 0
ip access-group prevention in
!
ip access-list standard prevention
remark Do not allow Jones subnet through
deny 172.22.0.0 0.0.255.255
remark Allow Main subnet
permit 172.25.0.0 0.0.255.255
Example: Filtering on Source Address, Destination Address, and IP Protocols
The following configuration example shows an interface with two access lists, one applied to outgoing packets and one applied to incoming packets. The standard access list named Internet_filter filters outgoing packets on source address. The only packets allowed out the interface must be from source 172.16.3.4.
The extended access list named marketing_group filters incoming packets. The access list permits Telnet packets from any source to network 172.26.0.0 and denies all other TCP packets. It permits any ICMP packets. It denies UDP packets from any source to network 172.26.0 0 on port numbers less than 1024. Finally, the access list denies all other IP packets and performs logging of packets passed or denied by that entry.
interface Ethernet0/5
ip address 172.20.5.1 255.255.255.0
ip access-group Internet_filter out
ip access-group marketing_group in
!
ip access-list standard Internet_filter
permit 172.16.3.4
ip access-list extended marketing_group
permit tcp any 172.26.0.0 0.0.255.255 eq telnet
deny tcp any any
permit icmp any any
deny udp any 172.26.0.0 0.0.255.255 lt 1024
deny ip any any
Example: Filtering on Source Address (Host and Subnets) Using a Numbered Access List
In the following example, network 10.0.0.0 is a Class A network whose second octet specifies a subnet; that is, its subnet mask is 255.255.0.0. The third and fourth octets of a network 10.0.0.0 address specify a particular host. Using access list 2, the Cisco IOS software would accept one address on subnet 48 and reject all others on that subnet. The last line of the list shows that the software would accept addresses on all other network 10.0.0.0 subnets.
interface ethernet 0
ip access-group 2 in
!
access-list 2 permit 10.48.0.3
access-list 2 deny 10.48.0.0 0.0.255.255
access-list 2 permit 10.0.0.0 0.255.255.255
Example: Preventing Telnet Access to a Subnet
In the following example, the Jones subnet is not allowed to Telnet out Ethernet interface 0:
interface ethernet 0
ip access-group telnetting out
!
ip access-list extended telnetting
remark Do not allow Jones subnet to telnet out
deny tcp 172.20.0.0 0.0.255.255 any eq telnet
remark Allow Top subnet to telnet out
permit tcp 172.33.0.0 0.0.255.255 any eq telnet
Example: Filtering on TCP and ICMP Using Port Numbers
In the following example, the first line of the extended access list named goodports permits any incoming TCP connections with destination ports greater than 1023. The second line permits incoming TCP connections to the Simple Mail Transfer Protocol (SMTP) port of host 172.28.1.2. The last line permits incoming ICMP messages for error feedback.
interface ethernet 0
ip access-group goodports in
!
ip access-list extended goodports
permit tcp any 172.28.0.0 0.0.255.255 gt 1023
permit tcp any host 172.28.1.2 eq 25
permit icmp any 172.28.0.0 255.255.255.255
Example: Allowing SMTP (E-mail) and Established TCP Connections
Suppose you have a network connected to the Internet, and you want any host on an Ethernet to be able to form TCP connections to any host on the Internet. However, you do not want IP hosts to be able to form TCP connections to hosts on the Ethernet except to the mail (SMTP) port of a dedicated mail host.
SMTP uses TCP port 25 on one end of the connection and a random port number on the other end. The same two port numbers are used throughout the life of the connection. Mail packets coming in from the Internet will have a destination port of 25. Outbound packets will have the port numbers reversed. The fact that the secure system behind the router always will accept mail connections on port 25 is what makes possible separate control of incoming and outgoing services. The access list can be configured on either the outbound or inbound interface.
In the following example, the Ethernet network is a Class B network with the address 172.18.0.0, and the address of the mail host is 172.18.1.2. The established keyword is used only for the TCP protocol to indicate an established connection. A match occurs if the TCP datagram has the ACK or RST bits set, which indicate that the packet belongs to an existing connection.
interface ethernet 0
ip access-group 102 in
!
access-list 102 permit tcp any 172.18.0.0 0.0.255.255 established
access-list 102 permit tcp any host 172.18.1.2 eq 25
Example: Preventing Access to the Web By Filtering on Port Name
In the following example, the Winter and Smith workstations are not allowed web access; other hosts on network 172.20.0.0 are allowed web access:
interface ethernet 0 ip access-group no_web out
!
ip access-list extended no_web
remark Do not allow Winter to browse the web
deny host 172.20.3.85 any eq http
remark Do not allow Smith to browse the web
deny host 172.20.3.13 any eq http
remark Allow others on our network to browse the web
permit 172.20.0.0 0.0.255.255 any eq http
Example: Filtering on Source Address and Logging the Packets Permitted and Denied
The following example defines access lists 1 and 2, both of which have logging enabled:
interface ethernet 0
ip address 172.16.1.1 255.0.0.0
ip access-group 1 in
ip access-group 2 out
!
access-list 1 permit 172.25.0.0 0.0.255.255 log
access-list 1 deny 172.30.0.0 0.0.255.255 log
!
access-list 2 permit 172.27.3.4 log
access-list 2 deny 172.17.0.0 0.0.255.255 log
If the interface receives 10 packets from 172.25.7.7 and 14 packets from 172.17.23.21, the first log will look like the following:
list 1 permit 172.25.7.7 1 packet
list 2 deny 172.17.23.21 1 packet
Five minutes later, the console will receive the following log:
list 1 permit 172.25.7.7 9 packets
list 2 deny 172.17.23.21 13 packets
Example: Limiting Debug Output
The following example configuration example uses an access list to limit the debug command output displayed. Limiting debug output narrows the volume of data to what you are interested in, saving you time and resources.
ip access-list idaho remark Displays only advertisements for LDP peer in idaho
permit host 10.0.0.44
Router# debug mpls ldp advertisements peer-acl idaho
tagcon: peer 10.0.0.44:0 (pp 0x60E105BC): advertise 172.17.0.33
tagcon: peer 10.0.0.44:0 (pp 0x60E105BC): advertise 172.16.0.31
tagcon: peer 10.0.0.44:0 (pp 0x60E105BC): advertise 172.22.0.33
tagcon: peer 10.0.0.44:0 (pp 0x60E105BC): advertise 192.168.0.1
tagcon: peer 10.0.0.44:0 (pp 0x60E105BC): advertise 192.168.0.3
tagcon: peer 10.0.0.44:0 (pp 0x60E105BC): advertise 192.168.1.33
Where to Go Next
This module describes how to create an access list that permits or denies packets based on source or destination address or protocol. However, there are other fields you could filter on, and other ways to use access lists. If you want to create an access list that filters on other fields or if you want to apply an access list to something other than an interface, you should decide what you want to restrict in your network and determine the type of access list that achieves your goal.
See the following table for references to other fields to filter and other ways to use an IP access list.
|
|
---|---|
Filter based on IP Options, TCP flags, noncontiguous ports, or TTL value |
"Creating an IP Access List to Filter IP Options, TCP Flags, Noncontiguous Ports, or TTL Values" module |
Reorder your access list entries |
"Refining an IP Access List" module |
Limit access list entries to a time of day or week |
"Refining an IP Access List" module |
Restrict packets with noninitial fragments |
"Refining an IP Access List" module |
Restrict access to virtual terminal lines |
"Controlling Access to a Virtual Terminal Line" |
Control routing updates |
"Configuring Routing Protocol-Independent Features" module in the Cisco IOS IP Routing Protocols Configuration Guide |
Identify or classify traffic for features such as congestion avoidance, congestion management, and priority queuing |
"Regulating Packet Flow on a Per-Interface Basis—Using Generic Traffic Shaping" module in the Quality of Service Solutions Configuration Guide |
Additional References
Related Documents
|
|
---|---|
Cisco IOS commands |
|
Security Commands |
|
Order of access list entries |
"Refining an IP Access List" |
Access list entries based on time of day or week |
"Refining an IP Access List" |
Packets with noninitial fragments |
"Refining an IP Access List" |
Filtering on IP Options, TCP flags, noncontiguous ports, or TTL values |
"Creating an IP Access List to Filter IP Options, TCP Flags, Noncontiguous Ports, or TTL Values" |
Access to virtual terminal lines |
"Controlling Access to a Virtual Terminal Line" |
Routing updates and policy routing |
"Configuring Routing Protocol-Independent Features" modules in the Cisco IOS IP Routing Protocols Configuration Guide |
Traffic identification or classification for features such as congestion avoidance, congestion management, and priority queuing |
"Regulating Packet Flow on a Per-Interface Basis—Using Generic Traffic Shaping" module in the Quality of Service Solutions Configuration Guide |
Standards
|
|
---|---|
None |
— |
MIBs
|
|
---|---|
None |
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL: |
RFCs
|
|
---|---|
None |
— |
Technical Assistance
Feature Information for Creating an IP Access List and Applying It to an Interface
Table 1 lists the features in this module and provides links to specific configuration information.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note Table 1 lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
© 2006 Cisco Systems, Inc. All rights reserved.