They tried blocking specific ip addresses, which didn't work, because the attack was somewhat distributed. They then just turned on some caching, which allowed the site to function, albeit with an unknown excess bandwidth charge pending.
And, the DDoS itself can't of been terribly impressive, as all it took to mitigate was a bit of caching. He mentions 10 requests / sec as the scale of the attack.
He first mentions having to change Apache to recognize X-Forwarded-For, because there is Amazon Elastic Load Balancing between his site and the internet.
This means, of course, that the "attacking ips" aren't making direct connections to his EC2 instance. They are proxied connections, all from the internal ELB service.
So later, when he mentions trying to use iptables to block traffic...that just doesn't make sense. There are no connections from those ips to the EC2 instance. You could use .htaccess rules, since Apache is aware of X-Forwarded-For.
Lastly...why would you put an elastic load balancer in front of a single web server?
This blog posts explains the whole thing: https://centos.tips/fail2ban-behind-a-proxyload-balancer/
I have no idea if using .htaccess rules would be better than this solution, I just know that this one works.
Let's say you have a single web server you need to have up all of the time. You need high availability, but not necessarily instant fail-over, because you want to keep your costs low, and so you don't want two instances running all of the time. It may not serve much traffic at all, so there isn't much load to spread. What you can do is place an ELB in front of the web server, set a condition to start a new instance if the page becomes non-responsive (i.e., a failure), and set the auto-scaling to "min 1, max 1." This way, you'll always have a pool of one server, that will automatically rebuild if the instance fails.
I admit, it's not a common use case, but it's one of the more clever uses of the ELB I've heard. =)
Everything could have been planed way better (cached, written with a fancy language...), we could have had 10 mil requests/µsec... the main idea was just to get tell how we tried to manage the situation, with the website and skill we have.
I also think my testimony is nearer to what most of web dev can be confronted to, in contrary to one Cloudflare/Gihub BS press release written by 10 experts to increase valuation :p
I use async logic (previously OpenResty, more recently NodeJS and Go) and largely pregenerated sites, so 2500 requests/second is a minimum baseline -- on a much lower end instance than an m4.xlarge.
There's a reason I don't use PHP (or any primarily synchronous language like Ruby) any more.
Say an API call spins up a Linux VM and makes it available some user. Or a bulk upload of data which needs to be indexed. Or whatever.
The idea that a site should be able to handle X requests/sec because the stack can handle X NOOPs per second is odd.
[1] https://nestify.io/wp-content/uploads/2015/10/loader.io_.png
The language usually isn't the reason for issues like this...
The term actually seems to come from a 1920s boxing euphemism [2]: when a boxer is not actually knocked out but voluntarily lays down on the ground, it was called "a dive" for obvious reasons; euphemistically some people called this "going into the tank," since you'd dive into a pool.
How did this start referring to the vehicle? Again, back to [1], there was once a memo "recommending the proposed "caterpillar machine-gun destroyer" machines be entrusted to an organization "which, for secrecy, shall be called the 'Tank Supply Committee,' ..." and the rest is history.
[1] http://www.etymonline.com/index.php?term=tank
[2] http://www.slate.com/articles/news_and_politics/explainer/20...
It's not that impressive because we read everyday articles about crazy DDoS big companies are able to mitigate. But when it's the website your responsible for, whatever the number of requests/sec, you just need to find way to manage it, and CloudFlare can have some weird side effects.
my goodness.
For my own sites, I mostly use static html or server-parsed html.
There are many, very popular Wordpress plugins that take hundreds of SQL queries just to render a landing page. 10 hits/sec legitimately is "DDoS" territory for many businesses running such things.
cat <file> | cut -d ' ' -f1 | sort | uniq -c | sort -nr
Site not installed The site ghirardotti.fr is not yet installed
[Edit: it's up now.]
At least for this kind of attack, a more serious DDoS won't be tamed by "just adding cache"
[0]: http://lologhi.github.io/symfony2/2016/04/04/DDoS-attack-for...
[1]: https://webcache.googleusercontent.com/search?q=cache:J7lca_...
[2]: https://github.com/lologhi/lologhi.github.com/blob/master/_p...
villa-bali is not even close to this, my bet that you (or your ORM) are making too many requests to database. Try to record ALL requests to database during page rendering and I bet you have about hundred. Check out following test results:
8 test agents: http://loadme.socialtalents.com/Result/ViewById/57341f645b5f... - 5% of users have to wait more than 2 seconds 16 test agents: http://loadme.socialtalents.com/Result/ViewById/57341f1a5b5f... 5% of users need to wait for more than 4 seconds.
Definitely, any bot can nuke your website easily.
Stopped reading after that.
