mod-security-users — General discussion about mod_security

[mod-security-users] Race Conditions and mod_security Variables

[Patrick R. <P.R...@ma...>]

Hi all,

Does mod_security have a race condition problem/issue with its variables, or am I doing something incorrect with my configuration ?  (See details below.)

I’m wanting to rate limit connections to a resource to no more than 20 requests in a minute.  What I’m finding is that if (from a test client) I spawn connection requests as fast as possible, i.e.:

#!/bin/bash
for ((i=1;i<=3000;i++));
do
                nohup /usr/bin/curl -b /path/to/cookies https://myserver.url/fragile/script.php &
done

Then I was surprised to find that I could far more than 20 requests – I got not 20 but more than 350 requests through via my test.

When I set:

    SecDebugLog /var/log/httpd/modsec_debug.log

    SecDebugLogLevel 9

I was able to see what was happening.  This is modsec_debug grepped for “Set variable” and you can see that there’s an apparent race condition involving the variables as follows (note the short time period of 13 seconds):

[13/Mar/2022:16:50:39 +1300] [myserver.url/sid#56481359f968][rid#564813818810][/fragile/script.php][9] Set variable "ip.access_count" to "1".
[13/Mar/2022:16:50:39 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "1".
[13/Mar/2022:16:50:39 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "1".
[13/Mar/2022:16:50:39 +1300] [myserver.url/sid#56481359f968][rid#564813826880][/fragile/script.php][9] Set variable "ip.access_count" to "1".
[13/Mar/2022:16:50:40 +1300] [myserver.url/sid#56481359f968][rid#564813818880][/fragile/script.php][9] Set variable "ip.access_count" to "2".
[13/Mar/2022:16:50:40 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "2".
[13/Mar/2022:16:50:40 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "2".
[13/Mar/2022:16:50:40 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "2".
[13/Mar/2022:16:50:40 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "2".
[13/Mar/2022:16:50:40 +1300] [myserver.url/sid#56481359f968][rid#564813818810][/fragile/script.php][9] Set variable "ip.access_count" to "1".
[13/Mar/2022:16:50:41 +1300] [myserver.url/sid#56481359f968][rid#564813818880][/fragile/script.php][9] Set variable "ip.access_count" to "2".
[13/Mar/2022:16:50:41 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "2".
[13/Mar/2022:16:50:41 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "2".
[13/Mar/2022:16:50:41 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "2".
[13/Mar/2022:16:50:41 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "2".
[13/Mar/2022:16:50:41 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "2".
[13/Mar/2022:16:50:41 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "2".
[13/Mar/2022:16:50:41 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "2".
[13/Mar/2022:16:50:41 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "2".
[13/Mar/2022:16:50:41 +1300] [myserver.url/sid#56481359f968][rid#564813828890][/fragile/script.php][9] Set variable "ip.access_count" to "1".
[13/Mar/2022:16:50:41 +1300] [myserver.url/sid#56481359f968][rid#5648138e3f70][/fragile/script.php][9] Set variable "ip.access_count" to "2".
[13/Mar/2022:16:50:42 +1300] [myserver.url/sid#56481359f968][rid#564813818880][/fragile/script.php][9] Set variable "ip.access_count" to "3".
[13/Mar/2022:16:50:42 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "3".
[13/Mar/2022:16:50:42 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "3".
[13/Mar/2022:16:50:42 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "3".
[13/Mar/2022:16:50:42 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "3".
[13/Mar/2022:16:50:42 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "3".
[13/Mar/2022:16:50:42 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "3".
[13/Mar/2022:16:50:42 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "3".
[13/Mar/2022:16:50:42 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "3".
[13/Mar/2022:16:50:42 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "3".
[13/Mar/2022:16:50:42 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "3".
[13/Mar/2022:16:50:42 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "3".
[13/Mar/2022:16:50:42 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "3".
[13/Mar/2022:16:50:42 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "3".
[13/Mar/2022:16:50:42 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "3".
[13/Mar/2022:16:50:42 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "3".
[13/Mar/2022:16:50:42 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "3".

<< More than 300 lines with the same pattern as the above >>


[13/Mar/2022:16:50:51 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "19".

[13/Mar/2022:16:50:51 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "19".

[13/Mar/2022:16:50:51 +1300] [myserver.url/sid#56481359f968][rid#564813818880][/fragile/script.php][9] Set variable "ip.access_count" to "20".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813818880][/fragile/script.php][9] Set variable "ip.access_count" to "20".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

[13/Mar/2022:16:50:52 +1300] [myserver.url/sid#56481359f968][rid#564813816870][/fragile/script.php][9] Set variable "ip.access_count" to "21".

For “well behaved clients” there is no problem (i.e. if I send a request with a second pause etc between requests) – but the “fast as possible / brute force” incurs the above.

Looking at the Apache logs – for my 3,000 brute force connection attempts, I got 358 with HTTP Code 200, and 2642 with HTTP Code 429 (not 20 and 2950 respectively as expected).

Is this a bug with mod_security ?  Is there any way to avoid/workaround the above – even if it incurs some performance overhead ?

My complete mod_security config is:

<IfModule mod_security2.c>
    SecRuleEngine On
    SecRequestBodyAccess Off
    SecResponseBodyAccess Off
    SecDebugLog /var/log/httpd/modsec_debug.log
    SecDebugLogLevel 9
    SecAuditEngine RelevantOnly
    SecAuditLogRelevantStatus "^(?:5|4(?!04))"
    SecAuditLogParts ABIJDEFHZ
    SecAuditLogType Serial
    SecAuditLog /var/log/httpd/modsec_audit.log
    SecArgumentSeparator &
    SecCookieFormat 0
    SecTmpDir /var/lib/mod_security
    SecDataDir /var/lib/mod_security

<LocationMatch "^/fragile/script.php.*">
  # initialise the state based on X-Forwarded-For ip address
  SecRule REQUEST_HEADERS:X-Forwarded-For "@unconditionalMatch" "phase:2,initcol:ip=%{MATCHED_VAR},pass,nolog,id:100"
  SecRule IP:ACCESS_COUNT "@gt 20" "phase:2,deny,status:429,setenv:RATELIMITED,skip:1,nolog,id:102"
  SecAction "phase:2,setvar:ip.access_count=+1,pass,nolog,id:103"
  SecAction "phase:5,ctl:auditEngine=On,deprecatevar:ip.access_count=20/60,pass,nolog,id:104"
  Header always set Retry-After "10" env=RATELIMITED
</LocationMatch>

ErrorDocument 429 "Rate Limited"

Thanks in Advance,

Patrick

Re: [mod-security-users] Rate Limiting Apache: Units associated with "burst_rate_limit" ?

[Patrick R. <P.R...@ma...>]

Thanks Andrew for the great reply.  I’ll have a think about what you’re saying 😊

The site is a PHP based LMS (Learning Management System) – and it is behind a Paywall (i.e. you need an OAuth2 token).  It’s probably what I would call an intermediately sized site.  The site is generally very “chatty” – i.e. a single user can legitimately load hundreds/thousands of small artifacts (i.e. javascript, images, various small/inexpensive resources).  So there is a large amount of “background noise” to the platform.

Where we have run into a problem, is exactly what you have outlined.  Recently we had thousands of requests within a short period of time (less than a minute) to an expensive PHP resource.  Although it didn’t take the site down, it caused degraded performance in the frontend and an unusual drop in free PostgreSQL DB connections which was concerning.

Upstream we actually have a pool of Citrix Netscalers – but when we tried making use of the Citrix recommended DoS features, we found that we ended up hitting up many false positives (just due to the legitimate “background noise” that individual users generated). Perhaps there is a way for the Netscalers to handle URL based rules (with counters), but the Netscalers seem to be more focused on protection against massive DoS style events.

Perhaps a combination of the HTTPD frontends protecting “sensitive” PHP resources, and also making use of the Citrix DoS features (for truly “DoS Style” events) would be a good combination.  I don’t think the Netscalers are the best way to protect individual resources, though – it appears to be too coarse a tool for this purpose.

Thanks,

Patrick


From: Andrew Howe <and...@lo...>
Date: Saturday, 12 March 2022 at 9:05 AM
To: mod...@li... <mod...@li...>
Subject: Re: [mod-security-users] Rate Limiting Apache: Units associated with "burst_rate_limit" ?
Hi Patrick,

> Thanks for the reply, but I’m actually just wanting to protect a small portion of the site.  Almost all of the site can and should run without restrictions, except for some PHP scripts that (if hit repeatedly) cause performance issues.

If your solution is designed to stop *trusted users* from accidentally
pushing too hard on expensive PHP scripts then you might get away with
using ModSecurity for simple rate limiting.

If, on the other hand, you're looking for real denial of service
defence against malicious clients then you really don't want to be
using Apache+ModSecurity to provide that. In a production environment,
when Apache+ModSec DoS rules are put under pressure, you end up seeing
truly *staggering* resource usage (namely RAM), blocking can be
unreliable, odd error messages appear complaining about accessing the
underlying database files, the database files themselves can quickly
balloon and consume the file system (they need regular pruning), and
the whole thing just crumbles really easily.

You mentioned that you only want to rate limit requests to certain
URLs, which rules out doing anything clever at the network layer. I'm
personally moving all my use of Apache+ModSec DoS rules over to a
simple HAProxy instance sitting in front of Apache, which works
perfectly (HAProxy has a highly efficient key-value store, "stick
tables", which achieves much the same thing as the ModSec DoS rules,
but the configuration is simpler and the setup is extremely reliable
with only a fraction of the resource use). And there are other
options, too, like mod_qos, as mentioned earlier in the thread.

Have a good weekend.

Thanks,
Andrew

--

Andrew Howe
Loadbalancer.org Ltd.
https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.loadbalancer.org%2F&amp;data=04%7C01%7CP.Rynhart%40massey.ac.nz%7C62cb2ccddf8940ccbc9808da039a8872%7C388728e1bbd0437898dcf8682e644300%7C1%7C0%7C637826259509989850%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=LtV3e70Co2LjrpIZe7UQ3IVPRnj7uNUTbWJQ40QWddk%3D&amp;reserved=0
+1 888 867 9504 / +44 (0)330 380 1064


_______________________________________________
mod-security-users mailing list
mod...@li...
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fmod-security-users&amp;data=04%7C01%7CP.Rynhart%40massey.ac.nz%7C62cb2ccddf8940ccbc9808da039a8872%7C388728e1bbd0437898dcf8682e644300%7C1%7C0%7C637826259509989850%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=dl2NbKysyCIh8hXoYdXl5B6x5ZbTSehq5dOjutJymLs%3D&amp;reserved=0
Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.modsecurity.org%2Fprojects%2Fcommercial%2Frules%2F&amp;data=04%7C01%7CP.Rynhart%40massey.ac.nz%7C62cb2ccddf8940ccbc9808da039a8872%7C388728e1bbd0437898dcf8682e644300%7C1%7C0%7C637826259509989850%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=0MW1JqV2e7hNdC9gNZzGojovJhVPa33Fcdd56d%2FIREc%3D&amp;reserved=0
https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.modsecurity.org%2Fprojects%2Fcommercial%2Fsupport%2F&amp;data=04%7C01%7CP.Rynhart%40massey.ac.nz%7C62cb2ccddf8940ccbc9808da039a8872%7C388728e1bbd0437898dcf8682e644300%7C1%7C0%7C637826259509989850%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=ChOvB0BNq86UY7xV4uM1nByAV%2B1cOgn9x1sdJKOpqPM%3D&amp;reserved=0

Re: [mod-security-users] Rate Limiting Apache: Units associated with "burst_rate_limit" ?

[Andrew H. <and...@lo...>]

Hi Patrick,

> Thanks for the reply, but I’m actually just wanting to protect a small portion of the site.  Almost all of the site can and should run without restrictions, except for some PHP scripts that (if hit repeatedly) cause performance issues.

If your solution is designed to stop *trusted users* from accidentally
pushing too hard on expensive PHP scripts then you might get away with
using ModSecurity for simple rate limiting.

If, on the other hand, you're looking for real denial of service
defence against malicious clients then you really don't want to be
using Apache+ModSecurity to provide that. In a production environment,
when Apache+ModSec DoS rules are put under pressure, you end up seeing
truly *staggering* resource usage (namely RAM), blocking can be
unreliable, odd error messages appear complaining about accessing the
underlying database files, the database files themselves can quickly
balloon and consume the file system (they need regular pruning), and
the whole thing just crumbles really easily.

You mentioned that you only want to rate limit requests to certain
URLs, which rules out doing anything clever at the network layer. I'm
personally moving all my use of Apache+ModSec DoS rules over to a
simple HAProxy instance sitting in front of Apache, which works
perfectly (HAProxy has a highly efficient key-value store, "stick
tables", which achieves much the same thing as the ModSec DoS rules,
but the configuration is simpler and the setup is extremely reliable
with only a fraction of the resource use). And there are other
options, too, like mod_qos, as mentioned earlier in the thread.

Have a good weekend.

Thanks,
Andrew

-- 

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

Re: [mod-security-users] Rate Limiting Apache: Units associated with "burst_rate_limit" ?

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

Hi Patrick



I’m doing exactly this for a small portion of a website which to prevent
aggressive scrapping of content. This config is working for me:



    <LocationMatch "^/protectedme$">

        SecAction "initcol:ip=%{REMOTE_ADDR},pass,nolog,id:100"

        SecAction "phase:5,deprecatevar:ip.hitcounter=1/5,pass,nolog,id:102"

        SecRule IP:HITCOUNTER "@gt 30"
"phase:2,pause:300,deny,status:429,skip:1,nolog,id:103"

        SecAction
"phase:2,pass,setvar:ip.hitcounter=+1,expirevar:ip.hitcounter=150,nolog,id:104"

    </LocationMatch>



This is a “leaky-bucket” type setup whereby you are allowed a burst of 30
requests and the rate reducses at 1 request every 5 seconds.


Kind regards,

*Jamie*
ib3 Limited
01732 449974


[image: logo]






--

*From:* Patrick Rynhart <P.R...@ma...>
*Sent:* 11 March 2022 07:58
*To:* mod...@li...
*Subject:* Re: [mod-security-users] Rate Limiting Apache: Units associated
with "burst_rate_limit" ?



Thanks for the reply, but I’m actually just wanting to protect a small
portion of the site.  Almost all of the site can and should run without
restrictions, except for some PHP scripts that (if hit repeatedly) cause
performance issues.



When I looked into mod_evasive, you didn’t seem to be able to nominate a
location or location(s) for which you could only apply limits to.



In other words, I want to wrap it into a Location – something along the
lines of the following:



<LocationMatch "^/some/URL/that/needs/rate/limiting.php.*">

  SecRule REQUEST_HEADERS:X-Forwarded-For "@unconditionalMatch"
"phase:2,initcol:ip=%{MATCHED_VAR},pass,nolog,id:100"

  SecRule IP:ACCESS_COUNT "@gt XX"
"phase:2,deny,status:429,setenv:RATELIMITED,skip:1,nolog,id:102"

…

</LocationMatch>



With that in mind – does anyone know how the “@gt XX” “burst rate” for
mod_security is calculated ?  In particular, how long before the burst
counter gets reset etc ?



Thanks,



Patrick



*From: *Brent Clark <bre...@gm...>
*Date: *Friday, 11 March 2022 at 8:42 PM
*To: *mod...@li... <
mod...@li...>
*Subject: *Re: [mod-security-users] Rate Limiting Apache: Units associated
with "burst_rate_limit" ?

Hiya

If you want to look to some type of rate limiting.?
Rather look to Apaches mod_evasive module.

Mod_evasive monitors incoming requests for suspicious activity from one IP,
such as:

    Several requests for the same page in one second.
    More than 50 simultaneous requests per second.
    Requests made while the IP is temporarily blacklisted.

The module sends a 403 error if any of these things happen.

HTH
Regards
Brent

On 2022/03/11 05:59, Patrick Rynhart wrote:

Hi all,



I’m wanting to introduce IP based rate limiting protection to our Apache
config, and am basing my config off this Gist:



https://gist.github.com/josnidhin/91d1ea9cd71fde386c27a9228476834e
<https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.github.com%2Fjosnidhin%2F91d1ea9cd71fde386c27a9228476834e&data=04%7C01%7CP.Rynhart%40massey.ac.nz%7C0fac6166573140a450ab08da0332b551%7C388728e1bbd0437898dcf8682e644300%7C1%7C0%7C637825813584279072%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lu%2BO39925FXybkSHLv%2F2HTFdPpxrJwjJAxaQJMJI1nk%3D&reserved=0>



I’m wanting to understand the line:



SecRule IP:ACCESS_COUNT "@gt {{ burst_rate_limit }}"
"phase:2,pause:300,deny,status:503,setenv:RATELIMITED,skip:1,nolog,id:102"



In particular what are the units associated with burst_rate_limit ?  What
does it mean if you set this variable to a value like 100 ?  (Does this
correspond to a rate of 100 per minute ?  If not, what does it correspond
to ?)



Thanks,



Patrick







_______________________________________________

mod-security-users mailing list

mod...@li...

https://lists.sourceforge.net/lists/listinfo/mod-security-users
<https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fmod-security-users&data=04%7C01%7CP.Rynhart%40massey.ac.nz%7C0fac6166573140a450ab08da0332b551%7C388728e1bbd0437898dcf8682e644300%7C1%7C0%7C637825813584279072%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=sNHqrh149u%2B7FCSs7h9F6BW59GAHoe%2F%2BNuIBQ5bEDqw%3D&reserved=0>

Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:

http://www.modsecurity.org/projects/commercial/rules/
<https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.modsecurity.org%2Fprojects%2Fcommercial%2Frules%2F&data=04%7C01%7CP.Rynhart%40massey.ac.nz%7C0fac6166573140a450ab08da0332b551%7C388728e1bbd0437898dcf8682e644300%7C1%7C0%7C637825813584279072%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Iq6NueQhU%2Bc9elqjLZ5XmgwS3ea5qAt%2BELslo4yE4UQ%3D&reserved=0>

http://www.modsecurity.org/projects/commercial/support/
<https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.modsecurity.org%2Fprojects%2Fcommercial%2Fsupport%2F&data=04%7C01%7CP.Rynhart%40massey.ac.nz%7C0fac6166573140a450ab08da0332b551%7C388728e1bbd0437898dcf8682e644300%7C1%7C0%7C637825813584279072%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1f1yh%2FWlALfLfRMVHsSdJF1GBBx2TE7g0TwaLXMmoaY%3D&reserved=0>

Re: [mod-security-users] Rate Limiting Apache: Units associated with "burst_rate_limit" ?

[Christian F. <chr...@ne...>]

Honestly, I have no idea what this is.

It does not look like a ModSecurity variable at all.

What you want to achieve can be done by applying the DOS rules in the CRS.
However, while several users report good experience with them, I'm not a fan
and they are on the way to be removed from the rule set and shifted into an
optional plugin.

But you may want to try for yourself.

Other than that mod_evasive is a traditional module used for this purpose, yet
as you noted more for the overall server. An alternative is mod_qos which can
be configured in a more granular way. But please wear a helmet when working
with mod_qos, it's a bit of a beast.

Best,

Christian


On Fri, Mar 11, 2022 at 03:59:42AM +0000, Patrick Rynhart wrote:
> Hi all,
> 
> I’m wanting to introduce IP based rate limiting protection to our Apache config, and am basing my config off this Gist:
> 
> https://gist.github.com/josnidhin/91d1ea9cd71fde386c27a9228476834e
> 
> I’m wanting to understand the line:
> 
> SecRule IP:ACCESS_COUNT "@gt {{ burst_rate_limit }}" "phase:2,pause:300,deny,status:503,setenv:RATELIMITED,skip:1,nolog,id:102"
> 
> In particular what are the units associated with burst_rate_limit ?  What does it mean if you set this variable to a value like 100 ?  (Does this correspond to a rate of 100 per minute ?  If not, what does it correspond to ?)
> 
> Thanks,
> 
> Patrick
> 
> 


> _______________________________________________
> 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/

Re: [mod-security-users] Rate Limiting Apache: Units associated with "burst_rate_limit" ?

[Patrick R. <P.R...@ma...>]

Thanks for the reply, but I’m actually just wanting to protect a small portion of the site.  Almost all of the site can and should run without restrictions, except for some PHP scripts that (if hit repeatedly) cause performance issues.

When I looked into mod_evasive, you didn’t seem to be able to nominate a location or location(s) for which you could only apply limits to.

In other words, I want to wrap it into a Location – something along the lines of the following:

<LocationMatch "^/some/URL/that/needs/rate/limiting.php.*">
  SecRule REQUEST_HEADERS:X-Forwarded-For "@unconditionalMatch" "phase:2,initcol:ip=%{MATCHED_VAR},pass,nolog,id:100"
  SecRule IP:ACCESS_COUNT "@gt XX" "phase:2,deny,status:429,setenv:RATELIMITED,skip:1,nolog,id:102"
…
</LocationMatch>

With that in mind – does anyone know how the “@gt XX” “burst rate” for mod_security is calculated ?  In particular, how long before the burst counter gets reset etc ?

Thanks,

Patrick

From: Brent Clark <bre...@gm...>
Date: Friday, 11 March 2022 at 8:42 PM
To: mod...@li... <mod...@li...>
Subject: Re: [mod-security-users] Rate Limiting Apache: Units associated with "burst_rate_limit" ?

Hiya

If you want to look to some type of rate limiting.?
Rather look to Apaches mod_evasive module.

Mod_evasive monitors incoming requests for suspicious activity from one IP, such as:

    Several requests for the same page in one second.
    More than 50 simultaneous requests per second.
    Requests made while the IP is temporarily blacklisted.

The module sends a 403 error if any of these things happen.

HTH
Regards
Brent

On 2022/03/11 05:59, Patrick Rynhart wrote:
Hi all,

I’m wanting to introduce IP based rate limiting protection to our Apache config, and am basing my config off this Gist:

https://gist.github.com/josnidhin/91d1ea9cd71fde386c27a9228476834e<https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.github.com%2Fjosnidhin%2F91d1ea9cd71fde386c27a9228476834e&data=04%7C01%7CP.Rynhart%40massey.ac.nz%7C0fac6166573140a450ab08da0332b551%7C388728e1bbd0437898dcf8682e644300%7C1%7C0%7C637825813584279072%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lu%2BO39925FXybkSHLv%2F2HTFdPpxrJwjJAxaQJMJI1nk%3D&reserved=0>

I’m wanting to understand the line:

SecRule IP:ACCESS_COUNT "@gt {{ burst_rate_limit }}" "phase:2,pause:300,deny,status:503,setenv:RATELIMITED,skip:1,nolog,id:102"

In particular what are the units associated with burst_rate_limit ?  What does it mean if you set this variable to a value like 100 ?  (Does this correspond to a rate of 100 per minute ?  If not, what does it correspond to ?)

Thanks,

Patrick






_______________________________________________

mod-security-users mailing list

mod...@li...<mailto:mod...@li...>

https://lists.sourceforge.net/lists/listinfo/mod-security-users<https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fmod-security-users&data=04%7C01%7CP.Rynhart%40massey.ac.nz%7C0fac6166573140a450ab08da0332b551%7C388728e1bbd0437898dcf8682e644300%7C1%7C0%7C637825813584279072%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=sNHqrh149u%2B7FCSs7h9F6BW59GAHoe%2F%2BNuIBQ5bEDqw%3D&reserved=0>

Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:

http://www.modsecurity.org/projects/commercial/rules/<https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.modsecurity.org%2Fprojects%2Fcommercial%2Frules%2F&data=04%7C01%7CP.Rynhart%40massey.ac.nz%7C0fac6166573140a450ab08da0332b551%7C388728e1bbd0437898dcf8682e644300%7C1%7C0%7C637825813584279072%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Iq6NueQhU%2Bc9elqjLZ5XmgwS3ea5qAt%2BELslo4yE4UQ%3D&reserved=0>

http://www.modsecurity.org/projects/commercial/support/<https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.modsecurity.org%2Fprojects%2Fcommercial%2Fsupport%2F&data=04%7C01%7CP.Rynhart%40massey.ac.nz%7C0fac6166573140a450ab08da0332b551%7C388728e1bbd0437898dcf8682e644300%7C1%7C0%7C637825813584279072%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1f1yh%2FWlALfLfRMVHsSdJF1GBBx2TE7g0TwaLXMmoaY%3D&reserved=0>

Re: [mod-security-users] Rate Limiting Apache: Units associated with "burst_rate_limit" ?

[Brent C. <bre...@gm...>]

Hiya

If you want to look to some type of rate limiting.?
Rather look to Apaches mod_evasive module.

Mod_evasive monitors incoming requests for suspicious activity from one 
IP, such as:

     Several requests for the same page in one second.
     More than 50 simultaneous requests per second.
     Requests made while the IP is temporarily blacklisted.

The module sends a 403 error if any of these things happen.

HTH
Regards
Brent

On 2022/03/11 05:59, Patrick Rynhart wrote:
>
> Hi all,
>
> I’m wanting to introduce IP based rate limiting protection to our 
> Apache config, and am basing my config off this Gist:
>
> https://gist.github.com/josnidhin/91d1ea9cd71fde386c27a9228476834e
>
> I’m wanting to understand the line:
>
> SecRule IP:ACCESS_COUNT "@gt {{ burst_rate_limit }}" 
> "phase:2,pause:300,deny,status:503,setenv:RATELIMITED,skip:1,nolog,id:102"
>
> In particular what are the units associated with burst_rate_limit ?  
> What does it mean if you set this variable to a value like 100 ?  
> (Does this correspond to a rate of 100 per minute ?  If not, what does 
> it correspond to ?)
>
> Thanks,
>
> Patrick
>
>
>
> _______________________________________________
> 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/

[mod-security-users] Rate Limiting Apache: Units associated with "burst_rate_limit" ?

[Patrick R. <P.R...@ma...>]

Hi all,

I’m wanting to introduce IP based rate limiting protection to our Apache config, and am basing my config off this Gist:

https://gist.github.com/josnidhin/91d1ea9cd71fde386c27a9228476834e

I’m wanting to understand the line:

SecRule IP:ACCESS_COUNT "@gt {{ burst_rate_limit }}" "phase:2,pause:300,deny,status:503,setenv:RATELIMITED,skip:1,nolog,id:102"

In particular what are the units associated with burst_rate_limit ?  What does it mean if you set this variable to a value like 100 ?  (Does this correspond to a rate of 100 per minute ?  If not, what does it correspond to ?)

Thanks,

Patrick

Re: [mod-security-users] How can I run a Shell Command when Rate Limiting is activated ?

[<az...@po...>]

Hi Patrick,

there are multiple methods how you can run external command using Modsecurity:
  -  
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-%28v2.x%29#inspectFile (read the docs about security  
warning!)
  -  
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-%28v2.x%29#SecRuleScript


Anyway, i would not allow my web server to run external commands only  
because of alerting. There are other, maybe better and definitely much  
safer ways - for example, replace action 'nolog' with action 'log' in  
your rule with ID 102. Then process web server logs using, for  
example, fail2ban.

azurit




Citát Patrick Rynhart <P.R...@ma...>:

> Hi all,
>
> I’ve got the following snippet from our Apache configuration which  
> successfully provides rate limiting protection against a PHP resource.
> How can I run a shell command when this rule kicks in so that we are  
> alerted that rate limiting protection has been activated (preferably  
> without it being run hundreds of times) ?
>
> Scenario is that I would like to know when this rule kicks in –  
> we’ve got a busy production environment and would refer a script to  
> be run (rather than trying to process the HTTPD logs after the fact).
>
> <LocationMatch "^/course/view.php.*">
>   SecRule REQUEST_HEADERS:X-Forwarded-For "@unconditionalMatch"  
> "phase:2,initcol:ip=%{MATCHED_VAR},pass,nolog,id:100"
>   SecRule IP:ACCESS_COUNT "@gt 1"  
> "phase:2,pause:300,deny,status:429,setenv:RATELIMITED,skip:1,nolog,id:102"
>   SecAction "phase:2,setvar:ip.access_count=+1,pass,nolog,id:103"
>   SecAction  
> "phase:5,ctl:auditEngine=On,deprecatevar:ip.access_count=1/1,pass,nolog,id:104"
>   Header always set Retry-After "10" env=RATELIMITED
> </LocationMatch>
> ErrorDocument 429 "Rate Limited"
>
> With Thanks,
>
> Patrick Rynhart

[mod-security-users] How can I run a Shell Command when Rate Limiting is activated ?

[Patrick R. <P.R...@ma...>]

Hi all,

I’ve got the following snippet from our Apache configuration which successfully provides rate limiting protection against a PHP resource.
How can I run a shell command when this rule kicks in so that we are alerted that rate limiting protection has been activated (preferably without it being run hundreds of times) ?

Scenario is that I would like to know when this rule kicks in – we’ve got a busy production environment and would refer a script to be run (rather than trying to process the HTTPD logs after the fact).

<LocationMatch "^/course/view.php.*">
  SecRule REQUEST_HEADERS:X-Forwarded-For "@unconditionalMatch" "phase:2,initcol:ip=%{MATCHED_VAR},pass,nolog,id:100"
  SecRule IP:ACCESS_COUNT "@gt 1" "phase:2,pause:300,deny,status:429,setenv:RATELIMITED,skip:1,nolog,id:102"
  SecAction "phase:2,setvar:ip.access_count=+1,pass,nolog,id:103"
  SecAction "phase:5,ctl:auditEngine=On,deprecatevar:ip.access_count=1/1,pass,nolog,id:104"
  Header always set Retry-After "10" env=RATELIMITED
</LocationMatch>
ErrorDocument 429 "Rate Limited"

With Thanks,

Patrick Rynhart

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

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

Excellent, thanks for your help.

---

From: Andrew Howe <and...@lo...>
Sent: 21 February 2022 14:03
To: mod...@li...
Subject: Re: [mod-security-users] Retry-After header not being set?

Hi Jamie,

> 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?

You _could_ try moving your deprecatevar rule to phase 2 so that it's
executed before your deny rule, but that may well introduce unintended
side effects I haven't considered... (The point of having deprecatevar
execute in phase 5, as I understand it, is so that it takes place
unconditionally: putting it elsewhere could result in it being skipped or
removed or for something unforeseen to happen, breaking the whole
construct.)

You might have more luck decoupling the detection and blocking logic by
setting an "is_blocked" flag, checking for that, and then playing with
variable expiry times. You could even zero-out your counting/detection
variable on a successful block, so that it's back to 0 again once a
temporary block is over. There are some examples like this in the
ModSecurity Handbook, and I've seen a few tutorials online doing similar
things.

I'd still recommend steering clear of doing this in ModSecurity, though :)

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/

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

[Andrew H. <and...@lo...>]

Hi Jamie,

> 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?

You _could_ try moving your deprecatevar rule to phase 2 so that it's
executed before your deny rule, but that may well introduce unintended
side effects I haven't considered... (The point of having deprecatevar
execute in phase 5, as I understand it, is so that it takes place
unconditionally: putting it elsewhere could result in it being skipped
or removed or for something unforeseen to happen, breaking the whole
construct.)

You might have more luck decoupling the detection and blocking logic
by setting an "is_blocked" flag, checking for that, and then playing
with variable expiry times. You could even zero-out your
counting/detection variable on a successful block, so that it's back
to 0 again once a temporary block is over. There are some examples
like this in the ModSecurity Handbook, and I've seen a few tutorials
online doing similar things.

I'd still recommend steering clear of doing this in ModSecurity, though :)

Thanks,
Andrew

--

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

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

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

You can't achieve simple URL specific rate limiting with iptables. I am
not trying to thwart DoS attacks - you do not understand my use case.

-----Original Message-----
From: Reindl Harald <h.r...@th...>
Sent: 18 February 2022 15:14
To: mod...@li...
Subject: Re: [mod-security-users] Retry-After header not being set?



Am 18.02.22 um 10:27 schrieb Jamie Burchell:
> Hi Reindl
>
>> your expectation is simply wrong
>> when you use a PHP script for error-pages the default response is 200
> because you override the error
>
> This is not true. I have the ErrorDocument for a 429 set to a very
> basic PHP page which outputs the unique request ID for diagnostic
> purposes and the response code is 429, not 200. The PHP script does
> not do anything else.
>
> Further, headers I am setting in Apache are in that same response:
>
> Strict-Transport-Security: max-age=63072000; includeSubDomains;
> preload
> X-UA-Compatible: IE=edge
> X-Content-Type-Options: nosniff
> X-XSS-Protection: 1; mode=block
> ...
>
> If I add Header always set Retry-After "10" in the virtual host block,
> that header is in the response for all requests (including those
> handled by PHP) and for 200 and 429 responses.
>
> The part that seems not to work is the condition based on the
> environment variable in combination with processing the PHP file

anyways, ratelimits in the webserver are pretty pointless iptables
xt_recent with DROP is the solution

especially with small bursts because it don't break clients which hit the
limit by accident - the TCP layer can't decide between drop and packet
loss

so it's a short "hang" for a client behind a shared IP instead of random
errors and load is completly taken away from the webserver

have fun with apllication prcoessed ratelimts under real load where you
need them most

ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0
      ctstate RELATED,ESTABLISHED
DROP   all  --  *      *       0.0.0.0/0            0.0.0.0/0
  recent: UPDATE seconds: 2 reap hit_count: 150 name: all side: source
mask: 255.255.255.255
all  --  *      *       0.0.0.0/0            0.0.0.0/0
recent: SET name: all side: source mask: 255.255.255.255


_______________________________________________
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/

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

[Reindl H. <h.r...@th...>]

Am 18.02.22 um 10:27 schrieb Jamie Burchell:
> Hi Reindl
> 
>> your expectation is simply wrong
>> when you use a PHP script for error-pages the default response is 200
> because you override the error
> 
> This is not true. I have the ErrorDocument for a 429 set to a very basic
> PHP page which outputs the unique request ID for diagnostic purposes and
> the response code is 429, not 200. The PHP script does not do anything
> else.
> 
> Further, headers I am setting in Apache are in that same response:
> 
> Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
> X-UA-Compatible: IE=edge
> X-Content-Type-Options: nosniff
> X-XSS-Protection: 1; mode=block
> ...
> 
> If I add Header always set Retry-After "10" in the virtual host block,
> that header is in the response for all requests (including those handled
> by PHP) and for 200 and 429 responses.
> 
> The part that seems not to work is the condition based on the environment
> variable in combination with processing the PHP file

anyways, ratelimits in the webserver are pretty pointless
iptables xt_recent with DROP is the solution

especially with small bursts because it don't break clients which hit 
the limit by accident - the TCP layer can't decide between drop and 
packet loss

so it's a short "hang" for a client behind a shared IP instead of random 
errors and load is completly taken away from the webserver

have fun with apllication prcoessed ratelimts under real load where you 
need them most

ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0 
      ctstate RELATED,ESTABLISHED
DROP   all  --  *      *       0.0.0.0/0            0.0.0.0/0 
  recent: UPDATE seconds: 2 reap hit_count: 150 name: all side: source 
mask: 255.255.255.255
all  --  *      *       0.0.0.0/0            0.0.0.0/0 
recent: SET name: all side: source mask: 255.255.255.255

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

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

Hi Reindl

> your expectation is simply wrong
> when you use a PHP script for error-pages the default response is 200
because you override the error

This is not true. I have the ErrorDocument for a 429 set to a very basic
PHP page which outputs the unique request ID for diagnostic purposes and
the response code is 429, not 200. The PHP script does not do anything
else.

Further, headers I am setting in Apache are in that same response:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
X-UA-Compatible: IE=edge
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
...

If I add Header always set Retry-After "10" in the virtual host block,
that header is in the response for all requests (including those handled
by PHP) and for 200 and 429 responses.

The part that seems not to work is the condition based on the environment
variable in combination with processing the PHP file.

Jamie

-----Original Message-----
From: Reindl Harald <h.r...@th...>
Sent: 17 February 2022 23:07
To: mod...@li...
Subject: Re: [mod-security-users] Retry-After header not being set?



Am 18.02.22 um 00:02 schrieb Jamie Burchell:
> No, I'm not sending the headers from there, but I could

you must

> I expected the
> headers set by Apache to work though, since the HSTS header works.

your expectation is simply wrong

when you use a PHP script for error-pages the default response is 200
because you override the error

rule of thumbs: don't use custom error pages (with dynamic scripts) for
anything else but 403/404

and for rate-limits (which shouldn't be handeled in the application layer
to begin with) it's pretty nonsense to add the burden of a dynamic script

> -----Original Message-----
> From: Reindl Harald <h.r...@th...>
> Sent: 17 February 2022 21:26
> To: mod...@li...
> Subject: Re: [mod-security-users] Retry-After header not being set?
>
>
>
> Am 17.02.22 um 21:35 schrieb Jamie Burchell:
>> 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
>
> does your "error.php" send the correct header?


_______________________________________________
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/

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

[Reindl H. <h.r...@th...>]

Am 18.02.22 um 00:02 schrieb Jamie Burchell:
> No, I'm not sending the headers from there, but I could

you must

> I expected the
> headers set by Apache to work though, since the HSTS header works.

your expectation is simply wrong

when you use a PHP script for error-pages the default response is 200 
because you override the error

rule of thumbs: don't use custom error pages (with dynamic scripts) for 
anything else but 403/404

and for rate-limits (which shouldn't be handeled in the application 
layer to begin with) it's pretty nonsense to add the burden of a dynamic 
script

> -----Original Message-----
> From: Reindl Harald <h.r...@th...>
> Sent: 17 February 2022 21:26
> To: mod...@li...
> Subject: Re: [mod-security-users] Retry-After header not being set?
> 
> 
> 
> Am 17.02.22 um 21:35 schrieb Jamie Burchell:
>> 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
> 
> does your "error.php" send the correct header?

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

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

I tried setting all the phases to 2, but that didn't work. Now after the
initial 429 I get a 200 then a 429 ... forever more.

Yes, I really don't understand mod_security ☹

-----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/

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

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

No, I'm not sending the headers from there, but I could. I expected the
headers set by Apache to work though, since the HSTS header works.

-----Original Message-----
From: Reindl Harald <h.r...@th...>
Sent: 17 February 2022 21:26
To: mod...@li...
Subject: Re: [mod-security-users] Retry-After header not being set?



Am 17.02.22 um 21:35 schrieb Jamie Burchell:
> 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

does your "error.php" send the correct header?


_______________________________________________
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/

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

[Reindl H. <h.r...@th...>]

Am 17.02.22 um 21:35 schrieb Jamie Burchell:
> 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

does your "error.php" send the correct header?

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/

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

[Andrew H. <and...@lo...>]

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

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

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

I haven’t. I’m using mod_security already for CRS stuff, so I was hoping I
could just add basic limiting for a couple of URLs with it although I
appreciate it might not be the best tool for the job. As I say, it works,
but without the header being set. Maybe that’s because my error document is
a PHP script and it’s getting removed somehow.



*From:* Michael Woods via mod-security-users <
mod...@li...>
*Sent:* 17 February 2022 09:20
*To:* mod...@li...
*Cc:* Michael Woods <sco...@ya...>
*Subject:* Re: [mod-security-users] Retry-After header not being set?



Have you looked at mod_qos, this is a third part module which needs to be
built and installed into Apache. We are having a lot of success with it in
rate limiting incoming requests.



Email:  sco...@ya...





On Wednesday, 16 February 2022, 19:13:52 GMT, Jamie Burchell <ja...@ib...>
wrote:





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.


-----Original Message-----
From: Jamie Burchell <ja...@ib...>
Sent: 16 February 2022 18:45
To: mod...@li...
Subject: RE: [mod-security-users] Retry-After header not being set?

Hi Andrew

mod_headers is there; I'm using the same syntax to set a HSTS expiry header
in the virtualhost block. That header is present, but not the Retry-After.

Thanks
Jamie

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

Hi Jamie,

That works for me:

> GET /foo HTTP/1.1
> Host: example.com
> User-Agent: curl/7.81.0
> Accept: */*
>
* Mark bundle as not supporting multiuse < HTTP/1.1 429 Too Many Requests <
Date: Wed, 16 Feb 2022 16:52:32 GMT < Server: Apache < Retry-After: 10 <
Content-Length: 227 < Content-Type: text/html; charset=iso-8859-1

Is your Apache config loading mod_headers? E.g.:
    LoadModule headers_module lib/httpd/mod_headers.so

It's not a "core" Apache module, so it may not be compiled by default.

For what it's worth, in my opinion, ModSecurity is really, really not a good
place to do any kind of rate limiting. Especially on Apache:
the underlying persistent collection mechanism is ridiculously flakey and
will break your heart (and eat your RAM). The implementation of
'deprecatevar' is particularly "interesting". (Can you tell I've been burnt
by all this before? :)  )

I've had much more success putting HAProxy in front of Apache and using its
stick tables to take care of rate limiting. I've also heard good things
about using the Apache mod_qos module, although I've never tried it myself.
You can also do some clever things using iptables and tc.

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/


_______________________________________________
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/

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

[Michael W. <sco...@ya...>]

Have you looked at mod_qos, this is a third part module which needs to be built and installed into Apache. We are having a lot of success with it in rate limiting incoming requests.

Email:  sco...@ya... 

    On Wednesday, 16 February 2022, 19:13:52 GMT, Jamie Burchell <ja...@ib...> wrote:  
 
 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.

-----Original Message-----
From: Jamie Burchell <ja...@ib...>
Sent: 16 February 2022 18:45
To: mod...@li...
Subject: RE: [mod-security-users] Retry-After header not being set?

Hi Andrew

mod_headers is there; I'm using the same syntax to set a HSTS expiry header
in the virtualhost block. That header is present, but not the Retry-After.

Thanks
Jamie

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

Hi Jamie,

That works for me:

> GET /foo HTTP/1.1
> Host: example.com
> User-Agent: curl/7.81.0
> Accept: */*
>
* Mark bundle as not supporting multiuse < HTTP/1.1 429 Too Many Requests <
Date: Wed, 16 Feb 2022 16:52:32 GMT < Server: Apache < Retry-After: 10 <
Content-Length: 227 < Content-Type: text/html; charset=iso-8859-1

Is your Apache config loading mod_headers? E.g.:
    LoadModule headers_module lib/httpd/mod_headers.so

It's not a "core" Apache module, so it may not be compiled by default.

For what it's worth, in my opinion, ModSecurity is really, really not a good
place to do any kind of rate limiting. Especially on Apache:
the underlying persistent collection mechanism is ridiculously flakey and
will break your heart (and eat your RAM). The implementation of
'deprecatevar' is particularly "interesting". (Can you tell I've been burnt
by all this before? :)  )

I've had much more success putting HAProxy in front of Apache and using its
stick tables to take care of rate limiting. I've also heard good things
about using the Apache mod_qos module, although I've never tried it myself.
You can also do some clever things using iptables and tc.

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/


_______________________________________________
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/
  

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

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

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.

-----Original Message-----
From: Jamie Burchell <ja...@ib...>
Sent: 16 February 2022 18:45
To: mod...@li...
Subject: RE: [mod-security-users] Retry-After header not being set?

Hi Andrew

mod_headers is there; I'm using the same syntax to set a HSTS expiry header
in the virtualhost block. That header is present, but not the Retry-After.

Thanks
Jamie

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

Hi Jamie,

That works for me:

> GET /foo HTTP/1.1
> Host: example.com
> User-Agent: curl/7.81.0
> Accept: */*
>
* Mark bundle as not supporting multiuse < HTTP/1.1 429 Too Many Requests <
Date: Wed, 16 Feb 2022 16:52:32 GMT < Server: Apache < Retry-After: 10 <
Content-Length: 227 < Content-Type: text/html; charset=iso-8859-1

Is your Apache config loading mod_headers? E.g.:
    LoadModule headers_module lib/httpd/mod_headers.so

It's not a "core" Apache module, so it may not be compiled by default.

For what it's worth, in my opinion, ModSecurity is really, really not a good
place to do any kind of rate limiting. Especially on Apache:
the underlying persistent collection mechanism is ridiculously flakey and
will break your heart (and eat your RAM). The implementation of
'deprecatevar' is particularly "interesting". (Can you tell I've been burnt
by all this before? :)  )

I've had much more success putting HAProxy in front of Apache and using its
stick tables to take care of rate limiting. I've also heard good things
about using the Apache mod_qos module, although I've never tried it myself.
You can also do some clever things using iptables and tc.

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/

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

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

Hi Andrew

mod_headers is there; I'm using the same syntax to set a HSTS expiry
header in the virtualhost block. That header is present, but not the
Retry-After.

Thanks
Jamie

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

Hi Jamie,

That works for me:

> GET /foo HTTP/1.1
> Host: example.com
> User-Agent: curl/7.81.0
> Accept: */*
>
* Mark bundle as not supporting multiuse < HTTP/1.1 429 Too Many Requests
< Date: Wed, 16 Feb 2022 16:52:32 GMT < Server: Apache < Retry-After: 10 <
Content-Length: 227 < Content-Type: text/html; charset=iso-8859-1

Is your Apache config loading mod_headers? E.g.:
    LoadModule headers_module lib/httpd/mod_headers.so

It's not a "core" Apache module, so it may not be compiled by default.

For what it's worth, in my opinion, ModSecurity is really, really not a
good place to do any kind of rate limiting. Especially on Apache:
the underlying persistent collection mechanism is ridiculously flakey and
will break your heart (and eat your RAM). The implementation of
'deprecatevar' is particularly "interesting". (Can you tell I've been
burnt by all this before? :)  )

I've had much more success putting HAProxy in front of Apache and using
its stick tables to take care of rate limiting. I've also heard good
things about using the Apache mod_qos module, although I've never tried it
myself. You can also do some clever things using iptables and tc.

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/