Cloud DDoS Mitigation Services Can Be Easily Bypassed (softpedia.com) 40
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.
Re:Duh (Score:5, Insightful)
I'm not so sure if hard drives help mitigate DDoS. But hey, feel free to give it a try!
Re: (Score:1)
sure. store all those packets on the drives, then respond to them later when you have time!
Re: (Score:2)
Your ideas are intriguing to me and I wish to subscribe to your newsletter.
G2O to the rescue (Score:2)
If you use Akamai, you can turn on the G2O feature [f5.com] and configure your servers to check for it. Apache, Nginx [github.com], F5 load-balancers [f5.com], IIS [akamai.com], 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 c
Re: (Score:1)
Do you understand how a DDoS works? If they can find your server IP, they can flood it with more traffic than you can imagine. Very few bother with "request spam" type resource attacks -- because they are "trivial" to deal with. (spin up more VMs, offload to CDNs, etc.)
Re: (Score:2)
The "offload to CDN" method is exactly, what you need something like G2O for...
have your origin accessible to only your provider (Score:3, Interesting)
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?
Re: (Score:2)
Re: (Score:3)
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 t
Paper finds most webmasters don't have a clue (Score:3, Insightful)
Re: (Score:2)
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.
One "hole" that they missed is that a lot of sites send confirmation emails when creating an account, and that can reveal the IP in the email headers.
Re: (Score:2)
P.S. I love the point you made. I did not think of that hole in the armor.
Re: (Score:2)
What I did at first to fix this potential hole was to catch the incoming email and then do a manual activation and reply from a Yahoo account. Later I had the email trigger a script that sent a signal to a different server and that server sent the email.*
Of course, if they were really determined they'd just start DDOSing that server which would crash other sites I own, but I figured they'd be watching the original site to see if it was being affected, and when it wasn't (because they weren't hitting the ri
Easily? (Score:5, Insightful)
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.
Re:Easily? (Score:5, Insightful)
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.
Or they are using it as a free caching CDN like me, and dont care about IP being exposed.
Re: (Score:2)
Re: (Score:2)
Who the heck actually still runs an FTP server as part of their website, in this day and age?
More than I care to admit or remember... I've seen a lot of advertising firms using FTP for transferring material to/from clients all over the place. They figure user/pass and origin IP are secure enough. Well, maybe their data isn't important enough to transfer with any level of encryption.
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
Very true, but many smaller websites may not have the luxury of moving their IPs about.
Re: (Score:2)
$ ftp ftp.slashdot.org
ftp: Can't connect to `216.34.181.48:21': Connection refused
It's just a stale DNS record.
Re: (Score:2)
$ 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.
Re: (Score:3)
"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."
Every site that provides downloadable drivers for your hardware almost certainly has an FTP mirror.
Re: (Score:2)
No way! Cloud Flare assured me that they could hand 520 Unknown error [cloudflare.com]
I don't think that means they can handle 520 different unknown errors...
Email Headers (Score:5, Insightful)
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.
Re: (Score:2)
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.
Dang, you beat me to it. :)
I posted a slightly longer explanation, but yes, you are exactly right. Email confirmation messages can reveal the IP.
This is true, plus on they missed (Score:2)
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
Only applies to 'Proxied' Cloud DDOS services (Score:4, Informative)
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.
Re: (Score:1)
Re: (Score:1)
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.
Good for them for raising awareness (Score:1)
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... [incapsula.com]