Security Configuration

mod_security

It is possible to enable mod_security at the Web ADC level, but we do not recommend it.

mod_security at the ADC level will dramatically slow down the distribution of data. Instead, you should let the backend LiteSpeed Web Servers handle the heavy load incurred by loading, checking, and filtering mod_security rules.

If you still wish to enable mod_security, you may do so following our LiteSpeed Web Server instructions.

Anti-DDoS ConfigServer or iptables

LiteSpeed ADC's Anti-DDoS feature can be used to modify a firewall via ifconfig and ipset to block suspicious IPs. This guide explains how to integrate the ADC's Anti-DDoS feature with either ConfigServer Security & Firewall (csf), or iptables.

LiteSpeed ADC Configuration

Log into the ADC WebAdmin Console at https://SERVER_IP:7090. navigate to Configuration > Security.

Set Enable Anti-DDoS Protection and Enable Firewall Modifications to Yes to enable Anti-DDoS protection.

!

ConfigServer Security & Firewall Configuration

For csf, create the file /etc/csf/csfpost.sh, and add the following content:

#!/bin/bash
ipset create ls-anti-ddos hash:ip hashsize 4096
ipset create ls-quic-ports bitmap:port range 0-65535 -exist
iptables -I INPUT -m set --match-set ls-anti-ddos src -j DROP
iptables -I FORWARD -m set --match-set ls-anti-ddos src -j DROP
iptables -I INPUT -p udp -m set --match-set ls-quic-ports dst -j ACCEPT

Reload with the command csf -r.

iptables Configuration

For iptables, run the following commands to set up the list and rules:

ipset create ls-anti-ddos hash:ip hashsize 4096
ipset create ls-quic-ports bitmap:port range 0-65535 -exist
iptables -I INPUT -m set --match-set ls-anti-ddos src -j DROP
iptables -I FORWARD -m set --match-set ls-anti-ddos src -j DROP
iptables -I INPUT -p udp -m set --match-set ls-quic-ports dst -j ACCEPT

Verify the script works as intended by checking with the ipset list command. You should see two blocks: ls-anti-ddos and ls-quic-ports.

[root@test]# ipset list
...
...
Name: ls-anti-ddos
Type: hash:ip
Revision: 1
Header: family inet hashsize 4096 maxelem 65536
Size in memory: 65680
References: 2
Members:

Name: ls-quic-ports
Type: bitmap:port
Revision: 1
Header: range 0-65535
Size in memory: 524432
References: 1
Members:

Test

There are several cases where LiteSpeed ADC will consider an incoming request suspicious. For example, a failed reCAPTCHA test, or a badly formatted request.

For demonstration purposes, we will use a reCAPTCHA failed verification to trigger the block. So, if a visitor fails to verify repeatedly in a short period of time, the firewall block will be triggered and a log generated, like this one:

[root@test logs]# grep ipset error.log
2019-12-04 20:27:15.594490 [NOTICE] [24606] [T0] [FIREWALL] execute command: 'ipset add ls-anti-ddos 111.222.333.444 ', ret: -1, status: 0

If you run ipset list again, you will see content like this:

Name: ls-anti-ddos
Type: hash:ip
Revision: 1
Header: family inet hashsize 4096 maxelem 65536
Size in memory: 65696
References: 1
Members:
111.222.333.444

The block on the IP will be removed in 10 minutes, if the suspicious behavior stops. At that point, you should see this in the log:

2019-12-04 20:37:20.304327 [NOTICE] [24823] [T0] [FIREWALL] execute command: 'ipset del ls-anti-ddos 111.222.333.444 ', ret: -1, status: 0

WordPress Brute Force Attack Protection

A ‘brute force’ login attack is a type of attack against a website to gain access to the site by guessing the username and password, over and over again. WordPress is the most popular CMS and therefore it’s a frequent target of this type of attack. The wp-login.php and xmlrpc.php pages are the most common target of brute force attack by POST method. WordPress doesn’t have any built-in protection to prevent this, hence the need for a third-party solution.

LiteSpeed Web ADC has a built-in WordPress brute force attack protection system. It will protect shared hosting WordPress environments from large-scale brute force attacks, which have the potential to bring down entire servers.

How Brute Force Protection Works

The WordPress Protection directive is: [Throttle, Deny, Drop, Disable ]
The action is optional, and defaults to Disable. The Allowed Login Attempts can be set as value of (0|1|5-1000)

  • 0 disables WordPress Protection.
  • 1, when used by a virtual host, defers to the setting used by the server.
  • 5-1000 enables WordPress protection and also specifies the login value. (Values lower than 5 will be treated as 5, and values higher than 1000 will be treated as 1000)

The Allowed Login Attempts value specifies the maximum number of wp-login.php and xmlrpc.php login attempts allowed within 5 minutes before the IP is blocked.

This Allowed Login Attempts is handled using a quota system that works as follows:

  • The quota starts at the specified Allowed Login Attempts value.
  • Each POST attempt decreases the quota by 1
  • Once the quota reaches half of the value, the IP will be throttled, slowing more as the quota drops further.
  • When the quota reaches 0, the desired action (drop, deny, or throttle) is taken.
  • Over the course of 5 minutes without further POST attempts, the quota gradually increases back to the set Allowed Login Attempts.
  • Restarting LSADC will reset the quota back to the specified value.

Example

  • Assume the Allowed Login Attempts is set to 10.
  • When there are more than 5 attempts within a short period of time, the IP will be throttled.
  • Once the quota reaches 0, the desired action (drop, deny, or throttle) will be taken.
  • Every 30 seconds (5 minutes divided by the value = 30 seconds), if there are no further POST attempts, the quota will increase by 1.

Example

  • Assume the value is set to 300.
  • When there are more than 150 attempts within a short period of time, the IP will be throttled.
  • Once the quota reaches 0, the desired action (drop, deny, or throttle) will be taken.
  • After 1 second (5 minutes divided by the value = 1 second) without further POST attempts, the quota will increase by 1.

Enable from Web Console

The LSADC WordPressProtect feature is disabled by default.

You may wish to override the default settings at the server level, or virtual-host level. Before making any changes, it helps to understand the logic that drives WordPressProtect at the different levels.

Changing the settings at the Virtual-Host level configuration will override the Server-Level configuration.

Server Level:

!

Virtual Host Level :

!

The design logic looks like the following:

Server Level VHost Level Result
not set not set X
5 not set 5
5 10 10
Disable 10 10

Real Testing

Drop

This test was conducted with WordPressProtect set to drop 10. We can see the time start to increase at Round 6 and finally get a connection error at Round 10.

Round:  1
fail 0.291 status: 200
Round:  2
fail 0.256 status: 200
Round:  3
fail 0.256 status: 200
Round:  4
fail 0.279 status: 200
Round:  5
fail 0.249 status: 200
Round:  6
fail 1.275 status: 200
Round:  7
fail 2.287 status: 200
Round:  8
fail 3.267 status: 200
Round:  9
fail 4.271 status: 200
Round:  10
Erro MSG:  ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response',))

Deny

This test was conducted with WordPressProtect set to deny 10. We can see the time start to increase at Round 6 and start getting permission deny 403 status code from Round 10.

Round:  1
fail 0.292 status: 200
Round:  2
fail 0.267 status: 200
Round:  3
fail 0.270 status: 200
Round:  4
fail 0.253 status: 200
Round:  5
fail 0.268 status: 200
Round:  6
fail 1.257 status: 200
Round:  7
fail 2.276 status: 200
Round:  8
fail 3.260 status: 200
Round:  9
fail 4.182 status: 200
Round:  10
fail 1.010 status: 403

Log:

Brute force detected, deny

Throttle

This test was conducted with WordPressProtect set to throttle 10. We can see the time start to increase at Round 6 and start throttling from Round 10.

Round:  1
fail 0.289 status: 200
Round:  2
fail 0.269 status: 200
Round:  3
fail 0.268 status: 200
Round:  4
fail 0.243 status: 200
Round:  5
fail 0.263 status: 200
Round:  6
fail 1.269 status: 200
Round:  7
fail 2.266 status: 200
Round:  8
fail 3.280 status: 200
Round:  9
fail 4.182 status: 200
Round:  10
fail 29.249 status: 200

Log:

Brute force detected, throttle

reCAPTCHA

reCAPTCHA is available as a method of defense against DDoS attack.

Enable Globally at the Server Level

Access the WebAdmin console via https://YOUR_SERVER_IP:7090

Navigate to Configuration > Server > Security > reCAPTCHA Protection

!recaptchaconf0

Set Enable reCAPTCHA to Yes. This is the master switch. It will enable the reCAPTCHA feature for the entire Web ADC. It may be overridden at the virtual host level.

For other options, hover over the ? symbol to view detailed information about that option.

For demonstration purposes, we will set Connection Limit and SSL Connection Limit to 1, and reCAPTCHA Type to Checkbox. You may adjust these values according to your needs. Save and restart the Web ADC. This conneciton limit setting will be inherited by all virtual hosts unless overridden at the virtual host level.

!recaptchaconf1

When a visitor accesses the website, they will need to go though reCAPTCHA validation. This validation protects the server against HTTP Flood and other DDoS attacks.

After passing the reCAPTCHA validation, the visitor is temporarily whitelisted as long as they continue to browse the site. This makes for a better user experience. Once the visitor has been inactive for more than 20 minutes, reCAPTCHA is once again enabled for that visitor's next request.

!recaptchaverify

You can also enable reCAPTCHA on an individual virtual host that is under attack, while leaving other websites disabled.

Override/Disable at the Virtual Host Level

Assuming you have enabled reCAPTCHA at the server level globally, you can override the settings at a virtual host level.

Use the Web ADC WebAdmin console to override reCAPTCHA for the VHost.

Navigate to Configuration > Virtual Hosts > Security > reCAPTCHA Protection.

!recaptchaconf2

Advanced Configuration: Define reCAPTCHA Actions through Rewrite Rules.

If you want to further define the reCAPTCHA action as deny or drop, you can use one of the following rewrite rule directives:

  • [E=verifycaptcha]
  • [E=verifycaptcha:deny]
  • [E=verifycaptcha:drop]

[E=verifycaptcha] will always redirect to reCAPTCHA until verified. ACTION can be deny to return a 403 or drop to drop the connection when Max Tries is reached. Until Max Tries is reached, the client will be redirected to reCAPTCHA.

Example

RewriteCond SOME-CONDITIONAL-CHECK
RewriteRule .* - [E=verifycaptcha]

(SOME-CONDITIONAL-CHECK would be a suspicious UA, IP address, etc.)

Note

In most cases, rewrite rules will override the default server behavior. However, in cases where trigger sensitivity is high, visitors may be sent directly to reCAPTCHA before the rewrite rules can even be processed.

Enable reCAPTCHA Protection for any URL

You can enable reCAPTCHA for a specific URL. For example, you might want to protect the admin area (/administrator/) for all Joomla sites on the server.

Example

In cPanel, create /etc/apache2/conf.d/userdata/joomlaprotection.conf with the following content:

<IfModule LiteSpeed>
RewriteRule /administrator/ - [E=verifycaptcha:deny]
</IfModule>

Apply to all cPanel virtual hosts and restart LiteSpeed:

/usr/local/cpanel/scripts/rebuildhttpdconf
service lsws restart

Customize the Good Bots List

Google bots are considered good bots because they help index your site. However, they cannot do their job properly without receiving the correct page. The Bot Whitelist configuration may be used to specify bots that you may need for your site.

!reCAPTCHABots

Here, we have configured Edge in the Bot Whitelist text area. Bot Whitelist is a contains match (case sensitive), but regex may be used as well.

After restarting, browsers containing Edge in the user-agent header will bypass reCAPTCHA:

!reCAPTCHATest

The Allowed Bot Hits configuration may be used to limit how many times a good bot (including Googlebot) is allowed to hit a URL before it is redirected to reCAPTCHA as well. This may be useful to prevent bad actors from bypassing reCAPTCHA using a custom user agent.

Customize the reCAPTCHA Page

The default reCAPTCHA page is generic. If you would like to customize the page, you may do so by creating a file at $SERVER_ROOT/lsrecaptcha/_recaptcha_custom.shtml.

There are two script tags that are required and it is strongly recommended to avoid changing the form and the recaptchadiv unless you know what you are doing. There are three echos within the page itself. Those are used by the web server to customize the reCAPTCHA type and keys and specify any query string used.

Beyond those required attributes, everything else is customizable. As noted before, please ensure that you have backups of the default page and your customized page. Note that the .shtml extension is required in order to use the LSWS configured type and keys.

Apply Your Own Site Key

You can apply your own reCAPTCHA key and adjust the configuration as you like from the Google developer reCAPTCHA page. Client verification is completely determined by Google's reCAPTCHA service. The invisible type may display a difficult puzzle.

For server wide protection that needs to cover a lot of domains, make sure Verify the origin of reCAPTCHA solutions is unchecked. Otherwise, you may need to apply a key for each domain. Please refer to the Google doc.


Last update: November 9, 2020