
How to launch and defend against a DDoS attack [pdf] - jgrahamc
http://www.secure.edu.pl/pdf/2013/D1_1530_A_Graham-Cumming.pdf
======
MichaelGG
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.

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

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

~~~
madsushi
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.

~~~
imbriaco
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.

~~~
tokenizerrr
madsushi is talking about servers, not resolvers.

------
dmourati
I watched Artur Bergman's talk at Surgecon:

[http://www.youtube.com/watch?feature=player_embedded&v=LQ_6o...](http://www.youtube.com/watch?feature=player_embedded&v=LQ_6oS3UqsM#t=761)

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

------
joshguthrie
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?

~~~
elorant
And what happens if you use a VPN?

~~~
AsymetricCom
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.

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

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

------
richbradshaw
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?

~~~
oceanplexian
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.

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

~~~
avtar
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.

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

------
alimoeeny
What are the Martian ip addresses?

~~~
joshguthrie
[http://en.wikipedia.org/wiki/Martian_packet](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."

