Re: [mod-security-users] How to limit access rate by header?

[Luciano G. F. <luc...@gm...>]

And the final rule is:

# Limit client hits by user agent
SecRule REQUEST_HEADERS:User-Agent "@pmf data/ratelimit-clients.data" \

"id:100008,phase:2,nolog,pass,setuid:%{tx.ua_hash},setvar:user.ratelimit_client=+1,expirevar:user.ratelimit_client=3"

SecRule USER:RATELIMIT_CLIENT "@gt 1" \

"chain,id:1000009,phase:2,deny,status:429,setenv:RATELIMITED,log,msg:'RATELIMITED
BOT'"

    SecRule REQUEST_HEADERS:User-Agent "@pmf data/ratelimit-clients.data"

Header always set Retry-After "3" env=RATELIMITED

ErrorDocument 429 "Too Many Requests"

El mié., 12 de dic. de 2018 a la(s) 18:16, Luciano Guillermo Fantuzzi (
luc...@gm...) escribió:

> Oh, I didn't realize we were not anymore in the main mailing thread. I'm
> re-joining it from here. Just in case I've documented all I could in my own
> question here:
> https://stackoverflow.com/questions/53620557/modsecurity-apache-how-to-limit-access-rate-by-header
>
> BTW, I'm following the advice of removing the "pause" part. I'm not sure
> about why it was needed in the first place, but I left it there because I
> saw it in other example snippets I found (like
> https://gist.github.com/josnidhin/91d1ea9cd71fde386c27a9228476834e). I
> thought it was something related to stop successive hits (like trying to
> delay the origin request), but I'm not sure it makes a lot of sense here...
>
> > Hmm. Do not know, but %{matched_var} is generally a good friend. Did you
> > try it with capture? I mostly stick to matched_var.
> I'm not sure I understand the "capture" part. The rule was entirely the
> same, just replaced tx.0 with matched_var. @pm is the capture part you are
> refering to? I'm using @pmf so I think it's the same mechanism. I'm not
> seeing anything else in the docs for TX usage:
> https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#TX
>
> > And I'd do an empty
> > line between 11 and 12, but nothing else springs to mind.
> I'm kind obsessive with coding standards. In this case, I didn't add an
> empty line there just to make it look like a single rule (I have other
> custom rules in that file), but I wasn't sure it was ok. For what I see,
> indentation with no empty lines in main directives are only for chained
> rules. On the other hand, rules helper blocks follow the format:
>
>  76 #
>  77 # [ description ]
>  78 #
>  79 # - reference X
>  80 #
>
> I don't know if that helper block is following some docs standard so it
> can be parsed by some tool (eg. Javadoc).
>
> Have a nice day.
>
> El mié., 12 de dic. de 2018 a la(s) 17:11, Christian Folini (
> chr...@ne...) escribió:
>
>> Hey, hey,
>>
>> On Wed, Dec 12, 2018 at 02:18:47PM -0300, Luciano Guillermo Fantuzzi
>> wrote:
>> > Well, it finally worked with %{matched_var} instead of %{tx.0}. I don't
>> > know why, because according to docs, tx.0 should contain the matching
>> value
>> > of @pm (I assume @pmf works the same way):
>>
>> Hmm. Do not know, but %{matched_var} is generally a good friend. Did you
>> try it with capture? I mostly stick to matched_var.
>>
>> > Following your tip of t:sha1 in the same line didn't work for some
>> reason.
>>
>> Oops. Forgot to tell you about the t:hexEncode. t:sha1 is binary, it takes
>> the encoding to become useful as key. Sorry.
>>
>> > So I replaced %{matched_var} with %{tx.ua_hash} and it still works and I
>> > think it's a more consistent way in case I need a more complex UA match.
>>
>> Very good.
>>
>> >   9 # Limit client hits by user agent
>> >  10 SecRule REQUEST_HEADERS:User-Agent "@pmf
>> data/ratelimit-clients.data" \
>> >  11
>> >
>> "id:400009,phase:2,nolog,pass,setuid:%{tx.ua_hash},setvar:user.ratelimit_client=+1,expirevar:user.ratelimit_client=3"
>> >  12 SecRule USER:RATELIMIT_CLIENT "@gt 1" \
>> >  13
>> >
>> "chain,id:4000010,phase:2,pause:300,deny,status:429,setenv:RATELIMITED,log,msg:'RATELIMITED
>> > BOT'"
>> >  14     SecRule REQUEST_HEADERS:User-Agent "@pmf
>> > data/ratelimit-clients.data"
>> >  15 Header always set Retry-After "3" env=RATELIMITED
>> >  16 ErrorDocument 429 "Too Many Requests"
>>
>> That looks quite good. I'd move into the rule range below 100000, though.
>>
>> The pause, deny combination actually blocks the server too. You could
>> simply issue a drop. That's lighter on the server.
>>
>> > Is there some coding standards to write these rules?
>>
>> CRS has a coding guideline on the wiki on github. But that's just a
>> convention. Personally, I put chain at the end of a rule. And I'd do an
>> empty
>> line between 11 and 12, but nothing else springs to mind.
>>
>> > Thank you for your tips, Christian.
>>
>> You're welcome. Glad it worked out for your in the end. It would be nice
>> if
>> you could post your recipe to the mailinglist. It might help other people
>> in a
>> similar situation in the future.
>>
>> Ahoj,
>>
>> Christian
>>
>>
>>
>> --
>> A political leader must keep looking over his shoulder all the
>> time to see if the boys are still there. If they aren’t still there,
>> he’s no longer a political leader.
>> -- Bernard Baruch
>>
>