Roughly, 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…
I was shocked that 12 requests/second could take down any site. 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.
My first DDoS attack for a $200 ransom
31–40 of 67 posts
Re: My first DDoS attack for a $200 ransom
#32> 40 cores [m4.10xlarge], but still unable to process 10 requests/sec my goodness.
That'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…
Re: My first DDoS attack for a $200 ransom
#33Earlier quoted context omitted.
I was shocked that 12 requests/second could take down any site. 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.
The language used is meaningless absent the context of the whole application, especially the database. I can do 2500 requests a second with ruby or php on a micro instance on AWS. But that's meaningless after I plug into a mysql database that's going to bottleneck at 2 requests a second after i try to render abad wordpress theme out of MySql.
Of course I've avoided WordPress and similar frameworks for years for a reason as well; I've seen front-end frameworks that require dozens if not hundreds of database queries to render a page, which is such bad design that it makes my brain hurt.
Re: My first DDoS attack for a $200 ransom
#34Earlier quoted context omitted.
I was shocked that 12 requests/second could take down any site. 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.
If the request is performing heavy calculations you will see fever req/sec obviously. 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.
Node can render more NOOPs per second than that; I've heard of a well tuned Node server hitting 100k. But because of the async nature of the handling of responses, you don't need dozens or hundreds of threads to handle thousands of clients, and it's the threads that kill you.
Unless you've just got an awful architecture, in which case that will kill you first.
Re: My first DDoS attack for a $200 ransom
#35For next time you don't want to have to copy and paste. No need for SED. cat | cut -d ' ' -f1 | sort | uniq -c | sort -nr
tail -n 10000 apache.logRe: My first DDoS attack for a $200 ransom
#36Earlier quoted context omitted.
I was shocked that 12 requests/second could take down any site. 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.
A well configured small / medium instance should easily handle 100 requests/second. My test PHP setup on micro instances serves 1000 requests/second before any signs of slowdown. [1] [1] https://nestify.io/wp-content/uploads/2015/10/loader.io_.png
Re: My first DDoS attack for a $200 ransom
#37Earlier quoted context omitted.
That'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…
The overhead of an SQL query has nothing to do with the language you're using.
Re: My first DDoS attack for a $200 ransom
#38Roughly, 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…
I was shocked that 12 requests/second could take down any site. 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.
The language usually isn't the reason for issues like this...
Re: My first DDoS attack for a $200 ransom
#39Re: My first DDoS attack for a $200 ransom
#40Roughly, 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…
Thinking 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…
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. =)