Just limit the number of connections from each IP, LSWS will block IP that abuse the server automatically, no need to do anything extra unless you are hitting by a botnet with hundreds or thousands zombies.

Well what you have here is a classic get attack. I suppose the site is a php/mysql site? The goal of such attack is resource exhaustion, they can be difficult to mitigate but it can be done.

What I first recommend is csf firewall with connection tracking features on, you wanna make a ct_limit of about 25-60 depending on how many connections most legit users make. Then make the ban permanent - ct_perm to 1. Then turn on the mod_security failure blocking.

Then set your litespeed settings as suggested above. I usually keep the connection limits to 5 soft, 15 hard. And even lower if needed but be careful legit users may start getting banned. It also has a lot to do with the sites as well. If they have a lot of images and other things to load it will have more requests per second as well as connections. Optimizing your site will help as well.

Then if all else fails, tail your access_log and see if you see a pattern with the user_agent like if they are all using the same user_agent. Get that and google it to see if it is a legit one, if not then just edit one of the mod_security rules for user_agents and put that one in there. Or use iptables string match to get it.

Then if all else fails try a click to enter page, a simple html page with enter link, If the attacker modifies their attack to go directly to index.php or whatever then you will be fighting a losing war and it is time to think about getting some ddos protection somewhere that has one of the click or captcha pages at the router.

Sasha, good mod_security rules will help with a large percentage of what you are getting hit with, and reduce the load on your server quite a bit. Due to the size of the forums you're running you'd be better with:

I get some of the same errors, and I asked about them in an email to LS Support, and they responded that they don't mean anything, because if you wait a few minutes and refresh the page the errors are all gone. They are mod_security alerts, so technically you could go through the mod_security log and find out what it triggering it, but I never have and everything works fine.

Another good tool to install and configure is MailScanner. You can protect yourself from the HTML:Iframe injections, and it works perfectly with ClamAV. Just configure everything, start it, and it scans incoming and outgoing mail for spam to protect your server from rogue spam scripts, as well as from people trying to use your server as a mail bomber / spammer / etc.

Make sure you have all the php.ini disable_functions set in the default /usr/local/lib/php.ini
Make sure you have safe mode cgi so cgi scripts CANNOT override the default php.ini permissions (as that is what the latest crackers are using to root boxes).

I have SuPHP, Suhosin, Safe Mode, Safe CGI Mode, mod_perl, mod_security, mod_bandwidth, and when setting up packages choose for users to NOT have cgi access unless you know that person and can trust them. It's what puts you at risk for more sql injections and so forth.

I learned the hard way. Then once all that is recompiled, build matching php in LSWS.

I don't give anyone CGI access unless they request it for special reasons.

Note: A common misbelief is that VPS already have CGI safe-moded, but in reality it depends upon the actual setup they have. Most can be circumvented and end up rooting the entire box, hence wiping out your VPS and the rest of the raid storage; thus putting you at financial responsibility for the damage caused if it happens. You can Google 'safe mode cgi' and see the supply of workarounds.

Now as far as the protection part, well I can only offer enough knowledge to show what I did, and I use WHM/cPanel. So here are my steps I took, which I assume should exist in other Admin Panels.

Click Basic cPanel/WHM Setup and scroll to the CGI Access option and put a n there instead of a y.

Now whenever you create any new packages the CGI Access option will be unselected automatically; however, if you have already created some packages, you should edit each package and unselect CGI Access.

Now when I built Apache I chose these options by doing the exhaustive list of options and selecting all of the below. You will see the option for Safe PHP CGI.

I have also attached my default build to this post, as you can use that too, but be prepared to make some Suhosin edits in the php.ini if you run certain content. Usually just having this pasted at the bottom of the php.ini once everything is built will solve any issues associated with running Suhosin in environments such as bulletin boards.

now in /etc/my.cnf (this is just mine, which is on a dual Xeon 3.0ghz 4gb ram) Raghav or whomever may need to tweak yours for your specific hardware, but even applying this if you have nothing in your my.cnf will help reduce load averages and (d)dos effects

I have done all what has been said by Ant. Appreciate it.
But the Mod Security rules you posted on the other thread forbids members to post reply or post a new thread ... i think some settings has to be lowered..