An Access list is essentially a list of conditions that categorize packets. They can really help when you need to exercise control over network traffic. An access list would be your tool of choice for decision making in these situations.
One of the most common and easiest to understand uses of access lists is filtering unwanted packets when implementing security policies. For example, you can set them up to make very specific decisions about regulating traffic patterns so that they’ll allow only certain hosts to access web resources on the internet while restricting others. With the right combination of access lists, network managers arm themselves with the power to enforce nearly any security policy they can invent.
Access lists can even be used in situations that don’t necessarily involve blocking packets. For example, you can use them to control which networks will or not be advertised by dynamic routing protocols. How you configure the access list is the same. The difference here is simply how you apply it to a routing protocol instead of an interface. When you apply an access list in this way, it’s called a distribute-list, and it does not stop routing advertisements, it just controls their content. You can also use access lists to categorize packets for queuing or QoS-type services and for controlling which types of traffic can activate a pricey ISDN link.
Creating access lists is really a lot like programming a series of if-then statements if a given condition is met, then a given action is taken. If the specific condition isn’t met, nothing happens and the next statement is evaluated. Access-list statements are basically packet filters that packets are compared against, categorized by, and acted upon accordingly. Once the lists are built, they can be applied to either inbound traffic on any interface. Applying an access list causes the router to analyze every packet crossing that interface in the specified direction and take the appropriate action.
There are a few important rules that a packet follows when it’s being compared with an access list:
- It’s always compared with each line of the access list in sequential order that is, it’ll always start with the first line of the access list, then go to line 2, then line 3, and so on.
- It’s compared with lines of the access list only until a match is made. Once the packet matches the condition on a line of the access list, the packet is acted upon and no further comparison takes place.
- There is an implicit deny at the end of each access list this means that if a packet doesn’t match the condition on any of the lines in the access list, the packet will be discarded.
Each of the rules has some powerful implications when filtering IP packets with access lists, so keep in mind that creating effective access lists truly takes some practice.
There are two main types of access lists:
Standard Access Lists: These use only the source IP address in an IP packet as the condition test. All decisions are made based on the source IP address. This means that standard access lists basically permit or deny an entire suite of protocols. They don’t distinguish between any of the many types of IP traffic such as web, Telnet, UDP, and so on.
Extended Access Lists: Extended access lists can evaluate many of the other fields in the layer 3 and layer 4 headers of an IP packet. They can evaluate the source and destination IP addresses, the protocol field in the Network layer header, and the port number at the Transport layer header. This gives extended access lists the ability to make much more granular decisions when controlling traffic.
Named Access Lists: hey, wait a minute, we said there are two types of access lists but listed three! Well, technically there really are only two since named access lists are either standard or extended and not actually a new type. We are just distinguishing them because they’re created and referred to differently than standard and extended access lists, but they’re functionally the same.
Once you create an access list, it’s not really going to do anything until you apply to it. Yes, they’re there are on the router, but they’re inactive until you tell that router what to do with them.
To use an access list as a packet filter, you need to apply it to an interface on the router where you want the traffic filtered. And you’ve got to specify which direction of traffic you want the access list applied to. There’s a good reason for this you may want different controls in place for traffic leaving your enterprise destined for the internet than you’d want for traffic coming into your enterprise from the Internet. So, by specifying the direction of traffic, you can and frequently you’ll need to use different access lists for inbound and outbound traffic on a single interface.
Inbound Access Lists: when an access list is applied to inbound packets on an interface, those packets are processed through the access list before being routed to the outbound interface. Any packets that are denied won’t be routed because they’re discarded before the routing process is invoked.
Outbound Access Lists: when an access list is applied to outbound packets on an interface, those packets are routed to the outbound interface and then processed through the access list before being queued.
There are some general access-list guidelines that should be followed when you’re creating and implementing access lists on a router:
- You can assign only one access list per interface per protocol per direction. This means that when creating IP access lists, you can have only one inbound access list and one outbound access list per interface.
- Organize your access lists so that the more specific tests are at the top of the access list.
- Any time a new entry is added to the access list, it will be placed at the bottom of the list. Using a text editor for access lists is highly suggested.
- You cannot remove one line from an access list. If you try to do this, you will remove the entire list. It is best to copy the access list to a text editor before trying to edit the list. The only exception is when using named access lists.
- Unless your access list ends with a permit any command, all packets will be discarded if they do not meet any of the list’s tests. Every list should have at least one permit statement or it will deny all traffic.
- Create access lists and then apply them to an interface. Any access list applied to an interface without an access list present will not filter traffic.
- Access lists are designed to filter traffic going through the router. They will not filter traffic that has originated from the router.
- Place IP standard access lists as close to the destination as possible. This is the reason we don’t really want to use standard access lists in our networks. You cannot put a standard access list close to the source host or network because you can only filter based on the source address and nothing would be forwarded.
- Place IP extended access lists as close to the source as possible. Since extended access lists can filter on very specific addresses and protocols, you don’t want your traffic to traverse the entire network and then be denied. By placing this list as close to the source address as possible, you can filter traffic before it uses up your precious bandwidth.
Before we move on to how to configure basic and advanced access lists, let’s discuss how ACLs can be used to mitigate the security threats we discussed earlier in this article.
Mitigating security Issues with ACLs
Here is a list of the many security threats you can mitigate with ACLs:
- IP address spoofing, inbound
- IP address spoofing, outbound
- Denial of service (DoS) TCP SYN attacks, blocking external attacks
- DoS TCP SYN attacks, using TCP intercept
- DoS smurf attacks
- Filtering ICMP message, inbound
- Filtering ICMP message, outbound
- Filtering traceroute
It’s generally wise not to allow into a private network any IP packets that contain the source address of any internal hosts or networks just don’t do it!
Here’s a list of rules to live by when configuring ACLs from the Internet to your production network to mitigate security problems:
- Deny any addresses from your internal networks.
- Deny any localhost addresses (127.0.0.0/8).
- Deny any reserved private addresses.
- Deny any addresses in the IP multicast address range (22.214.171.124/24).
None of the above addresses should be allowed to enter your internetwork. Okay, finally, let’s get to work on configuring some basic and advanced access lists.