In my previous article, “Understanding the basics of Cisco IP access control lists,” I explained how to create and implement a basic ACL. The difference between a basic ACL and an extended ACL is subtle, yet powerful. A basic ACL controls the flow of information based on network address (origin and destination). An extended IP ACL controls the flow of information based on the type of packet, as well as network address. Let’s take a look at how to effectively implement an extended ACL.
The power of an extended ACL
As you can see, being able to filter by the type of packet is the dividing line between the two kinds of lists. To illustrate the power of this feature, I’ll paint a simple example.
Let’s say your company Web server has become a toy for hackers and script kiddies. You struggle daily to replace defaced pages and occasionally have to reload from scratch. Marketing complains that your company is losing revenue, and your boss is losing patience with your ability to protect the network. What do you do?
- You connect the Web server to a port on your gateway router.
- On this port, between your Web server and the router, you create an outbound filter. (Filter direction runs from router to Web server.)
- You add three entries to your ACL. The first entry permits HTTP traffic to the Web server IP address. The second entry permits FTP traffic from a specific host or range of hosts on your internal network. (This allows someone to update the server.) The third entry denies everything else to that same address. This entry is really unnecessary since there is a Deny All statement at the bottom of every ACL, but you turn on logging for this entry because it makes great statistics.
- Enjoy your security.
That is the power of an extended ACL. Let’s examine the syntax for an extended ACL and look at some practical examples.
Creating an extended ACL
These lists are created and applied to an interface as either inbound or outbound packet filters. They are implemented in this format:
Access-list [list number] [permit | deny] [protocol] [source address] [source-mask] [destination address] [destination-mask] [operator] [port] [log]
- List Number—A number between 100 and 199 (Think of it as the name of the list.)
- Permit | Deny—Whether to permit or deny this packet of information if conditions match
- Protocol—Type of protocol for this packet (i.e., IP, ICMP, UDP, TCP, or protocol number)
- Source Address—Number of the network or host that the packet is from (Use the dotted-decimal format 192.168.1.12 or use the keyword ANY as an abbreviation for an address of 0.0.0.0 255.255.255.255 or use HOST and the dotted-decimal address.)
- Source Mask—The network mask to use with the source address (Cisco masks are a little different, 0 = octet must match exactly; 255 = octet is not significant or doesn’t matter.)
- Destination Address—The address that the packet is going to, or ANY
- Destination Mask—The network mask to use with the destination address (if you specify one)
- Operator (optional entry)—This applies to TCP or UDP ports only
range=a range of ports; you must specify two different port numbers
- Port (optional entry)—TCP/UDP destination port number or service
- Log—Whether to log (if logging is enabled) this entry to the console
A sample inbound ACL would be:
access-list 100 deny ip 10.0.0.0 0.255.255.255 any log
access-list 100 deny ip 172.16.0.0 0.15.255.255 any log
access-list 100 deny ip 192.168.0.0 0.0.255.255 any log
access-list 100 deny ip any host 127.0.0.1 log
access-list 100 permit ip any [your network IP address] [your network mask] est
access-list 100 deny ip [your network IP address] [your network mask] any log
access-list 100 deny tcp any any eq 22222 log
access-list 100 deny tcp any any range 60000 60020 log
access-list 100 deny udp any any eq snmp log
access-list 100 permit ip any any
Entries 1,2, 3, and 4 deny the internal, nonroutable IP addresses for each network class (as defined by RFC 1597) and the hardware loop-back address for an Ethernet adapter. None of these should travel across the Internet, but I have seen them in my logs. Thus, I deny them because there is always the possibility of connecting to somebody else’s improperly configured router.
Let’s look at the other six entries and see how each entry differs in what it specifically denies or permits:
- Entry 5—“permit ip any [your network IP address] [your network mask] est”—automatically allows all IP sessions already established with the ack bit turned. The purpose of this entry is to ensure that if your firewall allows a connection request to leave your network, the router doesn’t stop its return.
- Entry 6—“deny ip [your network IP address] [your network mask] any log”—denies anyone from entering your network from the outside with an internal address (spoofing your network) and logs each packet occurrence. This is very important for good security.
- Entry 7—“deny tcp any any eq 22222 log”—denies the infamous Donald Dick and Prosiak ports.
- Entry 8—“deny tcp any any range 60000 60020 log”—denies the Deepthroat and Sockets des Troie ports.
- Entry 9—“deny udp any any eq snmp log”—denies any snmp requests from the outside. SNMP is a valuable tool to hackers for network discovery.
- Entry 10—“permit ip any any”—permits packets that were not previously rejected to enter your network.
You apply this extended ACL the same way you applied the basic ACL.
When writing your extended ACL, a simple rule to follow is to have your most specific deny and permit statements at the top of the list, followed by the most active general entries.
Finally, I’d like to say something about ACLs in general. Their true use can either be to:
My preference is to allow by rule. I prefer this method because it provides much greater control over what enters and exits my network. This method is harder to implement from the start. You’ll need to know your network thoroughly, what services operate and what IP addresses need access to your internal network. (You should really know the answer to those questions already if you are interested in security.)
I run an allow-by-rule ACL, and the benefit is that I have never been contacted (day or night) because of a security breach. Stay tuned for more packet security tips from the Packet Professor.
We invite you to share your insights and experiences. You can start a discussion below or send the editor an e-mail.