Apache mod-security

hanj | 3 Jun 20:47

Trouble with phpMyAdmin and mod_sec (getting caught in phase:1)

Hello

I'm having trouble the excluding phpMyAdmin from mod_sec.

I've added the SecRuleInheritance Off and SecRuleEngine Off in the
Directory area of my VirtualHost. This seems to apply to phase:2, but
not phase:1. I'm getting a 400 status when I try to edit a record.

I also tried the SecRule REQUEST_FILENAME and allowing phase:1, but I
continue to get the 400 status.

Here is my modsec_audit.log and below that is a view of my apache
config for that directory. Any suggestions are greatly appreciated.

--816a6d09-A--
[03/Jun/2007:12:37:24 --0600] vVBTC0LbO5UAAD46MaoAAAAA xxx.xxx.xxx.xxx
1359 xxx.xxx.xxx.xxx 443 --816a6d09-B--
GET /phpmyadmin/tbl_change.php?db=mydb&table=data&token=323cf89f3969db1b855a159b9b250bc3&pos=0&session_max_rows=30&disp_direction=horiz
ontal&repeat_cells=100&dontlimitchars=0&primary_key=+%60data%60.%60DataID%60+%3D+702&sql_query=SELECT+%2A+FROM+%60data%60+WHERE+LastName+LIKE+%27%25doe%25%27&goto=sql.php
HTTP/1.1 Host: my.host.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8.0.12) Gecko/20070508 Firefox/1.5.0.12 Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://my.host.com/phpmyadmin/import.php
Cookie: pmaCookieVer=4; pma_collation_connection=utf8_unicode_ci;
pma_charset=iso-8859-1; pma_lang=en-utf-8;

(Continue reading)

headers

Ryan Barnett | 4 Jun 01:49

Re: Trouble with phpMyAdmin and mod_sec (gettingcaught in phase:1)

Rule ID 950107 has been generating a fair amount of False Positive hits
due to the way that various app are using encoded % signs (%25).  In
your example phpMyAdmin request string, it is passing SQL queries on the
URL line and is using %25 characters.  We will need to re-examine this
rule to see if there are any ways to improve the RegEx.

With that being said, the issue you are running into has to do with Rule
ID 950107 running in phase 1 and you are attempting to utilize Apache
scope directives (Vhost, Directory, etc...) to disable Mod.  This will
not work as all Apache scope directives are not available until phase 2.
So, if you want to disable Mod for a specific URL, you need to use the
same rule you had below -

SecRule REQUEST_FILENAME "^/phpmyadmin" \
	"allow,phase:1,nolog,ctl:ruleEngine=Off"

However, you need to call this rule up BEFORE the other Core Rules files
(which has Rule ID 950107).  Please see my Blog post on creating custom
rules and handling false positives -
http://www.modsecurity.org/blog/archives/2007/02/handling_false.html

--

-- 
Ryan C. Barnett
ModSecurity Community Manager
Breach Security: Director of Application Security Training
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache

(Continue reading)

headers

hanj | 4 Jun 03:37

Re: Trouble with phpMyAdmin and mod_sec (gettingcaught in phase:1)

On Sun, 3 Jun 2007 19:49:09 -0400
"Ryan Barnett" <Ryan.Barnett <at> Breach.com> wrote:

> Rule ID 950107 has been generating a fair amount of False Positive hits
> due to the way that various app are using encoded % signs (%25).  In
> your example phpMyAdmin request string, it is passing SQL queries on the
> URL line and is using %25 characters.  We will need to re-examine this
> rule to see if there are any ways to improve the RegEx.
> 
> With that being said, the issue you are running into has to do with Rule
> ID 950107 running in phase 1 and you are attempting to utilize Apache
> scope directives (Vhost, Directory, etc...) to disable Mod.  This will
> not work as all Apache scope directives are not available until phase 2.
> So, if you want to disable Mod for a specific URL, you need to use the
> same rule you had below -
> 
> SecRule REQUEST_FILENAME "^/phpmyadmin" \
> 	"allow,phase:1,nolog,ctl:ruleEngine=Off"
> 
> However, you need to call this rule up BEFORE the other Core Rules files
> (which has Rule ID 950107).  Please see my Blog post on creating custom
> rules and handling false positives -
> http://www.modsecurity.org/blog/archives/2007/02/handling_false.html

Hello Ryan

Weird. I applied this before the other rules and it was getting caught
on phase:2 even though I had SecRuleEngine Off. The only way for me to
get this to work was adding 'allow' to phase:2 as well as phase:1

(Continue reading)

headers

Avi Aminov | 4 Jun 09:20

Re: Trouble with phpMyAdmin and mod_sec (gettingcaught in phase:1)

Hi there Hanj,

You're saying the last rule worked for you? I find it hard to believe
that it prevented a rule in phase:1 from working. I tried it myself and
it didn't work. The thing is, when you specify the phase directive
twice, the last one counts. That means that your rule actually takes
place in phase 2, so it disables the protection in phase 2, and all the
rules of phase 1 should be performed.

I'll go back to your first message. The reason "SecRuleEngine Off" did
not work, is that the apache <directory> block is evaluated only after
phase 1 (after the request line has been interpreted by apache).
Meaning, all the rules/directives you put there, will NOT be executed
before the beginning of phase 2. This is why it didn't stop the rule in
phase 1 from going.

>From the same reason, this rule did not work:
	SecRule REQUEST_FILENAME "^/phpmyadmin" \
 	"allow,phase:1,nolog,ctl:ruleEngine=Off"
This rule is written well, but should be OUTSIDE the <directory> block.

On another note, rule 950107, among many other rules, have all been
moved to phase:2 in CoreRules V.1.4 (this was one of the reasons). This
version of the core rules is not bundled with ModSecurity2.1.1, and
should be installed separately. It can be found in the ModSecurity
download page, right below the main version.

Avi

-----Original Message-----

(Continue reading)