Re: [mod-security-users] Collections

[Ryan B. <rya...@br...>]

On Thursday 15 October 2009 04:47:06 am Marc Stern wrote:
> The goal is to not fill up the log with several thousand warnings.
> I indeed used a resource based on the application name, but I'd like
> something more for some environments.
>
Are you looking for more of a "log-once" type of alerting?  We have to deal 
with this type of scenario with the Breach WebDefend product when dealing with 
Application Integrity/Defect issues.  These are not *attack* types of rules 
but rather look for config mistakes, etc... where you want to let the WAF user 
know about the issue but you don't want to flood them every time you see it.

If this sounds like the same category, you could take a queue from the the CRS 
for how it handles one-time alerting when it identifies compression -

SecRule RESPONSE_HEADERS:Content-Encoding "!^Identity$" 
"phase:4,t:none,pass,nolog,auditlog,msg:'ModSecurity does not support content 
encodings',id:'960903',severity:'4',chain,initcol:global=global"
        SecRule &GLOBAL:alerted_960903_compression "@eq 0" 
"setvar:global.alerted_960903_compression,setvar:tx.anomaly_score=+5,setvar:tx.policy_score=+1,setvar:tx.
%{rule.id}-POLICY/ENCODING_RESTRICTED-%{matched_var_name}=%{matched_var}"

You could do something similar for your scenario where you initiate a global 
collection and set a variable when you see the outbound response header you 
want to flag.  You make it a chained rule so that there is a 2nd check to see 
if you have already alerted on it.  If so, you won't alert again.  Something 
like this might work (untested) -

SecRule &GLOBAL:alerted_response_header_name "@eq 0" \
	"chain,phase:4,t:none,pass,nolog,auditlog,msg:'Invalid Response Header. 
',initcol:global=global"	
		SecRule RESPONSE_HEADERS_NAMES "^x-" \
		
"setvar:global.alerted_response_header_name_%{MATCHED_VAR}=1,expirevar:global.alerted_response_header_name_%{MATCHED_VAR}=86400"

 Note with this rule, that we put the check for the global variable first so 
that it will only ever reach the 2nd rule the first time through.  Also note 
that we are expiring the global variable every day so the there should be a 
max of 1 alert per day for this event.  You could obviously increase this if 
you only wanted to alert once per week or something.  This type of alert 
throttling helps for appdefect issues so that you don't flood the WAF admin, 
but you still keep alerting every once in awhile so that the issue is not 
forgotten and you can identify when the app devs/admin fix the issue.

Hope this helps.

-Ryan


> Marc
>
> Brian Rectanus wrote:
> Hmm, not sure I understand what you are trying to accomplish here.
>
> This would:
>
> 1) Create a new collection for the first X- header and persist it
> 2) This collection would only have a single value: done=1
> 3) Other requests that would generate these same first header would then
> have the collection read in and see the done=1 value
>
> What good is this?
>
> What about this instead:
>
> # Create a resource collection based on the app
> # name (ie first path segment in this example)
> SecRule REQUEST_URI "^/[^/]*" \
>   "phase:1,pass,nolog,capture, \
>    initcol:resource=%{TX.0}"
>
> # Add any invalid headers to the collection
> # NOTE: this works because of the pass and no chain
> SecRule RESPONSE_HEADERS_NAMES "^x-" \
>   "phase:3,nolog,pass,setvar:resource.%{MATCHED_VAR}"
>
> Now you have all the invalid headers in the collection per-app. And can
> look if it has an invalid one:
>
> SecRule &RESOURCE "@gt 0" \
>   "..."
>
>
> Although this would do it as well without the collection, heh:
>
> SecRule &RESPONSE_HEADERS_NAMES:/^x-/ "@gt 0" "..."
>
> later,
> -B
>
>
> Marc Stern wrote:
> Hi Brian,
>
> Here is a (simplified) example:
>
> I want to check that no header beginning with "X-" is coming from the
> application.
> I'd like to do this check only once for a header.
> I would create/use a collection like this:
>
>     SecRule RESPONSE_HEADERS_NAMES "^x-"
>     "...,initcol:invalidheader=%{MATCHED_VAR},chain,log,pass"
>     SecRule &invalidheader:done "@eq 0" "...,setvar:invalidheader.done"
>
> Marc
>
>
> Brian Rectanus wrote:
> Ryan Barnett wrote:
>
> On Wednesday 14 October 2009 06:11:42 am Marc Stern wrote:
> > It seems that we cannot create any collection, but "registered" ones.
> > Is there an exhaustive list of collection?
> > ip, user, session, resource, global, ...
>
> I believe those are the only ones. Brian can confirm.
>
>
> Those are all (except TX, but I think you meant persistent collections).
>
> I'd like to add support for custom collections, though. What need do
> you have?
>
> -B