Configure your router to block DOS attempts

Some time ago I had a discussion with a friend. He disagreed with my recommendations on how to configure a border router and the firewall behind it. I claimed that in the border router between you and your ISP, configure the six rules to block most denial of service traffic; in the firewall, configure additional packet filtering and content inspection. He claimed that it’s better to repeat the router rules in the firewall, and if possible repeat the firewall rules in the router.

This struck me as disingenuous: “Why do the same work twice?” I asked. “It’s defense in depth,” came the expected reply. “If a bad guy gets through the router, maybe the firewall will stop him.”

No, it isn’t defense in depth. Defense in depth is about doing the correct things at all layers, and only things that are appropriate for each layer. When defense in depth degenerates into duplication of effort, the resulting security posture becomes more brittle and, arguably, less secure.

There are three kinds of vulnerabilities:

  • Code: an error in the software that you fix with a patch
  • Configuration: an error a human made while setting something up
  • Circumvention: an error in a security policy that encourages people to look for ways to get around the policy

By far, the most commonly occuring type (according to some research from CERT) is the second: configuration vulnerabilities. Given that it’s far more likely for me to make a mistake in my rules than for the code in the router or firewall to be buggy, it’s far more likely for a bad guy to break in through my error-ridden rules than for him to break in through a code vulnerability in either device.

Complexity is the enemy of security. Simplicity always wins. Therefore, to keep a network simple (and more secure), ensure that your defense in depth measures are tuned and specific for each layer, not merely duplicates of something you’ve taken care of at another layer.


Blocking DOS attacks

Now, back to the title of this post. In a border router, you should have six rules that will block almost all denial of service attacks. Remember the attack against the Internet in February 2000? Mafiaboy, the 17-year-old Canadian script kiddie, brought down 11 sites using 75 computers in 52 countries to send 10,700 messages in 10 seconds, causing an estimated $1.7 billion in damages. (Canadian police discovered him from his boasting in chat rooms. In 2001 he pled guilty to 56 charges and was sentenced to two years in a juvenile detention center).

Why did Yahoo,, eBay, CNN,, ZDNet, ETrade, Dell, and Excite all succumb to the attack? Because they lacked one or more of these six important rules. MSN and Microsoft were targeted, but because our routers have these rules, we escaped the attack. The rules:

  1. Block all inbound traffic where the source address is from your internal networks. Why in the world would there be traffic on the outside that originates from the inside? This is a sign that someone is spoofing you.
  2. Block all outbound traffic where the source address isn’t from your internal networks. This is the inverse of #1: there’s never any reason for your network to emit traffic that’s sourced from some other network. Somone on the inside is spoofing someone else (we have a term for such people: employee).
  3. Block all inbound and outbound traffic where the source or destination addresses are from the private address ranges. Defined in RFC1918, these addresses are for use in internal networks; ISPs agree not to route such traffic. Of course, ISPs make configuration mistakes, too; I’ve seen traffic with these addresses on the Internet. So don’t trust that your ISP is perfect, block the stuff yourself. And remember to include the Windows automatic private IP addressing block. The ranges, then, are:,,, and
  4. Block all source-routed packets. Way back in 1970, when “routers” were Unix computers running a routing deamon, they weren’t all that reliable. So IP includes a provision for the headers of a packet to indicate the route the packet should take from its source to its destination. Source-routing was necessary then, but it’s completely unnecessary today: routers are some of the most reliable gear around. Source-routed traffic is the sign of an attack: drop it all.
  5. Block all broadcast packets, including directed broadcasts. Broadcasts are useful inside a network, but have pretty much zero utility between networks, so don’t let the stuff in (or out). And good old smurf attacks, still seen as a form of revenge in IRC, rely on directed broadcasts. [Thanks to Michael Dragone for suggesting this additional rule.]
  6. Block all packet fragments. Fragrouter is an old but wonderful tool, imminently useful for evading network intrusion detection. With it, an attacker can create packet fragments — TCP or UDP packets missing the TCP or UDP header — and, for example, map out your firewall policy and prod for holes and mistakes in your configuration. With one notable exception, fragments are generally not created, so there’s no reason to permit them into your network. What’s the exception? IPsec — or, more precisely, IKE authentication in IPsec. During the authentication sequence, IKE performs six round trips between the peers. As the peers negotiate a protection suite and exchange keys, IKE generates fragments: very rarely will the key fit in a single packet. So if you’re allowing IPsec between the Internet and something behind your border router, you’ll need to skip this final rule.

There you go. Program these six rules in your border router (and consider dropping whatever else you’ve got there now) and you, too, can tell the likes of Mafiaboy to go pound sand. Oh, and guess what? By being more secure yourself, you directly affect — negatively — the security posture of your neighbors and competitors! Did you ever think that a router configuration could become strategic competitive advantage? 🙂

Comments (12)

  1. Anonymous says:

    Contrary to popular belief, the rumors of my demise have been greatly exaggerated. Well, ok, no actual

  2. Anonymous says:

    "Defence in depth" (or "defense in depth", if you’re American) is a frequently misunderstood term in…

  3. Mike says:

    Excellent post! You should also consider limiting both inbound and outbound as well as broadcasts inbound/outbound, depending of course on your particular site requirements.

  4. steriley says:


    However, it isn’t necessary to add to the list. The entire 127 network is the localhost, not just All IP stacks behave this way; traffic with a destination anywhere in will never leave a computer.

    How do you figure that broadcast traffic creates a security issue?

  5. ram says:

    I have one question for which I do not know the correct answer.

    If the MTU is larger than what you want to accept, fragmentation is needed, even when using Path MTU discovery,ICMP should be allowed. Administrator worry about ICMP leaving the network, Is there any way to still keep ICMP inside, the DF on and let the user know that his MTU needs to be adjusted.

    I bring this question, because, I had to adjust my Linksys SOHO router’s MTU to work. I have no idea why it was set to anything larger than 1500?

  6. Mike says:

    Years ago wasn’t there a DOS attack (Smurf?) that utilized IP directed broadcasts? I don’t see why I would want broadcast traffic from another network entering mine.

    As for not blocking the localhost addresses, I realize that all IP stacks aren’t supposed to pass along that traffic, but my thinking was that somehow someday there might be something that uses the localhost range as part of an exploit. So it didn’t seem like a bad idea to me to block that traffic just in case, even though it should never show up.

    However, I’m probably not the best barometer for this as I’m quite paranoid. 🙂

  7. steriley says:

    MIKE> Right, smurf (and it’s variants) relied on directed broadcasts. I had forgotten about that! It’s a good sixth rule to add to the list, which I’ll put in now.

    I’ve never seen an IP implementation that mishandled So I guess in the name of simplicity, I’d not add that rule to my router. But if you want to, then absolutely that’s ok.

    RAM> If you need to allow the ICMP message for fragmentation needed, then you should permit only ICMP type 3 code 4. Don’t allow anything else. Messages indicating "unreachable" are especially dangerous: they’re very useful for reconnaisance.

  8. Xavier Ashe says:

    Interesting followup to you article.  CSO just posted "Consortium Builds Super Firewall to Stop DDOS"

    "The project, which started in 2004, was budgeted at €3 million (US$3.8 million) and received funding in part from the Information Society Technologies, a European Union organization that coordinates IT programs. It has been extended for three more months, Carle said."

    You need to call them up and offer $2 Million…

  9. ryanheff says:

    “This struck me as disingenuous: ‘Why do the same work twice?’ I asked. ‘It’s defense in depth,’ came the expected reply. ‘If a bad guy gets through the router, maybe the firewall will stop him.’

    No, it isn’t defense in depth. Defense in depth is about doing the correct things at all layers, and only things that are appropriate for each layer. When defense in depth degenerates into duplication of effort, the resulting security posture becomes more brittle and, arguably, less secure.”

    I think the notion of “defense in depth” is too vague, and the security community should abandon it because it confuses people. Like you, I’ve seen many people duplicate efforts and make unsound choices under the guise of defense in depth.

    Instead of defense in depth, we should talk about “fault tolerant security”. Fault tolerance is a more precise term because it’s specific to individual faults. If the security community spoke in terms of fault tolerance, your friend probably would have immediately understood that although duplicating the rules between router and firewall does introduces some additional fault tolerance, the faults it does protect against are extremely rare ones, and thus not worth trading much for. With our current language, I wouldn’t be surprised if your friend still sticks to his guns in spite of your explanation.

  10. Alun Jones says:

    "However, it isn’t necessary to add to the list. The entire 127 network is the localhost, not just All IP stacks behave this way; "

    You’d /think/ that, wouldn’t you?  Certainly, that’s the way the RFC puts it.

    But a few years ago (less than ten), a customer called me to complain that he couldn’t get WFTPD to work in his network – although it started up and was listening, it refused to respond to connections from other machines on his network.

    I don’t even remember how we got it figured out, but he had a network of about a dozen machines (he swore they were Suns) all with IP addresses starting with "127.".  These machines were all communicating with one another, he assured me.

    Since this was all over the telephone, it’s a bit of an unreliable story, as I definitely didn’t have the ability to verify it with my own eyes – but as with the RFC 1918 addresses, why not actually enforce the rules that such traffic will never appear on your network?

    It’d be a piece of relative child’s play to forge a packet that had 127.* as its source address, and place it on the wire.  Once on the wire, what stops it from being routed?  What stops it from being responded to?

    I’m trying to remember the details of an attack on a server where you use a loopback-sourced packet to cause the server to connect back on itself, and create massive feedback.  A search reveals nothing, but my memory of such things is usually reliable.

  11. Fred Pullen says:

    Is there a need to block or any of the other special-use IP ranges addressed in RFC3330?  ( AFAIK it’s never been an issue, but then again 127.* hasn’t either–for most of us.  🙂  

    BTW, RFC1918 doesn’t cover APIPA.

  12. steriley says:

    Interesting. Maybe blocking could be useful. I suppose, as Alun said about 127.*, that malware could create traffic with a 0.* source address. According to RFC 1700, 0.* addresses can only be used as source addresses. I really don’t know what happens if you try to use a 0.* as a destination address.

    Blocking the other address ranges in RFC 3330 isn’t a good idea, since (other than the RFC 1918 and link local blocks) they are addresses that are in legitmate use.

    And yes, I know that 169.254 (the link local block used for APIPA) isn’t part of RFC 1918, but it’s useful to mention them together.