Thanks, I have been looking at this too long and totally missed that it was a site and not page trigger. Apologies 
mod_shield seems to be powerful but absolutely requires tuning per site/application, especially for complex environments with shared IPs and legitimate high-frequency activity.
For example, I have several clients on a server running PrestaShop and WordPress. The PrestaShop site is also used as a POS, with 6-7 people working in the backend simultaneously, all sharing the same public IP.
I am concerned about the significant adjustments required to make this beneficial in the long run.
I also donāt want to spend time creating overrides for each client. Another concern is that if traffic comes from remote locations with high latency or slow connections, this could cause additional issues.
However, I do think improvements are possible. If a āmonitoring/learningā mode could be implemented, it would be easier to see how traffic is actually being detected. Would it be possible to create a GUI that makes logging and monitoring easier to manage? Plus some basic features like GEO blocking or exception if country or ASN is = xxx then higher limits applies. (vice versa)
Last but not least, if a Captcha JS challenge could be added when rate limits are reached, it would provide a much better experience than a hard block.
Blocks work longitudinally now. Ideally, this should provide the same baseline protection while improving long-term tracking. There should no interruption to present usage.
Ibid.
This is the purpose behind the RFC: to establish demographics.
That process is fallible. IPs constantly change hands and ranges get caught up in friendly fire. Thereās an example in the docs that covers blocking China. Youāre trusting a third-party to provide accurate ASN data.
For now, itās well beyond scope. This is a lightweight counter designed to preserve CPU cycles - counteracting the many shortcomings in Cloudflare. I redesigned this because my servers were pegging out CPU usage (> 80%) 24x7 as WordPress sites served bogus 404 requests.
Itās an improvement over the previous but far from perfect. mod_shield also solves some key gaps in Cloudflareās intended protection.
Iāve added support to merge global settings with <Files ā¦> or <Location ā¦> now, so additional declarations are unnecessary.
dnf --enablerepo=apnscp-testing update mod_shield
New release reports points accumulated per second in block message, both in syslog + /tmp/dos-IP file. Thisāll give a better indication of how quickly these scores are met. First is a wp-login.php brute-force, second + third are random URI probes at different rates.
Jun 20 10:59:36 falcon mod_shield[2139326]: Blacklisting address 178.128.216.137: possible DoS attack. (page, limit 5 [1.12 pps] on x.com).
Jun 20 11:01:41 falcon mod_shield[2139326]: Blacklisting address 34.23.104.17: possible DoS attack. (site, limit 500 [3944.49 pps] on y.net).
Jun 20 11:04:49 falcon mod_shield[2125717]: Blacklisting address 27.124.4.23: possible DoS attack. (site, limit 500 [23.42 pps] on z.com).
To update
dnf --enablerepo=apnscp-testing -y update mod_shield
Provided nothing major comes up, this will become the first public release.
New release, 202506241806.
- Added support for dispatcher redirections that report non-2xx requests, e.g. GET /foo flows to /index.php (200 OK), which reports a custom 404 error. That 404 is now scored accordingly.
- Scoring curves are now located in /etc/httpd/conf.d/shield.curves. You may edit conf/shield.conf directly.
- Moved existing blocks to before .htaccess reads. On a 2x Ryzen 7 5700X VM, throughput increased 44% from 28.4k rps to 40.9k rps. Blocks incur very little overhead now, even in Cloudflare passthrough scenarios.
Scope implementation + docs are still left.
1 Like
This is still proving to be problematic and I donāt fully understand scoring or how any of this works to really properly troubleshoot. I have users getting 429 errors with Wordpress, Forums and more and all under typical usage. With some sites loading hundreds of images and scripts per page load, a 500 Site limit over 5 seconds may be too aggressive.
This is a neat feature and I applaud the effort, but I donāt think itās going to work well in a shared hosting environment with hundreds of accounts and 5x as many domains on a single server with shared configuration. Customers donāt want to find out that their visitors canāt view their website and they have no recourse or even a way to see whoās been blocked and why.
Iām going to be removing this from my test servers or dropping Site and Page limits to 500 / 1 second.
Send me the access_log from one of these sites that triggered it organically and all /tmp/dos-* files on the server. Iād like to see both.
Hereās data from one server. the last day with ASN. Growth Freq is an item of interest, itās how fast the target threshold was reached.
Contrasted with the most egregious offendersā¦
Growth freq is the last value on the second line, i.e.
1341730
site 1 500 x.com 1751286950 107.74
/media/wp-includes/wlwmanifest.xml
ā107.74ā in the above example.
Counters are tracked by HTTP hostnames in the request, so domain count doesnāt matter. Weāre attempting to trap irregular usage patterns.
Iād be careful with this as it doesnāt reflect original mod_evasive settings. mod_shield behaves similar to mod_evasive in how it operates - count x hits over y period. mod_shield adds new scoring dimensions.
To make mod_shield behave identical to mod_evasive add this to httpd-custom.conf:
# Remove enhanced scoring features
DOSPageDeadline off
DOSSiteStatusPenalty off
# Disable block ramp-up
DOSBlockingPeriod 10
# Original settings
DOSPageCount 20
DOSSiteCount 300
DOSPageInterval 2
DOSSiteInterval 4
mod_shield is now the HTTP DoS filter on edge.
- Dropped both site + page interval to 75, threshold for site/page 500/180 respectively
- A static file bypass is present, so resource-heavy sites wonāt trigger a 429 response while loading css/js/jpg/png/webp. It works off match, so no path resolution is performed. If it flows to a CPU-heavy dispatcher, like index.php, it remains unscored
- To disable, use
cpcmd scope:set apache.shield-static-bypass false - Iād like to move this into the module code directly down the road to calculate off the final, resolved URI after mod_rewrite processes it
- To disable, use
- apache:shield Scopes are available and mirror apache:evasive Scopes
- Increased Rampart detection threshold from 1 event in 12 hours to 2 before itās blocked in server firewall. Firewall block time is reduced to 3 minutes
- All āf2b_evasive_Xā overrides are migrated
Opinon piece: Iām going to have to agree with Troy here. I havenāt the time to dig into and analyse all the causes of frequent blocks being issued but Iāve got a wide range of platforms running sites, and Wordpress and MODX are those which are causing me the most grief. Primarily when doing administrative things - these platforms which are hammering a load of traffic through a handful of connectors/controllers. Itās actually impossible to do anything in the back end of a MODX site with the default settings.
I threw up a /status page but find myself blocked from viewing the output of that if something was triggered by me! Iāll need to set aside some time to see how I can customise the values to suit what Iām seeing but again, as Troy implies, resorting to spreadsheets and analysing stats that you donāt fully understand is time youād rather not have to spend. Itās also unmanagable for shared hosting servers really, I donāt have time to sit through and analyse behaviours of sites, CMSes and user behaviour. Backing off values in the short term is of course an option but thatās little more than moving the screaming child further down the hallway so you can hear yourself think, rather than finding out whatās wrong with her.
Iām absolutely all for progress and enhancement of what is truly an amazing platform. Ironically, the time it saves me because of hands-off, self-healing, self-managing is why itās so appealing. Sadly, mod_shield is leaving a bit of a dirty stain on an exemplary record so far 
Edit: Looks like this might primarily being triggered by 404s, which Iām looking into. This could well be a thing that only Iām seeing because of the (questionable) quality of some of the sites sitting on it. I suppose the argument still holds though - some better, muppet-friendly reporting would be a great addition to help with quick diagnosis.
Send me the access_log from one of these sites that triggered it organically and all /tmp/dos-* files on the server. Iād like to see both.
Thanks Matt - resolved for now, I think.
This is a snippet from /tmp/dos:
2899449
site 3 500 29erorg.qdxs.co.uk 1752485184 55.15
/assets/components/ace/modx.texteditor.js
That .js file was missing so I can only assume this was contributary in some significant way. I donāt have time to dig out the apache logs but if I have issues in the future, Iāll spend time assembling the associated logs.
Thanks for the offer of help for now. My request for better reporting still remains!
Cheers
W.
dnf update --enablerepo=apnscp-testing mod_shield
Static file bypass for .js was added in mod_shield-2.999-202507061626. Youāre running an older version which doesnāt have this feature.
To read it
From the above example, the IP address was scoring 55 points per second to reach the threshold of 500, so this happened over 9 seconds of interaction.
A request made to /assets/components/ace/modx.texteditor.js didnāt exist. It was scored 50 points that tipped it over the threshold of 500; this threshold resets every 75 seconds. If a page were refreshed 10 times in 9 seconds, then this behavior would be sufficient to trigger the threshold resulting in the block.
Contributory requests can be examined by looking at var/log/httpd/access_log within the siteās VFS to determine what other anomalous status codes added. Presently the following status codes are scored in addition to the base score of 1. ā-1ā effectively cancels out the score.
| Status | Score |
|---|---|
| 301 Moved Permanently | 25 |
| 302 Found | 25 |
| 304 Not Modified | -1 |
| 404 Not Found | 50 |
Further, you may whitelist your IP range to prevent future blocks by mod_shield.
# Whitelist 1.2.3.1 to 1.2.3.254
cpcmd scope:set apache.shield-whitelist 1.2.3.1/24
This combined with the status handler is intended to help you make informed decisions while protecting server load from malicious actors.
I target around 400 - 600 sites per VM with a few VMs partitioned from antiquated Westmere Xeons. If I can ensure sites meet expectations on that old ass hardware, then for folks running newer EPYC platforms - youāll benefit very well from this feature. Benefit not just in improved capacity but lower load averages and improved TTFB in spite of what is a pervasive problem.