mod_limitipconn throttling

Discussion in 'Feedback/Feature Requests' started by IrPr, Aug 20, 2008.

  1. IrPr

    IrPr New Member

    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: Nov 26, 2010
  2. mistwang

    mistwang LiteSpeed Staff

    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.
  3. IrPr

    IrPr New Member

    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: Aug 20, 2008
  4. IrPr

    IrPr New Member

    Bump
    any update on this?
  5. anewday

    anewday Moderator

    I want this feature too. ;)
  6. fastproxy

    fastproxy New Member

    Me too, This feature is essential for shared hosting server especially
  7. anewday

    anewday Moderator

    Any updates?

    It'd be nice to be able to exclude certain extentions and directories.
  8. IrPr

    IrPr New Member

    Any chance?
    Please update us if you can add this feature to your todo list
  9. xing

    xing LiteSpeed Staff

    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: Nov 26, 2010
  10. ravendawson

    ravendawson New Member

    Great, thanks for the info.

Share This Page