mod-security-users — General discussion about mod_security

Re: [mod-security-users] TRACE Method

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

ml...@pa... wrote:

> Hi,
> I'm using mod_security 1.8.2 on Apache2. 
> My configuration (apache2.conf) is below,
> 
> <IfModule mod_security.c>
>  SecFilterEngine On
>  SecFilterDefaultAction "deny,status:406"
>  SecFilterSelective REQUEST_METHOD "!(GET|POST|HEAD)"
> </IfModule>
> 
> It is work fine in proxy path which using ProxyPass, but not catch up
> TRACE method in non-proxy path, so I must use mod_rewrite.
> 
> any idea in mod_security?

  mod_security does not see the TRACE requests because it
  runs in a late phase in request processing. The use of
  mod_rewrite to handle TRACE is recommended. Future versions
  of mod_security may include a hook to run certain
  checks earlier.

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

[mod-security-users] [ANNOUNCE] mod_security 1.8.3 released

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

Mod_security 1.8.3 has been released. It is available for immediate
download from:

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

Version 1.8.3 is a maintenance release that fixes all the known
(minor) issues with the recently released version 1.8.2.

About mod_security
------------------
Mod_security is an Apache module whose purpose is to protect
vulnerable applications and reject human or automated attacks.
It is an open source intrusion detection and prevention system
for Apache. In addition to request filtering, it also creates Web
application audit logs. 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

With few general rules mod_security can protect from both
known and unknown vulnerabilities.


Changes (v1.8.3)
----------------

 * Fixed the invalid URL encoding validation bug, which occurred
   when a percentage sign was found in a multipart/form-data
   request variable.

 * Fixed the warning (on FreeBSD) about child process mutex
   reinitialization failing.

 * Improved log escaping slightly.

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

[mod-security-users] TRACE Method

[<ml...@pa...>]

Hi,
I'm using mod_security 1.8.2 on Apache2. 
My configuration (apache2.conf) is below,

<IfModule mod_security.c>
 SecFilterEngine On
 SecFilterDefaultAction "deny,status:406"
 SecFilterSelective REQUEST_METHOD "!(GET|POST|HEAD)"
</IfModule>

It is work fine in proxy path which using ProxyPass, but not catch up
TRACE method in non-proxy path, so I must use mod_rewrite.

any idea in mod_security?

--
Katsuharu Watanabe

Re: [mod-security-users] locations in windows, XSS

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

Daniel Guido wrote:
> /feedback.php is a little bit of overkill in my case.  ive got about 20
> different subdomains and the feedback.php script only exists on
> www.xxxx.com and not dave.xxxx.com or etc.xxxx.com.  i'll use it, but is
> there another way to specify only that script?

  Why don't you put the <Location> part only into one virtual host?


> and how would i know if i configured php correctly?

  By reading about dynamic filtering in the manual? :)

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

[Fwd: Re: [mod-security-users] locations in windows, XSS]

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

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

Re: [mod-security-users] locations in windows, XSS

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

Daniel Guido wrote:
> i have a very simple php script that has guestbook-like functionality.
> it also has no input sanitation.  therefore, i'd like to use one of
> those XSS regex's provided to check for XSS exploits in ONLY that one
> script being that I use things like javascript elsewhere on my server.
> here is what i used.  it doesn't prevent me from putting javascript into
> the input fields, submitting it over POST, and then having it display on
> the page.
> 
> SecFilterEngine DynamicOnly

  Make sure you've configured PHP properly to do this. If you
  are not sure, use "On" for the time being. Upgrade to "DynamicOnly"
  afterwards.


> <Location "C:\Apache2\users\www\feedback.php">
>     SecFilterSelective ARGS "<[[:space:]]*script"
> </Location>

  The <Location directives are not correctly configured. You
  probably want to use just

  <Location "/feedback.php">
  ...
  </Location>

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

Re: [mod-security-users] New to mod_security

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

> I was wondering if Ivan Ristic or other experienced mod_security users
> would be kind enough to post something more aggressive than
> httpd.conf.example.minimal but practical/proven enough to use "as-is" on
> a production public web server.

  I don't, at least not at this time. Yours is the first request
  for more aggressive rules :) Most problems I've dealt with in the
  past are with users being over-protective with their servers
  and preventing applications from working properly.

  But I've been thinking about a mod_security HOWTO for some time
  now and I expect to write it fairly soon.

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

[mod-security-users] locations in windows, XSS

[Daniel G. <inf...@sp...>]

i have a very simple php script that has guestbook-like functionality. 
it also has no input sanitation.  therefore, i'd like to use one of 
those XSS regex's provided to check for XSS exploits in ONLY that one 
script being that I use things like javascript elsewhere on my server. 
here is what i used.  it doesn't prevent me from putting javascript into 
the input fields, submitting it over POST, and then having it display on 
the page.

SecFilterEngine DynamicOnly
SecFilterScanPOST On

...

     <Location "C:\Apache2\users\www\feedback.php">
         SecFilterSelective ARGS "<[[:space:]]*script"
     </Location>

can anyone offer me any help?  i'm obviously running windows.  maybe the 
path is being handled wrong?  maybe the regex is wrong?  winxp, apache2, 
modsec 1.8.2, php4.  i ran the tests included in the source for 
modsecurity, they all worked.

dan

[mod-security-users] New to mod_security

[Altec <alt...@ya...>]

Hi,

First, thank you VERY MUCH for giving us such a great tool!

It looks like there's httpd.conf.example.minimal to help us get started 
and httpd.conf.regression-v2 that contains some additional rules (but 
mixed with test-only rules).

I was wondering if Ivan Ristic or other experienced mod_security users 
would be kind enough to post something more aggressive than 
httpd.conf.example.minimal but practical/proven enough to use "as-is" on 
a production public web server.

[mod-security-users] [ANNOUNCE] mod_security 1.8.2 released

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

Mod_security 1.8.2 has been released. It is available for immediate
download from:

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

Version 1.8.2 is a maintenance release that fixes all the known
issues with the recently released version 1.8.

About mod_security
------------------
Mod_security is an Apache module whose purpose is to protect
vulnerable applications and reject human or automated attacks.
It is an open source intrusion detection and prevention system
for Apache. In addition to request filtering, it also creates Web
application audit logs. 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

With few general rules mod_security can protect from both
known and unknown vulnerabilities.


Changes (v1.8.2)
----------------

 * Zero-length POST payloads are now allowed.

 * The Apache function ap_escape_logitem is no longer
   used, allowing mod_security to be used with older Apache
   releases.

 * The bug resulting in the closure of stdin during
   multipart/form-data requests was fixed.

 * POST payload scanning during multipart/form-data requests
   now works properly.

 * An error in the default configuration file was fixed.

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

Re: [mod-security-users] mod_security 1.8

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

Colin Tinker wrote:
> Hi
> 
> I have just installed the above and get this error:-
> 
> modulesSyntax error on line 44 of /etc/mod_security/mod_security.conf:
> 
> The line is:-
> 
> SecFilterSelective HTTP_Content-Type "!^(|application/x-www-form-urlencoded|
> multipart/form-data)$"
> 
> Does anyone have any idea why as it is part of the default config file.

  Because it appears to work with Apache 1.3.27 and Apache 2.x, but not
  with Apache 1.3.29 (or greater, I think). It complains about the
  expression being empty. Don't know why. I didn't notice it in my
  tests.

  Rewriting that line (of the file) like this:

  SecFilterSelective HTTP_Content-Type
  "!(^$|^application/x-www-form-urlencoded$|^multipart/form-data$)"

  should fix it. I did the same in the configuration in the CVS.

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

[mod-security-users] mod_security 1.8

[Colin T. <g1...@g1...>]

Hi

I have just installed the above and get this error:-

modulesSyntax error on line 44 of /etc/mod_security/mod_security.conf:

The line is:-

SecFilterSelective HTTP_Content-Type "!^(|application/x-www-form-urlencoded|
multipart/form-data)$"

Does anyone have any idea why as it is part of the default config file.

Thanks

Colin
-- 
Linux: Because rebooting is for adding hardware.

Re: [mod-security-users] Problem with with characters portugeses

[Luis M. C. <lu...@b2...>]

Well, I only spoke from my experience.
I didn=B4t know if there was a relation with the charset configuration=20
from httpd.conf and mod_security

Ivan Ristic wrote:

> Luis Miguel Cruz wrote:
>=20
>=20
>>What is the DefaultCharset you are using?
>>Those are not portugeses characters, they are also
>>spanish characters :(
>=20
>=20
>   There are no restrictions by default (if there are - that would be a
>   bug), it all depends on your configuration. Also, HTTP does not
>   care about character encodings.
>=20

Re: [mod-security-users] Problem with with characters portugeses

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

Luis Miguel Cruz wrote:

> What is the DefaultCharset you are using?
> Those are not portugeses characters, they are also
> spanish characters :(

  There are no restrictions by default (if there are - that would be a
  bug), it all depends on your configuration. Also, HTTP does not
  care about character encodings.

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

Re: [mod-security-users] Problem with with characters portugeses

[Luis M. C. <lu...@b2...>]

What is the DefaultCharset you are using?
Those are not portugeses characters, they are also spanish characters :(


Telepac wrote:

> I'm Portuguese
> I have problem with GET or POST whenever I intend to send characters as=
 for
> eg: " =E1 " or " =E9 "
>=20
> please help me
>=20
> Best regards
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKN=
D
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>=20

Re: [mod-security-users] Problem with with characters portugeses

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

Telepac wrote:

> I'm Portuguese
> I have problem with GET or POST whenever I intend to send characters as=
 for
> eg: " =E1 " or " =E9 "

  You are likely restricting requests with:

  SecFilterForceByteRange FROM TO (set FROM to 0 and TO to 255)

  or

  SecFilterCheckUnicodeEncoding (should be off unless you know
  what you're doing)

  But you should really send us your full mod_security configuration
  so we can see for ourselves.

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

[mod-security-users] Problem with with characters portugeses

[Telepac <op2...@ma...>]

I'm Portuguese
I have problem with GET or POST whenever I intend to send characters as for
eg: " á " or " é "

please help me

Best regards

[mod-security-users] [ANNOUNCE] mod_security 1.8 released

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

Mod_security 1.8 has been released. It is available for immediate
download from:

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

After more than six months of development, resulting in a
40% larger code base, a stable version of the 1.8 branch
is available. The list of changes below contains only the
list of improvement since the last v1.7.x release.


About mod_security
------------------
Mod_security is an Apache module whose purpose is to protect
vulnerable applications and reject human or automated attacks.
It is an open source intrusion detection and prevention system
for Apache. In addition to request filtering, it also creates Web
application audit logs. 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

With few general rules mod_security can protect from both
known and unknown vulnerabilities.


Changes (since v1.7)
--------------------

  * Implementation of a multipart/form-data parser, closing
    a hole attackers could use to go through.

  * File upload interception and validation (via
    external scripts).

  * Improved audit log logs full requests (referencing
    files stored outside the file when necessary).

  * Improved debug logging, data is now properly escaped.

  * Improved logging, log entries now contain all the data
    needed to identify who, what, when, and where.

  * Keep uploaded files (option).

  * Much improved configuration code.

  * POST analysis can be turned off on the per-request
    basis now, dynamically.

  * A new (validating) cookie parser. Cookie data can
    be normalized or not.

  * Support for custom logging (to log only mod_security
    relevant requests).

  * Rewritten chroot support, now always works.

  * External scripts work with suExec.

  * Fixed a long-standing design flaw, where rejects due
    to normalization errors would not execute a default
    action.

  * The automated testing utility now supports a debug
    mode, where it prints the request and the response
    to the output.

  * Many small improvements. Many bugs fixed.

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

[mod-security-users] [ANNOUNCE] mod_security 1.8RC2 released

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

Mod_security 1.8RC2 has been released. It is available for immediate
download from:

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

This is the second release candidate on the road to the final
release next week. It fixes a few small bugs and greatly
enhances the way events are logged into the error log.


About mod_security
------------------
Mod_security is an Apache module whose purpose is to protect
vulnerable applications and reject human or automated attacks.
It is an open source intrusion detection and prevention system
for Apache. In addition to request filtering, it also creates Web
application audit logs. 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

With few general rules mod_security can protect from both
known and unknown vulnerabilities.


Changes (v1.8RC2)
------------------

  * Fixed a problem where validation functions would reject a
    request without performing the default action fully
    (previously only the status was honored).

  * Improved logging a great deal. It is now easy to identify
    what and where went wrong.

  * Child processes now re-initialize mutexes, as they should (Apache
    2.x only)

  * Other cosmetic changes here and there.

  * BUG Temporary files were being created with wrong permissions.

  * BUG Fixed a problem in the UTF-8 validation routine. Some valid
    UTF-8 streams were being rejected as invalid.


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

Re: [mod-security-users] problem chroot/mod_security apache with mod_ssl

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

fwd wrote:
> Hello, 
>  
> I need a little help on problem with chrooting apache via mod_security with
> SecChrootdir and ssl support via mod_ssl. 
> 
> SecChrootdir /home/chroot/usr/local/apache/

  I'd say you want to use "/home/chroot" here.


> [Mon Jun 14 23:42:43 2004] [notice] Accept mutex: sysvsem (Default: sysvsem)
> [Mon Jun 14 23:42:43 2004] [error] mod_ssl: Child could not open SSLMutex
> lockfile /usr/local/apache/logs/ssl_mutex.2648 (Syst
> em error follows)

  Yes, with the chroot path as you defined, the place mod_ssl
  looks for its lock file is:

  /home/chroot/usr/local/apache/usr/local/apache/logs/ssl_mutex.2647

  and that's why it doesn't work.

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

[Fwd: Re: [mod-security-users] problem chroot/mod_security apache with mod_ssl]

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

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

[Fwd: Re: [mod-security-users] problem chroot/mod_security apache with mod_ssl]

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

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

[mod-security-users] problem chroot/mod_security apache with mod_ssl

[fwd <for...@if...>]

Hello, 
 
I need a little help on problem with chrooting apache via mod_security with
SecChrootdir and ssl support via mod_ssl. 

----------------------------------------------------------------------------
--------------------------------------------------------------

in httpd.conf : 
 
LoadModule security_module    libexec/mod_security.so
LoadModule env_module         libexec/mod_env.so
LoadModule config_log_module  libexec/mod_log_config.so
LoadModule mime_module        libexec/mod_mime.so
LoadModule negotiation_module libexec/mod_negotiation.so
LoadModule status_module      libexec/mod_status.so
LoadModule includes_module    libexec/mod_include.so
LoadModule autoindex_module   libexec/mod_autoindex.so
LoadModule dir_module         libexec/mod_dir.so
LoadModule cgi_module         libexec/mod_cgi.so
LoadModule asis_module        libexec/mod_asis.so
LoadModule imap_module        libexec/mod_imap.so
LoadModule action_module      libexec/mod_actions.so
LoadModule userdir_module     libexec/mod_userdir.so
LoadModule alias_module       libexec/mod_alias.so
LoadModule rewrite_module     libexec/mod_rewrite.so
LoadModule access_module      libexec/mod_access.so
LoadModule auth_module        libexec/mod_auth.so
LoadModule setenvif_module    libexec/mod_setenvif.so
<IfDefine SSL>
LoadModule ssl_module         libexec/libssl.so
</IfDefine>
LoadModule php4_module        libexec/libphp4.so
LoadModule perl_module        libexec/libperl.so
ClearModuleList
AddModule mod_security.c
AddModule mod_env.c
AddModule mod_log_config.c
AddModule mod_mime.c
AddModule mod_negotiation.c
AddModule mod_status.c
AddModule mod_include.c
AddModule mod_autoindex.c
AddModule mod_dir.c
AddModule mod_cgi.c
AddModule mod_asis.c
AddModule mod_imap.c
AddModule mod_actions.c
AddModule mod_userdir.c
AddModule mod_alias.c
AddModule mod_rewrite.c
AddModule mod_access.c
AddModule mod_auth.c
AddModule mod_so.c
AddModule mod_setenvif.c
<IfDefine SSL>
AddModule mod_ssl.c
</IfDefine>
AddModule mod_php4.c
AddModule mod_perl.c


-----
& 
-----
 
<IfModule mod_security.c>
SecFilterEngine On
SecServerSignature "Microsoft-IIS/4.0"
SecChrootdir /home/chroot/usr/local/apache/
SecFilterCheckURLEncoding On
SecFilterCheckUnicodeEncoding On
SecFilterForceByteRange 0 255
SecAuditEngine RelevantOnly
SecAuditLog logs/modsec_log
SecFilterDebugLog logs/modsec_debug_log
SecFilterDebugLevel 0
SecFilterScanPOST On
SecFilterDefaultAction "deny,log,status:401"
</IfModule>

----------------------------------------------------------------------------
--------------------------------------------------------------
 
# apachectl stop
/usr/local/apache/bin/apachectl stop: httpd stopped
# apachectl startssl
Apache/1.3.31 mod_ssl/2.8.18 (Pass Phrase Dialog)
Some of your private key files are encrypted for security reasons.
In order to read them you have to provide us with the pass phrases.
 
Server www.test.com <http://www.test.com:443> :443 (RSA)
Enter pass phrase:
 
Ok: Pass Phrase Dialog successful.
/usr/local/apache/bin/apachectl startssl: httpd started
# ps -auwx | grep httpd
root      2649  1.2  8.5  8344 5224 ?        S    23:42   0:00
/usr/local/apache/bin/httpd -DSSL
apache    2749  0.0  0.0     0    0 ?        Z    23:42   0:00 [httpd
<defunct>]
root      2751  0.0  1.2  1976  792 pts/1    R    23:42   0:00 grep httpd

----------------------------------------------------------------------------
--------------------------------------------------------------
 
but 
 
----------------------------------------------------------------------------
--------------------------------------------------------------
 
# apachectl start
/usr/local/apache/bin/apachectl start: httpd started
# ps -auwx | grep httpd
root     16086  1.1  6.4  6464 3904 ?        S    00:02   0:00
/usr/local/apache/bin/httpd
apache   16087  0.0  6.4  6488 3928 ?        S    00:02   0:00
/usr/local/apache/bin/httpd
apache   16088  0.1  6.4  6488 3928 ?        S    00:02   0:00
/usr/local/apache/bin/httpd
apache   16089  0.0  6.4  6488 3928 ?        S    00:02   0:00
/usr/local/apache/bin/httpd
apache   16090  0.0  6.4  6488 3928 ?        S    00:02   0:00
/usr/local/apache/bin/httpd
apache   16091  0.0  6.4  6488 3928 ?        S    00:02   0:00
/usr/local/apache/bin/httpd
root     16103  0.0  1.2  1976  792 pts/1    R    00:03   0:00 grep httpd

----------------------------------------------------------------------------
--------------------------------------------------------------

in /usr/local/apache/error_log : 

[Mon Jun 14 23:42:43 2004] [notice] mod_security: performed chroot,
path=/home/chroot/usr/local/apache/
[Mon Jun 14 23:42:43 2004] [notice] Apache configured -- resuming normal
operations
[Mon Jun 14 23:42:43 2004] [notice] Accept mutex: sysvsem (Default: sysvsem)
[Mon Jun 14 23:42:43 2004] [error] mod_ssl: Child could not open SSLMutex
lockfile /usr/local/apache/logs/ssl_mutex.2648 (Syst
em error follows)
[Mon Jun 14 23:42:43 2004] [error] System: Aucun fichier ou r\xe9pertoire de
ce type (errno: 2)

----------------------------------------------------------------------------
--------------------------------------------------------------

When i comment the SecChrootdir /home/chroot/usr/local/apache/ line,
everything's fine.
 
# ps -auwx | grep httpd
root     15992  1.5  8.5  8344 5220 ?        S    23:51   0:00
/usr/local/apache/bin/httpd -DSSL
apache   15998  0.5  8.5  8344 5228 ?        S    23:51   0:00
/usr/local/apache/bin/httpd -DSSL
apache   15999  0.0  8.5  8344 5228 ?        S    23:51   0:00
/usr/local/apache/bin/httpd -DSSL
apache   16000  0.0  8.5  8344 5228 ?        S    23:51   0:00
/usr/local/apache/bin/httpd -DSSL
apache   16001  0.5  8.5  8344 5228 ?        S    23:51   0:00
/usr/local/apache/bin/httpd -DSSL
apache   16002  0.0  8.5  8344 5228 ?        S    23:51   0:00
/usr/local/apache/bin/httpd -DSSL
root     16004  0.0  1.3  1976  800 pts/1    S    23:51   0:00 grep httpd

----------------------------------------------------------------------------
--------------------------------------------------------------
 
Directory /home/chroot/usr/local/apache/ exists : 
 
# ls -l -R /home/chroot/
/home/chroot/:
total 4
drwxr-xr-x    3 root     root         4096 jun 14 01:31 usr/
 
/home/chroot/usr:
total 4
drwxr-xr-x    3 root     root         4096 jun 14 01:31 local/
 
/home/chroot/usr/local:
total 4
drwxr-xr-x    2 root     root         4096 jun 14 01:31 apache/
 
/home/chroot/usr/local/apache:
total 0


----------------------------------------------------------------------------
--------------------------------------------------------------
 
Is it possible that apache mod_security chrooting works fine with mod_ssl ? 
Do you have ideas about that ? 
am i obliged to pass from a chroot usual way ? 
 
Thanks in advance
 
Fwd.

[mod-security-users] 1.8RC1 is out

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

Guys,

mod_security 1.8 Release Candidate 1 is out. It is the best
version of mod_security yet and, to the best of my knowledge,
without any faults (although there is a small chance that I've
introduced some making small changes in the last couple of
days).

I've been working on the 1.8 for months. The new Apache 1.x
version is 50K larger (total of 140K). Apache 2.x version is
60K larger (160K total). You can see this is the largest
single improvement since the beginning.

From here on there will be no improvements made, only bug
fixes until the official release on June 16. Also, the final
code review will be performed. If bugs are discovered, new
release candidates will be released weekly. The release date
is set in stone.

I would appreciate if you would download and try this version
on your production systems, so we can have a smooth release
of a new stable version. I am eager to put this release behind
us and focus on the improvements in the next development
cycle.

Thanks!

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

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 ]