Lecture #5 - Access Lists

Applications include:

• Filtering packets entering or leaving an interface.
• Filtering routing information entering or leaving an interface.
• Identifying packets for Name Address Translation (NAT).
• Identifing packets for encapsulation and encryption.
• Identifing packets that are to be provided with Quality of Service (QoS).
• Implementation of BGP policy via route maps (see later lectures).

In this lecture we primarily examine the use of access lists for filtering data traffic, however the same basic principles apply for other applications.

Matching Criteria

The matching criteria may include:

• Source IP address
• Destination IP address
• Source protocol number
• Destination protocol number
• Source port number
• Destination port number

The source wildcard mask (0.0.0.0) tells the router which parts of the IP address must match and which bits do not matter. A mask of 0.0.0.0 may be omitted as this is the default assumed by the router. Otherwise the host keyword may be used for clarity:

R4#configure terminal
R4(config)#access-list 1 permit host 149.144.20.200
R4(config)#

The wildcard mask is interpreted as a string of 32 bits, a "0" bit means that the corresponding bit of the IP address must match for the filter to apply. A "1" means that this bit does not have to match. This is effectively the inverse of a traditional netmask.

For example the following filter permits packets from any address in the 149.144.20.0/24 network:

R4(config)#access-list 1 permit 149.144.20.0 0.0.0.255

Applying the Access List to an Interface

An access list on its own does nothing - for it to be of use packets must be sent to it by a calling command. Here is how the access list would be applied to packets entering the router via the Ethernet0/0 interface:

R4#configure terminal
R4(config)#interface Ethernet0/0
R4(config-if)#ip access-group 1 in

To filter outgoing packets:

R4#configure terminal
R4(config)#interface Ethernet0/0
R4(config-if)#ip access-group 1 out

To remove a previously applied access group simply add the no keyword:

R4#configure terminal
R4(config)#interface Ethernet0/0
R4(config-if)#no ip access-group 1 out

Note: You need to understand where the routing protocol is directing the traffic in order to select the correct interface to apply the access list.

Editing Access Lists

There are a few things to be aware of when working with access lists. Firstly, editing is difficult and removing a single filter from an access list can be challenging. For example, the following may not achieve the result you intend:

R4(config)#no access-list 1 permit 149.144.21.0 0.0.0.255

The router will only see the "no access-list 1" part of the command and will remove the entire access list, instead of the single filter. Also, the access-list command always appends to the end of the list. As a result, it is far easier to edit your access lists in a text file (start with a no access-list command at the top) and simply download the commands to the router.

It is worth noting that newer IOS versions assign a sequence number to each filter and allow you to delete a single filter, or insert a filter into an arbitrary location within a list. Another configuration mode is also available via the ip access-list command. This allows for more finegrained editing and more terse commands.

For example to block traffic between the 149.144.21.0/24 and 149.144.20.0/24 networks, one could use (wrapped for readability):

R4#configure terminal
R4(config)#access-list 100 deny ip
             149.144.21.0 0.0.0.255 149.144.20.0 0.0.0.255
R4(config)#access-list 100 permit ip
             0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

Note the use of the ip keyword to permit all encapsulated protocols. Also, the any keyword could be used in place of the IP address of 0.0.0.0 and wildcard mask of 255.255.255.255. Exercise: Why is the permit rule necessary?

For example to block web traffic from anywhere to the 123.100.20.0/24 network, entering via interface Ethernet0/0, you could use:

R4#configure terminal
R4(config)#access-list 105 deny tcp any 123.100.20.0 0.0.0.255 eq www
R4(config)#access-list 105 permit tcp any any
R4(config)#interface Ethernet0/0
R4(config-if)#ip access-group 105 in
R4(config-if)#^Z
R4#

Or better yet, block all traffic and only allow web traffic to 149.144.20.200:

R4#configure terminal
R4(config)#access-list 106 permit tcp any host 149.144.20.200 eq www
R4(config)#access-list 106 deny tcp any any
R4(config)#interface Ethernet0/0
R4(config-if)#ip access-group 106 in
R4(config-if)#^Z
R4#

Note the use of a redundant (but more readable) deny tcp any any filter.

Named Access Lists

Rather than using numbers to identify access lists, IOS version 11.2 onwards allows the use of named access lists. This allows a descriptive name to be associated with your access list. These are accessed via the ip access-list command - the permit and deny filters now become shorter statements, much like configuring an interface.

For example:

ip access-list standard students
  permit 149.144.21.0 0.0.0.255
  deny 0.0.0.0 255.255.255.255

Or:

ip access-list extended webserver
  permit tcp any host 149.144.20.200 eq www
  deny tcp any any

These can then be assigned to an interface via name:

R4(config)#interface Ethernet0/0
R4(config-if)#ip access-group webserver in

Adding Comments to an Access List

Clearly documenting your ACLs will assist in future maintenance and will make life easier when multiple people are managing the list. The remark keyword can be used for this purpose:

access-list 1 remark Don't allow access from the student network!
access-list 1 deny 149.144.21.0 0.0.0.255
access-list 1 remark Allow from all other subnets
access-list 1 permit 149.144.0.0 0.0.255.255

Filtering on Interfaces

It is important to understand how and when access lists are processed when applied to an interface. This has implications for both security and performance.

In most cases outbound filtering is more efficient than inbound filtering. This is probably counterintuitive since one would assume that inbound filtering would reduce routing overhead. Whilst this is partially true, inbound filtering prevents routing caches and fast-switching paths from being used, resulting in a much slower routing process after the access list has been applied.

However, this may mean that outbound filtering is necessary on several interfaces, rather than inbound filtering on a single interface.

Viewing and Monitoring Access Lists

Thus far we have looked at creating access lists, however it is also necessary to be able to view and monitor them.

The show ip access-list command will display currently configured access-lists:

R4#show ip access-list
Standard IP access list 1
    permit 149.144.20.0, wildcard bits 0.0.0.255
Extended IP access list 106
    permit tcp any host 149.144.20.200 eq www
    deny   tcp any any

Or it can be used to display a single access list:

R4#show ip access-list 1
Standard IP access list 1
    permit 149.144.20.0, wildcard bits 0.0.0.255

The number of packets that are being denied by access lists can be viewed using the show ip accounting access-violations command.

Updating Lists in a Production Environment

When updating/changing access lists on a Cisco router, you need to remember that all of your changes (and mistakes) are going to go into immediate operation. This may result in traffic being blocked that should not be, or vice versa. Neither is a good result!

One trick that can be beneficial here is to create and edit a new access list that will be used to replace the existing list. For example, let us assume that access list 105 is currently used to filter traffic that is outgoing on Ethernet0/0.

As the network administrator you can now create and debug a new access list, say 106. Once you have completed your changes you can readily swap the access lists over (each interface can only have one access list for inbound traffic and one access list for outbound traffic). If you need to revert your changes you can simply change the access group back to the original access list. The original list can be removed when it is no longer required.

References

Configuring IP Access Lists