Preventing Basic DDoS Attacks – Part 1 of 5

By Anthony Sequeira on June 20th, 2011

DDoS Overview

Network engineers shudder when they see this string of letters – D-D-O-S. Decades ago a basic Denial of Service (DoS) attack was bad enough. Someone with too much time on their hands would find a vulnerability in an Operating System and then attack that weak point with a flood of traffic to render the service or entire machine unusable.

But things certainly advance over time. The Distributed Denial of Service (DDOS) attack steps it up considerable. With these attacks, client systems install specialized programs on systems called Handlers. These systems the turn around and control thousands of other infected computers called Agents. The many, many Agents then turn around and carry out the attack against the victim systems.

When I am ready to relax and not think about this madness, I put on the classics like The Beatles, Bob Dylan, and The Stones. When security professionals want to stress out, they think about the DDoS classics like SMURF, SYN FLOOD, and SQL SLAMMER. 

SQL SLAMMER was truly amazing. Here are some eye-popping statistics regarding that attack.

  • The attack took advantage of a small vulnerability in SQL Server which could be attacked with a specially crafted packet to the port UDP port of 1434 , this would set off a stack overflow; Microsoft had released a patch for the vulnerability 6 months prior to the attack – DOH!
  • A single system with the required high-speed Internet connection could scan the entire Internet in 12 hours for the required SQL SLAMMER vulnerabilities
  • There were 75,000 victim systems within the first 10 minutes of the attack launch and it is estimated that this amounted to 90% of the infected machines

Yes – DDoS attacks happen fast and furious when they occur.

To make matters worse, these attacks follow a disturbing trend that has developed in the area of Network Security, the attacks get more sophisticated all of the time, and the sophistication level required to engage in the exploits is less and less. This is partially due to the development and easy deployment and advertising of attack applications.

Some famous attack applications that have been used for DDoS include:

  • Trinoo
  • TFN
  • TFN2K
  • Stacheldraht

In this first post of the series, we will examine a first step of five steps on Cisco routers that can help combat most common DDoS attacks.

Step 1 – Unicast Reverse Path Forwarding (uRPF)

This wonderful invention can stop SMURF, and attacks like it, right in their tracks. This is because uRPF seeks to combat IP source address spoofing.

You probably recall how Reverse Path Forwarding (RPF) and the RPF Check work in Multicast. It is the loop prevention mechanism there. The router receives a multicast packet and checks the source address of that packet. It then examines the routing table to determine if it makes sense that the packet with that source address should enter on the interface that it did. If it makes no sense, then it drops the packet.

Unicast Reverse Path Forwarding operates in a similar manner. It makes this little sanity check on where the packet is coming in from. Once again the routing table is check to see if the source address makes sense to come in from a certain interface.

I keep saying the routing table here, but that is actually an oversimplification. To make this all much more efficient, uRPF relies on Cisco Express Forwarding (CEF). In fact, CEF is a requirement for this feature. So technically speaking, uRPF makes its check against the Forwarding Information Base (FIB).

Configuring and Monitoring uRPF

Where would you configure this feature? On the uplinks (primary and backups) to your ISP. And hopefully your ISP(s) are aware of the feature and they are using it as well.

The configuration is very simple. On 12.4T code as an example, the command is:

myhappyrouter(config-if)# ip verify unicast reverse-path [list]

REMEMBER: You must have Cisco Express Forwarding enabled in order for this feature to function.

Notice the optional access list parameter that can be specified here. If you use an access list, your permit entries will allow potentially spoofed addresses to pass through to their destination, while deny entries will be blocked if spoofing is suspected. Note you could also use logging in the access list to further the built-in accounting capabilities of the feature.

show ip traffic, show ip interface, and show access-lists are all verification commands that can be used to monitor this important feature.

We hope you will join us for the next post in this series – Part 2 covers filtering RFC1918 and Bogons from entering your critical networks.

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

Preventing Basic DDoS Attacks - Part 1 of 5, 2.6 out of 5 based on 14 ratings
Be Sociable, Share!

    Tags: CCIE, ccie lab, CCIE Security, CCIE Security 3.0, CCIE Security Lab

    One Response to “Preventing Basic DDoS Attacks – Part 1 of 5”

    1. John says:

      This article is way behind in time. The attack sophistication, techniques and tools have evolved much beyond what’s described here.

      VA:F [1.9.22_1171]
      Rating: 4.5/5 (2 votes cast)

    Leave a Reply