LiteSpeed Web Server has its own high-performance mod_security engine, offering excellent compatibility and performance. LSWS works well with popular mod_security rules sets such as OWASP, Atomicorp, Comodo and CloudLinux Imunify360. Additionally, LiteSpeed works well with firewalls such as ConfigServer Security & Firewall (CSF).

Disable Concurrent Audit logging

Mod_security rules are directly managed by WHM. LiteSpeed works in the same way as Apache, usually, and there is no extra configuration required. However, WHM mod_security integration may act differently based on mod_security configuration.


Do not configure mod_security rules via LiteSpeed WebAdmin console. Those rules are only applied to LSWS native virtual hosts. Virtual hosts configured through Apache configuration files are only protected with ModSecurity rules that are also configured through Apache configuration files.

There are two mod_security log modes: Concurrent and Serial.

SecAuditLogType Concurrent


SecAuditLogType Serial

Apache supports both modes while LSWS only supports Serial mode.

When Concurrent mode is used, "ModSecurity Tools" looks for a log file created in concurrent mode. Since LiteSpeed only uses Serial mode regardless of SecAuditLogType configuration, "ModSecurity Tools" will be looking in the wrong place and won't report any hits.

To fix the problem and get LiteSpeed Web Server logging, turn off the mod_security concurrent logger configuration and change it to serial mode.


Supported Features List (Not Comprehensive)

  • @rbl - real time block list. (since 5.1)
  • @fileinspect - scan attached files. (since 5.1)
  • Scan request header/body.
  • Scan response header.
  • Audit logging (Serial mode only)


LSWS only supports the serial mode for audit logging, since LiteSpeed is event driven. Unlike Apache, which can have multiple processes and could change UID.

Not Yet Supported Features

  • Scan response body
  • PDF functions
  • LUA
  • Parsing XML

Reasons They are Unsupported

  • The feature is not often used.
  • The feature may slow down LiteSpeed considerably due to our single-thread event driven architecture.
  • Requests to static files bypass mod_security scanning as they are unlikely to cause any real security issues.


Does LSWS Support "@inspectFile" ?

Yes, but please make sure when using @inspectFile with a 3rd-party scanner, that the script returns 0 for block , and 1 for continue/pass.

Example code from the mod_security reference manual:

$output = "0 Unable to parse clamscan output [$1]";

if ($error_message =~ m/: Empty file\.?$/) {
    $output = "1 empty file";
elsif ($error_message =~ m/: (.+) ERROR$/) {
    $output = "0 clamscan: $1";
elsif ($error_message =~ m/: (.+) FOUND$/) {
    $output = "0 clamscan: $1";
elsif ($error_message =~ m/: OK$/) {
    $output = "1 clamscan: OK";
print "$output\n";

Does LSWS Support the "Concurrent" Type of Audit Log?

No. LiteSpeed Web Server only supports the serial mode for audit logging.

A concurrent-mode audit log is only useful for servers like Apache which is process-driven and has multiple processes that may change UID. LiteSpeed is event-driven, and as such, concurrent mode is not needed.

What is Unsupported Variable Error?

Sometimes you may see some errors like the following:

    2018-10-08 15:51:43.075081  ERROR   [ModSecurity] FILES:import_file "@rx <": Rule not supported.
    2018-10-08 15:51:43.077152  ERROR   [ModSecurity] failed to parse a modsec variable. while parsing: %{TIME_EPOCH}
    2018-10-08 15:51:43.077934  ERROR   [ModSecurity] unknown server variable while parsing: FILES:import_file
    2018-10-08 15:51:43.077942  ERROR   [ModSecurity] FILES:import_file "@contains <": Rule not supported.
    2018-10-08 15:51:43.081368  ERROR   [ModSecurity] unknown server variable while parsing: MATCHED_VARS_NAMES
    2018-10-08 15:51:43.081385  ERROR   [ModSecurity] MATCHED_VARS_NAMES "@rx ^ARGS:AGENDA_EXT_(?:NAME|SRC|COLOR)__[\d]{1}$" "t:none": Rule not supported.
    2018-10-08 15:51:43.104981  ERROR   [ModSecurity] unknown server variable while parsing: FILES:file
    2018-10-08 15:51:43.105000  ERROR   [ModSecurity] FILES:file "@contains <" "t:none,t:urlDecodeUni,t:htmlEntityDecode": Rule not supported.
    2018-10-08 15:51:43.110779  ERROR   [ModSecurity] failed to parse a modsec variable. while parsing: %{REQUEST_COOKIES.pwg_id}
    2018-10-08 15:51:43.110937  ERROR   [ModSecurity] failed to parse a modsec variable. while parsing: %{REQUEST_COOKIES.pwg_id}
    2018-09-26 16:57:36.700054 [INFO] Processing config file:
    2018-09-26 16:57:36.700631 [ERROR] [ModSecurity] unknown server variable while parsing: FILES_COMBINED_SIZE
    2018-09-26 16:57:36.700669 [ERROR] [ModSecurity] FILES_COMBINED_SIZE "@gt %{tx.combined_file_sizes}" "t:none": Rule not supported.
    2018-09-26 16:57:36.703233 [ERROR] [ModSecurity] unknown server variable while parsing: MATCHED_VARS_NAMES
    2018-09-26 16:57:36.703266 [ERROR] [ModSecurity] MATCHED_VARS_NAMES "TX:paramcounter_(.*)" "capture": Rule not supported.
    2018-09-26 16:57:36.706773 [ERROR] [ModSecurity] unknown server variable while parsing: ARGS_COMBINED_SIZE
    2018-09-26 16:57:36.706802 [ERROR] [ModSecurity] ARGS_COMBINED_SIZE "@gt %{tx.total_arg_length}" "t:none": Rule not supported.
    2018-09-26 16:57:36.707414 [ERROR] [ModSecurity] unknown server variable while parsing: REQBODY_ERROR
    2018-09-26 16:57:36.707456 [ERROR] [ModSecurity] REQBODY_ERROR "!@eq 0" "msg:'Failed to parse request body.||MVN:%{MATCHED_VAR_NAME}||T:LITESPEED||MV:%{MATCHED_VAR}||PC:%{PERF_COMBINED}',tag:'i360',id:88139653,rev:'1',maturity:'9',accuracy:'9',phase:request,pass,t:none,tag:'noshow',severity:7,tag:'o'": Rule not supported.
    2018-09-26 16:57:36.708774 [INFO] Processing config file:
    2018-09-26 16:57:36.709169 [INFO] Processing config file:
    2018-09-26 16:57:36.709222 [INFO] Processing config file:
    2018-09-26 16:57:36.907572 [INFO] Processing config file:
    2018-09-26 16:57:36.908424 [INFO] Processing config file:
We try to keep LSWS compatible with the latest mod_security (2.5 and above) and GotRoot rules. LSWS supports most of these rules. We attempt not to miss any really important features/rules used in the real world, and we regularly add support for more features based on our user feedback. However, because of the complexity and fluctuating nature of these security rules, it is not possible to be 100% compatible with Apache at any one time.

The above error messages simply mean the given variables are not supported by LSWS yet. The errors can simply be ignored. We periodically review our mod_security engine and frequently add new support. Stay tuned.

Does LSWS Support the "LocationMatch" directive?

When you use SecDebugLogLevel, SecAuditLogParts or SecAuditLog within the LocationMatch directive, you may see the following errors on LSWS:

Directive 'SecDebugLogLevel' is not allowed in current context.
Directive 'SecAuditLogParts' is not allowed in current context.
Directive 'SecAuditLog' is not allowed in current context.

LiteSpeed Web Server does support the LocationMatch context, however the above three directives may not be configured within it. On LSWS, audit log can only be set at the server level, and the debug log level can be set at vhost level. We have no plans to make these directives available at the matching context level, as it would be counterproductive to the optimization applied to the engine.

Can I Disable ModSecurity for a Single Domain?

Yes. While ModSecurity is normally enabled at the server level and applied to all domains on the shared hosting server, it is possible to disable it for a single domain using .htacess, if particular rules are causing an application to break the site.

As long as AllowOverride is permitted, you can place the following directives in .htaccess.

To disable ModSecurity entirely for a virtual host:

<IfModule mod_security.c>
  SecRuleEngine Off
  SecRequestBodyAccess Off

To disable a particular ModeSecurity rule for a virtual host:

<IfModule mod_security.c>
  SecRuleRemoveById 1234567


We recommend turning on debug logging when looking to troubleshoot an issue. Turn on logging, reproduce the issue, and check the log.

To turn on mod_security debug logging, edit the config, like so:

vi /etc/apache2/conf.d/modsec2.conf

Change SecDebugLogLevel 0 to SecDebugLogLevel 9, and restart LSWS.


SecDebugLog logs/modsec_debug.log is for Apache only. LiteSpeed doesn't use the SecDebugLog directive and logs mod_security errors directly to the server's error log.

After you enable debug logging, you can check the server error log see if mod_security rules have been executed, or find details explaining why mod_security didn't properly execute.

Here are some common troubleshooting scenarios.

mod_security Disabled for Magento 2

In a LiteSpeed environment, mod_security is erroneously disabled by Magento 2's default .htaccess rules. This doesn't happen with other apps on the system, and it doesn't happen when Apache is running.

This is because Magento 2's doc root .htaccess contains mod_security rules within <IfModule mod_security.c> or <IfModule mod_security2.c> conditionals. These are not processed by LiteSpeed, because mod_security is an Apache module, and not a LiteSpeed one.

To make sure that LiteSpeed doesn't execute the code in Magento 2's .htaccess, you can do one of three things: adjust .htaccess directly, turn off .htaccess override in WebAdmin, or turn off .htaccess override in the config file.

  1. Comment out the following rules in Magento 2's doc root .htaccess:
        <IfModule mod_security.c>
        ## disable POST processing to not break multiple image upload
        SecFilterEngine Off
        SecFilterScanPOST Off
  2. Use Disable .htaccess Override. Navigate to LSWS WebAdmin Console > Configuration > Server > Security > Web Application Firewall (WAF) and set Disable .htaccess Override to Yes. This is a global setting only available at the server level.
  3. Edit the LiteSpeed configuration file: vi /usr/local/lsws/conf/httpd_config.xml, look for the <security>...</security> section within <censorshipControl>...</censorshipControl> and add <disableSecHtaccess>1</disableSecHtaccess>.

Last update: July 14, 2020