Apache mod-security

Robert Rowley | 29 Dec 2011 07:00

mod_sec rule for hash collision DoS

I couldn't find where to recommend rules for the CRS but wanted to get
this out there:

With this morning's interesting re-release of hash collision denial of
service attacks[1][2] I found it trivial easy to implement a
preventative "band-aid" with mod_sec. And really, trivial is  an
understatement:

SecRule &ARGS " <at> gt 1000" deny

No really, that's it. It's a similar 'work around' that PHP developers
implemented in 5.3.9 and 5.4.0RC4 with "max_input_vars". [3]

Now, the good question the above rule doesn't catch cookies. Will
{COOKIES_COUNT " <at> gt 1000"} work in 2.x? (I see this variable was
introduced back in 2005 with mod_sec 1.9)

[1] http://events.ccc.de/congress/2011/Fahrplan/events/4680.en.html
[2] http://permalink.gmane.org/gmane.comp.security.full-disclosure/83694
[3] http://svn.php.net/viewvc?view=revision&revision=321040

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net

(Continue reading)

headers

Josh Amishav-Zlatin | 29 Dec 2011 09:46

Re: mod_sec rule for hash collision DoS

On Thu, Dec 29, 2011 at 8:00 AM, Robert Rowley <robert <at> robrowley.com> wrote:
> I couldn't find where to recommend rules for the CRS but wanted to get
> this out there:
>
> With this morning's interesting re-release of hash collision denial of
> service attacks[1][2] I found it trivial easy to implement a
> preventative "band-aid" with mod_sec. And really, trivial is  an
> understatement:
>
> SecRule &ARGS " <at> gt 1000" deny

Hi Robert,

The CRS already has rules to limit the number of parameters in a
request. The modsecurity_crs_10_config.conf initially configures the
threshold:

  ## Maximum number of arguments in request limited
  SecAction "phase:1,id:'981211',t:none,nolog,pass,setvar:tx.max_num_args=255"

The modsecurity_crs_23_request_limits.conf file adjusts the anomaly
score when the request has more then the defined number of parameters:

  SecRule &ARGS " <at> gt %{tx.max_num_args}"
"t:none,setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%
  {tx.notice_anomaly_score},setvar:tx.policy_score=+%{tx.notice_anomaly_score},setvar:tx.%{rule.id}-
  POLICY/SIZE_LIMIT-%{matched_var_name}=%{matched_var}"

> Now, the good question the above rule doesn't catch cookies. Will
> {COOKIES_COUNT " <at> gt 1000"} work in 2.x? (I see this variable was

(Continue reading)

headers

Ryan Barnett | 29 Dec 2011 15:44

Re: mod_sec rule for hash collision DoS


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

>On Thu, Dec 29, 2011 at 8:00 AM, Robert Rowley <robert <at> robrowley.com>
>wrote:
>> I couldn't find where to recommend rules for the CRS but wanted to get
>> this out there:
>>
>> With this morning's interesting re-release of hash collision denial of
>> service attacks[1][2] I found it trivial easy to implement a
>> preventative "band-aid" with mod_sec. And really, trivial is  an
>> understatement:
>>
>> SecRule &ARGS " <at> gt 1000" deny
>
>Hi Robert,
>
>The CRS already has rules to limit the number of parameters in a
>request. The modsecurity_crs_10_config.conf initially configures the
>threshold:
>
>  ## Maximum number of arguments in request limited
>  SecAction
>"phase:1,id:'981211',t:none,nolog,pass,setvar:tx.max_num_args=255"
>
>The modsecurity_crs_23_request_limits.conf file adjusts the anomaly
>score when the request has more then the defined number of parameters:
>
>  SecRule &ARGS " <at> gt %{tx.max_num_args}"
>"t:none,setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%

(Continue reading)