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.
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.
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 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?
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.
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.
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?
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.
21 comments
[ 2.7 ms ] story [ 50.4 ms ] threadWhat 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.
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.
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.
http://www.youtube.com/watch?feature=player_embedded&v=LQ_6o...
He covers DDoS in detail. Warning, possibly NSFW for many f-bombs.
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.
TL;DR: "Today, all CloudFlare routers were being DDoS'ed by 127.0.0.1. CloudFlare is now investigating its employees."
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?
Get Ecatel's upstreams to cut their ports and you'll get rid of 80% of it.