mod-security-users

[mod-security-users] mod_security rules for specific IPs or subnets

[Dionysios G. S. <ds...@no...>]

mod_security rules for specific IPs or subnets

Since our site is edited only from within our LAN (subnet), I would like 
to instruct mod_security to permit access to certain pages like eg. 
admin.php only from a specific subnet, or IP. Something like:

SecFilter "admin\.php"
SecFilter "user\.php"

but only for IPs outside our LAN (people that visit the site).

Does anyone know how to do that?

Re: [mod-security-users] mod_security rules for specific IPs or subnets

[Ivan R. <iv...@we...>]

Dionysios G. Synodinos wrote:

> mod_security rules for specific IPs or subnets
> 
> Since our site is edited only from within our LAN (subnet), I would like
> to instruct mod_security to permit access to certain pages like eg.
> admin.php only from a specific subnet, or IP. Something like:
> 
> SecFilter "admin\.php"
> SecFilter "user\.php"

  These filters are too broad. If you want to match script filename
  use a selective filter:

   SecFilterSelective SCRIPT_FILENAME "admin\.php$"

  SecFilter will apply the signature to the filename, the query_string,
  post data and result in false positives.


> but only for IPs outside our LAN (people that visit the site).
> 
> Does anyone know how to do that?

  Sure you can do it with mod_security, but it is natural to do it
  with Apache built-in features, using mod_access:

   http://httpd.apache.org/docs/mod/mod_access.html

  Like this:

   <Files ~ "(admin\.php|user\.php)$">
       # deny everything by default
       order allow,deny
       # only allow access from the LAN
       allow from 192.168.254.
   </Files>

  With mod_security, something like this would equally work:

   SecFilterSelective REMOTE_ADDR "!^192.168.254" chain
   SecFilterSelective SCRIPT_FILENAME "(admin\.php|user\.php)$"

  (examples not tested, please make sure they work for you)

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

[mod-security-users] Bigger test fails but chained rule is recorded in audit_log

[Dionysios G. S. <ds...@no...>]

I use the following "big test":

    SecFilterSelective REMOTE_ADDR "!^148.101.211" chain
    SecFilterSelective SCRIPT_FILENAME "(admin\.php|user\.php)$"

which restricts access to admin.php & user.php (*) from outside my LAN.

It seems that since the first filter matches for any other request from 
the internet, it is recorded in the audit_log, even if the "big test" 
doesn't match.

Is there a way to avoid this behaviour since it clutters my logs with 
unneccesary information..?

I use "SecAuditEngine RelevantOnly"

-dsin

(*) I also use mod_access for that after Ivan's suggestion

Re: [mod-security-users] Bigger test fails but chained rule is recorded in audit_log

[Ivan R. <iv...@we...>]

Dionysios G. Synodinos wrote:

> I use the following "big test":
> 
>    SecFilterSelective REMOTE_ADDR "!^148.101.211" chain
>    SecFilterSelective SCRIPT_FILENAME "(admin\.php|user\.php)$"
> 
> which restricts access to admin.php & user.php (*) from outside my LAN.
> 
> It seems that since the first filter matches for any other request from 
> the internet, it is recorded in the audit_log, even if the "big test" 
> doesn't match.
> 
> Is there a way to avoid this behaviour since it clutters my logs with 
> unneccesary information..?
> 
> I use "SecAuditEngine RelevantOnly"

   That sounds like a bug to me, so you can count on it
   being fixed before 1.8.

Bye,
Ivan

Re: [mod-security-users] Bigger test fails but chained rule is recorded in audit_log

[Dionysios G. S. <ds...@no...>]

Ivan Ristic wrote:

> Dionysios G. Synodinos wrote:
>
>> I use the following "big test":
>>
>>    SecFilterSelective REMOTE_ADDR "!^148.101.211" chain
>>    SecFilterSelective SCRIPT_FILENAME "(admin\.php|user\.php)$"
>>
>> which restricts access to admin.php & user.php (*) from outside my LAN.
>>
>> It seems that since the first filter matches for any other request 
>> from the internet, it is recorded in the audit_log, even if the "big 
>> test" doesn't match.
>>
>> Is there a way to avoid this behaviour since it clutters my logs with 
>> unneccesary information..?
>>
>> I use "SecAuditEngine RelevantOnly"
>
>
>   That sounds like a bug to me, so you can count on it
>   being fixed before 1.8.

When one of the chained rules fails then the message that is recorded in the audit_log informs that:

	mod_security-message: Access denied with code 403. Pattern match BLAH BAH BLAH 

If the whole chain fails then it adds a line (action):

	mod_security-message: Access denied with code 403. Pattern match BLAH BLAH BLAH 
	mod_security-action: 403

It all depends on what your definition of what "RelevantOnly" means. If it is "relevant" to record any match in a chain even if the whole chain fails then it is not a bug. I would hope thow that something like:

	SecAuditEngine ActionOnly &
	SecAuditEngine MessageOnly

comes ups that will assist in fine tuning of what is recorded in the audit_log.

Anyway I tried to reverse the rules to see what happens and the result was that NOTHING IS RECORDED in the audit_log. I attach a piece of the debug_log.

Kind regards,
-dsin

Re: [mod-security-users] Bigger test fails but chained rule is recorded in audit_log

[Ivan R. <iv...@we...>]

Dionysios G. Synodinos wrote:
> I use the following "big test":
> 
>    SecFilterSelective REMOTE_ADDR "!^148.101.211" chain
>    SecFilterSelective SCRIPT_FILENAME "(admin\.php|user\.php)$"
> 
> which restricts access to admin.php & user.php (*) from outside my LAN.
> 
> It seems that since the first filter matches for any other request from
> the internet, it is recorded in the audit_log, even if the "big test"
> doesn't match.
> 
> Is there a way to avoid this behaviour since it clutters my logs with
> unneccesary information..?

  I couldn't repeat your problem using the 1.8.x branch. Please
  download the 1.8RC1 version (just released) and try it out.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]