Difference between revisions of "Litespeed"

From Atomicorp Wiki
Jump to: navigation, search
m (Does ASL work with LiteSpeed?)
m (I've loaded the rules into Litespeed, does that mean they work with Litespeed?)
(36 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
== Does ASL work with LiteSpeed?  ==
 
== Does ASL work with LiteSpeed?  ==
  
Partially, but the Web Application Firewall does not. This is because LiteSpeed has a proprietary implementation of mod_security, the Web Application Firewall (WAF) module we use in Apache. '''Litespeeds implementation of mod_security is is neither a drop in replacement for the real mod_security module, nor does it support the full rule set or rule languageBecause of this, it is not fully compatible with modern mod_security rules.'''
+
Yes, ASL is supported with LiteSpeed.   
  
According to this forum post on the cpanel forums their implementation is currently incomplete:
+
== Do the modsecurity rules work with Litespeed ==
  
http://www.litespeedtech.com/support/forum/showthread.php?t=4619&highlight=modsecurity
+
'''When used with the [https://www.atomicorp.com/wiki/index.php/ASL_WAF#WAF_Tab ASL Transparent WAF (T-WAF)] in front of Litespeed all rules are supported.'''
  
Litespeed currently only supports 1.9.x features and possibly a handful of 2.0 features.  1.9.x was obsolete many years ago, the current version of the modsecurity rule language is 2.5.x. 
+
When using the rules directly with Litespeed, please see the official Litespeed page for what rule language features Litespeed supports:
  
If you want to use LiteSpeed, you will either have to forgoe web application protection (definitely not recommended), or you will need to install a WAF in front of LiteSpeed to get web application protection, either via a standalone WAF or an apache proxy with our WAF module included.
+
http://www.litespeedtech.com/support/wiki/doku.php?id=litespeed_wiki:mod_security_compatibility
  
We do encourage you to encourage LiteSpeed to support the full mod_security rule language.  We would really like to be able to support it!
+
Currently, if you do not use the T-WAF, this means Litespeed does not support the following features:
  
== What should LiteSpeed users do for a WAF? ==
+
# Output analysis: This means Litespeed can not inspect the output from the web server.  This means rules like malware detection, malicious shell prevention, brute force protection, data loss protection and other rules that analyze the output from the web server are not supported by Litespeed, unless you use [https://www.atomicorp.com/wiki/index.php/ASL_WAF#WAF_Tab the ASL Transparent WAF (T-WAF) in front of Litespeed].
 +
# XML inspection: Litespeed has chosen to not support XML inspection, this means XML based attacks are unfortunately not protected on that platform, unless you use [https://www.atomicorp.com/wiki/index.php/ASL_WAF#WAF_Tab the ASL Transparent WAF (T-WAF) in front of Litespeed].
 +
# Multi-part Upload protection:  Litspeed does not support scanning attached files content in multi-part upload.  If you use [https://www.atomicorp.com/wiki/index.php/ASL_WAF#WAF_Tab the ASL Transparent WAF (T-WAF) in front of Litespeed] you will be able to scan attached files in a multi-part upload.
 +
# lua: This is a language that lets us construct advanced rules.  Currently they are used for advanced anti-spam protection and advanced SQLi and XSS injection protection.  Therefore, these types of rules are not supported by Litespeed, unless you use [https://www.atomicorp.com/wiki/index.php/ASL_WAF#WAF_Tab the ASL Transparent WAF (T-WAF) in front of Litespeed].
  
If you must run LiteSpeed, then you will want to use a feature complete WAF in front of it. We recommend you put an Apache reverse proxy in front of LiteSpeed, as Apaches modsecurity module is complete.  Litespeeds modsecurity like module is not, and no modern ruleset will work correctly or completely with it.
+
== How to configure a local WAF for litespeed ==
  
== Why are all rules written for the 2.5.x lanuage? ==
+
=== ASL V ===
  
All the current rulesets out there (Atomicorp, Gotroot, OWASP, etc.) require support for the 2.5.x rule language. Those rules have a different syntax from the older 1.9.x rules, and also use lots of features that the older implementation (1.9.x) does not have - which means 2.5.x rules are WAY WAY more robust but also, incompatible with 1.9.x implementations.  In fact, modsecurity 2.0 was a complete re-write, so the differences between pre 2.x rules and 2.x rules are vast and the changes are all quite necessary.
+
Step 1) Log into ASL.  
  
There are things we can do in 2.5.x that are simply not possible in 1.9.x (the features don't exist, like lua scripts, branching logic, DOS protections, anti-obfuscation countermeasures, transforms, etc.). There are things we can do in 2.5.x that are really fast, which in 1.9.x were painfully impossibly slow, such as the ability to do Aho-Corasick matching - which made it possible to do matches against large lists super fast (think big blacklists of malicious domains, IPs, etc.). We can also do branching logic in 2.5.x, which we can't do 1.9.x - think of if then else statements, which are used by both the OWASP and GotRoot rules for huge performance gains (if I dont see X in this payload, skip all these rules). In fact, both rule sets won't even work correctly with a 1.9.x implementation because of the lack of branching logic, which is a real biggie. Probably 100% of the rules won't work right without that logic alone.
+
Step 2) Click on the "ASL" tab.
  
We can also do anomaly detection in 2.5.x, again, this doesnt exist in 1.9.x, so if you use either ruleset in anomaly detection mode 100% of the rules don't work in 1.9.x implemenations. So its really a square peg in a round hole trying to get 2.5.x rules to work in the less capable 1.9.x implementation. It just won't work.
+
Step 3) Click on the "WAF Configuration" menu option.  
  
And finally, the new rule language lets us do things that massively reduces false positives. Its like night and day from a reliability point of view. The improvements in this area were so great that 1.9.x was dropped by rule authors for probably that reason alone!
+
Step 4) Click the "Add" button.
  
So, the advantages of the 2.5.x implementation are just worth so much its not worth maintaining rulesets for 1.9.x. We retired our 1.9.x rules many years ago for just those reasons. So, the 2.5.x change was a big positive change well worth the adoption.
+
Step 5) In the "Add New TWAF Setting" window from the "Add protection for ..." drop down, select "Local Web Server"
  
Unfortunately, thats means 1.9.x implementations such as LiteSpeeds are left in the cold because the big rule projects moved onto 2.5.x years ago. Its like being forced to support something you know is just out of date, inefficient and not powerful enough to solve the problems you know you need to solve to protect your users. No security guy wants that. :-)
+
Step 6) Select the port that litespeed runs on. Normally this is port 80.  
  
So, we hope that Litespeed can support 2.5.x soon, we'd love to be able to help out LiteSpeed users with our rules. If you must use 1.9.x rules, we do still publish 1.9.x rules at www.gotroot.com, but they are End Of Life, unsupported and we would not rely on any 1.9.x rules to protect you from modern attacks.  False Positives will also be much higher with 1.9.x rules, as its just not possible to do all the things we've been doing for years with the 2.5.x rules in 1.9.x. Too many things can get past an older implementation.
+
Step 7) Check the SSL box
  
I hope this information helps everyone to understand where things are, and I wish LiteSpeed all the success in the world getting a 2.5.x implementation in place!
+
Enter the file system path to your SSL certificate, and SSL key in the "Path to SSL Certificate" and "Path to SSL Key file" boxes.
 +
 
 +
Step 8) Click Save
 +
 
 +
=== ASL 4 ===
 +
 
 +
Step 1) Log into ASL.
 +
 
 +
Step 2) Click on the "Configuration" tab.
 +
 
 +
Step 3) Click on the "WAF" tab and select "WAF configuration".
 +
 
 +
Step 4) Click the "Add" button.
 +
 
 +
Step 5) Select "Local Web Server" from the "Add protection for" drop down.
 +
 
 +
Step 6) Select the port that litespeed runs on.  Normally this is port 80.
 +
 
 +
Step 7) Check the SSL box
 +
 
 +
Enter the file system path to your SSL certificate, and SSL key in the "Path to SSL Certificate" and "Path to SSL Key file" boxes.
 +
 
 +
Step 8) Click Save
 +
 
 +
Note:  Litespeed does not support the WAF in embedded mode.
 +
 
 +
= Questions =
 +
 
 +
== I've loaded the rules into Litespeed, does that mean they work with Litespeed? ==
 +
 
 +
Yes, but please see the LSWS official page for what language features Litespeed supports and does not support.
 +
 
 +
https://www.litespeedtech.com/support/wiki/doku.php/litespeed_wiki:config:mod_security-compatibility

Revision as of 13:47, 19 June 2017

Contents

Does ASL work with LiteSpeed?

Yes, ASL is supported with LiteSpeed.

Do the modsecurity rules work with Litespeed

When used with the ASL Transparent WAF (T-WAF) in front of Litespeed all rules are supported.

When using the rules directly with Litespeed, please see the official Litespeed page for what rule language features Litespeed supports:

http://www.litespeedtech.com/support/wiki/doku.php?id=litespeed_wiki:mod_security_compatibility

Currently, if you do not use the T-WAF, this means Litespeed does not support the following features:

  1. Output analysis: This means Litespeed can not inspect the output from the web server. This means rules like malware detection, malicious shell prevention, brute force protection, data loss protection and other rules that analyze the output from the web server are not supported by Litespeed, unless you use the ASL Transparent WAF (T-WAF) in front of Litespeed.
  2. XML inspection: Litespeed has chosen to not support XML inspection, this means XML based attacks are unfortunately not protected on that platform, unless you use the ASL Transparent WAF (T-WAF) in front of Litespeed.
  3. Multi-part Upload protection: Litspeed does not support scanning attached files content in multi-part upload. If you use the ASL Transparent WAF (T-WAF) in front of Litespeed you will be able to scan attached files in a multi-part upload.
  4. lua: This is a language that lets us construct advanced rules. Currently they are used for advanced anti-spam protection and advanced SQLi and XSS injection protection. Therefore, these types of rules are not supported by Litespeed, unless you use the ASL Transparent WAF (T-WAF) in front of Litespeed.

How to configure a local WAF for litespeed

ASL V

Step 1) Log into ASL.

Step 2) Click on the "ASL" tab.

Step 3) Click on the "WAF Configuration" menu option.

Step 4) Click the "Add" button.

Step 5) In the "Add New TWAF Setting" window from the "Add protection for ..." drop down, select "Local Web Server"

Step 6) Select the port that litespeed runs on. Normally this is port 80.

Step 7) Check the SSL box

Enter the file system path to your SSL certificate, and SSL key in the "Path to SSL Certificate" and "Path to SSL Key file" boxes.

Step 8) Click Save

ASL 4

Step 1) Log into ASL.

Step 2) Click on the "Configuration" tab.

Step 3) Click on the "WAF" tab and select "WAF configuration".

Step 4) Click the "Add" button.

Step 5) Select "Local Web Server" from the "Add protection for" drop down.

Step 6) Select the port that litespeed runs on. Normally this is port 80.

Step 7) Check the SSL box

Enter the file system path to your SSL certificate, and SSL key in the "Path to SSL Certificate" and "Path to SSL Key file" boxes.

Step 8) Click Save

Note: Litespeed does not support the WAF in embedded mode.

Questions

I've loaded the rules into Litespeed, does that mean they work with Litespeed?

Yes, but please see the LSWS official page for what language features Litespeed supports and does not support.

https://www.litespeedtech.com/support/wiki/doku.php/litespeed_wiki:config:mod_security-compatibility

Personal tools