Types of Access Lists

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.

Table 7-3. Access list numbers

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.

Most commands that require an access list as an argument will take either a numbered or a named list. Some won't. Cisco is gradually fixing this problem by converting all commands to accept either a name or a number.

 

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:

  • Reflexive lists are designed for use on gateway routers (routers that connect you to the Internet, to a shared backbone, or to another company or organization).
  • The reflect keyword, which establishes a reflexive list, can be used only on permit statements.
  • Entries in reflexive lists automatically expire after a certain idle period, even if the session is not complete.
  • Entries are removed from the temporary list when the session is complete.
  • The outgoing IP addresses/ports and incoming IP addresses/ports will be "swapped" in the temporary lists.
  • Reflexive lists do not work on protocols such as FTP in which the incoming port does not match the outgoing port. To get FTP to work, perform the steps outlined later in "Permitting FTP through an access list."




Cisco IOS in a Nutshell
Cisco IOS in a Nutshell (In a Nutshell (OReilly))
ISBN: 0596008694
EAN: 2147483647
Year: 2006
Pages: 1031
Authors: James Boney
Simiral book on Amazon

Flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net