====== Enabling ModSecurity Rules on Standalone LiteSpeed Web Server======
In the LSWS Web Admin console, there is a **Web Application Firewall (WAF)** section which allows you to enable ModSecurity and add a rule set on an LSWS native server. (For a control panel environment, these steps are unnecessary. Simply enable the ModSecurity rule set from the control panel, the same way you would enable a rule set for Apache. For more information on that, please see [[litespeed_wiki:waf#with_a_control_panel|this wiki]].)

Navigate to **Server > Security**

{{ :litespeed_wiki:waf:lsws-builtin-waf.png?600 |}}

In the **Web Application Firewall (WAF)** section, you can choose whether to enable **Request Content Deep Inspection**. This feature is equivalent to Apache's ModSecurity, which can be used to detect and block requests with ill intention by matching them to known signatures.

There are many rule sets you can choose from, such as: 

  * OWASP
  * Comodo
  * Atomicorp
  * Imunify360
  
And others. LSWS is compatible with these rule sets, and you may choose your favorite. You may also define your own customized rules, if you are familiar with crafting ModSecurity rule sets. 

Let's see how to enable a ModSecurity rule set, using Comodo as an example.

[[https://waf.comodo.com/ | Comodo ]] is a ModSecurity rule set created by the Comodo Team. It provides real-time protection for web apps running on LiteSpeed Web Server. Its functions include:
  * Protecting sensitive customer data
  * Meeting PCI compliance requirements
  * Blocking unauthorized access
  * Preventing SQL injection and Cross Site Scripting (XSS) attacks

===== Download and Extract Rules =====

First, download Comodo rules that are compatible with Litespeed.

<code>
cd /usr/local/lsws/conf
wget https://waf.comodo.com/api/cpanel_litespeed_vendor
unzip cpanel_litespeed_vendor
cd comodo_litespeed/
mv rules.conf.main rules.conf
</code>

This will download Comodo Litespeed rules, and move ''rules.conf.main'' to ''rules.conf''. This is the master file including all rules. You can reference in the WebAdmin console for this master file.

=====Add WAF Rule Set=====

Navigate to **Configuration > Server > Security > WAF Rule Set**

{{ :litespeed_wiki:waf:waf-ruleset.png?600 |}}

Click **Add** to edit the **WAF Rule Set**.

{{ :litespeed_wiki:waf:waf-settings.png?600 |}}

  * **Name**: ''Comodo Litespeed''
  * **Action**: ''None''
  * **Enabled**: ''Yes''
  * **Rules Definition**: ''Include $SERVER_ROOT/conf/comodo_litespeed/rules.conf''

Click **Save** to activate the rules.

You can include as many rule files as you like in the **Rules Definition** area.

The Comodo ''Rules.conf.main'' file is a Comodo master file to include all rules in order. It the same as manually entering the following:

  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

If using some commercial rules set (like the Atomic rule set) or your own rules set, which does not have such a master file, you have two options:
  * Include rules with absolute path one by one in the **Rules Definition** field.
  * Make a master file to include all rules with full path, then include only that master file in the **Rules Definition** field. 

If including multi-rul files for mod_security, the files must be included in the right order to make them work properly. 

=====Enable Firewall=====

Navigate to **Configuration > Server > Security > Web Application Firewall (WAF)**

{{ :litespeed_wiki:waf:waf-enable.png?600 |}}

  * **Enable WAF**: ''Yes''
  * **Log Level**: ''0''
  * **Default Action**: ''deny,log,status:403''
  * **Scan Request Body**: ''Yes'' (If set to ''Yes'' will scan post request body)
  * **Temporary File Path**: ''/tmp''
  * **Disable .htaccess Override**: ''Not Set''
  * **Enable Security Audit Log**: ''Not Set''
  * **Security Audit Log**: ''$SERVER_ROOT/logs/security_audit.log''

Click **Save** to enable the firewall, and perform a Graceful Restart.

===== Test ModSecurity rule set =====
====Method 1====
To check CWAF for protection, send this request: 

<code>http://$server_domain/?a=b AND 1=1</code> 

If it's working, the server should respond with a 403 status code.

{{:litespeed_wiki:waf:comodo-5.png?500|}}

====Method 2: ====
You can check that CWAF works properly by sending a GET or POST request parameter ''cwaf_test_request=a12875a9e62e1ecbcd1dded1879ab06949566276''

Like this:

  http://$server_domain/?cwaf_test_request=a12875a9e62e1ecbcd1dded1879ab06949566276

If the web server returns a 403 Forbidden status, then CWAF works fine.

===== Troubleshooting =====

==== Test Method Won't Trigger 403 =====

The following test method for a command injection attack won't work due to the ModSecurity rule set change:

  - Create a ''delete.php'' file with following code: <code>
<?php
print("Please specify the name of the file to delete");
print("<p>");
$file=$_GET['filename'];
system("rm $file");
?>
</code>
  - Create a dummy file: <code>touch bob.txt</code>
  - Open: <code> http://$server_domain/delete.php?filename=bob.txt;id </code>

You will //not// get a 403 forbidden page if you test in this way. Please use other methods for testing. 

In terms of //how// to test for command injection attack protection, you may need to consult the corresponding ModSecurity rules providers. As LiteSpeed is not  a ModSecurity rule set provider, we are not in a position to provide such recommendations.