There are many different kinds of access lists. The basic concepts I've introduced with standard access lists apply to all of them: for example, they are processed sequentially, new rules are added to old rules rather than overriding old rules, and they permit or deny certain actions (typically, processing of a packet) based on information in the packet's headers.
With a few exceptions, you can tell an access list 's type by looking at its number. Each type of access list has been assigned a group of 100 numbers. Table 7-3 summarizes the access list types and their numeric ranges.
List type |
Numeric range |
---|---|
Standard IP access lists |
1-99 |
Extended IP access lists |
100-199 |
Ethernet type code |
200-299 |
DECnet |
300-399 |
XNS |
400-499 |
Extended XNS |
500-599 |
AppleTalk |
600-699 |
Ethernet address |
700-799 |
Novell |
800-899 |
Extended Novell |
900-999 |
Novell SAP |
1000-1099 |
Additional standard IP access lists[*] |
1300-1999 |
Additional extended IP access listsa |
2000-2699 |
Named access lists |
None |
Reflexive access lists |
None |
Dynamic access lists |
None |
[*] These additional ranges were added in recent releases of IOS (11.1(cc) and 12.0).
7.2.1. Extended Access Lists
Extended access lists are a relatively straightforward variation on standard access lists. Standard lists are limited to filtering based on the source and destination addresses of IP packets. Extended lists add the ability to filter based on the protocol and the port specified in the packet. Here's the syntax of an extended access list:
access-list number action protocol source s-port destination d-port [optional-args]
The action and source address are the same as for standard access lists. The other fields are:
number
A number identifying the list. For extended access lists, this number must be between 100 and 199.
protocol
An indication of the protocol to which the rule applies. This must be either ip, tcp, udp, or icmp.
s-port
For TCP or UDP packets, the packet's source port. There are a number of ways to specify ports. This field is optional. If the protocol is IP or ICMP, this field is omitted.
destination
The packet's destination address, specified the same way as the source address. That is, you can have an IP address followed by a wildcard mask, the keyword host followed by the IP address of a specific host, or the keyword any.
d-port
For TCP or UDP packets, the packet's destination port. There are a number of ways to specify ports. This field is optional. If the protocol is IP or ICMP, this field is omitted.
optional-args
An optional keyword that is applicable only if the protocol is TCP. For example, the keyword established is optional.
7.2.1.1. Specifying ports
When writing extended access lists for TCP or UDP, you can specify source and destination ports along with the source and destination addresses. You can specify either individual ports or a range of ports. By specifying ports you can permit or deny access to specific services, such as SMTP or HTTP. Here are the different ways to specify ports:
lt n
All port numbers less than n
gt n
All port numbers greater than n
eq n
Port n
neq n
All ports except for n
range n m
All ports from n through m, inclusive
For example, eq 80 refers to the well-known port for a web server; gt 1023 refers to all ports greater than 1023. For most well-known ports, you can use the standard name for the service rather than the actual port number. For example, eq www refers to the well-known HTTP port, which is 80. Likewise, you can use smtp to refer to port 25, and so on. Here are some examples.
The following two rules match (and permit) packets with any source address destined for the SMTP or HTTP ports on the host 10.10.1.5:
access-list 110 permit tcp any host 10.10.1.5 eq 25 access-list 110 permit tcp any host 10.10.1.5 eq 80
The next rule matches TCP packets with a destination port less than 1024, regardless of the source and destination addresses and denies access:
access-list 110 deny tcp any any lt 1024
This rule matches TCP packets with a destination port from 3000 to 3010, inclusive, and denies access:
access-list 110 deny tcp any any range 3000 3010
Finally, this rule matches UDP packets with a destination port of 3535, regardless of the source and destination addresses, and permits access:
access-list 110 permit udp any any eq 3535
7.2.1.2. Established connections
The established keyword can be added to access rules for TCP. Technically, this keyword matches packets that have the ACK or RST (Reset) bit set. If either the ACK or the RST bit is set, the router assumes that the packet is not the first packet of a session and that a session has already been established.
What does this mean in practice? It gives us a way to distinguish sessions originating inside our network from sessions originating elsewhere. For example, let's say that we want to allow our staff to initiate telnet connections with any site on the Internet but that we don't want people outside our site to be able to establish telnet connections to our systems. An easy way to enforce that policy is to block incoming packets that don't have the ACK or RST bits set by using the established keyword. This means that we allow return traffic for connections that are already established from the inside, and that we don't allow outsiders to establish connections with us. In short, the only people who can establish connections are the users inside our network. Here's how you might create and apply that list:
! Inbound access list access-list 110 permit tcp any any established access-list 110 deny ip any any ! ! Outbound access list access-list 111 permit tcp any any eq telnet access-list 111 deny ip any any ! interface serial0 access-group 110 in access-group 111 out
In practice, it would be a good idea to specify our network's address as the destination for the inbound list, rather than relying on any. The established keyword is almost always used on incoming packet filters, which allows connections to originate "behind" the router but prevents connections from the outside. (It could be used on outgoing access lists, but this would not be particularly useful.) This method of blocking unwanted traffic originating outside the network can be circumvented; it is possible to forge a packet with the appropriate bits set. Later in this chapter, "Reflexive Access Lists" covers another way to allow established connections.
7.2.1.3. ICMP protocol entries
ICMP packets are becoming increasingly important, as they have been used in many recent denial-of-service attacks. We can construct access list rules that permit or deny ICMP packets, allowing us to receive (or block) network error messages and ping packets. Here's a typical ICMP rule:
access-list 110 permit icmp any any echo-reply
ICMP is a surprisingly complicated protocol with lots of different packet types. It would be nice if you could either block ICMP entirely or allow it into your network without worrying about it. Unfortunately, neither approach is a good idea. You can't just block ICMP, because a number of important mechanisms for controlling traffic flow depend on it. (For example, Path MTU discovery relies on ICMP; if ICMP is blocked, you might find connections that start but die for no apparent reason.) And you can't allow ICMP in unquestioned, because it's the basis for a number of denial-of-service attacks.
Here's a set of access list rules that should be appropriate for most situations. They allow what you need and block packet types that you don't need or are dangerous:
! Allow pings into the network access-list 110 permit icmp any any echo ! Allow ping responses access-list 110 permit icmp any any echo-reply ! Allow ICMP source-quench (flow control) access-list 110 permit icmp any any source-quench ! Allow Path MTU discovery access-list 110 permit icmp any any packet-too-big ! Allow time-exceeded, which is useful for traceroute access-list 110 permit icmp any any time-exceeded ! Deny all other ICMP packets access-list 110 deny icmp any any
7.2.1.4. Applying an access list to an interface or line
We've already used the commands that apply access lists to interfaces fairly liberally, but it's worth looking at them in detail. To apply an access list to an interface, use the access-group command. Here are two examples:
interface ethernet0 ip access-group 110 in ip access-group 112 out
This code applies access list 110 to inbound packets and access list 112 to outbound packets on the interface ethernet0. Again, packets arriving at an interface and packets leaving the interface are filtered separately. You can apply only one access list per direction to an interface.
To apply a standard access list to a line, use the access-class command. For example:
line vty0 access-class 10 in
This means that access list 10 is used to control which hosts can access virtual terminal 0. In effect, this command limits telnet access to the router. You cannot apply an extended access list to a line.
There are many other contexts in which you can use access lists. Unfortunately, each has its own command for applying the list. The commands are more or less similar: you specify an access list number and usually specify whether the list applies to traffic leaving or entering the router.
7.2.2. Named Access Lists
So far, all the access lists we've seen have been identified by numbers. Numbers have some obvious problems: they're difficult to remember, and they're limitedyou get only 100 access lists of each type. While this should be plenty, it's strange to have this kind of limitation built into such a critical mechanism. (The most recent versions of IOS have added some additional blocks of numbers for standard and extended IP access lists, but numbers are still awkward, and the more you use, the more inconvenient they are.)
IOS 11.2 and later allow you to dispense with numbers and give access lists logical names. To create a simple access list named simplelist, use the command:
ip access-list standard simplelist
To create an extended list named inboundfilter, use the command:
ip access-list extended inboundfilter
Follow the ip access-list command with the rules that make up the list, omitting everything up to and including the number. For example, here's a standard list named filter1:
ip access-list standard filter1 permit 10.10.1.0 0.0.0.255 deny 10.10.0.0 0.0.255.255 permit any
If you're typing access lists at the command line, named access lists give you yet another prompt to worry about. Here's how we'd type the preceding list in a console session:
Router(config)#ip access-list standard filter1 Router(config-std-nacl)#permit 10.10.1.0 0.0.0.255 Router(config-std-nacl)#deny 10.10.0.0 0.0.255.255 Router(config-std-nacl)#permit any any
To apply a named access list to an interface, use the access-group command as shown in the previous section, but specify the list's name instead of its number:
interface serial 1 ip access-group filter1 in
Besides being more descriptive, named access lists have another advantage: you can edit them much more conveniently. That is, you can delete a line from within the access list; you don't have to delete the entire access list and re-enter it, as you do with numbered access lists. The following commands modify the filter1 list defined earlier:
Router(config)#ip access-list standard filter1 Router(config-std-nacl)#no permit 10.10.1.0 0.0.0.255 Router(config-std-nacl)#exit Router#show access-list filter1 ip access-list standard filter1 deny 10.10.0.0 0.0.255.255 permit any any
As you can see, the no command didn't erase the entire access list. Instead, it removed only the line we didn't want. However, the editing capabilities aren't perfect. Access lists are still additive; any new rules you add to filter1 will be added to the end. There's no way to modify a rule that's in the list. Therefore, you still must be careful when constructing your lists.
|
7.2.2.1. Entering noncontiguous ports
As of IOS 12.4, you are allowed to enter noncontiguous ports on a single line within a named access list. Why is this a big deal? Before, you would write such an access list like this:
ip access-list extended acllist1 permit tcp any host 192.168.1.1 eq telnet permit tcp any host 192.168.1.1 eq www permit tcp any host 192.168.1.1 eq smtp permit tcp any host 192.168.1.1 eq pop3
With noncontiguous port support, you can write it much more compactly, like this:
ip access-list extended acllist1 permit tcp any host 192.168.1.1 eq telnet www smtp pop3
7.2.3. Reflexive Access Lists
Reflexive access lists are an important tool that was added in IOS 11.3. They allow you to create lists that dynamically change based on what services your users need. Basically, you create an inbound and an outbound access list. The outbound access list creates entries in a temporary access list. This temporary access list is "evaluated" by the inbound access list. To put it another way, packets going out the interface create temporary entries to allow packets of the same session back in. When an outbound session ends, the temporary entries are destroyed, which closes the hole in the inbound access list.
Reflexive lists are similar to extended TCP access lists with the established keyword in that you will usually use reflexive lists to allow communications that have been initiated by your users. As I explained earlier, established connections rely on two bits (ACK and RST) being set in the incoming packet. While the established keyword works, it presents two problems. First, someone attempting to crack your site can exploit the established assumption by illegitimately setting the ACK and RST bits in a packet that doesn't belong to an established session, tricking the router into thinking the packet is legitimate. Second, the system is always open for attacks, even if no outbound sessions are in progress. With reflexive lists, however, we open the entry in the inbound access list only for valid current sessions.
The outbound reflexive list doesn't actually do any filtering, but rather detects attempts to initiate a TCP session. When a new session is started, an entry is automatically entered in the corresponding inbound list, allowing only the traffic belonging to that session. If that session is idle for a certain amount of time (by default, 300 seconds), the automatically generated entry expires, and traffic from the session is no longer allowed.
7.2.3.1. Creating the outbound reflexive list
The outbound reflexive list doesn't do any filtering; it simply provides a mechanism for generating the corresponding inbound list. The key to the outbound list is the reflect command, which watches for attempts to initiate TCP sessions and adds those sessions to the temporary list. Here's a simple list named outlist; the temporary list we're building is called tmplist:
ip access-list extended outlist ! Allow everything and add it to the reflexive list called tmplist permit tcp any any reflect tmplist
All traffic automatically matches this list and is passed through the interface. All outbound traffic will create an entry in the temporary list called tmplist.
7.2.3.2. Creating the inbound reflexive list
Now we need to create an inbound list that evaluates tmplist. To do so, we create a list named inlist that uses those temporary entries, and we add it to our configuration. This list is processed in order, just like any other access list, which means you can use deny and permit rules as in any other inbound list. In this example, we allow incoming access to our web server, plus any traffic that has been added to tmplist. All other traffic is denied.
ip access-list extended inlist ! allow tcp to our web server permit tcp any host 192.168.1.1 eq www ! evaluate our temporary reflexive list evaluate tmplist ! deny everything else deny ip any any
An entry can be in the tmplist only if it corresponds to a session that was initiated from within our internal network.
7.2.3.3. Applying the inbound and outbound reflexive lists to an interface
To apply the reflexive list to an interface, we just apply the outbound list and the inbound list in the appropriate directions:
interface serial0 description Internet Gateway interface ip access-group inlist in ip access-group outlist out
Now we do a show access-list. The tmplist will appear with all the temporary entries that are currently in the list. If there are no temporary entries, the list will be blank.
Router1#show access-list Extended IP access list inlist permit tcp any host 192.168.1.1 eq www evaluate tmplist deny ip any any Extended IP access list outlist permit tcp any any reflect tmplist Reflexive IP access list tmplist
7.2.3.4. Setting the reflexive timeout
By default, entries in the reflexive list time out after 300 seconds with no traffic; that is, if the session is idle for 300 seconds, the reflexive entry will be removed from the temporary list. If the session was not complete, it will need to be restarted. Five minutes is a long time for a connection to be idle, so let's reduce this to 200 seconds:
ip reflexive-list timeout 200
7.2.3.5. Reflexive list notes
Here are a few things you should keep in mind when you use reflexive lists:
Getting Started
IOS Images and Configuration Files
Basic Router Configuration
Line Commands
Interface Commands
Networking Technologies
Access Lists
IP Routing Topics
Interior Routing Protocols
Border Gateway Protocol
Quality of Service
Dial-on-Demand Routing
Specialized Networking Topics
Switches and VLANs
Router Security
Troubleshooting and Logging
Quick Reference
Appendix A Network Basics
Index