When ModSecurity is used with OpenLiteSpeed it will improve the security of your server by applying a Web Application Firewall (WAF). The ModSecurity WAF increases the protection level applied to your server by detecting and preventing attacks before they reach web-based software programs.

The ModSecurity module is configured by applying a flexible rules based engine that can perform multiple simple and complex operations. The rules based engine uses a Core Rule Set (CRS) which provides protection against cross website scripting,
bad user agents, SQL injection, trojans, session hijacking and more. DirectAdmin is able to use ModSecurity Core Rule Sets (CRS) provided by OWASP and Comodo and can be easily installed using custombuild.

The most common ModSecurity rule triggered on a server is the 403 Forbidden error. This simply means that the process you are trying to complete has been prevented from being actioned as you do not have the required permissions to access this process.

ModSecurity works in the background and will check every request against the various rules in the Core Rule Set to filter out any malicious requests. This could be attacks against WordPress core files such as wp-login.php or admin-ajax.php, known vulnerabilities in WordPress plugins such as the recent File Manager which is currently installed on 600,000+ websites and documented by the WordFence Security Team or against system files such as the .env file. The ultimate goal for the attack is too find an exploitable vulnerability in your server or software to hack your website or server.

In this guide, we will show you how to add and enable custom ModSecurity rules with OpenLitespeed and DirectAdmin. Rebuild the ModSecurity rules and apply them to all websites hosted on the server. This guide assumes you have already installed ModSecurity. If you haven’t, you can follow our How to Install ModSecurity with OpenLiteSpeed and DirectAdmin guide.

By default custombuild will use the httpd-modsecurity-enable.conf file to enable and configure ModSecurity with OpenLitespeed. However, we can’t write directly to this file as when we rebuild the vhost configuration files using the ./build rewrite_confs command custombuild will overwrite any changes.

We will need to use a custom httpd-modsecurity-enable.conf template to enable the changes and ensure they are added into the OpenLitespeed configuration file generated by custombuild.

To create the custom the httpd-modsecurity-enable.conf template file, simply use the following commands.

cd /usr/local/directadmin/custombuild/
mkdir -p custom/openlitespeed/conf
cp -p /usr/local/lsws/conf/httpd-modsecurity-enable.conf custom/openlitespeed/conf/

These commands how now created a new custom OpenLitespeed configuration folder within the existing custombuild folder and copied the existing httpd-modsecurity-enable.conf template. Now the file has been copied we can edit the file using the following commands.

nano /usr/local/directadmin/custombuild/custom/openlitespeed/conf/httpd-modsecurity-enable.conf

The default httpd-modsecurity-enable.conf template file will look similar to the example below.

module mod_security {
modsecurity on
modsecurity_rules_file /usr/local/lsws/conf/httpd-modsecurity.conf
modsecurity_rules_file /usr/local/directadmin/data/admin/modsecurity_rules
}

Before we add in our custom ModSecurity rules it is important to understand what each line means.

• modsecurity on – simply means that the ModSecurity Module is on. The available options are on or off.
• modsecurity_rules_file – specifies the location of the ModSecurity rules file. These are written to the bottom of the httpd-modsecurity.conf file by default.

Now we can add our custom ModSecurity rules to the httpd-modsecurity-enable.conf template inside the modsecurity_rules block. When adding custom rules to the modsecurity_rules block we need to ensure they are enclosed inside a backtick "`". Inside the block we can include multiple rules, however, it is important to keep in mind that ModSecurity will load all rules in order.

In the httpd-modsecurity-enable.conf file simply copy the example rule shown below after the modsecurity on line.

modsecurity_rules `
SecRuleEngine On
SecRule ARGS:testparam "@contains test" "id:12345,deny,status:403,msg:'Our modsec test rule has triggered'"
`

The file show now look like the example below.

module mod_security {
modsecurity on
modsecurity_rules `
SecRuleEngine On
SecRule ARGS:testparam "@contains test" "id:12345,deny,status:403,msg:'Our modsec test rule has triggered'"
`
modsecurity_rules_file /usr/local/lsws/conf/httpd-modsecurity.conf
modsecurity_rules_file /usr/local/directadmin/data/admin/modsecurity_rules
}

Below is an explanation of the new code we have added into the httpd-modsecurity-enable.conf file.

• modsecurity_rules – simply specifies the ModSecurity rules code block.
• SecRuleEngine On – means that ModSecurity will now log and block any rules that match.
• SecRule ARGS:testparam – is the custom ModSecurity rule.

After saving the httpd-modsecurity-enable.conf file you will need to rebuild the ModSecurity rules file and vhost configuration files using the following commands.

./build modsecurity_rules
./build rewrite_confs

Now you can test the custom ModSecurity rule has been implemented correctly using the following command.

https://example.com/index.html?testparam=test

After testing the custom ModSecurity rule you will get 403 Forbidden response. You can also check the ModSecurity log by logging into your DirectAdmin dashboard. Once in the main dashboard select the ModSecurity icon under Server Manager.

In the ModSecurity dashboard select Log from the tabbed menu. Under the domain section you will see the domain used in the test above, in our example it shows demo.vpsbasics.com alongside the request /index.html?testparam=test. To the right you will see the rule ID1234 has been blocked with the message Our modsec test rule has triggered.

That’s it. You have successfully added and enabled custom ModSecurity rule with OpenLitespeed and DirectAdmin. You have also rebuilt the ModSecurity rules file and applied it to all existing websites hosted on the server.