mod-security-users — General discussion about mod_security

Re: [mod-security-users] Trigger modsec log/deny from web script - logging web spam flagged by b2evolution

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

Jason Edgecombe wrote:
>
> Excellent! I'll implement that.
> 
> Is there another way incase I don't want to use the http error code?
> 
> For example, a http request contains a spam referrer, but I still want
> to serve the page to the client.

  I don't know anything about your software but you can serve
  a perfectly normal looking page with code 403 (since the code
  is not shown to the user). But if your setup does not allow
  for that you can try to use output buffering and catch
  spammers with:

  SecFilterSelective OUTPUT "keyword in the response"

  This is a somewhat slower solution, though.

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

Re: [mod-security-users] Trigger modsec log/deny from web script - logging web spam flagged by b2evolution

[Jason E. <jed...@ca...>]

Ivan Ristic wrote:

>Jason Edgecombe wrote:
>  
>
>>Hi there,
>>
>>Is there a way to have mod_security deny and log a request based on the
>>action of a php/perl/cgi script?
>>
>>Specifically, I'm using b2evolution for weblogs and I want to have
>>mod_security log the requests that b2evolution marks as spam. Currently,
>>b2evolution returns a 403 when a comment/trackback is spam. I don't see
>>a way to trigger mod_security based on response code. Would setting an
>>environment variable from within a PHP script accomplish this?
>>    
>>
>
>  How about:
>
>  SecAuditLogRelevantStatus ^403$
>
>  
>
Excellent! I'll implement that.

Is there another way incase I don't want to use the http error code?

For example, a http request contains a spam referrer, but I still want 
to serve the page to the client.

[mod-security-users] ModSecurity 1.9.1 has been released

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

ModSecurity 1.9.1 has been released. It is available for
immediate download from:

    http://www.modsecurity.org/download/

ModSecurity 1.9.1 is a bug-fix release. It fixes four minor
issues discovered in 1.9.


Changes (since 1.9)
-------------------

* Variables OUTPUT and OUTPUT_STATUS are no longer silently
  accepted (although they don't do anything) in the Apache
  1.3.x version of ModSecurity.

* Relaxed multipart checks to allow empty multipart body IE
  appears to (sometimes) send.

* Fixed a bug with chained rules and detect-only mode.

* Fixed a bug with FILE_NAME_* and FILE_SIZE_* variables.


About ModSecurity
-----------------
ModSecurity is a web application firewall designed to protect
vulnerable applications and reject manual and automated attacks.
It is an open source intrusion detection and prevention system. It
can work embedded in Apache, or as a standalone security device when
configured to work as part of an Apache-based reverse proxy.

Optionally, ModSecurity creates application audit logs, which contain
the full request body in addition to all other details. Requests are
filtered using regular expressions. Some of the things possible are:

  * Apply filters against any part of the request (URI,
    headers, either GET or POST)
  * Apply filters against individual parameters
  * Reject SQL injection attacks
  * Reject Cross site scripting attacks
  * Store the files uploaded through the web server, and have them
    checked by external scripts

With a few general rules ModSecurity can protect from both known
and unknown vulnerabilities. It excels as a tool for HTTP traffic
monitoring and just-in-time patching.

ModSecurity is dual-licensed. It can be used at no cost under the
terms of GPL v2. Support and commercial licences (for end-users
and OEM distributors) can be obtained from Thinking Stone
(http://www.thinkingstone.com).

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

Re: [mod-security-users] Blocking

[Terry D. <tdo...@na...>]

Gerwin Krist -|- Digitalus Webhosting wrote:
> Guys,
> 
> The things you proposed didn't worked you, 

No, my previous signature filter would have failed, because I made the mistake 
of assuming the matches were case sesnsitive.

SecFilterSelective ARGS_VALUES "\n\s*bcc:"

should work better (and it looks nicer).

>but found out it has to be 
> something like this? 
> 
> SecFilterSelective "POST_PAYLOAD" "\s*bcc:"
> 
> Please tell me that it safe to use this :)

It depends what you mean by safe. It will certainly work in that it will match 
any attempt to put 'bcc:' (possibly preceeded by whitespace) in any input 
field of any form.

Of course, the above paragraph I just typed would match it as well, so a 
perfectly legitimate discussion about mail headers in a forum could end up 
being blocked with a message that would leave the user assuming a server 
fault. If the above rule was all you required to trigger a denial, you could 
end up with a lot of false positives.

I think my initial suggestion may have been too simplistic. Where your case 
differs from my own is that my form is used for only one function and I can be 
certain that any occurrence of a mail header is a spam attempt, whereas you 
have numerous customers using various scripts that could be for any purpose.

Consider a scenario where someone posts full message headers in an input field 
in order to ask for help in anlysing a mailer issue. It's an extreme case, but 
it could be difficult to explain to an irate customer why you've 'broken' 
their forum...

If you can bear allowing the spam to happen a little longer, try just setting 
up an audit log for matching POSTs, rather than denying them immediately. If 
you're seeing a lot of spam, then you should soon have a large enough data set 
to spot an obvious pattern. You can then set up a ruleset (possibly a few 
chained rules) that match the necessary parts. Once the spam script starts to 
fail, it's highly unlikely that the spammer will waste their time trying to 
defeat your measures and they'll simply go away:

Depending on your ruleset, you should be able to enable audits with:

SecAuditEngine RelevantOnly
SecAuditLog <auditlogfile>

and adapt your above rule to cause a match, but pass it through:

SecFilterSelective "POST_PAYLOAD" "\s*bcc:" "log,pass"

 From this, you may well be able to isolate one or two originating IP 
addresses as the source of the spam and block them out at the firewall level.

Terry.

> Is this 
> Regards,
> Gerwin
> On Tuesday 29 November 2005 12:23, Terry Dooher wrote:
> 
>>Gerwin Krist -|- Digitalus Webhosting wrote:
>>
>>>Heya,
>>>
>>>Don't know if you guys see trends, but we see a huge trend of spammers
>>>abusing email forms for sending spam. Is there a way of blocking these,
>>>by blocking POST requests with email addys in it? Any help would be
>>>apreciated!
>>
>>I've seen a few of these attempted on a mail form I've written myself. The
>>form script is a simple PHP mailer that's only there to save us publishing
>>an email address on site.
>>
>>The usual tactic seems to be to fill in any text input fields with <short
>>random string> @ ourdomain.com, then filling the text area field in with an
>>attempt at RFC 2822 headers and the spam message. The hope is that the
>>mailer will simply send the stream as two messages.
>>
>>I've got some preg_match() lines in the PHP for blocking these. They
>>generally revolve around picking out message headers from the assembled
>>body, and sanitising any email address in the fields not marked 'email
>>address'. (I don't block these as legitiamte users can put their email
>>adress in the strangest of places)
>>
>>It's usually a good idea to do this kind of checking in the script, though,
>>as you'll find it easier to report errors to the user with some context
>>without having to use custom rejection rules and ErrorDocuments.
>>
>>That said, to pick the spam out at the mod_security stage, you might want
>>to scan specific ARGS_n values or just all of ARGS_VALUES for the basic
>>headers like "\s*To:", "\s*From:", "\s*Cc:" and "\s*Bcc:". The \s* will
>>match any possible leading whitespace as this can form part of a valid
>>header. You could do this match at the start of a line ("\n\s*To:" for
>>example) if you want to reduce the potential for false positives.
>>
>>Far more crudely, you could just block anything with ':' or '@' anywhere in
>>ARGS_VALUES.
>>
>>Terry.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log
>>files for problems?  Stop!  Download the new AJAX search engine that makes
>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>>_______________________________________________
>>mod-security-users mailing list
>>mod...@li...
>>https://lists.sourceforge.net/lists/listinfo/mod-security-users
> 
> 

Re: [mod-security-users] Trigger modsec log/deny from web script - logging web spam flagged by b2evolution

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

Jason Edgecombe wrote:
> Hi there,
> 
> Is there a way to have mod_security deny and log a request based on the
> action of a php/perl/cgi script?
> 
> Specifically, I'm using b2evolution for weblogs and I want to have
> mod_security log the requests that b2evolution marks as spam. Currently,
> b2evolution returns a 403 when a comment/trackback is spam. I don't see
> a way to trigger mod_security based on response code. Would setting an
> environment variable from within a PHP script accomplish this?

  How about:

  SecAuditLogRelevantStatus ^403$

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

[mod-security-users] Trigger modsec log/deny from web script - logging web spam flagged by b2evolution

[Jason E. <jed...@ca...>]

Hi there,

Is there a way to have mod_security deny and log a request based on the 
action of a php/perl/cgi script?

Specifically, I'm using b2evolution for weblogs and I want to have 
mod_security log the requests that b2evolution marks as spam. Currently, 
b2evolution returns a 403 when a comment/trackback is spam. I don't see 
a way to trigger mod_security based on response code. Would setting an 
environment variable from within a PHP script accomplish this?

How might I achieve this?

Sincerely,
Jason Edgecombe

Re: [mod-security-users] Blocking

[Gerwin K. -|- D. W. <ge...@di...>]

Guys,

The things you proposed didn't worked you, but found out it has to be=20
something like this?=20

SecFilterSelective "POST_PAYLOAD" "\s*bcc:"

Please tell me that it safe to use this :)

Is this=20
Regards,
Gerwin
On Tuesday 29 November 2005 12:23, Terry Dooher wrote:
> Gerwin Krist -|- Digitalus Webhosting wrote:
> > Heya,
> >
> > Don't know if you guys see trends, but we see a huge trend of spammers
> > abusing email forms for sending spam. Is there a way of blocking these,
> > by blocking POST requests with email addys in it? Any help would be
> > apreciated!
>
> I've seen a few of these attempted on a mail form I've written myself. The
> form script is a simple PHP mailer that's only there to save us publishing
> an email address on site.
>
> The usual tactic seems to be to fill in any text input fields with <short
> random string> @ ourdomain.com, then filling the text area field in with =
an
> attempt at RFC 2822 headers and the spam message. The hope is that the
> mailer will simply send the stream as two messages.
>
> I've got some preg_match() lines in the PHP for blocking these. They
> generally revolve around picking out message headers from the assembled
> body, and sanitising any email address in the fields not marked 'email
> address'. (I don't block these as legitiamte users can put their email
> adress in the strangest of places)
>
> It's usually a good idea to do this kind of checking in the script, thoug=
h,
> as you'll find it easier to report errors to the user with some context
> without having to use custom rejection rules and ErrorDocuments.
>
> That said, to pick the spam out at the mod_security stage, you might want
> to scan specific ARGS_n values or just all of ARGS_VALUES for the basic
> headers like "\s*To:", "\s*From:", "\s*Cc:" and "\s*Bcc:". The \s* will
> match any possible leading whitespace as this can form part of a valid
> header. You could do this match at the start of a line ("\n\s*To:" for
> example) if you want to reduce the potential for false positives.
>
> Far more crudely, you could just block anything with ':' or '@' anywhere =
in
> ARGS_VALUES.
>
> Terry.
>
>
>
>
>
>
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users

=2D-=20
Met vriendelijke groet/With kind regards,

Gerwin Krist

Digitalus
=46irst-class Internet Webhosting

(w) http://www.digitalus.nl
(e) gerwin at digitalus.nl
(p) PGP-ID: 79B325D4
(t) +31 (0) 598 630000
(f) +31 (0) 598 631860


***************************************************************************=
************
This message may contain information which is confidential or privileged.
If you are not the intended recipient, please advise the sender immediately
by reply e-mail and delete this message and any attachments without
retaining
a copy.
***************************************************************************=
************

Re: [mod-security-users] Blocking

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

Terry Dooher wrote:
>
> I thought there was a way of ignoring case in signatures, but I can't
> seem to find it, so I've covered all of the bases with single character
> matches.

  Actually, comparisons are case-insensitive, so you don't need
  to worry about case at all.


> As far as I know, The above will match the only valid way of presenting
> a bcc: header. There may be some way of masking newlines that would fool
> this filter, but still be a valid header. I'm not aware of one, however.
> It should be fairly obvious how to tailor this to match To:, From: etc...
> 
> It's also worth creating an audit log of infringing requests, at least
> to begin with.

  That's a good idea. I've been thinking about creating a special
  email address to accept audit log entries. The idea is to
  automate the process and put the log entries into a database
  automatically.

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

Re: [mod-security-users] Blocking

[Terry D. <tdo...@na...>]

Gerwin Krist -|- Digitalus Webhosting wrote:
> He Terry,
> 
> I do know how to code safe code, it's just these damn customers you know :D So 
> I think mod_security is the best way to do. Could you tell me what code to 
> use in mod_security for checking posts with bcc: (case insensitive)

Understandable. Keeping one's own code safe is enough work without having to 
maintain a number of customers' along with it.

Assuming you can't know any of your customers' code, then it's best to scan 
ARGS_VALUES for any infringing text. The following rule should match 0 or mroe 
whitespae characters followed by "bcc:" at the start of a line:

SecFilterSelective ARGS_VALUES "\n\s*[Bb][Cc][Cc]:"

I thought there was a way of ignoring case in signatures, but I can't seem to 
find it, so I've covered all of the bases with single character matches.

As far as I know, The above will match the only valid way of presenting a bcc: 
header. There may be some way of masking newlines that would fool this filter, 
but still be a valid header. I'm not aware of one, however. It should be 
fairly obvious how to tailor this to match To:, From: etc...

It's also worth creating an audit log of infringing requests, at least to 
begin with.

Hope this helps,

Terry.

> Thanks in advance :)
> 
> 
> On Tuesday 29 November 2005 12:23, Terry Dooher wrote:
> 
>>Gerwin Krist -|- Digitalus Webhosting wrote:
>>
>>>Heya,
>>>
>>>Don't know if you guys see trends, but we see a huge trend of spammers
>>>abusing email forms for sending spam. Is there a way of blocking these,
>>>by blocking POST requests with email addys in it? Any help would be
>>>apreciated!
>>
>>I've seen a few of these attempted on a mail form I've written myself. The
>>form script is a simple PHP mailer that's only there to save us publishing
>>an email address on site.
>>
>>The usual tactic seems to be to fill in any text input fields with <short
>>random string> @ ourdomain.com, then filling the text area field in with an
>>attempt at RFC 2822 headers and the spam message. The hope is that the
>>mailer will simply send the stream as two messages.
>>
>>I've got some preg_match() lines in the PHP for blocking these. They
>>generally revolve around picking out message headers from the assembled
>>body, and sanitising any email address in the fields not marked 'email
>>address'. (I don't block these as legitiamte users can put their email
>>adress in the strangest of places)
>>
>>It's usually a good idea to do this kind of checking in the script, though,
>>as you'll find it easier to report errors to the user with some context
>>without having to use custom rejection rules and ErrorDocuments.
>>
>>That said, to pick the spam out at the mod_security stage, you might want
>>to scan specific ARGS_n values or just all of ARGS_VALUES for the basic
>>headers like "\s*To:", "\s*From:", "\s*Cc:" and "\s*Bcc:". The \s* will
>>match any possible leading whitespace as this can form part of a valid
>>header. You could do this match at the start of a line ("\n\s*To:" for
>>example) if you want to reduce the potential for false positives.
>>
>>Far more crudely, you could just block anything with ':' or '@' anywhere in
>>ARGS_VALUES.
>>
>>Terry.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log
>>files for problems?  Stop!  Download the new AJAX search engine that makes
>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>>_______________________________________________
>>mod-security-users mailing list
>>mod...@li...
>>https://lists.sourceforge.net/lists/listinfo/mod-security-users
> 
> 

Re: [mod-security-users] Blocking

[Gerwin K. -|- D. W. <ge...@di...>]

He Terry,

I do know how to code safe code, it's just these damn customers you know :D=
 So=20
I think mod_security is the best way to do. Could you tell me what code to=
=20
use in mod_security for checking posts with bcc: (case insensitive)

Thanks in advance :)


On Tuesday 29 November 2005 12:23, Terry Dooher wrote:
> Gerwin Krist -|- Digitalus Webhosting wrote:
> > Heya,
> >
> > Don't know if you guys see trends, but we see a huge trend of spammers
> > abusing email forms for sending spam. Is there a way of blocking these,
> > by blocking POST requests with email addys in it? Any help would be
> > apreciated!
>
> I've seen a few of these attempted on a mail form I've written myself. The
> form script is a simple PHP mailer that's only there to save us publishing
> an email address on site.
>
> The usual tactic seems to be to fill in any text input fields with <short
> random string> @ ourdomain.com, then filling the text area field in with =
an
> attempt at RFC 2822 headers and the spam message. The hope is that the
> mailer will simply send the stream as two messages.
>
> I've got some preg_match() lines in the PHP for blocking these. They
> generally revolve around picking out message headers from the assembled
> body, and sanitising any email address in the fields not marked 'email
> address'. (I don't block these as legitiamte users can put their email
> adress in the strangest of places)
>
> It's usually a good idea to do this kind of checking in the script, thoug=
h,
> as you'll find it easier to report errors to the user with some context
> without having to use custom rejection rules and ErrorDocuments.
>
> That said, to pick the spam out at the mod_security stage, you might want
> to scan specific ARGS_n values or just all of ARGS_VALUES for the basic
> headers like "\s*To:", "\s*From:", "\s*Cc:" and "\s*Bcc:". The \s* will
> match any possible leading whitespace as this can form part of a valid
> header. You could do this match at the start of a line ("\n\s*To:" for
> example) if you want to reduce the potential for false positives.
>
> Far more crudely, you could just block anything with ':' or '@' anywhere =
in
> ARGS_VALUES.
>
> Terry.
>
>
>
>
>
>
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users

=2D-=20
Met vriendelijke groet/With kind regards,

Gerwin Krist

Digitalus
=46irst-class Internet Webhosting

(w) http://www.digitalus.nl
(e) gerwin at digitalus.nl
(p) PGP-ID: 79B325D4
(t) +31 (0) 598 630000
(f) +31 (0) 598 631860


***************************************************************************=
************
This message may contain information which is confidential or privileged.
If you are not the intended recipient, please advise the sender immediately
by reply e-mail and delete this message and any attachments without
retaining
a copy.
***************************************************************************=
************

Re: [mod-security-users] Blocking

[Terry D. <tdo...@na...>]

Gerwin Krist -|- Digitalus Webhosting wrote:
> Heya,
> 
> Don't know if you guys see trends, but we see a huge trend of spammers abusing 
> email forms for sending spam. Is there a way of blocking these, by blocking 
> POST requests with email addys in it? Any help would be apreciated!

I've seen a few of these attempted on a mail form I've written myself. The 
form script is a simple PHP mailer that's only there to save us publishing an 
email address on site.

The usual tactic seems to be to fill in any text input fields with <short 
random string> @ ourdomain.com, then filling the text area field in with an 
attempt at RFC 2822 headers and the spam message. The hope is that the mailer 
will simply send the stream as two messages.

I've got some preg_match() lines in the PHP for blocking these. They generally 
revolve around picking out message headers from the assembled body, and 
sanitising any email address in the fields not marked 'email address'. (I 
don't block these as legitiamte users can put their email adress in the 
strangest of places)

It's usually a good idea to do this kind of checking in the script, though, as 
you'll find it easier to report errors to the user with some context without 
having to use custom rejection rules and ErrorDocuments.

That said, to pick the spam out at the mod_security stage, you might want to 
scan specific ARGS_n values or just all of ARGS_VALUES for the basic headers 
like "\s*To:", "\s*From:", "\s*Cc:" and "\s*Bcc:". The \s* will match any 
possible leading whitespace as this can form part of a valid header. You could 
do this match at the start of a line ("\n\s*To:" for example) if you want to 
reduce the potential for false positives.

Far more crudely, you could just block anything with ':' or '@' anywhere in 
ARGS_VALUES.

Terry.

[mod-security-users] Blocking

[Gerwin K. -|- D. W. <ge...@di...>]

Heya,

Don't know if you guys see trends, but we see a huge trend of spammers abus=
ing=20
email forms for sending spam. Is there a way of blocking these, by blocking=
=20
POST requests with email addys in it? Any help would be apreciated!

=2D-=20
Met vriendelijke groet/With kind regards,

Gerwin Krist

Digitalus
=46irst-class Internet Webhosting

(w) http://www.digitalus.nl
(e) gerwin at digitalus.nl
(p) PGP-ID: 79B325D4
(t) +31 (0) 598 630000
(f) +31 (0) 598 631860


***************************************************************************=
************
This message may contain information which is confidential or privileged.
If you are not the intended recipient, please advise the sender immediately
by reply e-mail and delete this message and any attachments without
retaining
a copy.
***************************************************************************=
************

[mod-security-users] Exception

[Randvo <ra...@em...>]

Hello,



Can I Do the following: 



1) If I've a File , for example called www.domain.com/signup.php



and i want to turn (SOME) of the rule off for (I.E: passwd) this file/page
ONLY and to not affect other sites etc .



for example if i want to do this for all rule for this page on all site i
can do : 



<Location /*/signup.php>

SecFilterInheritance Off

</Location>



 

But what if i want to disable a specific rule in a specific file on a
specific domain/user ??



for example i want to disable rule" secfilter "passwd" in file signup.php
for the site: domain.com (it's user: domain)



What is the correct syntax for this please ? 





<Location domain.com/signup.php>    ( or /home/domain/public_html/signup
php) 

SecFilter "wget"

SecFilterInheritance Off

</Location>



** I Know that it's wrong  , just to express my question...





I Hope that you can help me in this  . 



Thanks In Advance . 



Your's . 

Re: [mod-security-users] .htaccess includes considerations

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

Justin Grindea wrote:
> hi,
> 
> What are the considerations and implications of allowing virtual hosting
> clients to protect their applications using mod_security filters, in
> .htaccess level?

  You would be giving your customers more ways to perform DoS
  attacks against the web server.


> Sites with PHPBB, Nuke and alike will be able to add rules on their own
> and most important - restrict access
> to admin areas per IP. Even if they're on dynamic IP, before they go
> admining the site, they put in the .htaccess
> their IP and get access.
>
> This is a big security improvement. Lets say a hacker gets a cookie and
> has a login, that's fine maybe to post something
> on the site but he won't get access to the /admin area and mess up
> things pretty bad.


  That is already possible, using mod_access.

> Now what are the cons of allowing "unknown - untrusted" users adding
> stuff to mod_security? I believe we can make
> all important rules mandatory. I wouldn't want to have a user disabling
> mod_security totally for example, neither
> mess with the audit_log.

  Ah, but that's the whole problem! It is not possible to
  choose what you allow or do not allow them to do. You either
  give them access to it or you don't.

  Personally, I think giving your customers direct access to ModSecurity
  would only create a headache because of the additional support
  requirements. I simply don't believe they will be inclined to
  completely understand ModSecurity before they attempt to use it.
  Consequently, you will need to constantly help them with it. In
  the end I think it is better for the skilled administrators to
  do all of the work.

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

[mod-security-users] Positive security model in ModSecurity

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

I have posted my thoughts on the positive security model
protection (in ModSecurity) on my blog:
http://www.modsecurity.org/blog/archives/2005/11/positive_securi.html

As this is something I will be adding to v2.0, the subject is
open for discussions if anyone is interested.

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

[mod-security-users] .htaccess includes considerations

[Justin G. <web...@sw...>]

hi,

What are the considerations and implications of allowing virtual hosting
clients to protect their applications using mod_security filters, in .htaccess level?

The -DISABLE_HTACCESS compile options seems very reasonable but allowing server users, specially with PHP
applications to harden their sites security can be a big plus, and, help the total security of the server.
Sites with PHPBB, Nuke and alike will be able to add rules on their own and most important - restrict access
to admin areas per IP. Even if they're on dynamic IP, before they go admining the site, they put in the .htaccess
their IP and get access.
This is a big security improvement. Lets say a hacker gets a cookie and has a login, that's fine maybe to post something
on the site but he won't get access to the /admin area and mess up things pretty bad.

Also, from my experience I need to shut off cookies, URL and Unicode checks on nearly every shared server.
The ability to add these per site can be great.

Lastly, such setup should reduce server load. Now many of us hosters have most of gotroot's rules since we need
to protect many applications and we never know what applications our users have and we can't keep track of it for
sure.
We could provide protection for basic apps like phpBB, Nuke, Mambo and a bunch of others, while keeping out the
vast amount of rules to all other php/cgi apps on a per need, per site rules.

Now what are the cons of allowing "unknown - untrusted" users adding stuff to mod_security? I believe we can make
all important rules mandatory. I wouldn't want to have a user disabling mod_security totally for example, neither
mess with the audit_log.


thanks,
	Justin

Re: [mod-security-users] Possible to exempt mod_security from certain trusted IPs?

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

jeremy@TICKWATCH wrote:
> We've just installed mod_security here and it looks very nice :)
> 
> The server is running Vbulletin and  it seems that any good set of most
> mod_security rules will bust the template manager system for Vbulletin.
> 
> So I'm curious if anyone knows if it is possible to disable the
> mod_security rules for a couple IP's (mine) deemed to be trusted.

  Sure it is, using something like (at the top):

  SecFilterSelective REMOTE_ADDR ^YOUR_IP_ADDRESS$ nolog,allow

  Look it up in the manual.

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

[mod-security-users] Possible to exempt mod_security from certain trusted IPs?

[<je...@TI...>]

We've just installed mod_security here and it looks very nice :)

The server is running Vbulletin and  it seems that any good set of most 
mod_security rules will bust the template manager system for Vbulletin.

So I'm curious if anyone knows if it is possible to disable the 
mod_security rules for a couple IP's (mine) deemed to be trusted.

Thanks

Re: [mod-security-users] Webdav won't work with SecFilter

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

li...@32... wrote:
> on 11/24/05 6:42 AM, Ivan Ristic at iv...@we... wrote:
> 
> 
>>>I am running Mac OS X Tiger. When I attempt to connect to my webdav folder I
>>>cannot. The 2 secfilters blocking me are as follows...
>>>
>>>#XSS Attacks
>>>SecFilter "<(.|\n)+>"
>>>
>>># Only accept request encodings we know how to handle
>>># we exclude GET requests from this because some (automated)
>>># clients supply "text/html" as Content-Type
>>>SecFilterSelective HTTP_Content-Type
>>>"!(^$|^application/x-www-form-urlencoded$|^multipart/form-data)"
>>>
>>>
>>>Is there any changes I can make to the secfilter syntax so webdav will work,
>>>BUT not opening up possible exploit paths?
>>
>>  The only thing you can do is disable those two rules selectively,
>>  for the WebDAV areas. The attacks they are guarding against are
>>  not effective for WebDAV anyway.
> 
> How would I write a rule so that is will only apply those rules if the
> request DOES NOT CONTAIN '/ical' or '/dav' ?

  Try something like this:

  SecFilterSelective REQUEST_URI "!^(/ical|/dav)" chain
  SecFilterSelective ... whatever you want here

  There are other ways... and they are all documented in the manual.

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

Re: [mod-security-users] (no subject)

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

Diego Pellegrino wrote:
> Hi. I need that mod_security decode and applies rules filters to
> arguments codified in base64. Those arguments are passed
> like:
> http://www.blablabla.com?name=XYWXZXWZ
> where XYWXZXWZ is base64 encoded.
> how can i do that?

  By changing the source code. Since you are probably after
  a quick & dirty solution, you could change the function
  parse_arguments to base64-decode parameter values (if a valid
  base64 encoding is detected).

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

Re: [Fwd: Re: [mod-security-users] error with pictures upload]

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

Justin Grindea wrote:
> hi Ivan,
> 
> attached is the audit_log.

  Thanks.

  I think these are simply (user-) interrupted file uploads, resulting
  in incorrect multipart-encoded request bodies. I don't think your
  users are experiencing any errors at all (at least not due to
  anything mod_security does). I'll see if I can detect the condition
  in code and emit a different error message.


> Justin Grindea wrote:
> 
>> hi,
>>
>> I'm seeing this error quite a lot, when clients upload stuff to the
>> server, mainly jpeg pics:
>>
>> mod_security-message: Access denied with code 500. Error processing
>> request body: Multipart: final boundary missing
>>
>> what triggers this error?
> 
> 
>   It means the multipart request body is not properly
>   constructed. Can you consistently reproduce the problem? I've
>   already had to make one workaround for inconsistent behaviour
>   in IE.
> 
>   Do you have an audit log entry I can look at? If you do
>   please send it to my private email.
> 


-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

[mod-security-users] (no subject)

[Diego P. <die...@ho...>]

<html><div style='background-color:'><P align=left><FONT face="Courier New, Courier, Monospace">Hi. I need that mod_security decode and applies rules filters to arguments codified in base64. Those arguments are passed<BR>like:<BR><A href="http://www.blablabla.com?name=XYWXZXWZ">http://www.blablabla.com?name=XYWXZXWZ</A> <BR>where XYWXZXWZ is base64 encoded.<BR>how can i do that?</FONT></P></div></html>

Re: [mod-security-users] error with pictures upload

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

Justin Grindea wrote:
> hi,
> 
> I'm seeing this error quite a lot, when clients upload stuff to the
> server, mainly jpeg pics:
> 
> mod_security-message: Access denied with code 500. Error processing
> request body: Multipart: final boundary missing
> 
> what triggers this error?

  It means the multipart request body is not properly
  constructed. Can you consistently reproduce the problem? I've
  already had to make one workaround for inconsistent behaviour
  in IE.

  Do you have an audit log entry I can look at? If you do
  please send it to my private email.

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

[mod-security-users] error with pictures upload

[Justin G. <web...@sw...>]

hi,

I'm seeing this error quite a lot, when clients upload stuff to the server, mainly jpeg pics:

mod_security-message: Access denied with code 500. Error processing request body: Multipart: final boundary missing


what triggers this error?

thanks,
	Justin

Re: [mod-security-users] Problem with mod_security 1.9 and the new "SecFilterSignatureActi on"

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

CASTELLE Thomas wrote:
> Hi there,
> 
> I just installed mod_security 1.9, and I have a problem with the
> SecFilterSignatureAction directive which might be a bug...

  Yes, it is a bug. I have just fixed it in the CVS (Apache 2.x
  version number 1.298.2.2, Apache 1.x version number 1.269.2.2).
  Please test the new version (http://www.modsecurity.org/download/)
  and let me know if it works for you too. (BTW, you can safely
  use the version in the CVS since there's only one other minor
  change made to it since 1.9.)

  Thank you for submitting such a detailed bug report!

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org