Live data from Hacker News

My first DDoS attack for a $200 ransom

ghirardotti.fr

31–40 of 67 posts

Re: My first DDoS attack for a $200 ransom

#31
post #8

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.

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.

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…

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

#33

Earlier 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.

That 2500 is after taking into account relevant database queries. With async servers (which, as far as I know, PHP can't be, at least with the way it typically integrates into Apache) you can accept all the requests, forward off the database requests each depends on, and still send back the pages to everyone who requested one.

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

#34

Earlier 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.

Not talking NOOPs. I'm talking multiple full round trips to the database per query.

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

#36

Earlier 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

A better test would be to disable any cache plugins in your wordpress and then run tests against your site.

Re: My first DDoS attack for a $200 ransom

#37
post #32

Earlier 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.

Of 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.

Re: My first DDoS attack for a $200 ransom

#38
post #8

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.

I bet you I can write a website in NodeJS or Go that will fail with fewer than 1 request / second. Heck, I bet you I can make a website that will fail even if it only receives one request in its lifetime!

The language usually isn't the reason for issues like this...

Re: My first DDoS attack for a $200 ransom

#40
post #11
post #8

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…

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…

There's a few cases; some have mentioned scenarios where you might want SSL offload. Those are perfectly valid. I'll contribute another.

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. =)

Post reply on HN