Difference between revisions of "Litespeed"

From Atomicorp Wiki
Jump to: navigation, search
(Does ASL work with LiteSpeed?)
(Does ASL work with LiteSpeed?)
Line 2: Line 2:
  
 
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 language.  Because of this, it is not compatible with modern mod_security rules and can not protect against modern web attacks.'''  
 
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 language.  Because of this, it is not compatible with modern mod_security rules and can not protect against modern web attacks.'''  
 +
 +
According to this forum post on the cpanel forums:
 +
 +
http://www.litespeedtech.com/support/forum/showthread.php?t=4619&highlight=modsecurity
 +
 +
Litespeed does not have a feature complete modsecurity implementation, and currently only supports 1.9.x features.  1.9.x was obsolete many years ago, the current version of the modsecurity rule langage is 2.5.x.
  
 
To currently support LiteSpeed we would have to significantly weaken the rules, and, ironically, they would also be much much slower using LiteSpeeds mod_security implementation.  This is actually not because LiteSpeed is slower than Apache (Litespeed claims the opposite), but because the LiteSpeed WAF module does not support the new rule language in mod_security that allows us to design in massive performance enhancements to the rules.
 
To currently support LiteSpeed we would have to significantly weaken the rules, and, ironically, they would also be much much slower using LiteSpeeds mod_security implementation.  This is actually not because LiteSpeed is slower than Apache (Litespeed claims the opposite), but because the LiteSpeed WAF module does not support the new rule language in mod_security that allows us to design in massive performance enhancements to the rules.
Line 8: Line 14:
  
 
We do encourage you to encourage LiteSpeed to support the full mod_security rule language, and also to document their implementation (we have had no luck finding any documentation on their implementation) - as well as to reply to our emails regarding their product.  We would really like to be able to support it!
 
We do encourage you to encourage LiteSpeed to support the full mod_security rule language, and also to document their implementation (we have had no luck finding any documentation on their implementation) - as well as to reply to our emails regarding their product.  We would really like to be able to support 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!

Revision as of 16:21, 9 February 2011

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 language. Because of this, it is not compatible with modern mod_security rules and can not protect against modern web attacks.

According to this forum post on the cpanel forums:

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

Litespeed does not have a feature complete modsecurity implementation, and currently only supports 1.9.x features. 1.9.x was obsolete many years ago, the current version of the modsecurity rule langage is 2.5.x.

To currently support LiteSpeed we would have to significantly weaken the rules, and, ironically, they would also be much much slower using LiteSpeeds mod_security implementation. This is actually not because LiteSpeed is slower than Apache (Litespeed claims the opposite), but because the LiteSpeed WAF module does not support the new rule language in mod_security that allows us to design in massive performance enhancements to the rules.

If you want to use LiteSpeed, you will either have to forgo 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.

We do encourage you to encourage LiteSpeed to support the full mod_security rule language, and also to document their implementation (we have had no luck finding any documentation on their implementation) - as well as to reply to our emails regarding their product. We would really like to be able to support 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