The ModSecurity module allows OpenLiteSpeed to use common ModSecurity rules, like OWASP or COMODO, to improve server security. For this guide, we assume you already have a working installation of OpenLiteSpeed 1.4.29 or greater.
If you install OpenLiteSpeed through packages, such as yum or apt-get, the ModSecurity module may have been included in your package already. Check the /usr/local/lsws/modules/mod_security.so file to see if it exists. If it exists. If it does, you can skip the ModSecurity module installation step.
If your OpenLiteSpeed server was installed from a Cloud Image, ols1clk, or the LiteSpeed repo, and you want to use OWASP, the following script will do the job and save you time:
bash <( curl -k https://raw.githubusercontent.com/litespeedtech/ols1clk/master/ols1clk.sh ) --owasp-enablePage Contents
Add the ModSecurity Module
Check whether /usr/local/lsws/modules/mod_security.so exists. If it does, skip this step, and go straight to Enable the Module. If it doesn’t exist, please choose one of the three module installation methods below. Choose the one that is the same as your OLS installation method.
Method 1. Install from Repository
Install via apt or yum with one of the following commands:
apt-get install ols-modsecurity -yyum install ols-modsecurity -yMethod 2. Download from Binary
Visit the download page and download the binary file. Untar the file with the following command:
tar -zxf openlitespeed-x.x.x.tgzCopy openlitespeed/modules/mod_security.so to your openlitespeed folder in /usr/local/lsws/modules.
Method 3. Build from source
Enter the ModSecurity module directory and run the make command, like so:
cd /openlitespeed_download/src/modules/modsecurity-ls
make -f Makefile.fThis command provides the latest version supported by OpenLiteSpeed. Do not use other versions of ModSecurity as they may not be supported.
All dependencies will be automatically handled in this step. If you encounter any problems at this stage, you can build the module manually by following the instructions here.
Copy the compiled module to the modules directory, like so:
cp mod_security.so /usr/local/lsws/modulesEnable the Module
You can set up the ModSecurity module through the OLS WebAdmin Console, if you like.
If you prefer the command line, you can use that instead. Edit OpenliteSpeed’s httpd_config.conf configuration file directly from the command line, and append the ModSecurity configuration and rules . You may combine rules, or list them out over multiple lines.
For example, a simple rule which would deny access to phpinfo.php might look something like this:
module mod_security {
modsecurity on
modsecurity_rules `
SecRuleEngine On
SecRule REQUEST_URI "@pm phpinfo.php" "phase:1,id:'10',log,deny,status:403"
`
modsecurity_rules_file /rule/file/path
ls_enabled 1
}Here’s what each option does:
modsecurity on|off: Enables or disables ModSecurity. Usually it is set toon.modsecurity_rules: Use backticks (`) at the beginning and the end of each rule, to enclose the ruleset. You can include multiple rules but keep in mind that ModSecurity rules load in order. Make sure you sort the configuration files accordingly.modsecurity_rules_file: Specifies the file path to the rules. This file must exist and be correct (see below) if you define this option.ls_enabled 1: Used to have OpenLiteSpeed activate the ModSecurity module. If using the user interface, this is not specified with the other rules but as described below.
Testing
You can test the example rule above following these steps:
- Before adding the definition, verify that
https://example.com/phpinfo.phpworks and delivers a phpinfo page as expected in your browser. - Add the sample rule above
- In the WebAdmin Console, set the Enable option
Onto enable the ModSecurity plugin - Restart OpenLiteSpeed
- Retry the URI in your browser and you should see a 403 message on the screen.
Again, this is just a test sample to verify that ModSecurity is working. You may want to remove this particular rule before going into production.
OWASP
The OLS ModSecurity engine uses the ModSecurity 3.x+ only and doesn’t support the ModSecurity 2.x rule set.
For OWASP, please make sure to use ModSecurity Core Rule Set (CRS) Version 3+.
Enabling OWASP ModSec rule set by script
bash <( curl -k https://raw.githubusercontent.com/litespeedtech/ols1clk/master/ols1clk.sh ) --owasp-enableEnabling OWASP ModSec rule set on OLS Manually
Download OWASP 3+ rule set:
mkdir -p /usr/local/lsws/conf/owasp
cd /usr/local/lsws/conf/owasp/
wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v4.0.0.zip
unzip -qq v4.0.0.zip
rm -f v4.0.0.zip
mv coreruleset-* owasp-modsecurity-crs
cd owasp-modsecurity-crs
Rename the sample crs-setup.conf.example to crs-setup.conf:
mv crs-setup.conf.example crs-setup.conf
Rename some sample rules under the rules/ directory:
cd rules
mv REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
mv RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf
cd ..
Create an include configuration file:
echo "include modsecurity.conf
include owasp-modsecurity-crs/crs-setup.conf
include owasp-modsecurity-crs/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
include owasp-modsecurity-crs/rules/REQUEST-901-INITIALIZATION.conf
include owasp-modsecurity-crs/rules/REQUEST-903.9001-DRUPAL-EXCLUSION-RULES.conf
include owasp-modsecurity-crs/rules/REQUEST-903.9002-WORDPRESS-EXCLUSION-RULES.conf
include owasp-modsecurity-crs/rules/REQUEST-903.9003-NEXTCLOUD-EXCLUSION-RULES.conf
include owasp-modsecurity-crs/rules/REQUEST-903.9004-DOKUWIKI-EXCLUSION-RULES.conf
include owasp-modsecurity-crs/rules/REQUEST-903.9005-CPANEL-EXCLUSION-RULES.conf
include owasp-modsecurity-crs/rules/REQUEST-903.9006-XENFORO-EXCLUSION-RULES.conf
include owasp-modsecurity-crs/rules/REQUEST-905-COMMON-EXCEPTIONS.conf
include owasp-modsecurity-crs/rules/REQUEST-910-IP-REPUTATION.conf
include owasp-modsecurity-crs/rules/REQUEST-911-METHOD-ENFORCEMENT.conf
include owasp-modsecurity-crs/rules/REQUEST-912-DOS-PROTECTION.conf
include owasp-modsecurity-crs/rules/REQUEST-913-SCANNER-DETECTION.conf
include owasp-modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf
include owasp-modsecurity-crs/rules/REQUEST-921-PROTOCOL-ATTACK.conf
include owasp-modsecurity-crs/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf
include owasp-modsecurity-crs/rules/REQUEST-931-APPLICATION-ATTACK-RFI.conf
include owasp-modsecurity-crs/rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf
include owasp-modsecurity-crs/rules/REQUEST-933-APPLICATION-ATTACK-PHP.conf
include owasp-modsecurity-crs/rules/REQUEST-934-APPLICATION-ATTACK-NODEJS.conf
include owasp-modsecurity-crs/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf
include owasp-modsecurity-crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf
include owasp-modsecurity-crs/rules/REQUEST-943-APPLICATION-ATTACK-SESSION-FIXATION.conf
include owasp-modsecurity-crs/rules/REQUEST-944-APPLICATION-ATTACK-JAVA.conf
include owasp-modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf
include owasp-modsecurity-crs/rules/RESPONSE-950-DATA-LEAKAGES.conf
include owasp-modsecurity-crs/rules/RESPONSE-951-DATA-LEAKAGES-SQL.conf
include owasp-modsecurity-crs/rules/RESPONSE-952-DATA-LEAKAGES-JAVA.conf
include owasp-modsecurity-crs/rules/RESPONSE-953-DATA-LEAKAGES-PHP.conf
include owasp-modsecurity-crs/rules/RESPONSE-954-DATA-LEAKAGES-IIS.conf
include owasp-modsecurity-crs/rules/RESPONSE-959-BLOCKING-EVALUATION.conf
include owasp-modsecurity-crs/rules/RESPONSE-980-CORRELATION.conf
include owasp-modsecurity-crs/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf">modsec_includes.conf
Configure OLS to use the OWASP Master ModSecurity rule file you just created:
module mod_security {
modsecurity on
modsecurity_rules `
SecRuleEngine On
`
modsecurity_rules_file /usr/local/lsws/conf/owasp/modsec_includes.conf
}
Save and restart OLS.
Testing OWASP with OLS
You can quickly test how your system responds to an XSS attack by appending ?user=<script>alert(123)</script> to your URL, as shown below. If the ModSecurity rule works, then we would expect a 403 status return.
curl 'http://www.example.com/?q="><script>alert(123)</script>'Error log:
[Module:mod_security] ModSecurity: Warning. detected XSS using libinjection. [file "/usr/local/lsws/conf/owasp/owasp-modsecurity-crs/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf"] [line "38"] [id "941100"]Here’s another example of SQL injection to test:
curl "http://www.example.com/?q='1 OR 1=1"Common Questions
What if I get a false positive error?
Please update to the latest Core Rule Set version, see Release Tags. Or raise an issue on the coreruleset official repo
How do I comment out a rule?
We’ll use rule ID 941100 as an example:
Comment out the whole id 941100 from the config file (/usr/local/lsws/conf/owasp/owasp-modsecurity-crs/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf), or add SecRuleRemoveById 941100 to the /usr/local/lsws/conf/owasp/owasp-modsecurity-crs/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf file to exclude the ID.
How do I comment out rules for a certain domain?
Since OpenLiteSpeed does not support SecRuleRemoveById in the .htaccess file, you can manually set rule conditions to exclude certain rules for specific domains or files.
Edit the /usr/local/lsws/conf/owasp/owasp-modsecurity-crs/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf file.
Comment out a rule for a domain (example.com):
SecRule SERVER_NAME "www\.example\.com$"
"id:1234, phase:1, nolog,\
ctl:ruleRemoveById=941100, \
ctl:ruleRemoveById=941160"Comment out a rule for a file (index.php):
SecRule REQUEST_URI "@beginsWith /index.php" \
"id:1234, phase:1, nolog,\
ctl:ruleRemoveById=941100, \
ctl:ruleRemoveById=941160"Check the OWASP Official Guide for more options and examples
Comodo
All commonly used Comodo rule sets, including those named LiteSpeed,Apache,Nginx or IIS are ModSecurity 2.x rule sets. None of these rule sets will match the OpenLiteSpeed ModSecurity 3.x engine, so they should not be used.
To use the Comodo rules, choose the Nginx/ModSec_3.0 release. Don’t worry that it specifically mentions “Nginx.” It is a simple ModSec_3.0 set, and it works with the OpenLiteSpeed ModSecurity engine. See the screenshot of the Comodo WAF download portal below to see how to choose the Nginx/ModSec_3.0 source.
NOTE: You should use only one set at a time (either Comodo or CRS) to avoid conflicts.
Enabling the COMODO ModSec_3.0 rule set on OLS
Log in to your account at https://waf.comodo.com/ and download the full Nginx/ModSec_3.0 rule set. The file will be a .tgz file and will include the version number, like so: cwaf_rules_nginx_3-1.223.tgz
Use an FTP tool to transfer this file to your server, and place it in the /usr/local/lsws/modsec/comodo/ directory. Crete the directory if it doesn’t exist.
comodo# pwd
/usr/local/lsws/modsec/comodo
comodo# ll
total 308
-rw-r--r-- 1 root root 312040 Oct 23 15:04 cwaf_rules_nginx_3-1.223.tgz
comodo# tar -zxvf cwaf_rules_nginx_3-1.223.tgz
comodo# mv rules.conf.main rules.confComodo has already provided an example master rules.conf.main file to include all rules. Rename it to rules.conf. Then you can configure this Master COMODO rule file instead of manually including all rule files one by one.
comodo# cat rules.conf
Include 00_Init_Initialization.conf
Include 01_Init_AppsInitialization.conf
Include 02_Global_Generic.conf
Include 03_Global_Agents.conf
Include 04_Global_Domains.conf
Include 05_Global_Incoming.conf
Include 06_Global_Backdoor.conf
Include 07_XSS_XSS.conf
Include 08_Global_Other.conf
Include 09_Bruteforce_Bruteforce.conf
Include 10_HTTP_HTTP.conf
Include 11_HTTP_HTTPDoS.conf
Include 12_HTTP_Protocol.conf
Include 13_HTTP_Request.conf
Include 14_Outgoing_FilterGen.conf
Include 15_Outgoing_FilterASP.conf
Include 16_Outgoing_FilterPHP.conf
Include 17_Outgoing_FilterSQL.conf
Include 18_Outgoing_FilterOther.conf
Include 19_Outgoing_FilterInFrame.conf
Include 20_Outgoing_FiltersEnd.conf
Include 21_PHP_PHPGen.conf
Include 22_SQL_SQLi.conf
Include 23_ROR_RORGen.conf
Include 24_Apps_Joomla.conf
Include 25_Apps_JComponent.conf
Include 26_Apps_WordPress.conf
Include 27_Apps_WPPlugin.conf
Include 28_Apps_WHMCS.conf
Include 29_Apps_Drupal.conf
Include 30_Apps_OtherApps.confConfigure OLS to use Comodo Master ModSecurity rule file:
module mod_security {
modsecurity on
modsecurity_rules `
SecRuleEngine On
`
modsecurity_rules_file /usr/local/lsws/modsec/comodo/rules.conf }Save the change and restart OLS.
Troubleshooting
You can turn on detailed auditing, including debug logging, if the rules are not working as expected:
module mod_security {
modsecurity on
modsecurity_rules `
SecRuleEngine On
SecDebugLog /tmp/auditlog-debug.txt
SecDebugLogLevel 9
SecAuditLogParts AB
SecAuditEngine On
SecAuditLog /tmp/auditlog.txt
SecAuditLogType Serial
SecAuditLogStorageDir /tmp/
SecRule REQUEST_URI "@pm phpinfo.php" "phase:1,id:'10',log,deny,status:403"
` }An attempt to access the phpinfo.php file will result in a large number of updates to the /tmp/auditlog-debug.txt file and a smaller number to the /tmp/auditlog.txt file. We recommend that you not enable debug logging unless necessary in production. Additionally, we suggest that you only enable more limited audit logging when there are techniques in place to prune the logs.
Notes:
- The last occurrence of
mod_security on|offwill be the one that takes effect. - We recommend that you use backticks
`(as shown above) to surroundmod_security_rulesrules to avoid any possible issues with single and double quotes used in the rules themselves. mod_security_rules,mod_security_rules_file, andmod_security_rules_remotecan mixed and used multiple times each if desired with all rules being combined.