There is a problem with rules skipping when it should not skip from what I understand.
This is explanation from atomi guys:
I submitted this 2 months ago to bug report email but received no reply. Is there anyone alive at ls who can tell me if it will be fixed or acknowledge the bug?
This is explanation from atomi guys:
Thank you, we do have a pretty good working relationship with litespeed so yes we'll definitely be opening a bug report with them. So for your benefit here is what I'm seeing, this rule:
SecRule REQUEST_URI "(?:/(?
?:wp-admin/(page|post|widgets|link|network/site-settings\.php|options|themes/basic/themify/img\.php\?src=|admin\.php?cf/cf\.php)|admin/(?:edittemplate|webpage_update|theme-options|add_edit_)|(?:signup|cpinquiry|profile))\.php|p(??:hpbb\/install\/install\.ph|l\/download\?file=htt)p|roxy\/cb_proxy\.\?a=http:\/\/)|i(?:ndex\.php\/admin\/system_config\/save\/section\/payment\/|mp\/compose\.php)|tiki-(?bjectpermissions|editpage|view_cache)|jomsocial\/[a-z]+\/(?:edit|add))|^(?:\/(??:[a-z0-9\-]+\/events\?(?:utm_|trk_)|node\/[0-9]+\/(?:edit|add)|[a-z]+\/unsubscribe)|(?:mysqldumper\/dump|xmlrpc)\.php$|go\.php\?u=affilorama&t=http:\/\/|\.services\/sitelogout)|/(?:b/ss/mxmacromedia|horde/services/go|node/add|cas/))|(??:jw_allvideos_player|mod_mp3player)\?(?:file|playlist)=htt|ubbthreads\/admin\/dofeatures\.ph)p|ad-?server\/adjs|\?mode=addshout|^/administrator/index\.php\?option=com_rsform|^/index\.php/profile/register/registerprofile|^/[a-z]+/edit|^/(?:elements|admin/media)/(?:s(?:ave|ettings?)|appearance)/|^/panel\?comd=nlwebform|^/cocms/index\.php\?|^/ls_javascript_combine/|^/index\.php\?option=com_rsform|^/killboard/\?a=admin_idfeedsyndication|^/api/users|^/numo/module/form_handler/|^/admin/add_edit_document)" phase:2,id:333814,rev:6,pass,t:none,t:lowercase,nolog,skipAfter:END_INJECTION_RULES_1
Is a special rule, basically it looks for known cases where the application is known to work with things like url= http://www.example.com, and when the rules see this kind of app they skip over rules like the test you were running. In your case I see litespeed processing the rule, but not handling it normally:
2015-05-26 01:09:34.916 [INFO] [xx.xxx.xx.xxx:34099-0#APVH_xx.xx.xx.xx:80 xx.xx.xx.xx:80 xx.xx.xx.xx:80 xx.xxx.xxx.xx:80_xxxxxxxxxxxxxxxxxxxxxx] [SECURITY] [ID:333814] match [REQUEST_URI] against pattern [(?:/(??:wp-admin/(page|post|widgets|link|network/site-settings\.php|options|themes/basic/themify/img\.php\?src=|admin\.php?cf/cf\.php)|admin/(?:edittemplate|webpage_update|theme-options|add_edit_)|(?:signup|cpinquiry|profile))\.php|p(??:hpbb\/install\/install\.ph|l\/download\?file=htt)p|roxy\/cb_proxy\.\?a=http:\/\/)|i(?:ndex\.php\/admin\/system_config\/save\/section\/payment\/|mp\/compose\.php)|tiki-(?bjectpermissions|editpage|view_cache)|jomsocial\/[a-z]+\/(?:edit|add))|^(?:\/(??:[a-z0-9\-]+\/events\?(?:utm_|trk_)|node\/[0-9]+\/(?:edit|add)|[a-z]+\/unsubscribe)|(?:mysqldumper\/dump|xmlrpc)\.php$|go\.php\?u=affilorama&t=http:\/\/|\.services\/sitelogout)|/(?:b/ss/mxmacromedia|horde/services/go|node/add|cas/))|(??:jw_allvideos_player|mod_mp3player)\?(?:file|playlist)=htt|ubbthreads\/admin\/dofeatures\.ph)p|ad-?server\/adjs|\?mode=addshout|^/administrator/index\.php\?option=com_rsform|^/index\.php/profile/register/registerprofile|^/[a-z]+/edit|^/(?:elements|admin/media)/(?:s(?:ave|ettings?)|appearance)/|^/panel\?comd=nlwebform|^/cocms/index\.php\?|^/ls_javascript_combine/|^/index\.php\?option=com_rsform|^/killboard/\?a=admin_idfeedsyndication|^/api/users|^/numo/module/form_handler/|^/admin/add_edit_document)], result: 0
Which correctly returns a "no match", hence the "result: 0". Only if its a match should it skip to a mark in the rules (modsec has a GOTO type language) skipping over a bunch of rules. Since its not a match it should continue to process, but its not going on to the next rule, it seems to be skipping over it, which it shouldnt be doing. The next rule we should see processed is 340162, which sometimes we do see processed on your system:
grep 340162 debug_log | wc -l
2
So sometimes this is processed correctly, other times its not and even in those cases the same result: 0 on rule 333814. So something isnt working right in litespeed and it seems intermittent, 340162 sometimes gets processed, and sometimes it gets skipped. Which means other things are getting intermittently skipped if this internal test is failing.
As I said before, the litespeed guys have been pretty good at working with us when we report bugs to them in litespeed, so we'll open a bug report with them. You may want to do the same yourself just so you can track this issue.
We'll get to the bottom of this, and appreciate your patience as we work with them to find out why litespeed is doing this.
SecRule REQUEST_URI "(?:/(?
?:wp-admin/(page|post|widgets|link|network/site-settings\.php|options|themes/basic/themify/img\.php\?src=|admin\.php?cf/cf\.php)|admin/(?:edittemplate|webpage_update|theme-options|add_edit_)|(?:signup|cpinquiry|profile))\.php|p(??:hpbb\/install\/install\.ph|l\/download\?file=htt)p|roxy\/cb_proxy\.\?a=http:\/\/)|i(?:ndex\.php\/admin\/system_config\/save\/section\/payment\/|mp\/compose\.php)|tiki-(?bjectpermissions|editpage|view_cache)|jomsocial\/[a-z]+\/(?:edit|add))|^(?:\/(??:[a-z0-9\-]+\/events\?(?:utm_|trk_)|node\/[0-9]+\/(?:edit|add)|[a-z]+\/unsubscribe)|(?:mysqldumper\/dump|xmlrpc)\.php$|go\.php\?u=affilorama&t=http:\/\/|\.services\/sitelogout)|/(?:b/ss/mxmacromedia|horde/services/go|node/add|cas/))|(??:jw_allvideos_player|mod_mp3player)\?(?:file|playlist)=htt|ubbthreads\/admin\/dofeatures\.ph)p|ad-?server\/adjs|\?mode=addshout|^/administrator/index\.php\?option=com_rsform|^/index\.php/profile/register/registerprofile|^/[a-z]+/edit|^/(?:elements|admin/media)/(?:s(?:ave|ettings?)|appearance)/|^/panel\?comd=nlwebform|^/cocms/index\.php\?|^/ls_javascript_combine/|^/index\.php\?option=com_rsform|^/killboard/\?a=admin_idfeedsyndication|^/api/users|^/numo/module/form_handler/|^/admin/add_edit_document)" phase:2,id:333814,rev:6,pass,t:none,t:lowercase,nolog,skipAfter:END_INJECTION_RULES_1Is a special rule, basically it looks for known cases where the application is known to work with things like url= http://www.example.com, and when the rules see this kind of app they skip over rules like the test you were running. In your case I see litespeed processing the rule, but not handling it normally:
2015-05-26 01:09:34.916 [INFO] [xx.xxx.xx.xxx:34099-0#APVH_xx.xx.xx.xx:80 xx.xx.xx.xx:80 xx.xx.xx.xx:80 xx.xxx.xxx.xx:80_xxxxxxxxxxxxxxxxxxxxxx] [SECURITY] [ID:333814] match [REQUEST_URI] against pattern [(?:/(?
?:wp-admin/(page|post|widgets|link|network/site-settings\.php|options|themes/basic/themify/img\.php\?src=|admin\.php?cf/cf\.php)|admin/(?:edittemplate|webpage_update|theme-options|add_edit_)|(?:signup|cpinquiry|profile))\.php|p(??:hpbb\/install\/install\.ph|l\/download\?file=htt)p|roxy\/cb_proxy\.\?a=http:\/\/)|i(?:ndex\.php\/admin\/system_config\/save\/section\/payment\/|mp\/compose\.php)|tiki-(?bjectpermissions|editpage|view_cache)|jomsocial\/[a-z]+\/(?:edit|add))|^(?:\/(??:[a-z0-9\-]+\/events\?(?:utm_|trk_)|node\/[0-9]+\/(?:edit|add)|[a-z]+\/unsubscribe)|(?:mysqldumper\/dump|xmlrpc)\.php$|go\.php\?u=affilorama&t=http:\/\/|\.services\/sitelogout)|/(?:b/ss/mxmacromedia|horde/services/go|node/add|cas/))|(??:jw_allvideos_player|mod_mp3player)\?(?:file|playlist)=htt|ubbthreads\/admin\/dofeatures\.ph)p|ad-?server\/adjs|\?mode=addshout|^/administrator/index\.php\?option=com_rsform|^/index\.php/profile/register/registerprofile|^/[a-z]+/edit|^/(?:elements|admin/media)/(?:s(?:ave|ettings?)|appearance)/|^/panel\?comd=nlwebform|^/cocms/index\.php\?|^/ls_javascript_combine/|^/index\.php\?option=com_rsform|^/killboard/\?a=admin_idfeedsyndication|^/api/users|^/numo/module/form_handler/|^/admin/add_edit_document)], result: 0Which correctly returns a "no match", hence the "result: 0". Only if its a match should it skip to a mark in the rules (modsec has a GOTO type language) skipping over a bunch of rules. Since its not a match it should continue to process, but its not going on to the next rule, it seems to be skipping over it, which it shouldnt be doing. The next rule we should see processed is 340162, which sometimes we do see processed on your system:
grep 340162 debug_log | wc -l
2
So sometimes this is processed correctly, other times its not and even in those cases the same result: 0 on rule 333814. So something isnt working right in litespeed and it seems intermittent, 340162 sometimes gets processed, and sometimes it gets skipped. Which means other things are getting intermittently skipped if this internal test is failing.
As I said before, the litespeed guys have been pretty good at working with us when we report bugs to them in litespeed, so we'll open a bug report with them. You may want to do the same yourself just so you can track this issue.
We'll get to the bottom of this, and appreciate your patience as we work with them to find out why litespeed is doing this.