Re: Retry-After header not being set?
Jamie Burchell <[email protected]> Thu, 17 Feb 2022 20:35:13 -0000
| Newsgroups | gmane.comp.apache.mod-security.user |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> Sent: 17 February 2022 12:30 To: [email protected] 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 [email protected] 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/ _______________________________________________ mod-security-users mailing list [email protected] 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/