Slashdot Mirror
Cloud DDoS Mitigation Services Can Be Easily Bypassed (softpedia.com)
An anonymous reader writes: A recent research paper shows that most Cloud-Based Security Providers are ineffective in protecting websites from DDoS attacks, mainly because they cannot entirely hide the origin website's IP address from attackers. As five security researchers from Belgium and the U.S. are claiming, there are eight methods through which these mitigation services can be bypassed. The techniques of obtaining a website's origin IP address rely on hackers searching through historical Web traffic databases, in DNS records, subdomains that resolve to the main domain directly, the site's own source code, when the main website triggers outbound connections, via SSL certificates, via sensitive files hosted on the website's server, and during migration or maintenance operations on the mitigation service itself, which leaves the target website temporarily exposed.
Akamai sells as an add-on for "origin cloaking", called "Site Shield", inwhich the origin to limits access to only a subset of akamai systems (which then distribute to the rest of akamai), and drops the rest of the internet. I wonder if that is effective against these attacks?
Wow, revelations here. I guess the point of the paper is to really show most webmasters don't know what they're doing. All of these things can totally be avoided if you do your job carefully and methodically. e.g. maybe change the IP address of the server after launching your DDoS mitigation service, oh look, now half that list is moot.
neorush
Let me summarise the key findings of the paper. The headline figure is stunning: over 70% of all sites they tested leaked their origin IP in some way.
But. It's not quite as simple as that. Virtually all websites that are DDoS protected are using CloudFlare, probably because it's a free service. The vast majority of the times they were able to find the origin IP address, it was due to basic oversights by the website admin, typically, having subdomains that resolve to the origin IP or simply never moving the server after signing up for CloudFlare at all. The most common subdomain that leaked the IP was called "ftp".
Who the heck actually still runs an FTP server as part of their website, in this day and age? No big websites do that's for sure.
And sure enough the paper concludes, not surprisingly, that bigger more important websites are much less likely to leak their origin IPs than smaller ones.
I think all this paper really says is that CloudFlare have a lot of small non-paying customers who aren't really playing in the big leagues and aren't being attacked by sophisticated attackers ... or possibly aren't being attacked at all .... and as a result are more likely to have made simple errors.
So when the headline says these protections are "easily" bypassed, all it's really saying is that if someone using a defensive system makes mistakes, they can still be attacked. That's not really news and doesn't tell us anything about the efficiency of these services when the people using them have done their homework.
As long as the servers dropping the traffic can keep up with both the legit traffic and the bad traffic. If an attacker can overload the server which is dropping non-akamai traffic then even legit traffic wont be able to get through. Since the akamai server has to read a packet to know whether or not to drop it it is still possible to overload that part of the system.
One other detection method not specifically called out is via email headers. Often times automated emails are sent from the same origin IP (not always, of course). Even if the email is routed through an email service before delivery, you can still see the origin in the full header.
All of what they described is true, plus one that they didn't cover explicitly.
Even if you have your site behind something like cloudflare, if you allow people to sign up for an account and your site sends a confirmation email, that email can reveal the source IP.
I've experienced this with one of my sites that had became somewhat popular. The owner of a competing site got his panties in a twist over the fact that my site was doing better and he started to DDOS my site. I changed the IP of my site and put it behind cloudflare, which worked fine- it totally mitigated the attack.
But...when you sign up to the site it sends a confirmation email to the user...and the headers in that email contain the IP that the site is currently sitting on. For a few days I worried that this scum-sucking asswipe would figure that out and begin his attack again but he apparently he lacked the brain power to realize he could find the IP that way.
The only way to get around this would be to have the target site route the outgoing mail through another IP or domain to mask its actual origin. I don't know if cloudflare has added some mechanism to do this or not, but confirmation emails are potentially a big hole in the service, and I'd guess that it's true of all such services similar to cloudflare.
FWIW, I recommend cloudflare for this kind of thing as well as general traffic management and mitigation of malicious probers, bots, and similar problems. Using cloudflare in conjunction with a bot-screening service like StopForumSpam or BotScout can stop a lot of this kind of shit dead in its tracks.
Just cruising through this digital world at 33 1/3 rpm...
This only applies if you are using a proxied service instead of a routed or tunneled service where you can't route around the proxy scrubbers. Most carrier DDOS service offerings allow you to route the traffic either through BGP steering or GRE tunneling such that your traffic must pass through the Cloud DDOS scrubbing center because the 'real' ip is routed that way.
I'm not so sure if hard drives help mitigate DDoS. But hey, feel free to give it a try!
CLI paste? paste.pr0.tips!
If you use Akamai, you can turn on the G2O feature and configure your servers to check for it. Apache, Nginx, F5 load-balancers, IIS, and Varnish all have extensions to support it (though the last one is not, unfortunately, open-sourced — for purely bureaucratic reasons, I might add).
Then, even if the enemies find your origin, all their hits will cost you is computing a digest of the requested URI and issuing a 403 or whatever — no file-lookups, no database-lookups, very little bandwidth. I suppose, your server can still be punished, but it certainly raises the bar quite a bit for any attacker.
In Soviet Washington the swamp drains you.
$ ftp ftp.slashdot.org
ftp: Can't connect to `216.34.181.48:21': Connection refused
It's just a stale DNS record.
it's a firewalled service
Yeah, because our technically literate Dive overlords would for once do everything right? (Must be a whitelisting firewall then which ALSO has the courtesy of not being a blackhole (since it returned a RST), then).
Somehow, I doubt it. But in all cases, whether there's no ftpd running at all, or a polite, whitelisting firewall, the outcome is the same, i.e. good.
CLI paste? paste.pr0.tips!
Do you know what DDOS is? Hint: they don't need to actually break it...
No way! Cloud Flare assured me that they could hand 520 Unknown error
I don't think that means they can handle 520 different unknown errors...
In the free world the media isn't government run; the government is media run.
sure. store all those packets on the drives, then respond to them later when you have time!
Sleep your way to a whiter smile...date a dentist!
Which as we can see from the article doesn't work due to the many ways they can be leaked.
E.g., for www.example.com, try origin.www.example.com, ftp.example.com or IPs used in the past for www.example.com.
Still suspectible to a volumetric bandwidth attack. I.e., attacks with enough packets to overwhelm the origin server(s) or the ISP link to those servers.
Useless against a volumetric attack if they are just different IPs connected to the same uplink/router. Difficult to keep switching to use different ISP and each new provider brings its own problems.
Not cheap. The XOR DDoS botnet has recently produced DDoS attacks up to 150+ Gbps.
Attackers sending traffic through the public internet to your origin are sending them to one of many scrubbing centers. The combined capacity on all these scrubbing centers can cope with volumetric attacks. The scrubbing centers will only forward desireable packets to the real origin using GRE tunneling.
Akamai's BGP redirection service has some restrictions typical of other services. E.g.,
Your ideas are intriguing to me and I wish to subscribe to your newsletter.
CLI paste? paste.pr0.tips!
I actually work for one of the DDoS mitigation providers mentioned in this research paper. (Incapsula)
Speaking as an "insider" I can tell you that, while the statistical study is very interesting, none of the origin-exposing vectors it mentions are particularly new.
In fact all of these could be countered by few well-known best practices, which we are suggesting for years.
I've put up a list of things you can do to immunize your website from origin-exposing attacks. https://www.incapsula.com/blog...
I hope that now, with the subject getting some long overdue recognition, more people will get acquainted with these and pay more attention to their deployment configuration.
PS: IP masking is really not the best way to protect your origin. Today, almost all cloud-based vendors offer BGP enabled DDoS protection for direct-to-origin attacks.
You should allow requests only from mitigation services IP's. Nothing can break it then.
That's actually a very good practice that will counter many of the origin-exposing vectors.