Configure your router to block DOS attempts

re: Configure your router to block DOS attempts

Mike — Tue, 11 Jul 2006 04:11:25 GMT

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

Interesting Finds: July 10, 2007

Jason Haley — Tue, 11 Jul 2006 06:47:48 GMT

re: Configure your router to block DOS attempts

Steve Riley — Tue, 11 Jul 2006 06:58:01 GMT

Thanks!

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

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

re: Configure your router to block DOS attempts

ram — Tue, 11 Jul 2006 19:51:35 GMT

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?

re: Configure your router to block DOS attempts

Mike — Wed, 12 Jul 2006 07:48:57 GMT

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. :)

re: Configure your router to block DOS attempts

Steve Riley — Thu, 13 Jul 2006 03:25:50 GMT

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 127.0.0.0/8. 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.

re: Configure your router to block DOS attempts

Xavier Ashe — Thu, 13 Jul 2006 17:14:54 GMT

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

http://www2.csoonline.com/blog_view.html?CID=22945

"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...

re: Defense in depth

ryanheff — Thu, 13 Jul 2006 22:37:36 GMT

“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.

re: Configure your router to block DOS attempts

Alun Jones — Tue, 18 Jul 2006 18:22:31 GMT

"However, it isn't necessary to add 127.0.0.0/8 to the list. The entire 127 network is the localhost, not just 127.0.0.1. 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.

Defence in death

Tales from the Crypto — Wed, 19 Jul 2006 18:16:37 GMT

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

re: Configure your router to block DOS attempts

Fred Pullen — Sun, 10 Sep 2006 10:52:24 GMT

Is there a need to block 0.0.0.0/8 or any of the other special-use IP ranges addressed in RFC3330? (http://www.faqs.org/rfcs/rfc3330.html) AFAIK it's never been an issue, but then again 127.* hasn't either--for most of us. :-)

BTW, RFC1918 doesn't cover APIPA.

re: Configure your router to block DOS attempts

Steve Riley — Mon, 11 Sep 2006 00:04:30 GMT

Interesting. Maybe blocking 0.0.0.0/8 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.

Directly connect to your corpnet with IPsec and IPv6

Steve Riley on Security — Wed, 25 Jun 2008 23:56:06 GMT

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