Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
litespeed_wiki:config:mitigating-ddos-attacks [2019/02/27 19:59]
Lisa Clarke [Check concurrent connections] Proofreading
litespeed_wiki:config:mitigating-ddos-attacks [2019/06/13 16:21] (current)
Lisa Clarke [Trusted IPs] Copyediting
Line 3: Line 3:
 LiteSpeed Web Server provides several features aimed at reducing and even eliminating the impact of HTTP-level Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks. You can either use LSWS built-in features or third party ModSecurity rules such as Owasp, Atomicorp, Comodo and CloudLinux Imunify360. The following LSWS built-in configuration settings will help mitigate such attacks. LiteSpeed Web Server provides several features aimed at reducing and even eliminating the impact of HTTP-level Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks. You can either use LSWS built-in features or third party ModSecurity rules such as Owasp, Atomicorp, Comodo and CloudLinux Imunify360. The following LSWS built-in configuration settings will help mitigate such attacks.
  
 +===== Enable reCAPTCHA feature =====
 +One of the most effective methods to mitigate DoS and DDoS attacks is to enable the reCAPTCHA feature. reCAPTCHA is a free service from Google that helps protect websites from spam and abuse. A “CAPTCHA” is a turing test to tell human and bots apart. It is easy for humans to solve, but hard for bots and other malicious software to figure out. The reCAPTCHA feature is supported as of LSWS 5.4RC1 and later. Please see [[litespeed_wiki:​config:​recaptcha|these instructions]] to enable reCAPTCHA.
 ===== Enable LiteSpeed Cache ===== ===== Enable LiteSpeed Cache =====
 Enabling LiteSpeed Cache will increase the server'​s capacity to handle heavy traffic. Enabling LiteSpeed Cache will increase the server'​s capacity to handle heavy traffic.
Line 128: Line 130:
   netstat -ntu | grep ESTABLISHED | awk '​{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr   netstat -ntu | grep ESTABLISHED | awk '​{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr
   ​   ​
-Please keep in mind that ''​netstat -ntu''​ will list TCP in TIME_WAIT state, which will inflate the number. For the correct concurrent TCP connections counting method, you should only count TCPs in ''​ESTABLISHED''​ state. Hence ''​grep ESTA''​ or ''​grep ESTABLISHED''​ will be required. ​+Please keep in mind that ''​netstat -ntu''​ will list TCP in TIME_WAIT state, which will inflate the number. For the correct concurrent TCP connections counting method, you should only count TCPs in ''​ESTABLISHED''​ state. Hence ''​grep ESTA''​ or ''​grep ESTABLISHED''​ will be required
 + 
 +==== Analysis of IPs from Attacker ====  
 + 
 +Bad IP's can make quick connections,​ and you end up with many ''​time_waits''​ which you won't see when just looking at established. 
 + 
 +If you don't necessarily count concurrent connections,​ and just want to analyze which IPs might be attackers, you can include ''​time_waits''​ connections. Run the command without ''​grep ESTABLISHED'',​ which gives you the ability to see what IP's just connected and dropped and may need to be blocked: 
 + 
 +   ​netstat -ntu | awk '​{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n | awk '$1 >= 5 {print $0}' 
 + 
 +An attacker could make a connection, send requests to an expensive URL, wait a little while, and then close the connection. If the server does not abort the process, the backend will be used up soon, as it will keep serving requests that have been abandoned. The above command will be useful during such a situation
 ==== Check the Banned IP and Reason ==== ==== Check the Banned IP and Reason ====
 If an IP has been banned, but you don't know why, you can check it with SSH. Here is an example of a connection that was banned because it reached the hard limit. If an IP has been banned, but you don't know why, you can check it with SSH. Here is an example of a connection that was banned because it reached the hard limit.
Line 148: Line 160:
  ​[NOTICE] [x.x.x.x reached per client hard connection limit: 1, close connection!  ​[NOTICE] [x.x.x.x reached per client hard connection limit: 1, close connection!
  ​[NOTICE] [x.x.x.x] bot detected for vhost [N/A], reason: OverConnHardLimit,​ close connection!  ​[NOTICE] [x.x.x.x] bot detected for vhost [N/A], reason: OverConnHardLimit,​ close connection!
 +</​code>​
 +or
 +<​code>​
 + ​[NOTICE] [x.x.x.x] bot detected for vhost [N/A], reason: OverConnSoftLimit,​ close connection
 </​code>​ </​code>​
  
Line 176: Line 192:
 In LSWS Admin Console Server → Security → Access Control → Allowed List, you can set Trusted IP there with trailing “T”. In LSWS Admin Console Server → Security → Access Control → Allowed List, you can set Trusted IP there with trailing “T”.
  
-=== Set Trusted IP on Virtual Host Level ===  +=== Set Trusted IP on Virtual Host Level .htaccess ​===  
-Since LSWS 5.4RC1, LSWS added virtual host trusted IP support, where you use ''​Trusted 1.2.3.4, 5.6.7.8''​ in Virtual Host document root .htaccess to unblock blocked IP and make that IP trusted for that vhost.+Since LSWS 5.4RC1, LSWS has virtual host trusted IP support, where you may use ''​Trusted 1.2.3.4, 5.6.7.8''​ in the Virtual Host document root .htaccess to unblock ​blocked IP and make that IP trusted for that vhost. This is not the same as the **Trusted IP** configured by Admin at server level. It has no effect on bandwidth. The main effect of adding it in .htaccess is to take that IP off of the blacklist and disable WordPress Protect and reCAPTCHA when accessing that specific virtual host
  
 ==== Drop or Deny ==== ==== Drop or Deny ====
 What if ModSecurity does a drop (TCP FIN) rather than deny for a trusted IP? The trusted list only has an effect on the "​drop"​ action, but not on the "​deny"​ action. A trusted IP won't be added to blacklist, but trust status has no effect on other actions. What if ModSecurity does a drop (TCP FIN) rather than deny for a trusted IP? The trusted list only has an effect on the "​drop"​ action, but not on the "​deny"​ action. A trusted IP won't be added to blacklist, but trust status has no effect on other actions.
  • Admin
  • Last modified: 2019/02/27 19:59
  • by Lisa Clarke