Output from show command

Using Cisco access lists is an easy way to enhance your network security. Learn how Lance Cockcroft uses this tool to block common attacks, including the dreaded denial of service (DoS) attack.

Cisco has built a tremendous amount of features into the Cisco Internetwork Operating System (IOS). This rich feature set gives network engineers a great deal of latitude in configuring specific areas within networks. One of the most powerful tools included in the Cisco IOS is the access control list (ACL). ACLs are rules configured by the administrator. Each incoming network packet is checked against the access list until a match is made. ACLs can be used for a number of different purposes, including route filtering, network address translation (NAT), traffic shaping, traffic analysis, and, most important, security.

In this Daily Drill Down, I’ll introduce you to ACLs by showing you how to block certain common networking attacks. In addition, I’ll show you how to block private addresses.

How ACLs work
In its most basic form, an ACL looks at every network packet and makes a decision based on the ACL rules as to whether the packet should be forwarded or dropped. You can configure ACL rules to filter packets based on source or destination address, as well as source or destination port. Although ACLs are used as a security mechanism on Cisco's IOS, they are not the only security feature built into the Cisco IOS. In the remainder of this Drill Down, I will examine a number of these features.

Today, the most prevalent network attack is arguably the denial of service (DoS) attack. A DoS attack (such as the Smurf or the SYN attack) attempts to overwhelm the target network. The purpose behind an attack of this kind usually is not to gain access to the network; the perpetrator simply wishes to crash the target network or host machine. Understanding the purpose of the attack sheds a lot of light on the type of person performing the attack. Normally, the DoS attacker is unsophisticated, lacks the talent to actually crack good network security, and must rely on brute-force tools that attempt to disable the network.

While this attack is very simple to start, it’s difficult to prevent. There are literally hundreds of free tools on the Internet that anyone can download and use to start a DoS attack. More sophisticated DoS attacks involve several individuals all working in concert while utilizing tens to hundreds of client machines to bombard a victim. The attackers also always use a spoofed address—an address that does not belong to the attacker. This is much like sending mail to someone and using somebody else's return address.

The first thing that you must discover during a DoS attack is what sort of DoS attack it is. The most prevalent DoS attack is the packet flood. You may think of ACLs as a way to stop DoS attacks; however, they can also be used to identify the type of attack you are witnessing. Consider the following ACL:
access-list 175 permit icmp any any echo
access-list 175 permit icmp any any echo-reply
access-list 175 permit udp any any eq echo
access-list 175 permit udp any eq echo any
access-list 175 permit tcp any any established
access-list 175 permit tcp any any
access-list 175 permit ip any any

interface serial 0
ip access-group 175 in

Access list syntax
Before I explain the sample ACL, here’s the actual syntax of an access list:
access-list list {permit|deny} protocol source source-mask
destination destination-mask [operator operand] [established]

Now, let’s look at my earlier example. The first line of the access list allows ICMP echo traffic from any host to any host onto the network. The second line of the access list allows any echo-reply messages into the network. The third line allows any UDP echo traffic into the network. The fourth line allows UDP echo replies into the network. The eq means that the packet must be an echo packet. The fifth line allows any TCP traffic from any host to any host that has an established connection. A connection is established if the ACK field is set to 1, meaning that a host inside the network established the connection to the outside host. The sixth line allows any TCP traffic from any host to any host within the network whether the connection was established or not. The last line in the access list allows any IP traffic to any host from any host. This access list is then applied to the Serial 0 interface and is used to examine all traffic that comes in the serial 0 interface. Traffic on other router interfaces and traffic going out the serial 0 interface is not examined.

You may notice that this access list does not stop any traffic at all. Nonetheless, this list can be very valuable in a DoS attack situation. You can use the command
show access list

which will show how many packets entering the serial 0 interface matched each line in the access list. By seeing how many packets entering the router matched each line, you can tell what kind of attack you are receiving. This output is from the
show access-list 175

access-list 175 permit icmp any any echo (3 matches)
access-list 175 permit icmp any any echo-reply (53126 matches)
access-list 175 permit udp any any eq echo
access-list 175 permit udp any eq echo any
access-list 175 permit tcp any any established (135 matches)
access-list 175 permit tcp any any (15 matches)
access-list 175 permit ip any any (66 matches)

By using the Show Access List command, you can see that most of the traffic entering the serial interface belongs to echo reply. This would indicate that the network was under a Smurf attack.

A Smurf attack involves three parties: the attacker, the reflector, and the ultimate target. The attacker sends an ICMP echo request to a subnet broadcast address, such as, but instead of using his or her own address as the source address, the attacker uses the address of the ultimate target. The address is translated to mean all hosts on the network When all the hosts on the network receive the ICMP echo request, they will respond with an echo reply. That could be over 16 million echo replies—all going to the same address, the ultimate target address. This amount of traffic will quickly overwhelm both the target’s and the reflector’s networks.

The Show Access List results from our sample network indicate that we are obviously the target network of a Smurf attack. If the first line in the access list has the majority of hits, this means we are sending out the echo requests and are thus considered the reflector.

Once you understand the type of attack, you can then modify the access list so that the second line reads:
access-list 175 deny icmp any any echo-reply log-input

This entry in the access list will now cause any packet that matched the statement to be logged and will stop the echo replies from being sent. By logging the information, you can discover the addresses that the echo replies are being sent to. With a Whois lookup, you can then contact that administrator to have him or her begin logging all incoming ICMP echo packets. This will begin the tracking down of the real perpetrator. Once you have logged the appropriate amount of information, you can modify the access list or create another one to stop all the incoming echo requests.

For example, if the reflector networks address was, you could create the following access list to stop the ICMP traffic:
access-list 180 deny ICMP any

interface serial 0
access-group 180 in

As you can see, the attacker is using the resources of one network to attack another. This can be prevented by not allowing your network to be used as a reflector. Using Cisco routers, you can add the
no ip directed broadcast

configuration command to prevent anyone from sending packets addressed to the broadcast address from the outside network. It is the responsibility of network administrators to prevent hackers from using their network as a reflector. The Netscan organization constantly scans IP address ranges, looking for unprotected networks that could be used as a reflector network. Netscan then publishes on its Web site the address ranges and contacts of companies that have not protected their network. The companies and names are published to attempt to shame the responsible parties into correcting the security flaw on their network; unfortunately, hackers also use the site to find reflector sites.

The Fraggle attack is the same as the Smurf attack except that Fraggle uses UDP echo requests instead of ICMP. The third and fourth lines of our access list would capture Fraggle information. Use the following access list entry to stop Fraggle attacks:
access-list 180 deny udp eq
echo any

interface serial 0
access-group 180 in

The first configuration line above is broken for readability.
SYN attacks
The last couple of lines in our access list are used to discover SYN attacks. The SYN attack is a third type of DoS attack in which the hacker sends thousands of SYN packets to a host system until that host system runs out of system resources.

Here’s how it works. Any two hosts wanting to communicate using TCP must first establish a connection because TCP is a connection-oriented protocol. To establish a connection, the attacking host sends the target host a SYN packet containing the beginning sequence number to be used. Once a host receives a SYN packet, it will set aside memory resources for that connection. If you send enough SYN packets fast enough, you can cause the host to run out of usable memory. Again, this does not allow the hacker access to the machine—it is used to crash a machine:
access-list 175 permit tcp any any established
access-list 175 permit tcp any any

SYN packets are sent only when establishing a connection. Once the connection is established, there is no need for additional SYN packets. Because an established connection does not have SYN packets, we know that any packets that match the sixth line in our access list are SYN packets. There is normally at least four times more TCP traffic than TCP SYN traffic; therefore, if the number of hits on line six exceed or even match the hits on line five, then you are experiencing a SYN DoS attack.

Blocking private addresses
Many hackers may choose to spoof addresses from the private address range. To prevent traffic from private Internet protocol addresses, use the following access list.
interface xy
ip access-group 101 in
access-list 101 deny ip any
access-list 101 deny ip any
access-list 101 deny ip any
access-list 101 deny ip any
access-list 101 permit ip any any

It is also a good idea to block any source addresses that use the network number. Remember that there is an invisible entry for all access lists that deny all traffic. It is therefore important to design access lists around this security feature.

Using access lists, the administrator can block any source, destination IP address, or port. Before blocking any ports, however, the administrator can first allow the traffic and then monitor the number of hits to an access list entry to ensure that no person or application on the network is currently using that address. For example, let’s say you want to block all traffic going to port 23 to prevent users from using the Telnet application. Before you implement such a change, it might be a good idea to check and make sure that this will not break any current network applications. You could use the following access list:
access-list 101 permit any any eq 23

interface serial 0
access-group 101 out

After a few days, you could use the
show access-list 101

command to see if any person or applications have been using the Telnet application. If you discover that no applications are using the Telnet application, you can use the
access-list 101 deny any any eq 23

command to prevent any outbound traffic to port 23.

Cisco IOS includes many security features and commands that allow network administrators to effectively manage their network security. Few features with the IOS are more granular or provide as much control as the access list. Cisco's Web site contains many documents relating to network security and how Cisco's IOS fits in and can be used to enforce an organization’s security policies.
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.

Editor's Picks