Mitigating DoS and DDoS 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.

Enabling LiteSpeed Cache will increase the server's capacity to handle heavy traffic.

LiteSpeed Cache is designed to improve site load speed and handle increasingly high traffic. LiteSpeed Cache cannot block any DDos attack, however, it can help the server to handle hundreds or thousands of times more requests/second. This definitely helps lessen the impact of DDoS attacks. See these instructions to learn how to enable LSCache. For a cPanel server, you can use LiteSpeed Cache manager to mass enable LSCache in one click.

LiteSpeed Web Server includes a built-in Per-Client Throttling feature which allows you to block bad IPs.

Navigate to Configuration > Server > Security configurations > Per Client Throttling to find several configuration settings that you can use to limit the request, bandwidth, and connection rate per remote IP address.

Separate controls are available for throttling requests for static files and dynamic content.

The server allows setting separate bandwidth limits for inbound and outbound traffic.

• Bandwidth numbers will be rounded up in 4KB increments.
• Set to 0 to disable throttling.
• The Outbound Bandwidth limit allows serving more unique clients and prevents limited network bandwidth from getting used up by a small number of clients with fast network connections.

These settings control concurrent connections coming from one client (IP address) and guard against DoS attacks.

• Connection Hard Limit controls how many concurrent connections are allowed from one IP address. If an IP reaches the hard connection limit, the web server will immediately close newly accepted connections from that IP address, and move on to pending connections from different IP addresses. As almost all web browsers support keep-alive/persistent connections (multiple requests pipelined through one connection), the number of connections required in normal browsing is very small. Typically, one connection is enough, but some web browsers try to establish additional connections to speed up downloading. Allowing 4 to 10 connections from one IP is recommended. Less than that will probably affect normal web services.
• Use Connection Soft Limit, Grace Period, and Banned Period to spot and mitigate abusers: An IP address that stays over the soft limit for the length of the grace period will be banned for the length of time set in Banned Period. This is a good way to identify IPs that should be added to the Denied List.

Note: The number of connections can temporarily exceed the soft limit during the grace period, as long as it is under the hard limit. After the grace period, if it is still above the soft limit, then no more connections will be allowed from that IP for duration of the banned period.

Default Settings:

Updated Settings:

Static Requests/second = 40 Dynamic Requests/second = 2 Outbound Bandwidth (bytes/sec) = 0 Inbound Bandwidth (bytes/sec) = 0 Connection Soft Limit = 15 Connection Hard Limit = 20 Block Bad Request = Yes Grace Period (sec) = 15 Banned Period (sec) = 60

Explanation: An IP that has established more than 20 connections with the web server, or has established over 15 connections of over 15 seconds (the grace period), is treated as a DoS-attacker. The server will ban the IP for 60 seconds and record a log entry in the error log file. To exclude any IP from the client throttle limits (and bypass DDoS detection), add the IP with a trailing 'T' (aka trusted) in Allowed List (WebAdmin Console > Server > Security > Access Control).

The hard limit can be adjusted based on an attacker's strategy. If the botnet is not very aggressive, you will need to lower the limit to just below their max connection per IP, to make sure it won't affect a regular user. If they only make very few connections per IP, do not use the hard limit to detect them.

The blocked IPs can be found in the real-time-stats report.

You can take advantage of the Max Request/Response Settings to reduce memory usage.

Under Configuration > Server > Tuning:

• Try to set Max Request URL Length, Max Request Header Size, Max Request Body Size, Max Dynamic Response Header Size, and Max Dynamic Response Body Size to values that go just above what you need to run your site. Getting these settings trimmed down will help identify attackers and reduce the amount of memory used when you do get attacked.

• Set Connection Timeout to around 30 seconds and Keep-Alive Timeout to around 15 seconds or less. This will help close dead connections as soon as possible and make connections available to other clients.

Increasing the Max Connection Settings will increase capacity and allow you to mitigate attack without limiting yourself.

Default: Change to: You should adjust Max Connections and Max SSL Connections to 20K/10K or even higher as long as the server has enough free memory. The purpose of the change is to increase the capacity, not to limit yourself under DoS attack.

The number of connection on port 80 doesn't matter. As long as the service is up, you've won!

If you know an attacker's IP, you can block it. Under Configuration > Server > Security:

• Block IPs that abuse your web server by listing them in the Denied List in the Access Control table.

If your server is flooded by hundreds of requests from different IPs but to the same URL, you can set up rules to block access to that URL.

For example, in a control panel environment, to block all access to /foo/, in the /foo/.htaccess of the targeted domain virtual host, place the following:

RewriteEngine On
RewriteRule .* - [L,F]

In LSWS native mode, you can either use rewrite rules as indicated above, or native context configuration like so:

1. Create a context (Configuration > Virtual Hosts > View/Edit > Context > Add > Type = Static) to block access to that URL.
2. Set Accessible to No and the context URI to match or include the URL being attacked.

If the server is pounded with requests for /foo/bar.html, then adding a context with Accessible set to No and the URI set to /foo/bar.html will block all of those requests. You can also set the context URI to /foo/ to block requests to all URLs that start with /foo/.

LSWS is campatible with the most common ModSecurity Rules, such as Owasp, Atomicorp, Comodo and CloudLinux Imunify360 etc. You can enable one of them on LSWS.

If you need assistance configuring your site to mitigate attacks, check out LiteSpeed's Advanced Anti-DDoS Setup Service. LiteSpeed Denial of Service Packet Filter Setup Service will fine-tune your anti-DDoS configuration and set up iptables to automatically block attacking IPs detected by the web server.

To order LiteSpeed Advanced Anti-DDos Setup Service, please visit our store.

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.

Note: Your logging level must be set at least to NOTICE in order to see the reason an IP is banned.

grep BLOCKED_IP /tmp/lshttpd/.rtreport* 

BLOCKED_IP: 47.22.54.182,

Whenever the server adds an IP to the block list, it will write a log to error log:

[<IP.addr>] bot detected for vhost [<vhostname>], reason: xxxxx, close connection!

For example:

tail -f /etc/apache2/logs/error_log

 [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!

or

2018-12-05 12:18:05.440745 [NOTICE] [x.x.x.x] bot detected for vhost [APVH_example.com:443], reason: DetectByWAF, close connection!

You should be able to find out why it is added and take action accordingly.

If the IP was banned but a record was not found in error_log, it's possible that IP was dropped by mod_security.

 grep "47.22.54.182" /usr/local/apache/logs/modsec_audit.log 

If the IP address involved is in the LSWS trusted list, it shows:

2018-12-05 12:18:05.440754 [NOTICE] [x.x.x.x] trusted, ignore!

Whenever a mod_security with “drop” action is triggered, LiteSpeed will add the IP to the blacklist. If the IP is in the trusted list, it will be ignored. As with too many blocks, please review the mod_security rule and audit_log, as LSWS will follow the rules there.

If ModSecurity blocks a request and LSWS sees the IP as trusted, the request is still served with 403 response, but that IP won't be blacklisted. If an IP is blacklisted, LSWS will stop serving future requests from that IP.

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.