mod-security-developers — Development discussion about mod_security

[Mod-security-developers] Advanced Slow DoS Mitigation

[Christian F. <chr...@ti...>]

Hi there,

ModSecurity always had a few nice options to help with request delaying
mitigation. The combination with mod_reqtimeout is a good strategy as
explained by Ryan at
http://blog.spiderlabs.com/2010/11/advanced-topic-of-the-week-mitigating-slow-http-dos-attacks.html

In May, I did a presentation on the defense against Request Delaying DDoS
aka as Slow DoS or Slowloris type attacks. That Swiss Cyberstorm talk is
now online at http://www.youtube.com/watch?v=svN49PIbcks

Around 32:30, I mention some advanced ideas on how to identify attackers
very easily.

As you know, a POST request to /index.html is perfectly okay with
Apache. You can prevent it with ModSecurity, but not immediately
when the server receives the requestline.

Ideally, you should be able to drop a request trying this immediately.
I would like to write rules that trigger as soon as the request line
has been received. A phase 0 somehow.

This would also be handy to drop requests that try to upload files
before the user has been authenticated. Apache does not mind large
uploads from unauthenticated users until it has received the whole
blob. Not even mod_reqtimeout is of big help if you need to allow
big file uploads.

Now I doubt that Apache allows for a phase 0 (I am not an apache developer and
as you know not even a ModSecurity developer) as there seems to be no
hook at that moment and if I get it right, the whole request record
is not being prepared until post-read-request. But maybe I am wrong.

So what do you guys think?

Cheers,

Christian


-- 
I think IT projects are about supporting social systems - about
communications between people and machines. They tend to fail due to
cultural issues.
-- Tim Berners-Lee

[Mod-security-developers] Availability of ModSecurity 2.6.1-rc1 Release

[Breno S. <bre...@gm...>]

*Availability of ModSecurity 2.6.1-RC1 Release*
(June 30, 2011)

The ModSecurity Development Team is pleased to announce the availability of
ModSecurity 2.6.1-rc1 Release.
This release includes some new features and bug fixes, please see the
release notes included into
CHANGES<http://mod-security.svn.sourceforge.net/viewvc/mod-security/m2/branches/2.6.x/CHANGES>file.

The new release has improvements on unicode mapping, trying to solve
problems like the one described in
http://www.lookout.net/2011/06/28/many-stops-equal-a-u002e-full-stop/
For known problems and more information about bug fixes, please see the
online ModSecurity Jira <https://www.modsecurity.org/tracker/>. Please
report any bug to
mod...@li...<http://lists.sourceforge.net/lists/listinfo/mod-security-developers>
.


Thanks

Breno Silva

Re: [Mod-security-developers] Apache2: SecRequestBodyLimitAction ProcessPartial corrupts POST data in proxy configuration

[Piotr K. <pio...@gm...>]

On Tue, Jun 7, 2011 at 11:43, Piotr Koper <pio...@gm...> wrote:

> Config:
>
>     SecRuleEngine DetectionOnly
>     SecRequestBodyAccess On
>     SecRequestBodyLimit 10
>
> Result with big POST:
>
> proxy host:
> [Tue Jun 07 10:40:51 2011] [error] [client a.b.c.d] ModSecurity: Request
> body (Content-Length) is larger than the configured limit (2048). [hostname
> "test"] [uri "/test"] [unique_id "Te3kEwoNzNMAACBtAX0AAAAA"]
>
>
Should be:
[Tue Jun 07 10:40:51 2011] [error] [client a.b.c.d] ModSecurity: Request
body (Content-Length) is larger than the configured limit (10). [hostname
"test"] [uri "/test"] [unique_id "Te3kEwoNzNMAACBtAX0AAAAA"]



> the request is then passed to the mod_proxy_balancer and to the another
> host with but the application gets corrupted data - data is truncated to the
> SecRequestBodyLimit.
>
> I've also tried setting "SecRuleEngine On" with "SecRequestBodyLimitAction
> ProcessPartial" but the result is the same - proxied POST data is corrupted.
>
> Removing SecRuleEngine from the configuration couses proxying without any
> problems.
>


Please, help.

Re: [Mod-security-developers] CRS DoS bugs/suggestions

[Oleg G. <ole...@ya...>]

No, I think it's a logical error. !ip.dos_counter is called only  after 
dos_counter reached the threshold. Now, think about the following  scenario:

1. I've sent a couple of requests
2. Waited for more than dos_burst_time_slice seconds hoping that it will clear 
the dos_counter
3. Send some requests again. All of them will be added to the dos_counter 
becuase it didn't expire.

All that means that you can keep adding to dos_counter for a very long  period 
of time, which is much longer than dos_burst_time_slice and it  defeats the 
purpose of dos_burst_time_slice parameter in my view.





----- Original Message ----
> From: Ryan Barnett <RBa...@tr...>
> To: "ol...@gr..." <ol...@gr...>; 
>"mod...@li..." 
><mod...@li...>
> Sent: Fri, June 17, 2011 5:15:57 AM
> Subject: Re: [Mod-security-developers] CRS DoS bugs/suggestions
> 
> Oleg,
> First of all, thank you for taking the time to test these rules  further.  The 
>rule quality will only improve if the community takes the  time to test them and 
>report back the status.
> 
> To your comments about the  lack of "expirevar" actions, this should not be 
>needed for the ip.dos_counter  var as the last rule uses the 
>"setvar:!ip.dos_counter" action to actually remove  that variable if the 
>operator matches.  Can you please check your debug log  during testing to verify 
>if that action is not removing that variable?   Perhaps there is a bug in 
>removing the variable with the "!" symbol and using  expirevar is more reliable.
> 
> Also – what version of ModSecurity are you  using?
> 
> -Ryan
> 
> From: Oleg Gryb <ole...@ya...<mailto:ole...@ya...>>
> Reply-To:  "ol...@gr...<mailto:ol...@gr...>" 
><ol...@gr...<mailto:ol...@gr...>>, 
>"mod...@li...<mailto:mod...@li...>"
>  
><mod...@li...<mailto:mod...@li...>>
>
> Date:  Thu, 16 Jun 2011 11:32:11 -0500
> To: 
>"mod...@li...<mailto:mod...@li...>"
>  
><mod...@li...<mailto:mod...@li...>>
>
> Subject:  [Mod-security-developers] CRS DoS bugs/suggestions
> 
> 
> I was testing DoS  ruleset lately and found that there probably was a bug 
>related to ip.dos_counter  variable. The expiration time was not set for this 
>var, as a result the counter  persists longer than tx.dos_burst_time_slice. As a 
>result, the history of hits  is counted for a longer time period.
> 
> I've added expiration time in two  places and it started to work correctly 
>after that. The changes are  below:
> 
> SecRule REQUEST_BASENAME "!\.(jpe?g|png|gif|js|css|ico)$"  
>"phase:5,t:none,nolog,pass,setvar:ip.dos_counter=+1,expirevar:ip.dos_counter=%{tx.dos_burst_time_slice}"
>
> 
> ...
> 
> SecRule  IP:DOS_COUNTER "@ge %{tx.dos_counter_threshold}"  
>"phase:5,t:none,nolog,pass,t:none,setvar:ip.dos_burst_counter=+1,expirevar:ip.dos_burst_counter=%{tx.dos_burst_time_slice},setvar:!ip.dos_counter,expirevar:ip.dos_counter=%{tx.dos_burst_time_slice}"
>
> 
> I've  also attached the sample of testing program. I think, we should have 
>something  like that to test all limits. There are only two tests implemented 
>for now: for  request size and DoS, but it should be easy to add  more.
> 
> 
> 
> ________________________________
> This transmission may  contain information that is privileged, confidential, 
>and/or exempt from  disclosure under applicable law. If you are not the intended 
>recipient, you are  hereby notified that any disclosure, copying, distribution, 
>or use of the  information contained herein (including any reliance thereon) is 
>STRICTLY  PROHIBITED. If you received this transmission in error, please 
>immediately  contact the sender and destroy the material in its entirety, 
>whether in  electronic or hard copy format.
> 
> 

Re: [Mod-security-developers] CRS DoS bugs/suggestions

[Ryan B. <RBa...@tr...>]

Oleg,
First of all, thank you for taking the time to test these rules further.  The rule quality will only improve if the community takes the time to test them and report back the status.

To your comments about the lack of "expirevar" actions, this should not be needed for the ip.dos_counter var as the last rule uses the "setvar:!ip.dos_counter" action to actually remove that variable if the operator matches.  Can you please check your debug log during testing to verify if that action is not removing that variable?  Perhaps there is a bug in removing the variable with the "!" symbol and using expirevar is more reliable.

Also – what version of ModSecurity are you using?

-Ryan

From: Oleg Gryb <ole...@ya...<mailto:ole...@ya...>>
Reply-To: "ol...@gr...<mailto:ol...@gr...>" <ol...@gr...<mailto:ol...@gr...>>, "mod...@li...<mailto:mod...@li...>" <mod...@li...<mailto:mod...@li...>>
Date: Thu, 16 Jun 2011 11:32:11 -0500
To: "mod...@li...<mailto:mod...@li...>" <mod...@li...<mailto:mod...@li...>>
Subject: [Mod-security-developers] CRS DoS bugs/suggestions


I was testing DoS ruleset lately and found that there probably was a bug related to ip.dos_counter variable. The expiration time was not set for this var, as a result the counter persists longer than tx.dos_burst_time_slice. As a result, the history of hits is counted for a longer time period.

I've added expiration time in two places and it started to work correctly after that. The changes are below:

SecRule REQUEST_BASENAME "!\.(jpe?g|png|gif|js|css|ico)$" "phase:5,t:none,nolog,pass,setvar:ip.dos_counter=+1,expirevar:ip.dos_counter=%{tx.dos_burst_time_slice}"

...

SecRule IP:DOS_COUNTER "@ge %{tx.dos_counter_threshold}" "phase:5,t:none,nolog,pass,t:none,setvar:ip.dos_burst_counter=+1,expirevar:ip.dos_burst_counter=%{tx.dos_burst_time_slice},setvar:!ip.dos_counter,expirevar:ip.dos_counter=%{tx.dos_burst_time_slice}"

I've also attached the sample of testing program. I think, we should have something like that to test all limits. There are only two tests implemented for now: for request size and DoS, but it should be easy to add more.



________________________________
This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.

Re: [Mod-security-developers] ModSecurity for Java

[Oleg G. <ole...@ya...>]

Juan, Ryan,

Thank you for the answers. I'll try to take a closer look if time permits and 
let you know my thoughts. If you have any suggestion is regards of the best 
candidate for experiments, please let me know what it is.

Oleg.


>
>From: Juan calderon <jua...@ow...>
>To: Oleg Gryb <ol...@gr...>; mod...@li...
>Sent: Thu, June 16, 2011 5:49:48 PM
>Subject: Re: [Mod-security-developers] ModSecurity for Java
>
>Hello Oleg
>
>The development is in progress and it will take 2 or 3 months more. If you need 
>the firewall you can use the version 1 from ESAPI 2.0GA. Notice ModSecurity 
>rules are not supported in that version. But, it is very easy to create rules 
>for it. let me know if you need any help with that.
>
>Regards,
>Juan Carlos Calderon
>
>
>On Thu, Jun 16, 2011 at 6:49 PM, Oleg Gryb <ole...@ya...> wrote:
>
>Can anyone please provide more data on this Java project? In particularly I 
need
>>to know:
>>
>>1. Is it stable enough to be used in production?
>>2. If it's not, do you have any timelines for the first version that can be 
>used
>>in prod?
>>
>>In general, I think it would be very useful for expanding the applicability of
>>mod-security.
>>
>>Thanks,
>>Oleg.
>>
>>
>>
>>
>>----- Original Message ----
>>> From: Juan Carlos Calderon Rojas <jua...@so...>
>>> To: "mod...@li..."
>>
>>><mod...@li...>
>>> Sent: Fri, June 3, 2011 6:18:56 AM
>>> Subject: Re: [Mod-security-developers] ModSecurity for Java
>>
>>>
>>> Yes I have, although as the implementations are different I guess there is a
>>>bug  or something on the original code of  OWASP Java WAF.
>>>
>>> I will leave  that part to later on and make some more progress on the
>>>evaluation of the  rules, keep you posted
>>>
>>> Thanks,
>>> Juan  Carlos
>>>
>>> ________________________________________
>>> De: Ryan Barnett [RBa...@tr...]
>>> Enviado el:  jueves, 02 de junio de 2011 07:28 a.m.
>>> Para: mod...@li...
>>> Asunto:  Re: [Mod-security-developers] ModSecurity for Java
>>>
>>> Hey Juan  Carlos,
>>> Thanks for the update!  Have you looked at the  "MsHttpServletResponse.java"
>>>code from the old ModSecurity for Java  project?
>>> http://www.modsecurity.org/download/msj-m3c.war
>>>
>>> Maybe that  would help.
>>>
>>> -Ryan
>>>
>>> From: Juan calderon 
<jua...@ow...<mailto:jua...@ow...>>
>>> Reply-To:
>>>"mod...@li...<mailto:mod...@li...>"
>>>
>>>
>>><mod...@li...<mailto:mod...@li...>>
>>>
>>>
>>> Date:  Thu, 2 Jun 2011 00:51:39 -0500
>>> To:
>>>"mod...@li...<mailto:mod...@li...>"
>>>
>>>
>>><mod...@li...<mailto:mod...@li...>>
>>>
>>>
>>> Subject:  [Mod-security-developers] ModSecurity for Java
>>>
>>> Hello Guys
>>>
>>> Just a  little update, Rule parser for this project is already working and
>>>supporting  the 4 directives (SecRuleEngine, SecRule, SecRequestBodyAccess,
>>>SecResponseBodyAccess ) of Rule Language Porting Spec Level 1 :)
>>>
>>> I am  struggling to get the Response variables working, I always get an 
empty
>>>string  for the response body buffer :(, can anyone give me some support on
>>>this one, I might not be using the ReponseWrapper  correctly.
>>>
>>> Regards,
>>> Juan Carlos  Calderon
>>>
>>> ________________________________
>>> This transmission may  contain information that is privileged, confidential,
>>>and/or exempt from  disclosure under applicable law. If you are not the 
>>intended
>>>recipient, you are  hereby notified that any disclosure, copying, 
>distribution,
>>>or use of the  information contained herein (including any reliance thereon) 
>is
>>>STRICTLY  PROHIBITED. If you received this transmission in error, please
>>>immediately  contact the sender and destroy the material in its entirety,
>>>whether in  electronic or hard copy  format.
>>>
>>>
>>> 
>------------------------------------------------------------------------------
>>> Simplify  data backup and recovery for your virtual environment with 
> vRanger.
>>> Installation's a snap, and flexible recovery options mean your data  is 
safe,
>>> secure and there when you need it. Data protection magic?
>>> Nope -  It's vRanger. Get your free trial download  today.
>>> http://p.sf.net/sfu/quest-sfdev2dev
>>> _______________________________________________
>>> mod-security-developers  mailing list
>>> mod...@li...
>>> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
>>> ModSecurity  Services from Trustwave's SpiderLabs:
>>> https://www.trustwave.com/spiderLabs.php
>>> 
>------------------------------------------------------------------------------
>>> Simplify  data backup and recovery for your virtual environment with 
> vRanger.
>>> Installation's a snap, and flexible recovery options mean your data  is 
safe,
>>> secure and there when you need it. Discover what all the cheering's  about.
>>> Get your free trial download today.
>>> http://p.sf.net/sfu/quest-dev2dev2
>>> _______________________________________________
>>> mod-security-developers  mailing list
>>> mod...@li...
>>> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
>>> ModSecurity  Services from Trustwave's SpiderLabs:
>>> https://www.trustwave.com/spiderLabs.php
>>>
>>
>>------------------------------------------------------------------------------
>>EditLive Enterprise is the world's most technically advanced content
>>authoring tool. Experience the power of Track Changes, Inline Image
>>Editing and ensure content is compliant with Accessibility Checking.
>>http://p.sf.net/sfu/ephox-dev2dev
>>
>>_______________________________________________
>>mod-security-developers mailing list
>>mod...@li...
>>https://lists.sourceforge.net/lists/listinfo/mod-security-developers
>>ModSecurity Services from Trustwave's SpiderLabs:
>>https://www.trustwave.com/spiderLabs.php
>>
>

Re: [Mod-security-developers] ModSecurity for Java

[Juan c. <jua...@ow...>]

Hello Oleg

The development is in progress and it will take 2 or 3 months more. If you
need the firewall you can use the version 1 from ESAPI 2.0GA. Notice
ModSecurity rules are not supported in that version. But, it is very easy to
create rules for it. let me know if you need any help with that.

Regards,
Juan Carlos Calderon

On Thu, Jun 16, 2011 at 6:49 PM, Oleg Gryb <ole...@ya...> wrote:

> Can anyone please provide more data on this Java project? In particularly I
> need
> to know:
>
> 1. Is it stable enough to be used in production?
> 2. If it's not, do you have any timelines for the first version that can be
> used
> in prod?
>
> In general, I think it would be very useful for expanding the applicability
> of
> mod-security.
>
> Thanks,
> Oleg.
>
>
>
> ----- Original Message ----
> > From: Juan Carlos Calderon Rojas <jua...@so...>
> > To: "mod...@li..."
> ><mod...@li...>
> > Sent: Fri, June 3, 2011 6:18:56 AM
> > Subject: Re: [Mod-security-developers] ModSecurity for Java
> >
> > Yes I have, although as the implementations are different I guess there
> is a
> >bug  or something on the original code of  OWASP Java WAF.
> >
> > I will leave  that part to later on and make some more progress on the
> >evaluation of the  rules, keep you posted
> >
> > Thanks,
> > Juan  Carlos
> >
> > ________________________________________
> > De: Ryan Barnett [RBa...@tr...]
> > Enviado el:  jueves, 02 de junio de 2011 07:28 a.m.
> > Para: mod...@li...
> > Asunto:  Re: [Mod-security-developers] ModSecurity for Java
> >
> > Hey Juan  Carlos,
> > Thanks for the update!  Have you looked at the
>  "MsHttpServletResponse.java"
> >code from the old ModSecurity for Java  project?
> > http://www.modsecurity.org/download/msj-m3c.war
> >
> > Maybe that  would help.
> >
> > -Ryan
> >
> > From: Juan calderon <jua...@ow...<mailto:
> jua...@ow...>>
> > Reply-To:
> >"mod...@li...<mailto:
> mod...@li...>"
> >
> ><mod...@li...<mailto:
> mod...@li...>>
> >
> > Date:  Thu, 2 Jun 2011 00:51:39 -0500
> > To:
> >"mod...@li...<mailto:
> mod...@li...>"
> >
> ><mod...@li...<mailto:
> mod...@li...>>
> >
> > Subject:  [Mod-security-developers] ModSecurity for Java
> >
> > Hello Guys
> >
> > Just a  little update, Rule parser for this project is already working
> and
> >supporting  the 4 directives (SecRuleEngine, SecRule,
> SecRequestBodyAccess,
> >SecResponseBodyAccess ) of Rule Language Porting Spec Level 1 :)
> >
> > I am  struggling to get the Response variables working, I always get an
> empty
> >string  for the response body buffer :(, can anyone give me some support
> on
> >this one, I might not be using the ReponseWrapper  correctly.
> >
> > Regards,
> > Juan Carlos  Calderon
> >
> > ________________________________
> > This transmission may  contain information that is privileged,
> confidential,
> >and/or exempt from  disclosure under applicable law. If you are not the
> intended
> >recipient, you are  hereby notified that any disclosure, copying,
> distribution,
> >or use of the  information contained herein (including any reliance
> thereon) is
> >STRICTLY  PROHIBITED. If you received this transmission in error, please
> >immediately  contact the sender and destroy the material in its entirety,
> >whether in  electronic or hard copy  format.
> >
> >
> >
> ------------------------------------------------------------------------------
> > Simplify  data backup and recovery for your virtual environment with
>  vRanger.
> > Installation's a snap, and flexible recovery options mean your data  is
> safe,
> > secure and there when you need it. Data protection magic?
> > Nope -  It's vRanger. Get your free trial download  today.
> > http://p.sf.net/sfu/quest-sfdev2dev
> > _______________________________________________
> > mod-security-developers  mailing list
> > mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> > ModSecurity  Services from Trustwave's SpiderLabs:
> > https://www.trustwave.com/spiderLabs.php
> >
> ------------------------------------------------------------------------------
> > Simplify  data backup and recovery for your virtual environment with
>  vRanger.
> > Installation's a snap, and flexible recovery options mean your data  is
> safe,
> > secure and there when you need it. Discover what all the cheering's
>  about.
> > Get your free trial download today.
> > http://p.sf.net/sfu/quest-dev2dev2
> > _______________________________________________
> > mod-security-developers  mailing list
> > mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> > ModSecurity  Services from Trustwave's SpiderLabs:
> > https://www.trustwave.com/spiderLabs.php
> >
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php
>

Re: [Mod-security-developers] ModSecurity for Java

[Ryan B. <RBa...@tr...>]

Juan Carlos would be the best one to answer those questions as he is the
OWASP Java WAF project lead.  What Juan and I discussed is that he is
updating the Java WAF code to accept ModSecurity SecRules.  In order to
help porting efforts to other platforms, the ModSecurity team has
developed a porting specification with 2 levels -

http://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Rules_La
nguage_Porting_Spec


We realize that it may not be feasible for all functionality to be ported
so we focused Level 1 on Core Features.  This should allow user to add in
basic ModSecurity SecRules.

If you have any input on the porting specs please let us know.

-Ryan

On 6/16/11 7:49 PM, "Oleg Gryb" <ole...@ya...> wrote:

>Can anyone please provide more data on this Java project? In particularly
>I need
>to know:
>
>1. Is it stable enough to be used in production?
>2. If it's not, do you have any timelines for the first version that can
>be used
>in prod?
>
>In general, I think it would be very useful for expanding the
>applicability of
>mod-security.
>
>Thanks,
>Oleg.
>
>
>
>----- Original Message ----
>> From: Juan Carlos Calderon Rojas <jua...@so...>
>> To: "mod...@li..."
>><mod...@li...>
>> Sent: Fri, June 3, 2011 6:18:56 AM
>> Subject: Re: [Mod-security-developers] ModSecurity for Java
>>
>> Yes I have, although as the implementations are different I guess there
>>is a
>>bug  or something on the original code of  OWASP Java WAF.
>>
>> I will leave  that part to later on and make some more progress on the
>>evaluation of the  rules, keep you posted
>>
>> Thanks,
>> Juan  Carlos
>>
>> ________________________________________
>> De: Ryan Barnett [RBa...@tr...]
>> Enviado el:  jueves, 02 de junio de 2011 07:28 a.m.
>> Para: mod...@li...
>> Asunto:  Re: [Mod-security-developers] ModSecurity for Java
>>
>> Hey Juan  Carlos,
>> Thanks for the update!  Have you looked at the
>>"MsHttpServletResponse.java"
>>code from the old ModSecurity for Java  project?
>> http://www.modsecurity.org/download/msj-m3c.war
>>
>> Maybe that  would help.
>>
>> -Ryan
>>
>> From: Juan calderon
>><jua...@ow...<mailto:jua...@ow...>>
>> Reply-To:
>>"mod...@li...<mailto:mod-security-develo
>>pe...@li...>"
>>
>><mod...@li...<mailto:mod-security-develo
>>pe...@li...>>
>>
>> Date:  Thu, 2 Jun 2011 00:51:39 -0500
>> To:
>>"mod...@li...<mailto:mod-security-develo
>>pe...@li...>"
>>
>><mod...@li...<mailto:mod-security-develo
>>pe...@li...>>
>>
>> Subject:  [Mod-security-developers] ModSecurity for Java
>>
>> Hello Guys
>>
>> Just a  little update, Rule parser for this project is already working
>>and
>>supporting  the 4 directives (SecRuleEngine, SecRule,
>>SecRequestBodyAccess,
>>SecResponseBodyAccess ) of Rule Language Porting Spec Level 1 :)
>>
>> I am  struggling to get the Response variables working, I always get an
>>empty
>>string  for the response body buffer :(, can anyone give me some support
>>on
>>this one, I might not be using the ReponseWrapper  correctly.
>>
>> Regards,
>> Juan Carlos  Calderon
>>
>> ________________________________
>> This transmission may  contain information that is privileged,
>>confidential,
>>and/or exempt from  disclosure under applicable law. If you are not the
>>intended
>>recipient, you are  hereby notified that any disclosure, copying,
>>distribution,
>>or use of the  information contained herein (including any reliance
>>thereon) is
>>STRICTLY  PROHIBITED. If you received this transmission in error, please
>>immediately  contact the sender and destroy the material in its
>>entirety,
>>whether in  electronic or hard copy  format.
>>
>>
>>
>>-------------------------------------------------------------------------
>>-----
>> Simplify  data backup and recovery for your virtual environment with
>>vRanger.
>> Installation's a snap, and flexible recovery options mean your data  is
>>safe,
>> secure and there when you need it. Data protection magic?
>> Nope -  It's vRanger. Get your free trial download  today.
>> http://p.sf.net/sfu/quest-sfdev2dev
>> _______________________________________________
>> mod-security-developers  mailing list
>> mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
>> ModSecurity  Services from Trustwave's SpiderLabs:
>> https://www.trustwave.com/spiderLabs.php
>>
>>-------------------------------------------------------------------------
>>-----
>> Simplify  data backup and recovery for your virtual environment with
>>vRanger.
>> Installation's a snap, and flexible recovery options mean your data  is
>>safe,
>> secure and there when you need it. Discover what all the cheering's
>>about.
>> Get your free trial download today.
>> http://p.sf.net/sfu/quest-dev2dev2
>> _______________________________________________
>> mod-security-developers  mailing list
>> mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
>> ModSecurity  Services from Trustwave's SpiderLabs:
>> https://www.trustwave.com/spiderLabs.php
>>
>
>--------------------------------------------------------------------------
>----
>EditLive Enterprise is the world's most technically advanced content
>authoring tool. Experience the power of Track Changes, Inline Image
>Editing and ensure content is compliant with Accessibility Checking.
>http://p.sf.net/sfu/ephox-dev2dev
>_______________________________________________
>mod-security-developers mailing list
>mod...@li...
>https://lists.sourceforge.net/lists/listinfo/mod-security-developers
>ModSecurity Services from Trustwave's SpiderLabs:
>https://www.trustwave.com/spiderLabs.php
>


This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.

Re: [Mod-security-developers] ModSecurity for Java

[Oleg G. <ole...@ya...>]

Can anyone please provide more data on this Java project? In particularly I need 
to know:

1. Is it stable enough to be used in production?
2. If it's not, do you have any timelines for the first version that can be used 
in prod?

In general, I think it would be very useful for expanding the applicability of 
mod-security.

Thanks,
Oleg.



----- Original Message ----
> From: Juan Carlos Calderon Rojas <jua...@so...>
> To: "mod...@li..." 
><mod...@li...>
> Sent: Fri, June 3, 2011 6:18:56 AM
> Subject: Re: [Mod-security-developers] ModSecurity for Java
> 
> Yes I have, although as the implementations are different I guess there is a 
>bug  or something on the original code of  OWASP Java WAF.
> 
> I will leave  that part to later on and make some more progress on the 
>evaluation of the  rules, keep you posted
> 
> Thanks,
> Juan  Carlos
> 
> ________________________________________
> De: Ryan Barnett [RBa...@tr...]
> Enviado el:  jueves, 02 de junio de 2011 07:28 a.m.
> Para: mod...@li...
> Asunto:  Re: [Mod-security-developers] ModSecurity for Java
> 
> Hey Juan  Carlos,
> Thanks for the update!  Have you looked at the  "MsHttpServletResponse.java" 
>code from the old ModSecurity for Java  project?
> http://www.modsecurity.org/download/msj-m3c.war
> 
> Maybe that  would help.
> 
> -Ryan
> 
> From: Juan calderon <jua...@ow...<mailto:jua...@ow...>>
> Reply-To:  
>"mod...@li...<mailto:mod...@li...>"
>  
><mod...@li...<mailto:mod...@li...>>
>
> Date:  Thu, 2 Jun 2011 00:51:39 -0500
> To: 
>"mod...@li...<mailto:mod...@li...>"
>  
><mod...@li...<mailto:mod...@li...>>
>
> Subject:  [Mod-security-developers] ModSecurity for Java
> 
> Hello Guys
> 
> Just a  little update, Rule parser for this project is already working and 
>supporting  the 4 directives (SecRuleEngine, SecRule, SecRequestBodyAccess,  
>SecResponseBodyAccess ) of Rule Language Porting Spec Level 1 :)
> 
> I am  struggling to get the Response variables working, I always get an empty  
>string  for the response body buffer :(, can anyone give me some support on  
>this one, I might not be using the ReponseWrapper  correctly.
> 
> Regards,
> Juan Carlos  Calderon
> 
> ________________________________
> This transmission may  contain information that is privileged, confidential, 
>and/or exempt from  disclosure under applicable law. If you are not the intended 
>recipient, you are  hereby notified that any disclosure, copying, distribution, 
>or use of the  information contained herein (including any reliance thereon) is 
>STRICTLY  PROHIBITED. If you received this transmission in error, please 
>immediately  contact the sender and destroy the material in its entirety, 
>whether in  electronic or hard copy  format.
> 
> 
> ------------------------------------------------------------------------------
> Simplify  data backup and recovery for your virtual environment with  vRanger.
> Installation's a snap, and flexible recovery options mean your data  is safe,
> secure and there when you need it. Data protection magic?
> Nope -  It's vRanger. Get your free trial download  today.
> http://p.sf.net/sfu/quest-sfdev2dev
> _______________________________________________
> mod-security-developers  mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity  Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php
> ------------------------------------------------------------------------------
> Simplify  data backup and recovery for your virtual environment with  vRanger.
> Installation's a snap, and flexible recovery options mean your data  is safe,
> secure and there when you need it. Discover what all the cheering's  about.
> Get your free trial download today. 
> http://p.sf.net/sfu/quest-dev2dev2 
> _______________________________________________
> mod-security-developers  mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity  Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php
> 

[Mod-security-developers] CRS DoS bugs/suggestions

[Oleg G. <ole...@ya...>]

I was testing DoS ruleset lately and found that there probably was a bug related to ip.dos_counter variable. The expiration time was not set for this var, as a result the counter persists longer than tx.dos_burst_time_slice. As a result, the history of hits is counted for a longer time period.

I've added expiration time in two places and it started to work correctly after that. The changes are below:

SecRule REQUEST_BASENAME "!\.(jpe?g|png|gif|js|css|ico)$" "phase:5,t:none,nolog,pass,setvar:ip.dos_counter=+1,expirevar:ip.dos_counter=%{tx.dos_burst_time_slice}"

...

SecRule IP:DOS_COUNTER "@ge %{tx.dos_counter_threshold}" "phase:5,t:none,nolog,pass,t:none,setvar:ip.dos_burst_counter=+1,expirevar:ip.dos_burst_counter=%{tx.dos_burst_time_slice},setvar:!ip.dos_counter,expirevar:ip.dos_counter=%{tx.dos_burst_time_slice}"

I've also attached the sample of testing program. I think, we should have something like that to test all limits. There are only two tests implemented for now: for request size and DoS, but it should be easy to add more.

Re: [Mod-security-developers] ModSecurity Happy Hour at Blackhat USA 2011

[Ryan B. <RBa...@tr...>]

Just a reminder to please RSVP for the ModSecurity Happy Hour if you are planning on being at Blackhat USA 2011!

I am looking forward to having some beers and discussing the ins and outs of ModSecurity with users :)

Cheers,
Ryan

From: Ryan Barnett <rba...@tr...<mailto:rba...@tr...>>
Date: Mon, 6 Jun 2011 12:24:08 -0500
To: "mod...@li...<mailto:mod...@li...>" <mod...@li...<mailto:mod...@li...>>, "owa...@li...<mailto:owa...@li...>" <owa...@li...<mailto:owa...@li...>>, "mod...@li...<mailto:mod...@li...>" <mod...@li...<mailto:mod...@li...>>
Subject: ModSecurity Happy Hour at Blackhat USA 2011

SpiderLabs is hosting a Happy Hour at Blackhat USA 2011.  If you are planning on attending Blackhat/DefCon, please come by.  Details/RSVP here - http://blog.spiderlabs.com/2011/06/modsecurity-happy-hour-at-blackhat-usa-2011.html

Hope to see you there!

Ryan

________________________________
This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.

[Mod-security-developers] Please i need your help from Miss Mary.

[Mary C. <m_r...@ya...>]

新しいメールアドレスをお知らせします新しいメールアドレス： m_r...@ya...

Please i need your help from Miss Mary.

Dearest one, I am Miss Mary Clement 21 years old. Please i have the sum of $7 million that i need your help. I inhreated this money from my late father. Please if you will help me reply me back so that i can tell you more about me and the money. 

- Mary Clement

[Mod-security-developers] Apache2: SecRequestBodyLimitAction ProcessPartial corrupts POST data in proxy configuration

[Piotr K. <pio...@gm...>]

Config:

    SecRuleEngine DetectionOnly
    SecRequestBodyAccess On
    SecRequestBodyLimit 10

Result with big POST:

proxy host:
[Tue Jun 07 10:40:51 2011] [error] [client a.b.c.d] ModSecurity: Request
body (Content-Length) is larger than the configured limit (2048). [hostname
"test"] [uri "/test"] [unique_id "Te3kEwoNzNMAACBtAX0AAAAA"]

the request is then passed to the mod_proxy_balancer and to the another host
with but the application gets corrupted data - data is truncated to the
SecRequestBodyLimit.

I've also tried setting "SecRuleEngine On" with "SecRequestBodyLimitAction
ProcessPartial" but the result is the same - proxied POST data is corrupted.

Removing SecRuleEngine from the configuration couses proxying without any
problems.


I'd like to add that low SecRequestBodyLimit is essential for me.

Cheers,
Peter

[Mod-security-developers] ModSecurity Happy Hour at Blackhat USA 2011

[Ryan B. <RBa...@tr...>]

SpiderLabs is hosting a Happy Hour at Blackhat USA 2011.  If you are planning on attending Blackhat/DefCon, please come by.  Details/RSVP here - http://blog.spiderlabs.com/2011/06/modsecurity-happy-hour-at-blackhat-usa-2011.html

Hope to see you there!

Ryan

________________________________
This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.

[Mod-security-developers] [PATCH] Fix wrong kill.

[Diego E. P. <fla...@gm...>]

Signed-off-by: Diego Elio Pettenò <fla...@gm...>
---
 build/find_lua.m4 |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

[Mod-security-developers] [PATCH] Fix the LUA_CFLAGS mangling.

[Diego E. P. <fla...@gm...>]

Signed-off-by: Diego Elio Pettenò <fla...@gm...>
---
 build/find_lua.m4 |    5 +----
 1 files changed, 1 insertions(+), 4 deletions(-)

[Mod-security-developers] [PATCH] Make sure to always set WITH_LUA.

[Diego E. P. <fla...@gm...>]

Signed-off-by: Diego Elio Pettenò <fla...@gm...>
---
 build/find_lua.m4 |    5 +----
 1 files changed, 1 insertions(+), 4 deletions(-)

[Mod-security-developers] [PATCH v2] build: cleanup a bit LUA finding, use proper cross-compilable pkg-config

[Diego E. P. <fla...@gm...>]

Signed-off-by: Diego Elio Pettenò <fla...@gm...>
---
 apache2/Makefile.am |    2 +-
 build/find_lua.m4   |   19 ++++++++-----------
 configure.ac        |    3 ---
 ext/Makefile.am     |    2 +-
 tests/Makefile.am   |    2 +-
 5 files changed, 11 insertions(+), 17 deletions(-)

[Mod-security-developers] [PATCH 6/6] build: cleanup a bit LUA finding, use proper cross-compilable pkg-config

[Diego E. P. <fla...@gm...>]

Signed-off-by: Diego Elio Pettenò <fla...@gm...>
---
 build/find_lua.m4 |   19 ++++++++-----------
 1 files changed, 8 insertions(+), 11 deletions(-)

[Mod-security-developers] [PATCH 4/6] build-sys: handle SUBDIRS in a more automake-conformant way

[Diego E. P. <fla...@gm...>]

Instead of doing the conditionals within the ./configure script, do them on
Makefile.am, this way make dist will always recurse into the directories
even if they are disabled.

Drop the docs options since the docs/ directory does not even exists.

Signed-off-by: Diego Elio Pettenò <fla...@gm...>
---
 Makefile.am  |   21 ++++++++++++++++++++-
 configure.ac |   47 ++---------------------------------------------
 2 files changed, 22 insertions(+), 46 deletions(-)

[Mod-security-developers] [PATCH 5/6] build-sys: avoid sub-shell for recursion.

[Diego E. P. <fla...@gm...>]

Signed-off-by: Diego Elio Pettenò <fla...@gm...>
---
 Makefile.am |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

[Mod-security-developers] [PATCH 3/6] build-sys: avoid using different LDFLAGS for different OSes.

[Diego E. P. <fla...@gm...>]

This also allows dropping a number of boring tests from the configure
script.

Signed-off-by: Diego Elio Pettenò <fla...@gm...>
---
 apache2/Makefile.am |   44 -----------------------------------
 configure.ac        |   63 ---------------------------------------------------
 2 files changed, 0 insertions(+), 107 deletions(-)

[Mod-security-developers] [PATCH 2/6] build-sys: avoid using hooks to handle Apache modules.

[Diego E. P. <fla...@gm...>]

Set the installation directory as library class instead of moving it, and
use -shared to ensure that the static library is never built.

Signed-off-by: Diego Elio Pettenò <fla...@gm...>
---
 apache2/Makefile.am |   28 ++++++++++------------------
 ext/Makefile.am     |   14 +++-----------
 2 files changed, 13 insertions(+), 29 deletions(-)

[Mod-security-developers] [PATCH 1/6] build-sys: declare the name of the project to follow the tarball released.

[Diego E. P. <fla...@gm...>]

This allows using make dist and generate similarly named tarballs.

Change version to 2.6.0-rc3 since rc2 was released already.

Signed-off-by: Diego Elio Pettenò <fla...@gm...>
---
 configure.ac |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Re: [Mod-security-developers] [Resolved] Re: Do not work with 2.6.0

[Breno S. <bre...@gm...>]

No problem man!

Please report it to APR devel guys.

thanks

Breno

On Sat, Jun 4, 2011 at 7:52 PM, momo-i <web...@mo...> wrote:

> Dear Breno,
>
> Ohhhh, That's OK by apr/1.4.4, apu/1.3.11!!!
> Very very thanks so much!!!!!
>
> I could't find such a simple thing, I'm embarrassed:(
>
> Best Regards,
> momo-i.
>
>
> (2011/06/05 9:29), Breno Silva wrote:
>
>> OK... please don't forget to re-compile your apache with the new apr/apu
>> library.
>>
>> thanks
>>
>> Breno
>>
>>