Using ACLs to Construct Static Packet Filters

Access control lists (ACL) can be used to provide basic traffic filtering capabilities on Cisco routers. ACLs can be configured for all routed network protocols to filter packets as they pass through a router or security appliance. There are a number of reasons why you might configure these. For instance, you might want to use an ACL to restrict the contents of routing updates or to provide traffic flow control. Perhaps the most important reason to configure ACLs is to provide security for your network, and that is what you will consider in this section. This section describes the different types of ACLs that are available and gives you guidelines to help you better create ACLs to provide network security.

The Basics of ACLs

An ACL may be used for packet filtering (a type of firewall), as well as for selecting types of traffic to be analyzed, forwarded, or influenced in some manner. It is because of this flexibility that the ACL is one of the most commonly used objects in Cisco IOS software.

Now that you understand the flexibility and the power of an ACL, let's consider its makeup. An ACL is a group of statements wherein each statement defines a pattern in an IP packet or UDP/TCP packet. If it is an extended ACL, you can include the port number and established bit if you like. As packets pass through an interface where an ACL has been associated, the router scans the list from top to bottom in the exact order in which it appears, looking for a pattern that matches the incoming packet. Each pattern has an associated permit or deny rule that determines whether the packet is allowed or denied entry to the network.

ACLs are used as packet filters to determine which packets can access a router service or cross an interface. Packets that are allowed across an interface are called "permitted" packets. Those that are not allowed across an interface are called "denied" packets.

You may use an ACL to enforce one or more of your corporate security policies. For instance, you might have a corporate security policy that states that you may allow packets only using source addresses from within the trusted network to access the Internet. With a written security policy such as this, you can develop an ACL that includes certain statements that, when applied to a router interface, can enforce this corporate security policy.

Well-written ACLs are central to Cisco router security. They are used to restrict access to router network services and to filter packets as they pass through the router.

Cisco routers support two types of ACLs—standard IP ACLs and extended IP ACLs:

Standard ACLs allow you to permit or deny traffic from only specific IP addresses. With these ACLs, the destination of the packet and the ports involved are not taken into account. In the following example, this ACL allows traffic from all addresses in the range to

Key Topic access-list 10 permit

■ Extended ACLs are made up of a series of statements created in global mode. With extended ACLs you can filter IP packets based on a number of attributes. Extended ACLs can filter packets according to protocol type, source and IP address, destination IP address, source TCP or UDP ports, destination TCP or UDP ports, and optional protocol type information if you require finer granularity of control. The following example shows ACL 101, which has been configured to permit traffic originating from any address on the network to any destination host port 80 (HTTP):

access-list 101 permit tcp any eq 80

Cisco ACL Configuration

In versions of the Cisco IOS before Release 11.2, a number had to be assigned to each ACL when it was created. Since this release, you may now use either a number or a name to identify Cisco ACLs and the protocols that they are being used to filter.

Numbered ACLs can be effective when working with smaller networks with more homogeneously defined traffic. Each ACL type is limited to an assigned range of numbers, so it is easy to determine the type of ACL that you are using. There can be up to 99 standard IP ACLs, numbered from 1 to 99. Additionally, the expanded range for standard ACLs range from 1300 to 1999. Extended IP ACLs may range from 100 to 199, with an expanded range from 2000 to 2699. Table 10-9 lists the number ranges and the types of associated ACL.

Table 10-9 ACL Numbers and Types

Table 10-9 ACL Numbers and Types

ACL Number Range


1 to 99

IP standard ACL

100 to 199

IP extended ACL

200 to 299

Protocol type code ACL

300 to 399

DECnet (developed by Digital Equipment Corporation) ACL

400 to 499

Xerox Network Systems (XNS) standard ACL

500 to 599

XNS extended ACL

600 to 699

AppleTalk ACL

700 to 799

48-bit MAC address ACL

800 to 899

Internetwork Packet Exchange (IPX) standard ACL

900 to 999

IPX extended ACL

1000 to 1099

IPX Service Advertisement Protocol (SAP) ACL

1100 to 1199

Extended 48-bit MAC address ACL

1200 to 1299

IPX summary address ACL

1300 to 1999

IP standard ACL (expanded range)

2000 to 2699

IP extended ACL (expanded range)

As mentioned, with Cisco IOS Release 11.2, you can now identify ACLs with a name rather than a number. If you're working with a release earlier than IOS 11.2, it will not recognize named ACLs. Named ACLs give you greater flexibility and allow you to configure more ACLs in a router than you could with numbered ACLs. Note, however, that if you identify your ACL with a name instead of a number, the mode and command syntax you will use are different. Also be aware that for now, only packet and route filters can use a named list.

Working with Turbo ACLs

As discussed earlier, routers work with ACLs by searching the ACL sequentially, looking for a matching rule. However, because of increasing needs and requirements for security filtering, along with packet classification, ACLs are getting longer and longer. ACLs can expand to the point that searching them can require a significant amount of time and can impact the memory used when the router is forwarding packets. Another issue is that the time it takes the router to search the list is not always consistent. Unfortunately, this adds variable latency to the packet forwarding. ACLs with several entries can impact your router, causing a high CPU load as well.

The Cisco 7200 series, Cisco 7500 series, and Cisco 12000 series routers support the Turbo ACL feature, which processes ACLs into lookup tables for greater efficiency. Turbo ACLs use the packet header to access these tables in a small, fixed number of lookups, independent of the existing number of ACL entries. The Turbo ACL feature has a number of benefits:

■ For ACLs with more than three entries, the CPU load is lower when matching the packet to the predetermined packet matching. The Turbo ACL feature fixes the CPU load, regardless of the size of the ACL, allowing the use of larger ACLs without adding CPU overhead.

■ The Turbo ACL feature leads to much reduced latency because the time it takes to match the packet is fixed. More importantly, the time taken to match is consistent, allowing for better network stability and more accurate transit times.

Figure 10-15 shows a sample topology with Turbo ACLs.

Figure 10-15 Turbo ACLs e0/0

Remote Access LAN

If the routers you are working with support Turbo ACLs, you should use the access-list compiled command in global configuration mode whenever you develop ACLs with more than three statements. This command supports no keywords or arguments.

If you want to view the status of your Turbo ACLs, you may use the show access-list compiled command in privileged EXEC mode. This command does not support any keywords or arguments.

R2(config)# access-list compiled

R2(config)# exit

R2# show access-list compiled

Developing ACLs

You must consider a number of things before you begin developing any ACLs. Table 10-10 summarizes some of the key considerations.

Table 10-10 Guidelines for Developing ACLs



Create ACLs based on your security policy

The ACLs you create should be based on a comprehensive security policy so that you can be sure that they will control access in the way that you intended.

Write out your ACLs

Always map out your ACLs in writing before sitting down at a router to implement them. It is a best practice to write out a list of things that you want the ACL to accomplish before you begin. You can begin with a simple statement such as this:

"This ACL must block all Internet Control Message Protocol (ICMP) traffic to the router except for traffic from the host at"

Set up a development system

Develop and store your ACLs on a specific secured machine. You can use any word processor or text editor you like, so long as you can save the files in ASCII text format.

It is a good idea to create a library of commonly used ACLs and use them as a source when creating new files.

After they are developed, your ACLs can be pasted into the router running configuration, or they may be stored in a router configuration file. Whatever system you choose should support TFTP to make it possible for you to transfer any resulting configuration files to the router.

Test your ACLs

Whenever possible, be sure to test your ACLs in a secure environment before putting them onto a production router. Some organizations might view testing as an unnecessary cost, but over time it can save both time and money.

Using the CLI to Apply ACLs to the Router Interface

For the ACL to take effect, you must first apply packet-filtering ACLs to a router interface. These ACLs are applied based on the direction of the data flow.

Figure 10-16 shows the directional nature of ACL application to router interfaces. The ACL may be applied to either incoming packets (an "in ACL") or outgoing packets (an "out ACL"):

■ Inbound (in): Applies to packets received on the router interface.

■ Outbound (out): Applies to packets transmitted outbound on the router interface. When configuring out ACLs, you set up the filter only on the one outgoing interface instead of on each individual incoming interface.

Figure 10-16 Applying ACLs to Router Interfaces

Figure 10-16 Applying ACLs to Router Interfaces

• Inbound ("in ACL"): Data flows toward the router interface.

• Outbound ("out ACL"): Data flows away from the router interface.

• Inbound ("in ACL"): Data flows toward the router interface.

• Outbound ("out ACL"): Data flows away from the router interface.

One of the more challenging aspects of applying an ACL is making sure that it is applied in the right direction. Before you apply a packet-filtering ACL to a router interface, be sure that you understand in which direction it will filter.

To apply an ACL to a router's interface, use the ip access-group command in interface configuration mode:

ip access-group {access-list-number | access-list-name} {in | out}

Table 10-11 describes this syntax.

Table 10-11 ip access-group Command Syntax

\ Topic flnmmflnrl Flpmpnt Dp^rrintinn

Considerations When Creating ACLs

Table 10-12 describes some of the caveats that you need to consider when creating ACLs.

Table 10-12 Caveats to Consider When Creating ACLs

\ Topic non«iHpr»tinn DoQnri nt inn ip access-group Command Syntax

Table 10-11 ip access-group Command Syntax

\ Topic

Command Element



The number of the IP standard numbered or IP extended numbered ACL. This is a decimal number from 1 to 199 or from 1300 to 2699.


The name of the IP standard named or IP extended named ACL as specified in the ip access-list command.


Used to filter on inbound (flowing toward the router interface) packets.


Used to filter on outbound (flowing away from the router interface) packets.

Caveats to Consider When Creating ACLs

Table 10-12 Caveats to Consider When Creating ACLs

\ Topic



Implicit deny all

Each Cisco ACL ends with an implicit deny all statement. Although you may not actually see this statement in your ACLs, it is there.

Standard ACL limitation

Standard ACLs are limited to packet filtering on source addresses only. Creating extended ACLs may be necessary to implement your various security policies.

Standard evaluation order

ACL statements are evaluated sequentially, starting with the first entry in the list. Therefore, it is very important to consider the order in which you place statements in your ACLs.

Order of specific statements

Place more-specific ACL statements higher in the ACL. Be careful that statements at the top of the ACL do not negate any statements found lower in the list.

Directional filtering

A directional filter on the Cisco ACLs determines whether they examine inbound packets (toward the interface) or outbound packets (away from the interface). Be sure to double-check the direction of data that your ACL is filtering.

Modifying numbered ACLs

On Cisco IOS Release 12.2 and earlier, append any new statements you want to add to an existing ACL to the bottom of the ACL. Because ACLs use a top-down statement evaluation order, new entries may render the ACL unusable. Should a new statement render the ACL unusable, create a new ACL with the correct statement order. Next, delete the old ACL and assign the new ACL to the router interface.

,■■ Table 10-12 Caveats to Consider When Creating ACLs (Continued)

,■■ Table 10-12 Caveats to Consider When Creating ACLs (Continued)



Special packets

Router-generated packets (routing table updates) are not subject to outbound ACL statements on the source router. Inbound ACLs on adjacent routers or other router filter mechanisms using ACLs must be used to do the filtering task if your security policy requires filtering these types of packets.

Extended ACL placement

Using extended ACLs on routers too far from the source that you need to filter might adversely affect packets flowing to other routers and interfaces. It is best to place extended ACLs on routers as close as possible to the source that you are filtering.

Standard ACL placement

Placing standard ACLs too close to the source can adversely affect packets destined for other destinations, because these filter packets are based on the source address. It is best to place standard ACLs as close to the destination as possible.

Filtering Traffic with ACLs

You should filter traffic with ACLs to block services that hackers use to gather information about your network. This is an effective way to decrease the likelihood that an attacker will be able to develop an effective footprint of your organization's services. Always apply these general rules when considering how to handle router services, ports, and protocols:

■ Disable unused services, ports, or protocols: If you find that there is no need to use an enabled service, port, or protocol, disable it immediately.

■ Limit access to services, ports, or protocols: If a limited number of users or systems need access to an enabled router service, port, or protocol, limit access to it using ACLs.

ACLs act as traffic filters between your corporate (trusted) network and the Internet (untrusted network), as shown in Figure 10-17. The router uses these ACLs to enforce corporate security policies by rejecting protocols and restricting port usage.

The "Blocked Services" table lists common router services attackers use to gather information about your network and that might lead to an attack. Unless your specific network configuration requires one of these services to operate properly, do not allow them to traverse the router. ACLs should be used to block these services inbound to the protected network and outbound to the Internet. Table 10-13 lists blocked services, along with the port and transport protocol that they use.

Figure 10-17 Filtering Traffic with ACLs

Corporate (Trusted) Network

Figure 10-17 Filtering Traffic with ACLs

Corporate (Trusted) Network

• Use ACLs to filter ingress and egress from routers and firewall appliances.

• Use ACLs to disable and limit services, ports, and protocols.

• Use ACLs to filter ingress and egress from routers and firewall appliances.

• Use ACLs to disable and limit services, ports, and protocols.

Table 10-13 Blocked Services














































NetBIOS Name Service (NBNS)



NetBIOS Datagram Service (NetBIOS-DGN)






NetBIOS Session Service (NetBIOS-SSN)



X-Display Manager Client Protocol (XDMCP)









Line printer remote (LPR)









UNIX-to-UNIX Copy Program (UUCP)



Internet Relay Chat (IRC)



Microsoft UPnP SSDP

1900, 5000


Network File System (NFS)



X Window System

6000 to 6063



12345, 12346


Back Orifice



Table 10-14 lists common services that reside on either the corporate protected network or the router itself. ACLs should be used to deny these services to untrusted clients.

Table 10-14 lists common services that reside on either the corporate protected network or the router itself. ACLs should be used to deny these services to untrusted clients.

— Table 10-14 Services to Deny

— Table 10-14 Services to Deny










SNMP trap









Remote Shell Protocol (rsh), Remote Copy Protocol (rcp), rdist, rdump









Access to router services can be controlled in two ways:

■ Disable the service: Disabling a router service makes it impossible for anyone to use that service. This is a safer and more reliable action than attempting to block all access to the service using an ACL.

■ Restrict access to the service using ACLs: If limited access to a service is required, it is best to build and test appropriate ACLs to apply to the service.

Preventing IP Spoofing with ACLs

You may implement ACLs to mitigate a wide range of threats. This section looks at how you can use ACLs to mitigate IP spoofing:

■ IP address spoofing: inbound

■ IP address spoofing: outbound

To mitigate IP address spoofing, do not allow any IP packets containing the source address of any internal hosts or networks inbound to a private network. Figure 10-18 shows the topology referenced in the ACL application shown in Example 10-1, where ACL 150 is applied to router R2.

Figure 10-18 Mitigating IP Address Spoofing Corporate LAN R2

Remote Access LAN

Example 10-1 Mitigating IP Address Spoofing with an ACL

R2(config)# access-list 150 deny ip any log R2(config)# access-list 150 deny ip any log R2(config)# access-list 150 deny ip any log R2(config)# access-list 150 deny ip any log R2(config)# access-list 150 deny ip any log R2(config)# access-list 150 deny ip any log R2(config)# access-list 150 deny ip host any log R2(config)# access-list 150 permit ip any R2(config)# interface e0/1 R2(config-if)# ip access-group 150 in R2(config-if)# exit

This ACL denies all packets containing these IP addresses in their source field:

■ Any addresses from the internal network

■ Any reserved private addresses (RFC 1918)

■ Any addresses in the IP multicast address range (

You will want to apply this ACL inbound to the external interface (e0/1) of router R2 to help mitigate IP spoofing attacks.

Also, you should not allow any outbound IP packets with a source address other than a valid IP address of the internal network. Example 10-2 shows the application of an ACL to do this.

Example 10-2 Applying an ACL to Disallow Any Outbound Packets with a Nonvalid Source Address

R2(config)# access-list 105 permit ip any R2(config)# access-list 105 deny ip any any log R2(config)# interface e0/1 R2(config-if)# ip access-group 105 in

R2(config-if)# end

ACL 105 is on router R2. This ACL permits only packets that contain source addresses from the network and denies all others.

Note that this ACL is applied inbound to the inside interface (e0/0) of router R2.

If you are working with Cisco routers running Cisco IOS Release 12.0 and later, they may use IP Unicast Reverse Path Forwarding (RPF) verification. This would provide an alternative IP address spoof mitigation mechanism.

Restricting ICMP Traffic with ACLs

Unfortunately, hackers can use a number of ICMP message types to attack a network. Many legitimate ICMP messages exist, so deciding what to permit and what to deny can be challenging. For instance, various management applications use ICMP messages, and network management uses ICMP messages automatically generated by the router.

One favorite of hackers are ICMP echo packets. Hackers use ICMP echo packets to discover subnets and hosts on the protected network as well as to generate DoS floods. Hackers can also use ICMP redirect messages to alter host routing tables. Because hackers can use both ICMP echo and redirect messages maliciously, the router should block them inbound.

Example 10-3 shows ACL 112. This ACL statement is used to block all ICMP echo and redirect messages.

Example 10-3 Blocking ICMP Echo and Redirect Messages with an ACL

R2(config)# access-list 112 deny icmp any any echo log R2(config)# access-list 112 deny icmp any any redirect log R2(config)# access-list 112 deny icmp any any mask-request log R2(config)# access-list 112 permit icmp any R2(config)# interface e0/0 R2(config-if)# ip access-group 112 in R2(config-if)# end

For even greater security, this ACL also blocks ICMP mask request messages. Note that this ACL allows all other ICMP messages inbound to the network.

The following ICMP messages are required for proper network operation; they should be allowed outbound:

■ Echo allows users to ping external hosts.

■ Parameter problem tells the host about packet header problems.

■ Packet too big is required for packet maximum transmission unit (MTU) discovery.

■ Source quench throttles down traffic as needed.

As a best practice, all other ICMP message types should be blocked outbound. Example 10-4 shows how you can use an ACL to properly handle ICMP messages.

Example 10-4 Applying an ACL to Properly Handle ICMP Messages

R2(config)# access-list 114 permit icmp any echo R2(config)# access-list 114 permit icmp any parameter-problem R2(config)# access-list 114 permit icmp any packet-too-big R2(config)# access-list 114 permit icmp any source-quench R2(config)# access-list 114 deny icmp any any log R2(config)# interface e0/1 R2(config-if)# ip access-group 114 out R2(config-if)# end

ACL 114 permits all the required ICMP messages outbound to the e0/1 interface while denying all others.

Configuring ACLs to Filter Router Service Traffic

ACLs are an effective means of filtering router service traffic. This section examines how to use ACLs to filter IP traffic destined for Telnet, SNMP, and Routing Information Protocol (RIP).

Typically when constructing an ACL, you would not build a succession of small ACLs, as we will here. However, for clarity it is best to initially examine each of these individually. In practice, you might want to build at least one ACL for the outside router interface, one for the inside router interface, and one or more ACLs for general router use.

vty Filtering

Systems administrators use Secure Shell (SSH) to remotely access the router console to perform configuration and maintenance. Because of the power this solution provides, you should restrict which hosts have access to the router's vty lines by using an ACL statement.

Figure 10-19 shows an example of vty filtering with an ACL. Example 10-5 shows how to create an ACL to perform vty filtering.

Figure 10-19 vty Filtering with an ACL

Authentication Server

File Server


Corporate LAN__

Remote Access LAN

Example 10-5 Performing vty Filtering with an ACL

R2(config)# access-list 90 permit host 12

2.1.3 log

R2(config)# access-list 90 deny any log

R2(config)# line vty 0 4

R2(config-line)# login authentication vty


R2(config-line)# transport input ssh

R2(config-line)# access-class 90 in

R2(config-line)# end

The IP standard ACL 90 shown here allows only host to access router R2 using SSH (port 22). The command transport input ssh also denies SSH access to R2 from any other hosts. As configured, this ACL also logs all successful and unsuccessful attempts to access R2 using SSH. This log provides a record for future reference and can serve as a means to help detect attempted unauthorized access.

SNMP Service Filtering

SNMP version 2c (SNMPv2c) lacks authentication, so you should use it only on protected internal networks. It is also a best practice to limit access to a router SNMP agent using an ACL statement.

Figure 10-20 shows a topology in which SNMP service filtering with an ACL occurs. Example 10-6 shows the syntax necessary to perform SNMP service filtering with an ACL.

Figure 10-20 SNMP Service Filtering with an ACL

Authentication Server


File Server

SNMP Server

SNMP Server

Remote Access LAN

Example 10-6 Using an ACL to Provide SNMP Service Filtering

R2(config)# access-list 80 permit host R2(config)# snmp-server community snmp-host1 ro 80

Here only the SNMP server with an IP address of may access the router R2 SNMP agent. The snmp-server command specifies that the SNMP server must use a community string of snmp-host1.

SNMP version 3 (SNMPv3) is supported in the latest Cisco IOS software versions. This version offers more-secure SNMP operations and should be implemented rather than older SNMP versions whenever possible.

RIPv2 Route Filtering

To provide directions on where to route traffic, Cisco routers share routing table update information. You can use ACLs to limit which routes a router accepts or advertises to its counterparts. Figure 10-21 shows a sample topology using RIPv2. Example 10-7 shows the syntax necessary to provide RIPv2 filtering with an ACL.

Figure 10-21 RIPv2 Route Filtering with an ACL

Corporate LAN

Domain Name System

Domain Name System

Public Web Mail Admin Server Server Server User

0 0

Post a comment