Re: [mod-security-users] Retry-After header not being set?

[Jamie B. <ja...@ib...>]

Hi Andrew

Thanks for taking the time to help me. I have narrowed the header issue
down. If I remove:

ErrorDocument 429 /error.php

The default Apache error document is used, and the header is in the
response. It seems that somehow it is being removed when I'm passing the
processing off to PHP-FPM.

Regarding the phasing, please can you tell me which numbers to use to make
that work? All the examples I have found use the same phase numbers. If I
set them the same, presumably the counter will never move?

Thanks
Jamie

-----Original Message-----
From: Andrew Howe <and...@lo...>
Sent: 17 February 2022 12:30
To: mod...@li...
Subject: Re: [mod-security-users] Retry-After header not being set?

Hi Jamie,

> One peculiar thing I noticed is that after the 429 response, the next
> request gives me a 429 even if I have waited for a long time.

I think that's because of the phases of your rules. The following test,
and its deny action if the rule matches, is executed in phase 2:

    SecRule IP:HITCOUNTER "@gt 60" "phase:2,pause:300,deny,...

Even if you've waited long enough for HITCOUNTER to cool off, the
deprecatevar action to apply that 'cooling off' doesn't take place until
later on, in phase 5:

    SecAction "phase:5,deprecatevar:ip.hitcounter=1/10,...

Unless HITCOUNTER has fully _expired_ it will still retain its high value
when your next request hits after a long break. That request then gets
denied, deprecatevar then 'cools off' HITCOUNTER to its expected value,
and then the *next* request after that will pass through, as intended.


> mod_headers is there; I'm using the same syntax to set a HSTS expiry

I've just triple-checked, and your initial set of rules definitely work
for me out of the box, with no alterations. I can only think that
something in your set up is causing you problems.

Maybe try walking it back to the simplest possible setup, see if that
works, and then add each additional piece of complexity until it breaks?
For example, does this work on its own:

    Header always set Retry-After "10"

If that *doesn't* work then there's something fundamentally wrong. But if
that *does* work, then does this work:

    SecAction "id:103,phase:2,pass,nolog,setenv:RATELIMITED"
    Header always set Retry-After "12" env=RATELIMITED

If that works, then does this work:

    SecAction "id:100,pass,nolog,initcol:ip=%{REMOTE_ADDR}"
    SecAction "id:110,pass,nolog,setvar:'ip.hitcounter=100'"
    SecRule IP:HITCOUNTER "@gt 60"
"phase:2,pause:300,deny,status:429,setenv:RATELIMITED,skip:1,nolog,id:103"
    Header always set Retry-After "10" env=RATELIMITED

And so on and so forth.

Thanks,
Andrew

-- 

Andrew Howe
Loadbalancer.org Ltd.
www.loadbalancer.org
+1 888 867 9504 / +44 (0)330 380 1064


_______________________________________________
mod-security-users mailing list
mod...@li...
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
http://www.modsecurity.org/projects/commercial/rules/
http://www.modsecurity.org/projects/commercial/support/