9 ms·
My first DDoS attack for a $200 ransom
- jasonlfunk 10y agoApparently, it didn't work. :) Site not installed The site ghirardotti.fr is not yet installed [Edit: it's up now.]
- jasonlfunk 10y agoThough, it is interesting how an article with a dead link made it on the frontpage with 3 points.
- LaurentGh 10y agoIt's working well for me. And as it's a GitHub website, it should be ok...
- LaurentGh 10y agoAnd there are 73 persons on it right now if I believe Google Analytics
- barkingcat 10y ago[ Edit: I'm almost certain it's an ipv6 vs ipv4 issue. the ipv4 addresses resolve to github pages land, the ipv6 address resolves to somewhere inside OVH - the issue being that if the viewer's network infrastructure prefers ipv6, they will get a holding page from OVH stating that that "Site not installed / The site ghirardotti.fr is not yet installed" ] Dig: dig ghirardotti.fr ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 19860 ;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;; ghirardotti.fr. IN A ;; ANSWER SECTION: ghirardotti.fr. 3112 IN A 192.30.252.154 ghirardotti.fr. 3112 IN A 192.30.252.153 ;; AUTHORITY SECTION: ;; ADDITIONAL SECTION: Both ip's belong to Github, probably used as a failover/load balancing/round robin pair of some kind. reverse dns dig -x 192.30.252.154 ; <<>> DiG 9.8.3-P1 <<>> -x 192.30.252.154 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46826 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;154.252.30.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 154.252.30.192.in-addr.arpa. 3593 IN PTR pages.github.com. dig ipv6: dig AAAA ghirardotti.fr ; <<>> DiG 9.8.3-P1 <<>> AAAA ghirardotti.fr ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 0 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;ghirardotti.fr. IN AAAA ;; ANSWER SECTION: ghirardotti.fr. 1613 IN AAAA 2001:41d0:1:1b00:213:186:33:19 ;; Query time: 91 msec Reverse dns on that: dig -x 2001:41d0:1:1b00:213:186:33:19 ; <<>> DiG 9.8.3-P1 <<>> -x 2001:41d0:1:1b00:213:186:33:19 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25262 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;9.1.0.0.3.3.0.0.6.8.1.0.3.1.2.0.0.0.b.1.1.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa. IN PTR ;; ANSWER SECTION: 9.1.0.0.3.3.0.0.6.8.1.0.3.1.2.0.0.0.b.1.1.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa. 85728 IN PTR cluster010.ovh.net.
- cpncrunch 10y agoIf they're using OVH they already have free DDoS protection. I use OVH myself and I've had a few mitigated DDoS attacks that I barely noticed. Perhaps 10 requests/sec is below OVH's detection threshold. My last one was 8.4Gbps @ 1 million packets per sec. 10 requests/sec would be difficult to even notice :)
- LaurentGh 10y agoNope, OVH is just for our domain name. Also is talking about my blog, not https://www.villa-bali.com https://www.villa-bali.com website, which is on AWS.
- LaurentGh 10y agoThank you for this investigation! I've learned how to use dig! I've just remove the wrong AAAA record, as there is no IPv6 for Github Pages.
- woud420 10y agoFor next time you don't want to have to copy and paste. No need for SED. cat <file> | cut -d ' ' -f1 | sort | uniq -c | sort -nr
- tyingq 10y agoRoughly, a somewhat lackluster response to a somewhat lackluster DDoS attempt. 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.
- tyingq 10y agoThinking on this some more, this story makes even less sense. 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?
- Remiii 10y agoI can't answer for LaurentGh but if I well remember is a temporary situation (for few months).
- spatten 10y agoYou do this by telling iptables to look at the X-Forwarded-For header when deciding what IP that request is coming from. This blog posts explains the whole thing: https://centos.tips/fail2ban-behind-a-proxyload-balancer/ 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.
- tyingq 10y agoThe article shows the run of the mill iptables syntax being used, no packet inspection... And, it's possible this is https, which would render the packet inspection useless.
- otto_ortega 10y agoUmmmm.... A cache layer for any web application is a must have, perhaps he could have avoided the attack all along if it were present on the system since day one?... At least for this kind of attack, a more serious DDoS won't be tamed by "just adding cache"
- brbsix 10y agoThe webpage[0] seems to be having issues. The best I could do was the Google cache[1] or the Markdown source[2]. [0]: http://lologhi.github.io/symfony2/2016/04/04/DDoS-attack-for-ransom/ http://lologhi.github.io/symfony2/2016/04/04/DDoS-attack-for... [1]: https://webcache.googleusercontent.com/search?q=cache:J7lca_k5dWcJ:ghirardotti.fr/symfony2/2016/04/04/DDoS-attack-for-ransom/+&cd=2&hl=en&ct=clnk&gl=us https://webcache.googleusercontent.com/search?q=cache:J7lca_... [2]: https://github.com/lologhi/lologhi.github.com/blob/master/_posts/2016-05-04-DDoS-attack-for-ransom.md https://github.com/lologhi/lologhi.github.com/blob/master/_p...
- adrianpike 10y ago> 40 cores [m4.10xlarge], but still unable to process 10 requests/sec my goodness.
- cpncrunch 10y agoThat's php for you. Although I use php myself quite often, it can be a resource hog if you're lazy about optimization. A customer I was working with was using wordpress, and their homepage took about 5 seconds to load due to a hideously inefficient wordpress module that was doing the exact same sql query thousands of times! With a little bit of optimization I managed to get it down to about 1 or 2 seconds. For my own sites, I mostly use static html or server-parsed html.
- tcdent 10y agoThe overhead of an SQL query has nothing to do with the language you're using.
- cpncrunch 10y agoOf course I'm aware of that. I was just giving an example of a specific case I came across. The point I was making is that there is a lot of inefficient php code out there.
- 27182818284 10y agoRecently a colleague and I took a PHP+MySQL page that was taking 1-2 minutes to load and were able to drop it down to 30 seconds after our first round of revisions. After a second round of revisions, we got it under 15 seconds, then after another round we got it to the 1-5 second range. Most of the optimizations were in the PHP not in the SQL.
- technion 10y agoI came to make the same point - but PHP itself is not directly the problem. 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.
- cft 10y agoHow come the original post has 55 upvotes, but the karma of of original poster is only 18 (6:33 PM GMT)?
- kornish 10y agoUsers receive one karma for one comment upvote, but one submission upvote yields less than one karma for the user.
- ultramancool 10y agoThis is an amazingly weak DDoS, put your site behind CloudFlare or similar free service and go take a nap. They'll tank this without raising an eyebrow.
- ninjakeyboard 10y agoprobably because I've been playing an mmo, but i like the use of the word 'tank' here
- drostie 10y agoThe etymology here is actually really interesting. The term "tank" was an Americanism for a swimming pool once upon a time, and the etymology of that is pretty well-known: it was imported from a Portuguese word meaning "pond" which ultimately came from India [1]. The same source quotes a 1960s usage of the term for "failure" in the sport of Tennis. 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 http://www.etymonline.com/index.php?term=tank [2] http://www.slate.com/articles/news_and_politics/explainer/2008/10/explainer_goes_in_the_tank.html http://www.slate.com/articles/news_and_politics/explainer/20...
- LaurentGh 10y agoYep, true, it's planned. But sometimes their captcha page tend to block some legitimate trafic... 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.
- raverbashing 10y agoI wonder what would happen if GET / only returned a redirect to somewhere (either an HTTP code or an HTML with window.location='http:/yoursite.com/new_page'
- placeybordeaux 10y ago> 40 cores, but still unable to process 10 requests/sec Stopped reading after that.
- st78 10y agoWell, typical SLA for server side is 500 ms, then you have a chance to load a whole page under 3 seconds, which is recommended by google usability findings. 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/57341f645b5f160adca6c1bc 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/57341f1a5b5f160adca6c19b 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.