headers
Guillermo Caminer | 1 Mar 2011 17:27
Picon

Hexadecimal characters in Response Body

Hi everyone,
in "some" Web Services methods I see hexadecimal characters in the Response Body (part E of the
transaction log).
So the regex rules cannot match...

I said "some" because some methods shows ok in the logs.

In the client (Web Browser, curl) the response shows ok (printable characters).

I'm using ModSec deployed in Reverse Proxy.

Any ideas?

Thanks in advance!

------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
ModSecurity Services from Trustave's SpiderLabs:
https://www.trustwave.com/spiderLabs.php
Permalink | Reply | 4 comments |
headers
Nick Gearls | 1 Mar 2011 17:31
Picon

Rule 950801

Why does the rule validate the UTF-8 encoding of the REQUEST_FILENAME?
This should be URL-encoded, whatever charset you use in your 
application, no?

------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
ModSecurity Services from Trustave's SpiderLabs:
https://www.trustwave.com/spiderLabs.php
Permalink | Reply | 0 comments |
headers
Guillermo Caminer | 1 Mar 2011 19:26
Picon

Re: Hexadecimal characters in Response Body

Actually, the response body is gzip compressed because I'm using mod_deflate.

According to ModSec handbook:

"If you are using mod_deflate for response compression, it may, under some cir-
cumstances, cause ModSecurity to assess and log compressed data (which is not
very useful, and may even cause false positives). It is not clear what causes the
problem, but a fix to deal with the problem is in ModSecurity 2.5.11 and later."

Any fixes yet? I'm using ModSec 2.5.13

On 03/01/2011 01:27 PM, Guillermo Caminer wrote:
> Hi everyone,
> in "some" Web Services methods I see hexadecimal characters in the Response Body (part E of the
> transaction log).
> So the regex rules cannot match...
> 
> I said "some" because some methods shows ok in the logs.
> 
> In the client (Web Browser, curl) the response shows ok (printable characters).
> 
> I'm using ModSec deployed in Reverse Proxy.
> 
> Any ideas?
> 
> Thanks in advance!

------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
(Continue reading)

Permalink | Reply | 3 comments |
headers
Guillermo Caminer | 1 Mar 2011 19:35
Picon

Re: Hexadecimal characters in Response Body

Seems that mod_security runs before mod_deflate, that's why I'm getting compressed content in the logs.

Solution:

# Disable compression via mod_headers
RequestHeader unset Accept-Encoding
RequestHeader unset TE

Best Regards.

On 03/01/2011 03:26 PM, Guillermo Caminer wrote:
> Actually, the response body is gzip compressed because I'm using mod_deflate.
> 
> According to ModSec handbook:
> 
> "If you are using mod_deflate for response compression, it may, under some cir-
> cumstances, cause ModSecurity to assess and log compressed data (which is not
> very useful, and may even cause false positives). It is not clear what causes the
> problem, but a fix to deal with the problem is in ModSecurity 2.5.11 and later."
> 
> Any fixes yet? I'm using ModSec 2.5.13
> 
> On 03/01/2011 01:27 PM, Guillermo Caminer wrote:
>> Hi everyone,
>> in "some" Web Services methods I see hexadecimal characters in the Response Body (part E of the
>> transaction log).
>> So the regex rules cannot match...
>>
>> I said "some" because some methods shows ok in the logs.
>>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Josh Amishav-Zlatin | 2 Mar 2011 09:08
Picon

Re: Hexadecimal characters in Response Body

Hi Guillermo,

The SecDisableBackendCompression directive in trunk may interest you as well.

--
 - Josh

On Tue, Mar 1, 2011 at 8:35 PM, Guillermo Caminer
<flaco.webappsec <at> gmail.com> wrote:
> Seems that mod_security runs before mod_deflate, that's why I'm getting compressed content in the logs.
>
> Solution:
>
> # Disable compression via mod_headers
> RequestHeader unset Accept-Encoding
> RequestHeader unset TE
>
> Best Regards.
>
> On 03/01/2011 03:26 PM, Guillermo Caminer wrote:
>> Actually, the response body is gzip compressed because I'm using mod_deflate.
>>
>> According to ModSec handbook:
>>
>> "If you are using mod_deflate for response compression, it may, under some cir-
>> cumstances, cause ModSecurity to assess and log compressed data (which is not
>> very useful, and may even cause false positives). It is not clear what causes the
>> problem, but a fix to deal with the problem is in ModSecurity 2.5.11 and later."
>>
>> Any fixes yet? I'm using ModSec 2.5.13
(Continue reading)

Permalink | Reply | 1 comment |
headers
Klaubert Herr da Silveira | 2 Mar 2011 13:37
Picon
Gravatar

Re: mlogc problem

I just go around this by using the /mlogc-batch-load.pl provided with
modsecurity, running each 5 min on crontab.

I just need to make a simple patch against it beacuse their regexp
don't get all events:

--- /tmp/mlogc-batch-load.pl    2011-03-02 09:32:10.000000000 -0300
+++ /usr/sbin/mlogc-batch-load.pl       2011-02-21 19:09:42.000000000 -0300
 <at>  <at>  -42,7 +42,7  <at>  <at> 

(($dev,$ino,$mode,$nlink,$uid,$gid,$rdev,$size) = stat($_)) &&
                        -f _ &&
-                       /^\d{8}-\d+-\w{24}$/s
+                       /^\d{8}-\d+-[\w- <at> ]{24}$/s
                        && (($fn = $File::Find::name) =~ s/^\Q$ROOTDIR\E//)
                        && push( <at> AUDIT, [$fn, $size]);

the way to get it working is configure modsecurity to put events on
directory "SecAuditLogStorageDir /var/log/mlogc/modsec_audit" and
_don't_ pipe the log to mlogc, i.e. "SecAuditLog
/var/log/mlogc/modsec_audit.log"

Run from times to times...
/usr/sbin/mlogc-batch-load.pl /var/log/mlogc/modsec_audit/
/usr/sbin/mlogc /etc/mlogc.conf

Best regards,

Klaubert
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ryan Barnett | 2 Mar 2011 19:14

Re: mlogc problem

FYI - this has been fixed already -
https://www.modsecurity.org/tracker/browse/MODSEC-204

It is in the SVN trunk version -
http://mod-security.svn.sourceforge.net/viewvc/mod-security/m2/trunk/mlogc/
mlogc-batch-load.pl.in?revision=1615

-Ryan

On 3/2/11 7:37 AM, "Klaubert Herr da Silveira" <klaubert <at> gmail.com> wrote:

>I just go around this by using the /mlogc-batch-load.pl provided with
>modsecurity, running each 5 min on crontab.
>
>I just need to make a simple patch against it beacuse their regexp
>don't get all events:
>
>--- /tmp/mlogc-batch-load.pl    2011-03-02 09:32:10.000000000 -0300
>+++ /usr/sbin/mlogc-batch-load.pl       2011-02-21 19:09:42.000000000
>-0300
> <at>  <at>  -42,7 +42,7  <at>  <at> 
>
>
>(($dev,$ino,$mode,$nlink,$uid,$gid,$rdev,$size) = stat($_)) &&
>                        -f _ &&
>-                       /^\d{8}-\d+-\w{24}$/s
>+                       /^\d{8}-\d+-[\w- <at> ]{24}$/s
>                        && (($fn = $File::Find::name) =~
>s/^\Q$ROOTDIR\E//)
>                        && push( <at> AUDIT, [$fn, $size]);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ryan Barnett | 2 Mar 2011 14:10

Re: Hexadecimal characters in Response Body

I was going to mention that new feature as well.  It is in the 2.6 version
in SVN trunk.


The option that Guillermo showed will certainly work to fix the response
body inspection gzip issue but it comes at the expense of performance
since you are essentially removing all compressed response content.  The
SecDisableBackendCompression directive is a middle ground.  It will still
remove the same request headers (so that the apache reverse proxy and the
back-end server will non use compression) but it will remember which
front-end client supported compression and it will then compress the
content back to the client.

-Ryan

On 3/2/11 3:08 AM, "Josh Amishav-Zlatin" <jamuse <at> gmail.com> wrote:

>Hi Guillermo,
>
>The SecDisableBackendCompression directive in trunk may interest you as
>well.
>
>--
> - Josh
>
>On Tue, Mar 1, 2011 at 8:35 PM, Guillermo Caminer
><flaco.webappsec <at> gmail.com> wrote:
>> Seems that mod_security runs before mod_deflate, that's why I'm getting
>>compressed content in the logs.
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ryan Barnett | 2 Mar 2011 14:23

Re: pass actions in 40_generic_attacks


On 2/26/11 3:40 PM, "KT" <listclient <at> gmail.com> wrote:

>default modsecurity_crs_10_config states
>
>"Each detection rule uses the "block" action which will inherit the
>SecDefaultAction specified below"
>
>though rules 950117-20 in 40_generic_attacks using pass so
>SecDefaultAction deny does not have any effect for a request like
>http://domain.com/?http://another.com/evil.rfi
>
>Am I missing something? Thanks

Great catch.  I just updated those action to block and they are live in
SVN trunk -
http://mod-security.svn.sourceforge.net/viewvc/mod-security/crs/trunk/base_
rules/modsecurity_crs_40_generic_attacks.conf?revision=1617

-Ryan

>
>--------------------------------------------------------------------------
>----
>Free Software Download: Index, Search & Analyze Logs and other IT data in
>Real-Time with Splunk. Collect, index and harness all the fast moving IT
>data
>generated by your applications, servers and devices whether physical,
>virtual
>or in the cloud. Deliver compliance at lower cost and gain new business
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christian Bockermann | 2 Mar 2011 23:24

Creating Reports from ModSecurity logs


Hi list,

I've done some rewriting of my reporting-engine (soon part of the AuditConsole). For
testing purposes I created a standalone reporting tool, which allows for the easy
creation of reports from plain ModSecurity audit-logs.

I've just published a small blog post as a guiding example:

	https://secure.jwall.org/blog/2011/03/02/1299103760500.html

Using some simple config it allows for the creation of HTML as well as PDF reports.
PDF reports are not perfect, yet.

If this is helpful for anyone, I'd be happy to receive feedback. Bug reports are
welcome as well ;-)

Best regards,

    Chris
Permalink | Reply | 0 comments |

Gmane