Difference between revisions of "Litespeed"

From Atomicorp Wiki
Jump to: navigation, search
m (Does ASL work with LiteSpeed?)
m (Does ASL work with LiteSpeed?)
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 does not currently support the full rule set or rule language.  Because of this, it is not fully compatible with modern mod_security rules, such as ours.'''  
+
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 actually compatible with any modern mod_security rules.'''
  
According to this forum post on the cpanel forums their implementation is currently incomplete:
+
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:
  
 
http://www.litespeedtech.com/support/forum/showthread.php?t=4619&highlight=modsecurity
 
http://www.litespeedtech.com/support/forum/showthread.php?t=4619&highlight=modsecurity
  
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.  Litespeed is working on full 2.5.x compatibility, we encourage you to encourage LiteSpeed in their efforts to support the full mod_security rule language.  We would really like to be able to support Litespeed!
+
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.   
  
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.
+
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.
 +
 
 +
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.
 +
 
 +
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.
  
 
== What should LiteSpeed users do for a WAF?  ==
 
== What should LiteSpeed users do for a WAF?  ==

Revision as of 18:49, 21 June 2011

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 actually compatible with any modern mod_security rules.

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:

http://www.litespeedtech.com/support/forum/showthread.php?t=4619&highlight=modsecurity

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.

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.

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.

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.

What should LiteSpeed users do for a WAF?

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.

Why are all rules written for the 2.5.x lanuage?

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.

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.

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.

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!

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.

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. :-)

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.

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!

Personal tools