How to launch and defend against a DDoS attack [pdf] | Hacker News Reader

How to launch and defend against a DDoS attack [pdf]

secure.edu.pl

67 pointsjgrahamc21 comments

SIP is a particularly terrible protocol using UDP. A single SIP packet can generate significant processing, generally with IP address as the only sort of authentication. Most VoIP providers will fall over pretty quickly. The "best" implementation I've heard of is a simple L3 whitelist of known-OK IPs, but that still has the effect of killing your network to many customers. On top of that, RTP comes in dynamically on different IPs, so you need to propagate L7 info in real-time to your L3 filters. And of course, if an attacker knows who your customer is, they can just spoof their IPs.

Set your DNS records TTL to something relatively small like an hour.

If you are hit with a DDOS and want to direct traffic through a DDOS mitigation service you will often need to point your domain at their servers. If your DNS TTL is 48 hours then you will be up a creek for quite a while.

What are the downsides of a small TTL? Why wouldn't a low TTL be default?

If your TTL is very low, you end up creating/handling a lot more DNS traffic, because your records are flushed from the cache more often and have to be re-retrieved. Also, many public DNS servers (e.g. your ISP's, or Google's) set a minimum TTL on all records (overwriting any lower value) to minimize DNS traffic/requests. Setting your TTL to an hour is fairly standard, but some DNS hosts (especially old ones) will leave the defaults set to something like 48 hours for no real reason.

Very few resolvers break DNS TTLs in that way anymore. Google certainly honors TTLs down to at least 30 seconds. I'm not aware of any major ISPs that get this wrong anymore either.

This hasn't been a significant problem in years. When I execute a DNS change on a record with a 30 second TTL, I expect to see 95+% of the traffic move within a couple of minutes. The things that tend to get it wrong these days are applications that don't honor the TTL instead of resolvers, but browsers generally get it right.

madsushi is talking about servers, not resolvers.

The primary downside to a small TTL is cost. For many DNS providers you are allotted a number of requests per month that DNS will resolve. On particularly popular websites having a ton of DNS requests can cause the cost of DNS services to inflate significantly.

I watched Artur Bergman's talk at Surgecon:

http://www.youtube.com/watch?feature=player_embedded&v=LQ_6o...

He covers DDoS in detail. Warning, possibly NSFW for many f-bombs.

Martian packets are a funny thing: The packet is ALWAYS coming from somewhere, so why don't internet providers just flat out refuse to send packets exiting their networks if the given IP doesn't match what they get?

Okay, routers are supposed to get a packet and just route it to the next point by blindly following the instructions ("0.0.0.1 wants to UDP 124.40.28.9 on port 80"), but whatever the route taken, once my route leaves my home router, my first stop will ALWAYS be my provider's routers, the very company that gives me an IP.

So why can't these companies check on their client-to-outside-world routers that the request is coming from my IP and not something otherworldly?

And what happens if you use a VPN?

VPN is on another layer, the packets should still have valid IPs. 'V' stands for virtual (not Vendetta), there is no actual private network existing on top of the internet.

Reputable ones do check that (uRPF).

Get Ecatel's upstreams to cut their ports and you'll get rid of 80% of it.

I am quite surprised by "Dreamhost" listed in the spoofed IP list?

What is the reason Dreamhost servers are comprised? Are those the old server accounts?

I am also amazed by the durability of our infrastructure able to sustain this huge flow everyday. But good work, CF.

It's a list of spoofed addresses. That means they are pretending to be Dreamhost, not that Dreamhost is compromised.

I have a number of websites hosted on a dedicated server running Linux. Is there any specific things that I should do on my server to mitigate/prevent any impact from a DDoS against one of the site I host?

Make sure your upstream or colo provider comes with DDoS mitigation.

Nothing within your power can protect you from a multi-gigabit DDoS attack except bandwidth or a black hole route.

If you're getting smaller attacks you can try Fail2ban, some Nginx rules, or an edge cache.

Under "Hide Your Origin", how does one ensure that "IP only accepts packets from the [DDoS] service"?

Determine the range of addresses used by the service and then you could use hardware and/or software (iptables, pf, etc.) packet filtering to only allow packets from those hosts.

Are there any "best practice" settings for specific OS/firewalls? I use FreeBSD and pf.

What are the Martian ip addresses?

http://en.wikipedia.org/wiki/Martian_packet

TL;DR: "Today, all CloudFlare routers were being DDoS'ed by 127.0.0.1. CloudFlare is now investigating its employees."

Reply on news.ycombinator.com