All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
POST attack Flood
Hello everyone!
Recently I have been undergoing POST attacks directed at actually existing url on our site.
Using Wordpress, Nginx, Varnish,
Some useragent:
"Mozilla / 5.0 (Windows NT 6.1; WOW64) AppleWebKit / 537.36 (KHTML, like Gecko) Chrome / 43.0.2357.81 Safari / 537.36"
"Mozilla / 4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident / 4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4 .0E; Media Center PC 6.0) "
We are behind Cloudflare, nevertheless 90% of ip in the attack are Cloudflare.
http://grabilla.com/0650e-36ebb0f9-5887-4772-a22e-f4c28ea8009d.png
Someone can help me? Do you know a good way to mitigate these attacks?
Sorry for my English
Comments
Post flood attack? Increase your website protection to medium.
How about create rule matching POST data using mod security?
Hello, also in High does not block Cloudflare.
the posts are addressed to existing and legitimate articles on our blog.
what about get those ips and block em?
Switch to "I'm under attack" mode on CloudFlare, should stop them for the time being. And then try to find a more permanent solution
OP, add this into your server {} blocks:
https://support.cloudflare.com/hc/en-us/articles/200170706-How-do-I-restore-original-visitor-IP-with-Nginx-
Reload nginx, and any attacks will appear with real IP so you can block
One thing is, if your website isn't possibly of any interest to the Chinese, just block whole China IP ranges (available online) - I got a Chargen DDoS attack on my server before, when I asked my hosting provider to provide logs, most IPs are from China ISPs, probably a botnet.
I don't think it helps? I might be wrong. Just captchas for weird User-Agents.
Make a custom fail2ban filter like this:
http://xplus3.net/2013/05/09/securing-xmlrpc-wordpress/
Adjust pattern as needed.
Disable the comments till the attack is over?
"I'm under attack" mode forces every visitor's browser to solve a JavaScript puzzle, so it should stop most skid attacks
Yeah, the 'checking your browser' splashscreen is a hashcash style implementation, forcing the client to 'do work'.
It's easier to scale thousands of requests using a plain HTTP request than it is to have a JS enabled most-likely headless browser, the former failing the test.
I have nginx-testcookie installed to prevent layer7 + floods from browsers without JavaScript or cookies
enabled.
Basically, I modified it so it performs a few cookie checks, some calculations with JS and a user-agent check. It adds up the score in the browser and decides whether the proof cookie should be set. (proof being an encrypted hash with the time + IP + challenge time + request ID)
We have seen something like this this a few times (I am guessing its the same script or similar). Theres a quite a few ways we mitigate it. Heres some simple ways:
In our case this attack was JS aware using PhantomJS/V8.
Sorry I cant go into more details, we dont usually share our mitigation techniques. Cant have the bad actors adapting.
That's an easy one to mitigate I think, as it has variables in the document scope that can easily be detected. Bit harder with the likes of mozrepl. Browser uniqueness would be worth looking at if you were to go down that rabbit hole. I'd sooner analyse what they are POSTing and to where wrt the application layer.