How to enable ModSecurity on OLS

How Can We Help?
< Back
You are here:

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/ 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 ) --owasp-enable

Add the ModSecurity Module

Check whether /usr/local/lsws/modules/ 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 -y
yum install ols-modsecurity -y

Method 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.tgz

Copy openlitespeed/modules/ 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.f

This 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 /usr/local/lsws/modules

Enable 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 to on.
  • 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.


You can test the example rule above following these steps:

  • Before adding the definition, verify that works and delivers a phpinfo page as expected in your browser.
  • Add the sample rule above
  • In the WebAdmin Console, set the Enable option On to 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.


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 ) --owasp-enable

Enabling 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/
unzip -qq
rm -f
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
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-905-COMMON-EXCEPTIONS.conf
include owasp-modsecurity-crs/rules/REQUEST-911-METHOD-ENFORCEMENT.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-922-MULTIPART-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-GENERIC.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-955-WEB-SHELLS.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 '"><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 "'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 (

SecRule SERVER_NAME "www\.example\.com$"
    "id:1234, phase:1, nolog,\
    ctl:ruleRemoveById=941100, \

Comment out a rule for a file (index.php):

SecRule REQUEST_URI "@beginsWith /index.php" \ 
    "id:1234, phase:1, nolog,\ 
    ctl:ruleRemoveById=941100, \ 

Check the OWASP Official Guide for more options and examples


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 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
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.conf

Comodo 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.conf

Configure 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.


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.


  • The last occurrence of mod_security on|off will be the one that takes effect.
  • We recommend that you use backticks ` (as shown above) to surround mod_security_rules rules to avoid any possible issues with single and double quotes used in the rules themselves.
  • mod_security_rulesmod_security_rules_file, and mod_security_rules_remote can mixed and used multiple times each if desired with all rules being combined.