mod_limitipconn throttling

IrPr

Well-Known Member
#1
Hi,

There is Per Client Throttling settings in Server -> Security tab, but limits global connections
Im hosting some similar hosts which have same visitors
is it possible to seprate Connection limits for each VH? then each IP address can establish to another VH even exceeded limit for another VH

Options such as Limit Max connections per directory, <File> and <Directory> or per MIME type using htaccess or VH configurations would be usefill too

btw what would be happened if limit exceeded? would response 403 or 503 ?

Thank in advance
 
Last edited:

mistwang

LiteSpeed Staff
#2
The difficulty is that the VHost information is only available after receiving the "Host" header in the request. Right now, LSWS only need to look at the source IP of the socket connection.

If the limit exceed, LSWS will close the connection immediately without any response.
 

IrPr

Well-Known Member
#3
The difficulty is that the VHost information is only available after receiving the "Host" header in the request. Right now, LSWS only need to look at the source IP of the socket connection.

If the limit exceed, LSWS will close the connection immediately without any response.
Oh ok, thanks for reply
I was tought that it may be such difficult
Any chance to be implemented in future releases?
I think an Exnended Status similar to httpd or maybe better will implemented in 4.0 release then this would be possible

PS: mod_limitipconn for apache needs Extended Status to be On either
 
Last edited:

xing

LiteSpeed Staff
#9
The global per ip src connection limit is the only way to go if you really want protection of high volume bots from your servers. The vhost method doesn't work and will not work in the real-world environment. To protect your VHOSTS in a secondary and more granual protection, use the Per VHOST Per Source Request and/or Bandwidth Limit currently in LiteSpeed.

Here is how your server is currently protected by LiteSpeed.

1) Client: Attempts to makes a tcp connection to LiteSpeed at port 80.
2.1) LiteSpeed: If the Src IP is blocked/over-limit drop/reject connection and stop everything right here.
2.2) LiteSpeed: If the Src IP is good, continue.
3) LiteSpeed: Wait for packets to come from Client which includes the HOST header.
4) Client: Bots will take as long they possibly can to send the request packets.
5) LiteSpeed: Got request data, time to process request which include Host info.

The question is not whether it's possible to have per VHOST connection limits but whether it's actually useful in real deployments. We already have VHOST level per source request/s and bandwidth/s (in and/or out) limits in litespeed.

A) If a VHOST has high per-src connection limit while another VHOST has low limit, the attacker will still more likely to bring down the entire server due to the VHOST having a high per-src limit. In this case, the different limits has no long term value when it comes to protection. Either you give the same protection to all your shared hosting clients, or none-of them. You cannot pick and choose because they all are on the same physical server and the server's resource is what you are trying to protect.

B) If the per vhost src-ip connection limit is added, we are allowing the connection to actually happen and delaying the ddos protection to Stage 5) of the above timeline instead of stage 2), you have just given attackers much of the system resources and in effect, giving them much higher chance of succeeding. We are letting them connect, linger for a while, before we can do something. In this case, this per vhost per connection limit feature will have actually reduced LiteSpeed's protection and amplified the attacks.

C) Perhaps you just want to setup a system where you want to charge more for high volume clients and give them more "per ip src connections". This could be the case that would make sense since it has nothing to do with protection and more to do with value-added-service because as detailed in B) and C), the proposed feature will actually either have at best no effect or at worst, decrease the security protection of the server.

Of course, never say never. We are always looking for ways to improve and will listen to all suggestions. Others can chime in to see if there are any other user-cases where this feature would help/enhance the protection of the server.
 
Last edited:
Top