to compress or not to compress?

[felosi]

Lately there have been a lot of new kinds of ddos attacks coming up.I have been seeing a lot of this one where it actually uses the zombie computers browser and requests pages over and over unless it is just a good user agent spoof.

Anyway they are using these type of attacks on php/mysql sites because it will take down a server easier with less bots.

And it is usually pretty hard to fight off these type of attacks because they hardly ever build up enough connections to make anti-dos features or my firewall fire off. So its a constant battle.

Now, would it be better to turn off compression completely during these type of attacks?
Seems like it would use less cpu this way but would cost more bandwidth.

As far as the balance of bandwidth vs cpu which one would be a better choice? Surely using the dynamic compression on 1 does not save that much bandwidth, or does it?

 

[xing]

It really depends on the website in question, what type of content is pushed, the data distribution pushed back to the client. For example, an litespeed level dos protection strategy for a video hosting site is quite different than one that's only pushing mostly html/text.

Personally, I would say, CPU is usually the last resource exhausted in a litespeed system if the proper throttles are in place.

By reducing the data pushed to the client, you are reducing the number of aggregate packets hitting back so using compression is an advantage.

1) If the system is a blog/general website with very small POST, non-video upload, operations, set the "Per Client" incoming throttle to a very small value. For example, a 50KB incoming throttle should be more than enough.

2) You should always use keep-alive and have KA enabled in litespeed. KA uses a bit more cpu and ram but the advantages are numerous. In a keep-alive setup, a real web user should never use more than 3-5 concurrent TCP HTTP connections. Even if they download 100 pages per second, keep-alive connections allow real browsers to pipeline and queue those requests. Knowing this, a good throttle to have is understand the site in question and set this value. "Per Client" max connections soft and hard limit to something like soft:10, hard:15 is usually more than enough and even conservative.

If both 1/2 is properly set, you would need a very very large pool of zombies to have a true dos effect and 99.99% of the time, that's not the case. The floods are coming from a small finite pool of ips.

Not the least, you should have "syn cookies" enabled in your server. This will protect, not prevent, 1 packet SYN floods from even a small pool of zombies. Without this protection in place, even 2 clients can render your server useless. No request gets even past the L4 stage.

That's properly too bloated an answer to your question. But in my view, leave it on and optimize/throttle elsewhere where it is more meaningful.

 

[felosi]

yeah, I got other measures in place and litespeed is still 100 times better then apache in such situations but I guess its just php/mysql in general that are easy to take out. On the connection throttling I use 5 static requests per second, 1 dynamic requests per second. Connection limit 5 soft 15 hard. If I set the connection limit much lower Ill hear about it from clients and even manage to get myself banned.

As far as smart keep alive is concerned would it be better to have that disabled for a webserver where dealing with ddos is an everyday thing? Right now I have smart keep alive enabled with a keep alibe timeout of 10 seconds.

As of now I can pretty much take care of anything that gets to the server except these get attacks on php/mysql. I have heard some people call them CC attacks. And you are right it really depend son the script and how good its coded, all that.

Anytime you wanna come test a bit and play around let me know. Ask George what goes on in my servers lol. he has seen it plenty of times first hand and has helped me quite a few times.

But yea, if you ever wanna come tinker with litespeed in a live high stress environment, either ddos or high traffic lemme know. I got plenty of both

 

[xing]

Enabling KA allows much more accurate per client connection throttling. Without it, a client that visit a page with 50 pictures, it's hard to say how many connection his browser might behave and how many connections it might need/user to achieve a smooth page render. So the limits must be set higher. If KA is used, we can safely assume a much lower threshold knowing well the browser will not misbehave and open 10 KA connections regardless of the number of items from that domain. From what I see in a high traffic environment, browsers will not use more than 3 KA. Anything above 5 is suspicious and anything 10+ is either a crawler (google, yahoo), a proxy (aol), or script kiddies trying to scan for stuff. You would use the security accept/deny features to greenlist google, yahoo, aol. The last thing you want is a dos setting that slows down google's crawling speed and google can crawl very fast if it's allowed.

I would say KA timeout of 5 is enough. If a client's page takes more than 5 seconds to load, that's an another problem outside the scope of litespeed. =)

Haven't seen your setup or traffic volume yet, but I'm sure I will, one of these days. =)

 

[felosi]

oh yeah I use keep alive but I was wondering if the "Smart Keep Alive" would be better in tehse situations since it only keeps alive certain connections.
I am going to do some testing and see if I see a difference