Sorry for the trouble you had. Did you submit a support ticket to CloudFlare? Sounds like something was blocking requests from our network.
LOIC and a number of the more public DDoS tools make the attackers' identities relatively easy to track. The big attack we saw last Saturday is much more difficult to trace both because it is originated with a UDP request (the headers of which can be forged) and because it is reflected off open resolvers (essentially laundering the identity of the attack's source).
We tried to use Cloudflare when they teamed with Dreamhost a few months ago. We had more downtime than uptime....
Though this is super-relevant because during the struggle with Cloudflare, we released an article about LOIC and how easy it is to reveal the locations and identities of individuals involved in a DDoS attack using LOIC.
My point is the traffic isn't coming FROM CloudFlare. When you're attacked, there's no way of knowing who is attacking you. Your recourses are the same even if CloudFlare wasn't protecting the brochure/control panel websites of the services.
If you are being DDoSed. What do you do? Call the local police? Email abuse@fbi.gov?
The article mentions that these were UDP attacks... which are usually reflections based on spoofed IP addresses. So who should Cloudflare contact? In the meantime another few hundred small attacks arrive. It's more constructive to improve the capability to mitigate attacks as they and other network providers have agency over that.
After detecting a botnet attack originating from Cloudflare IPs, we logged in to Cloudflare. Shortly after, we received the message: "Sorry, you have been blocked. You are unable to access www.cloudflare.com." We hypothesize that a larger scale attack is underway.
Hmm i find the report a bit disappointing, besides mentioning how long the attack lasted, and that different providers restored DNS(edit, auto spellcheck failure) responses to a regular response time at different times, it says very little.
Where did the attack originate from? What was the actual attack 'request'? How many queries per second were there at the point of failure? Why do you tell cloudflare about all your traffic? (yes i don't like cloudflare or sites hosted via/by/proxied etc)
They weren't able to talk to my origin IP, because when I was using Cloudflare, I blocked at the firewall all IPs that weren't Cloudflare. The problem is that they would DDOS my server through Cloudflare. And because the traffic was being proxied, I couldn't block the attackers without blocking Cloudflare. Unless of course I wanted to fill out a form on their website 9,000 times. It's an awesome website by the way. I love their workers and r2 products. But Cloudflare honestly isn't that good at DDOS protection. These attacks were so bad that Cloudflare would start showing NGINX error pages before my web app even went down. Cloudflare should be paying me to protect them, rather than the other way around.
Is it plausible some ISP shared some IP address that was on Cloudflare's list of suspicious IPs, or that some IoT device on this person's network created a burst of suspicious traffic?
I get that this sucks for the end user, but I wonder how much we should blame Cloudflare vs the wider systemic challenges of managing DDOS protection on the web.
I don't trust any analysis from CloudFlare. These are the same people preventing people with vpns or tor browsers from reaching sites while screaming and yelling OMG DDoS!! then blaming the customer of CloudFlare for not knowing how to configure it.
Oh wow. I'm pinging the folks I know at CF, but it looks like they got owned. A quick dig shows that cloudflare.com points to the same server running clickfunnels.com; not sure what that indicates about the attack.
EDIT: scratch that, different IP.
EDIT 2: A CURL to www.cloudflare.com gives an error page. A CURL with the FF agent header gives the redirect.
EDIT 3: Word is, not a hack. Configuration mistake.
"This was flagged to my attention and I've reviewed all the interactions between the author and our team [cloudflare]. The site in question was using the free version of CloudFlare's service. On February 2, 2013, the site came under a substantial Layer 7 DDoS attack. While we provide basic DDoS mitigation for all customers (even those on the Free CloudFlare plan), for the mitigation of large attacks a site needs at least the Business tier of CloudFlare's service. In an effort to keep the site online, our ops team enabled I'm Under Attack Mode, which is available for Free customers and enhances DDoS protection.
The attack continued and began to affect the performance of other CloudFlare customers, at which point we routed traffic to the site away from our network."
That's concerning. Could you elaborate on how you identified the traffic as cloudflare workers? Also, what sorts of HTTP attacks? wp-admin probes? Plain DDoS?
Cloudflare has (had?) a murky history with not taking down DDoS for hire services ironically hosted behind cloudflare. But while you could argue they had an incentive to do that (sell protection), I can't think of any incentive to let Workers be abused.
Changing info at the registrar would have fixed this, they would probably have only lasted a few minutes w/o DDOS but it's not like cloudflare singlehandedly banished them from the internet. I mean, they sort of did due to the lack of protection, but it's not like cloudflare has the keys to the entire internet; just their ddos service.
LOIC and a number of the more public DDoS tools make the attackers' identities relatively easy to track. The big attack we saw last Saturday is much more difficult to trace both because it is originated with a UDP request (the headers of which can be forged) and because it is reflected off open resolvers (essentially laundering the identity of the attack's source).
reply