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

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

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
>