Difference between revisions of "Litespeed"

From Atomicorp Wiki
Jump to: navigation, search
m (→‎Does ASL work with LiteSpeed?)
m (→‎Do the modsecurity rules work with Litespeed)
 
(37 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
== Does ASL work with LiteSpeed?  ==
 
== Does ASL work with LiteSpeed?  ==
  
−
Yes, however, LiteSpeed has a proprietary closed implementation of mod_security, the WAF module we use in Apache.  '''The LiteSpeed modsecurity implementation is not complete, does not support the full rule language, and is not fully compatible with modern mod_security rules.''' We recommend you contact Litespeed to confirm what they do, and do not support in the modsecurity ruleset.
+
Yes, ASL is supported with LiteSpeed.   
  
−
The Litespeed modsecurity implementation is not the same as the real modsecurity module and is not fully compatible with modsecurity rules.  Therefore, modsecurity rules will not work with Litespeed.  We have provided Litespeed with our rules, and eagerly await the day when they will actually support modsecurity.  As of June 2011, the LiteSpeed implementation is still reported to be incomplete:
+
== Do the modsecurity rules work with Litespeed ==
  
−
http://www.litespeedtech.com/support/forum/showthread.php?t=4619&highlight=modsecurity
+
'''Yes, 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.'''
  
−
As a result of this, Litespeed currently only supports 1.9.x features and a subset of 2.0 features.  Our rules are built for modsecurity 2.6.0.  1.9.x was obsolete many years ago (and we retired the 1.9.x rules as a result many years ago).  The current version of the modsecurity rule language is 2.6.x, which we fully support.  Litespeed is working on some 2.6.x compatibility, but it is still not complete and it appears they do not intend to fully support the language.  We encourage you to encourage LiteSpeed in their efforts to support the full mod_security rule language. 
+
When using the rules without the ASL Transparent WAF, where the rules are only loaded directly into Litespeed, please see the official Litespeed page for what modsecurity features Litespeed supports:
  
−
To resolve this, we are working on a standalone proxy WAF in ASL that can be placed in front of Litespeed. When this available we will update this article.
+
http://www.litespeedtech.com/support/wiki/doku.php?id=litespeed_wiki:mod_security_compatibility
  
−
Some customers have asked if we could modify the rules to work with the incomplete Litespeed implementation, and we have looked into this.  Currently, the incomplete LiteSpeed modsecurity implementation leaves out several critical capabilities to detect modern attacks.  Therefore, certain attacks will bypass Litespeeds implementation leaving Litespeed systems open to attack.  The current implementation also does not support the new faster branching and conditional rule language in mod_security that allows us to design in significant performance enhancements.  Ironically, this makes the rules run much slower with LiteSpeed than with Apache (even though Litespeed itself is faster).  Therefore, we are not able to provide our customers with quality fast rules, that will also protect systems against modern attacks using the incomplete Litespeed implementation.
+
Currently, if you do not use the T-WAF, this means Litespeed does not support the following features:
  
−
If you want to use LiteSpeed as your webserver we strongly caution you that the modsecurity implementation in Litespeed is incomplete, and therefore will miss attacks. We recommend the installation of 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.
+
# 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].
  
−
== What should LiteSpeed users do for a WAF? ==
+
== How to configure a local WAF for 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.
+
=== ASL V ===
  
−
== Why are all rules written for the 2.5.x lanuage? ==
+
Step 1) Log into ASL.  
  
−
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 2) Click on the "ASL" tab.   
  
−
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 3) Click on the "WAF Configuration" menu option.  
  
−
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 4) Click the "Add" button.
  
−
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 5) In the "Add New TWAF Setting" window from the "Add protection for ..." drop down, select "Local Web Server"
  
−
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 6) Select the port that litespeed runs on. Normally this is port 80.  
  
−
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 7) Check the SSL box
  
−
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.
+
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.
  
−
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!
+
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, however please see the LSWS official page for what modsecurity features Litespeed supports and does not support.  
 +
 
 +
https://www.litespeedtech.com/support/wiki/doku.php/litespeed_wiki:config:mod_security-compatibility

Latest revision as of 16:29, 26 July 2022

Contents

[edit] Does ASL work with LiteSpeed?

Yes, ASL is supported with LiteSpeed.

[edit] Do the modsecurity rules work with Litespeed

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

When using the rules without the ASL Transparent WAF, where the rules are only loaded directly into Litespeed, please see the official Litespeed page for what modsecurity 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.

[edit] How to configure a local WAF for litespeed

[edit] 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

[edit] 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.

[edit] Questions

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

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

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

Retrieved from "https://wiki.atomicorp.com/wiki/index.php?title=Litespeed&oldid=6348"
Personal tools