When it comes to filtering traffic from the network, one of the most effective techniques is to actually nip that traffic in the bud at the network devices. This way, you can limit the amount of bandwidth wasted on inappropriate traffic, whether it traverses a limited-resource WAN link or an internal, high-speed LAN link. Oftentimes, the use of filters only arises when some specific form of unapproved, nonsecure, or otherwise problematic traffic comes to the attention of the networking staff.

In modern IT shops with limited resources, the immediate solution is all too often a hastily implemented basic access control list that may only address the problem within a somewhat narrow focus. In our haste to block this unwanted traffic, there isn’t always time to consider how to do so most effectively. And later, when the phone stops ringing and things slow down, it’s not uncommon to wonder whether there wasn’t some better way. We may ask ourselves what impact this basic solution could have on the network and how it could be optimized. Generally speaking, we can find more effective methods of filtering traffic by taking into consideration some features and concepts that go beyond the basic access list options. We can implement these enhanced methods of filtering traffic by gaining a deeper understanding of the parameters available, the default values, and some of the related concepts that can affect how and when we use them. At another level, some of these ideas simply make our lives easier by abbreviating or making the access list more readable.

In this Daily Drill Down, we’ll take a closer look at the structure of the access list statement. See this sidebar for the standard IP extended access list from IOS 12.0. Keep in mind that bold face denotes a keyword, italics represent fill-in parameters, statements in square brackets are optional, and curly brackets denote necessary values.


The port parameter

The port parameter is relevant to UDP and TCP protocols specifically. The established keyword is for use with TCP only. There are other parameters for specific use with ICMP and other protocols.

Interpreting access lists
It’s generally a good idea to use the complete syntax for an access list to provide greater readability. You can also document your list using descriptive comment lines in your router config file. These lines start with an exclamation point and are ignored by the router. Although it’s a good idea to briefly comment an access list, I don’t recommend too much verbosity, as it will increase the size of your router config file. Let’s consider some of the extended list parameters, along with common variations in syntax forms and abbreviations and how we can use them. Take the following statements, for instance:

The source in this statement ( could also have been represented with the ANY keyword. You will often see statements specifying ANY ANY for source and destinations, which means from all hosts and networks to all hosts and networks. Another thing to think about when deciphering the meaning of an access list is standard defaults. Consider this statement, which applies list 101 to a router interface:
ip access-group 101

What we don’t know by looking at this statement is what direction it is applied to; or do we? By default, all access lists are applied in an outbound direction.

There are a few other details that we need to think about as we deal with access lists. The first is the implicit deny all at the end of the access list. The tricky thing here is that when you view your router config, it doesn’t show up. Rest assured that the implicit denial is there and that any traffic you don’t specifically permit will be dropped. This is true unless you null the denial by placing a statement in your list to allow all traffic. If you do so, this allow statement will be matched against your traffic first, allowing it to pass. Another thing to keep in mind is that an access list requires at least one Permit statement in order to be functional. As far as the command-line interface (CLI) goes, access lists are created at the global config mode and applied at the interface config mode.

Application filtering
You can filter specific applications by specifying their port number or range. You can also filter all traffic by specifying IP as the protocol parameter in your access list. Since this does restrict the entire TCP/IP protocol suite, you’ll want to exercise caution with a statement like this. A nice option with the syntax in extended access lists is that you can use the actual application name, as opposed to the number. This feature makes your access lists much more readable. Something to remember is that some of these filters can easily be circumvented. Let’s take telnet, for instance. You can add a statement to your extended access list to block it on the standard telnet port, 23. But what is to prevent a host from telneting on another port? You’ll need to keep this in mind when designing your filters. Another thing to consider when filtering is that some applications may use multiple ports. Filtering FTP, for instance, would require you to block the FTP port, 20, as well as the FTP data port, 21. Let’s try it.

Taking things a step further, if you’ve got several ports used at random by a custom application, you can employ the port range operator.

This statement will allow all custom ports from 1024 to1336.

At this point, let’s look at a few of the optional parameters, starting with established. The established keyword is only relevant to the TCP protocol. It specifies that the packet must be part of an established connection. In other words, the packet can’t be attempting to start a new connection. Consider this example.

This statement will allow all previously set up sessions from any source to the network.

Another optional parameter of interest is the log parameter. When included, it causes informational messages about packets that match an entry to be sent to the console. You would use this in conjunction with the logging console command to specify the level of messages sent to the console.

This statement will cause all attempts for SMTP to be logged on the router. This logged information can be used to determine whether an access list is filtering the intended traffic. Be careful when using this feature, as it does add overhead to your router CPU.

Activating lists
Up to this point, we’ve considered the actual statements (and the extended options) that we use to filter traffic on the network. But until we activate the list, no filtering occurs.

To activate it, we use the access-group command at the interface config mode of the target interface. Following is the syntax.
ip access-group {access-list-number | name} {in | out}

As soon as you enter this command, the access list will immediately take effect. It’s wise to initiate a ping or some other form of continuous traffic in a different terminal session to a destination host on the other side of the interface that you’re filtering. This will allow you to monitor its accessibility when activating an access list. Beforehand, you’ll need to allow telnet access in your list if the interface you’re applying it to is the one you use to access a remote router. Otherwise, you can cut off your configuration session with the router.

Performance issues
Performance problems and network bottlenecks can be avoided if you keep in mind several issues pertinent to performance. Placement within your network and the relative sequence of statements can all have a considerable impact.

Let’s look first at where we might want to apply our filters. The general rule with extended access lists is to apply them as close as possible to the source of the traffic. The reasoning behind this is that it is better to remove the packets from the network as soon as possible, thereby freeing up network resources down the line. Also, the speed of a network link, traffic patterns, and the router’s processor can also be at issue.

To illustrate this logic, we’ll use a hub and spoke network with the hub router located at a central office and the spokes at satellite offices. There are several serial ports on the central router, and each is connected via a 56K leased line to one of the remote offices. There are several, centralized applications that the remote offices must access over these WAN links from the central office. The company also has a policy regarding inappropriate internal network traffic. So, where do we filter the traffic?

We could easily create one access list on the outbound interface of the central router and be done with it. Unfortunately, that doesn’t really address our problem since it only filters the traffic leaving the central router, not the internal traffic. What if we apply our access list to each incoming serial interface on the central router? It’s better than the first option, since it will keep the unapproved traffic from entering the central network, but it still isn’t the best way to go. Additionally, what if we consider the speed of the WAN links and the traffic patterns? Since the remote offices are accessing applications across these pipes (and they aren’t very wide), wouldn’t it be better to filter unapproved traffic at the remote office router? If we do, we’ll free up bandwidth for application access and distribute the burden of processing these packets across all of the spoke routers, rather than taxing the central router by filtering all traffic on its multiple serial interfaces. In so doing, we would be placing our extended access lists as close as possible to the source, as the rule prescribes.

However, the rules about placement are not hard and fast. The specific circumstances need to be weighed when determining where best to filter network traffic. That said, we’ll look at another scenario where the rules need to be tempered with a little common sense. Let’s use an Internet border router connected to a few small networks as an example. It is configured with a serial interface, S0, to the ISP and several Ethernet interfaces connected to internal networks. For outbound filtering, you could apply the list only on the one outgoing serial interface rather than inbound on each of the internal Ethernet interfaces. This would improve performance because you would be forcing outbound packet lookups only once at S0, rather than performing inbound lookups at each LAN interface. We may not be filtering as close to the source as possible, but this may be a better way to go under these circumstances.

In some cases, you may want to consider filtering just routers at the edge of the network. You will likely have higher traffic at the network core, and an access list here could create a serious bottleneck. It is recommended that an overall security policy be formulated and used in conjunction with standard methods to arrive at an appropriate and sensible configuration for your network needs.

The logging option can also cause an undue strain on router resources. You’ll always want to check utilization after applying an access list with the log option. Another thing to consider is that the longer your access list, the more work your router will have to do with every packet received. You should try to place statements most likely to match packets at the top of your list. These would generally be the most specific of your filter statements. As you travel down the list in sequence, the more general filter statements would likely match less traffic. In short, access lists do have a certain processing overhead, and you should be watchful about the burden on the router’s main CPU. You can check the router’s CPU utilization using the following command:
show process CPU

Look out for high CPU utilization. Also, problems may manifest themselves as packets dropped at the interface to which the list has been applied. You may want to consider baselining a router before applying an access list so that you will have some relative frame of reference for performance comparisons.

You can check the interface using the following command:
show ip int e0

This command will show the status of the Ethernet 0 interface.

It may be easy to implement a quickly contrived, basic access list in a high priority situation. But with the rich feature options and granular control provided by extended lists, you may want to look here for a better solution to your traffic filtering needs. We’ve only scratched the surface of the features and options available. However, the features we have mentioned, applied with sound design principles, will get you well on your way to enhancing throughput and security on your network.

Editorial disclaimer

The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.