Sorry for the delay in response, I wanted to push the merge request before
I sent a reply. I have addressed your questions inline below. Thank you
for your suggestions and feedback. Keep them coming :)
On 3/6/15, 7:52 AM, "Barry Pollard" <barry_poll...@hotmail.com> wrote:
>I've a few questions about modsecurity_crs_11_dos_protection.conf
>
>Question 1. The first set of rules are these:
>
>#
># Enforce an existing IP address block and log only 1-time/minute
># We don't want to get flooded by alerts during an attack or scan so
># we are only triggering an alert once/minute. You can adjust how often
># you want to receive status alerts by changing the expirevar setting
>below.
>#
>SecRule IP:DOS_BLOCK "@eq 1" "chain,phase:1,id:'981044',drop,msg:'Denial
>of Service (DoS) Attack Identified from %{tx.real_ip}
>(%{tx.dos_block_counter} hits since last
>alert)',setvar:ip.dos_block_counter=+1"
> SecRule &IP:DOS_BLOCK_FLAG "@eq 0"
>"setvar:ip.dos_block_flag=1,expirevar:ip.dos_block_flag=60,setvar:tx.dos_b
>lock_counter=%{ip.dos_block_counter},setvar:ip.dos_block_counter=0"
>
>#
># Block and track # of requests but don't log
>SecRule IP:DOS_BLOCK "@eq 1"
>"phase:1,id:'981045',t:none,drop,nolog,setvar:ip.dos_block_counter=+1"
>
>
>Is rule 981045 needed? Rule 981044 already increments the counter even if
>the chained rule does not match so I don't see the point in rule 981045.
>Or am I misunderstanding this:
>http://scanmail.trustwave.com/?c=4062&d=haj51OzUC8ULIw1rYMiGpRoqW4jwxmAZPw
>rskdE9ZA&s=5&u=https%3a%2f%2fgithub%2ecom%2fSpiderLabs%2fModSecurity%2fwik
>i%2fReference-Manual%23setvar
The difference between these two rules is that rule 981044 is there to
generate the log event when the threshold has been hit, whereas rule
981045 is present to increment the counter. 981045 does not write to the
log, otherwise during a DOS your log would fill up with many alerts.
Instead the rules have been split out to such that logging only occurs
once per DOS event.
>
>
>Question 2:
>
>#
># DOS Counter
># Count the number of requests to non-static resoures
>#
>SecRule REQUEST_BASENAME "!\.(jpe?g|png|gif|js|css|ico)$"
>"phase:5,id:'981047',t:none,nolog,pass,setvar:ip.dos_counter=+1"
>
>Any reason we don't use t:lowercase instead of assuming the file
>extensions are already in lowercase? Would also be nice to specify the
>exact pattern match in modsecurity_crs_10_setup.conf with it defaulting
>to above though I guess you can always use SecRuleUpdateTargetById to add
>your own extensions or other pattern matching.
These are great ideas, I have pushed a merge request to the 3.0.0 branch
with these changes. After testing you should see it in there.
>
>
>Question 3:
>
>#
># Check DOS Counter
># If the request count is greater than or equal to user settings,
># we then set the burst counter
>#
>SecRule IP:DOS_COUNTER "@gt %{tx.dos_counter_threshold}"
>"phase:5,id:'981048',t:none,nolog,pass,t:none,setvar:ip.dos_burst_counter=
>+1,expirevar:ip.dos_burst_counter=%{tx.dos_burst_time_slice},setvar:!ip.do
>s_counter"
>
>I presume this is a typo to have t:none specified twice in this rule?
This is part of the previous merge request as well, seems to be a typo.
>
>Question 4:
>
>Not directly related to this but has anyone made any progress in keeping
>ip.pag down to a reasonable size as doesn't seem to clean up like it
>should do? Several posts about this about the place but not managed to
>find any definitive answers...
>
Asking around the answer is that there are no definitive answers. The
problem is that we are using a database that was built to store a small
amount of data to store a massive amount of data and the mechanism that
sdbm has to protect agains race conditions were not built for the massive
amount of data that we are saving. There are ways to circumvent the
problem by using the modsec-sdbm utility + periodicals restarts but that
is pretty much as good as we get right now. This is a known issue and as
we look towards features for modsecv3 this is an underlying issue we are
looking to address.
>
>
>_______________________________________________
>Owasp-modsecurity-core-rule-set mailing list
>Owasp-modsecurity-core-rule-set@lists.owasp.org
>http://scanmail.trustwave.com/?c=4062&d=haj51OzUC8ULIw1rYMiGpRoqW4jwxmAZPw
>u4y9FoZA&s=5&u=https%3a%2f%2flists%2eowasp%2eorg%2fmailman%2flistinfo%2fow
>asp-modsecurity-core-rule-set
________________________________
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.
_______________________________________________
Owasp-modsecurity-core-rule-set mailing list
Owasp-modsecurity-core-rule-set@lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
