This is roughly the same approach used by the DDoS mitigation services; you run your servers on an unpublished address and front it on their address space.
I like that they've got the ghetto version of the technique documented. Better that you should rig this up on a couple VM hosting providers for a few hundred bucks than that you spend tens of thousands of dollars to get the same level of service from someone with slick marketing.
The obvious problem here is that it's hard to keep a determined attacker from finding your real address space, and as soon as that happens, you're done; attackers just skip the DNS and whack you directly.
This is a useful trick, but it's not the end of the story.
I'm interested in how you think an attacker would find your address - at least, presuming you have a web-only [1] host on a competently-run [2] network that drops anything but requests from the proxies [3].
Of course, there are (D)DoS attacks that don't consist of sending lots of bits/packets at a host, and this does assume you're hiring a dedicated server or somesuch.
Of course, they could try to sniff network traffic at one of the providers/on the backbone/..., but that's a lot harder to carry out than a basic DDoS attack.
[1] E.g. don't try to receive e-mail at this host while it's being attacked; you'll need to point an MX record at it, which pretty much defeats the purpose.
[2] IP spoofing will break the next defense; if the entire provider can be taken down, you have serious problems.
[3] If you accept all traffic, nmap/curl will easily find the host, after which the attack resumes. For bonus points, serve up an uninteresting-looking page.
btw in Italian the only way to say "second last" is "penultimo" and I guess in most other european languages should sound the same, so a lot of non mother tongue English readers are going to read this as "second last" anyway, completely missing the "very ultimate" (mis)meaning.
The "ultimate guide to x" would have sound to pretentious, so to be humble and as an attempt to humor they choose this title (usually a guide is "ultimate" until a next and better guide come out). Seems a reasonable explanation...
All words are cool if you don't know what they mean. If the reader knows what it means but the writer doesn't, the effects are less predictable and desirable.
Well, there is this: Opposites are a tricky concept, not well-defined in most domains. Your implication is that the opposite of last is "first". But doesn't it make at least as much sense to say the opposite of last is "not last"? From a programing/math standpoint, it seems like a strictly better, less arbitrary definition.
Something missing from the cost calculation in this article is the cost of bandwidth used for each VM. The VM itself may be low cost but at 100Mbps you will use about 1TB of bandwidth a day. You would need to select your VM provider with that in mind. A sustained attack could end up being fairly expensive.
Why would an attacker give up? The site may stay online but you are still having to pay thousands of dollars+ in bandwidth costs. It seems like a win-win for the attacker.
Because they can't see a site paying thousands of dollars, and they can see a site going down, and they're going to invest their attention in things they can see.
If they were thinking rationally about what they were doing, they'd (a) be demanding money to let up, and (b) breezing right past DNS-based defenses like this.
" Just be sure to set high TTL for the records so your DNS server does not collapse under the enormous volume."
The attacker, noticing your round-robin approach, decides to drop the DNS server and then only has one host to deal with.
There are a lot of weak points that can be attacked. Certain sites will have features that can be taken advantage of. If you have a long timeout/keepalive, the attacker could launch lots of quick requests with no proper tear-down. If you have a zillion servers setup like this - perhaps they can take out a major link before the traffic even gets to you.
I also don't think this is a new approach - unfortunately it is much harder to stop attacks than to create various approaches. The number of compromised machines is just too high - that is the ultimate solution.
Compared to HTTP DNS is crazy cheap to serve, but you'll still end up bottlenecking on the pps rate of your NIC and OS. Everybody optimizes for high throughput and ignores small packets.
Speaking of DNS DDoS, DNS Made Easy saw a 40Gbit DNS DDoS a few weeks back.
Not to mention that the attacker's DNS resolver could merely ignore the TTL and bombard your DNS server - if that's the weakest link, why even bother with the rest?
Because quite a few companies outsource DNS, and attacking a DNS provider involves many companies. Not to mention the fact that most DNS providers have been attacked before...
Timeouts would presumably be taken care of when setting up the proxies. Major DNS providers are used to getting DDoS'ed, and will typically be fine (not always, but it's a lot harder to drop them than to drop any random server).
I agree that there's probably a way to break things; but an attacker would need to actually do some work for most of them (e.g. create lots of accounts?)
DDoS attacks make the most sense for the attacker when they are an extortion attempt. The economics works in favor of the attacker. It costs the site dearly to be down, and they set a price that makes sense based on your site. Unfortunately, you may not hear about a lot of these attacks, and the attacker is never found or can't be arrested.
unixy.net sells DDoS insurance. You never know if the insurance policy was worth the monthly payments until an attack happens.
Note: I've never used unixy.net and can't speak to their effectiveness, but I don't like how they grossly oversimplify a complex problem
Meh, if the traffic only lasts a couple of hours before the attacker gives up, the VPS provider could still make a tidy profit - it's not like the VPS would do much for the rest of the month...
The sysctl.conf settings are bad.. like never ran a high end server bad. 1. tcp syncookies slows down connections considerably 2. rp_filter takes up a large amount of cpu time. 3. kernel.pid_max net.ipv4.ip_local_port_range is useless. Also this doesn't stop a DDOS attack, it mitigates it by having a bigger pipe than the bad guy. A real way to mitigate attacks is to 1. identify an attack based on history 2. make damn sure it's an attack 3. 'tarpiting' attacks (xtables-addons for linux). Tarpiting keeps connections in an open state on the client side thus eventually crashing the client.
This advice is very bad. Yes, I'm certain you can make a server go faster by disabling some security features, but without syncookies you're one SYN flood away from a painful crash.
Your "mitigation" is also useless - yes, tarpitting for antispam purposes can work, but a specialized DDoS tool likely uses raw socket access (i.e. the OS doesn't keep track of the connections). If you can't take the number of bits/packets thrown at you, you will be unreachable. And even if not - we're still talking about 10,000 machines talking to your one server. The bad guys have a lot more memory.
Security features? I will bet no give you a large sum of cash if you can show me that a server under a large pps DDOS survives with rp_filter and syncookies on with iptables on and without any crazy tcp modifications. In the real world there are no "specialized DDOS tools" most viruses are simple. EDIT: Why would you use a single server? Why on gods earth would you track tarpitted connections?
I like that they've got the ghetto version of the technique documented. Better that you should rig this up on a couple VM hosting providers for a few hundred bucks than that you spend tens of thousands of dollars to get the same level of service from someone with slick marketing.
The obvious problem here is that it's hard to keep a determined attacker from finding your real address space, and as soon as that happens, you're done; attackers just skip the DNS and whack you directly.
This is a useful trick, but it's not the end of the story.