Abuse Guard configuration reference

Almost every tuning knob the Abuse Guard reads lives in scan_nginx.sh as a built-in default; then /root/.barracuda.cnf is sourced and replaces any value it sets (the override is a plain assignment, not a merge). The one exception is the crawler-fleet family, whose defaults live in its own job, nginx_fleet.sh, and are read the same way.

This page is the authoritative reference for those variables: the real default, what it controls, and how it interacts with the rest of the scoring engine.

Where defaults come from. Two layers set these values. scan_nginx.sh hard-codes a built-in default for each variable so the script is correct on a box that has never been touched.

Separately, autoupboa seeds a subset into /root/.barracuda.cnf (the _DEFAULT_NGINX_DOS_* block) so they appear as editable lines: _NGINX_DOS_LINES, _NGINX_DOS_LIMIT, _NGINX_DOS_MODE, _NGINX_DOS_DIV_INC_NR, _NGINX_DOS_INC_MIN, _NGINX_DOS_LOG, _NGINX_DOS_IGNORE, _NGINX_DOS_STOP. autoupboa also normalises _NGINX_DOS_LIMIT back to 399 on each pass.

Those eight classics are the entire seeded set: the DDoS, path-flood, ignore-paths, 444-weight and php-probe knobs are not seeded, and neither is any knob of the newer detectors (_NGINX_HTTP10_AUTH_*, _NGINX_UA_BURST_*, _NGINX_GUARD404_*, _NGINX_I18N_FLOOD_*, _NGINX_FPM_*, _NGINX_FLEET_*) — they all take their script's built-in defaults unless you add them to /root/.barracuda.cnf yourself.

Where the seeded value differs from the script default, the seeded one wins — except _NGINX_DOS_LOG, which is seed-only: an existing uncommented line is never overwritten by a retune, because it is the landing key of the converted .debug.monitor.log.cnf marker and a set value must survive fleet retunes. The other _NGINX_DOS_* keys are reset to their defaults by a retune (with _NGINX_DOS_LIMIT re-normalised to 399).

Override semantics

built-in default assigned in scan_nginx.sh
        ↓
source /root/.barracuda.cnf
        ↓
any _NGINX_* line there REPLACES the default outright

• A scalar override (_NGINX_DOS_LIMIT=199) simply wins.
• A list override (_NGINX_DOS_IGNORE_PATHS, _NGINX_PATH_FLOOD_WATCH) replaces the whole list — it is not appended to. Include everything the box needs; an empty value disables that feature.
• A few weights (_NGINX_DOS_444_WEIGHT, _NGINX_PHP_PROBE_WEIGHT) are not in the static default block. They are computed after the config is sourced — _NGINX_DOS_LIMIT / 3 — but only if the operator did not set a numeric value. This deliberately preserves an explicit =0 (disable) or custom value from /root/.barracuda.cnf and avoids a stale default when the config later lowers _NGINX_DOS_LIMIT.

Window and per-IP scoring

The /user/login brute-force increment uses _INC_S_NR = _NGINX_DOS_LIMIT / 80 (≈ 5, floored at _NGINX_DOS_INC_MIN). The divisor _NGINX_DOS_DIV_INC_S_NR is derived as _NGINX_DOS_DIV_INC_NR × 2 and is not a separately tunable knob.

_NGINX_DOS_STOP — SQLi / blind-timing injection regex

_NGINX_DOS_STOP="WAITFOR.DELAY|DECLARE.*@x|/\*\*/|%27.*%29.*%3B|0x[0-9a-f]{6}"

This is not a generic flood-rate knob and not a "+5 counter" increment. It is a regular-expression set of SQL-injection / blind-timing fingerprints:

• WAITFOR DELAY
• a DECLARE @x payload
• inline /**/ comment obfuscation
• the %27…%29…%3B URL-encoded ') ; close
• a long hex literal

When a log line matches, _process_ip adds the full _NGINX_DOS_LIMIT to that IP's counter in a single hit, saturating its score to the block threshold at once. A block still also requires the IP to clear the _NGINX_MIN_BLOCK_REQS raw-request floor (default 3), so a lone probe from an otherwise idle IP is caught in aggregate, not instantly.

The regex is matched (unanchored) against the whole log line, so an injection attempt anywhere in the request trips it.

A +5 increment is sometimes mis-attributed to _NGINX_DOS_STOP. That is wrong on both counts: the +5 increments belong to the mode-1 /user, /node/add and /search patterns, while _NGINX_DOS_STOP adds the full _NGINX_DOS_LIMIT, not +5.

The default is also seeded into /root/.barracuda.cnf by autoupboa (_DEFAULT_NGINX_DOS_STOP). An empty value disables injection-keyword scoring entirely.

DDoS — shared-UA aggregate (detector 2)

See Detector 2 for the mechanism.

The defaults are sized for high-traffic boxes: within the ~5 s scan window the single most common real mobile-browser UA string is shared by well over 20 distinct IPs, and a genuine distributed botnet randomises its UA per IP — one UA shared by many IPs is the signature of a popular browser, not a bot.

Tune per box in /root/.barracuda.cnf; go tighter only on evidence of a genuinely homogeneous burst. Abusive single IPs are still caught by the per-IP scorer and the path-flood detector below.

Path-flood — search-amplification aggregate (detector 3)

See Detector 3 for the mechanism.

_NGINX_PATH_FLOOD_WATCH="apachesolr_search|search_api_views_fulltext|search_api_fulltext|im_taxonomy_vid|/search/node|/search/user"

The defaults cover legacy Apache Solr search paths, the Search API Views and programmatic fulltext query parameters, the faceted-search taxonomy facet parameter, and Drupal core node/user search. Add site-specific expensive endpoint substrings per box; the override replaces the list.

Worked example — an expensive path of your own

The classic case is a calendar: a /events/<year>/<month>/<day> (or ?date=) space is a cheap page for a human and a bottomless one for a crawler that wants "every single date of every single year", each request an uncached render. Nothing here is a single knob — the layers below already act before you change anything, and the watch list is the one you add to:

1. A crawler that says who it is is sorted by class at the edge. AI classes, scrapers and the $is_crawler set are answered 444 (or rate-limited per vendor) by the edge maps. A declared search crawler is served like a visitor, and $deny_on_high_load answers it 503 only once Spider Protection arms at high load, so a fleet that borrows a search engine's name renders pages until then.
2. A fleet that lies about who it is is caught in aggregate: Detector 5 on the shared forged browser name, Detector 2 on volume — but only when its answers are mostly bad statuses. A date-space crawl answers 200 every time, so those two stay quiet, on purpose.
3. The site stays up regardless because of the per-vhost cap on anonymous renders: it bounds how many uncached renders one site may hold in flight, so the front cache keeps absorbing the herd instead of collapsing under it. It ships at 100, which is inert behind a small pool — tune it per instance toward 1.5× the pool's pm.max_children (FPM capacity) before you expect it to bite.
4. To have the participants banned, put the path on the watch list. In /root/.barracuda.cnf, restate the whole list plus your substring (the override replaces, it does not append):

_NGINX_PATH_FLOOD_WATCH="apachesolr_search|search_api_views_fulltext|search_api_fulltext|im_taxonomy_vid|/search/node|/search/user|/events/"

From the next scorer tick that prefix is declared under flood once 30 distinct addresses or 100 backend answers hit it inside the window, and each address that reached the backend at least 20 times (200 answers, not the 444s the maps already shed) is written to web.log and temp-banned for 15 minutes on ports 80/443 by the ban pipeline; repeat offenders escalate to a persistent deny. A render slower than 3 s counts extra. The thresholds are the search-flood defaults and sit above a busy public page's legitimate peak — lower them only on a real report, and remember that detection is post-hoc: a burst that finishes inside one 5-second window is served cheaply and banned for its next visit, never mid-burst.

Two things to keep straight: the substring is matched against the whole log line, so choose one that cannot occur in ordinary URLs (/events/ catches /events/2026/09/03 and ?q=events/… alike; a bare events would also match /news/events-recap); and the search engines you want indexing that calendar are exempt through the whitelist, so a legitimate crawl of the same space is neither declared nor banned.

HTTP/1.0 auth-spam (detector 4)

Catches the slow registration/credential-spam botnet that POSTs to Drupal auth paths over HTTP/1.0 with a forged modern-browser User-Agent — no browser built in the last ~15 years speaks HTTP/1.0 to a public HTTPS host, so the protocol itself is the tell.

The bot paces roughly one request per IP every few minutes from a small CIDR block, staying under every volume detector above; this detector instead accumulates hits in a sliding window that persists across runs and bans through the standard pipeline. See the scoring engine for the mechanism.

_NGINX_HTTP10_AUTH_PATHS="^/([a-z]{2}/)?user/(register|password)(/|$)"

Non-positive-integer overrides of the three numeric knobs revert to the defaults. None of these is autoupboa-seeded — they take the script defaults unless added to /root/.barracuda.cnf by hand.

UA-burst scanner fleet (detector 5)

The per-IP scorer and detector 2 both exclude 301 redirects and both need high per-IP or per-UA volume, so a distributed scanner fleet — dozens of cloud IPs sharing one forged UA, a few requests each, mostly redirects and 404s to non-Drupal CMS paths — slips through every gate above.

This detector groups by UA, counts all statuses including 301, and trips only when a UA is shared by many IPs and its traffic is overwhelmingly "bad".

Non-positive-integer overrides revert to the defaults (the bad-ratio division requires _NGINX_UA_BURST_REQ_MIN of at least 1). Not autoupboa-seeded. Tune tighter, never looser, on real reports.

Guard-404 scraped-interactive-path (detector 6)

The no-referer request gates answer cold GETs to interactive-only paths (Flag toggles, HybridAuth windows) with a static 404 — each one a per-request bot verdict nginx already computed. This detector surfaces the campaign behind those gates once enough distinct IPs trip them at once, and can additionally ban the repeat-offender tail (cutting off the same address's parallel content-crawl 200s that no other detector counts). See the scoring engine for the mechanism, the crawler protections, and the rationale for excluding print paths.

The per-IP ban is opt-in and off by default. Unlike the HTTP/1.0 tell, this signal is browser-inducible: any third-party page can carry an <img referrerpolicy="no-referrer"> pointed at a hosted site's guarded path and make an innocent visitor's browser emit the exact trigger, so a default-on ban would let a stranger's page deny your visitors box-wide. Arm BAN per box on a confirmed campaign, the same way _NGINX_HARVEST_ACTION is armed.

_NGINX_GUARD404_PATHS="^/([A-Za-z]{2}(-[A-Za-z]+)?/)?([Ff][Ll][Aa][Gg]/(flag|unflag|FLAG|UNFLAG)/[A-Za-z0-9_]+/[0-9]|[Hh]ybrid[Aa]uth/window/[A-Za-z0-9_.-]+/?$)"

Non-positive-integer overrides of the numeric knobs revert to the defaults. Not autoupboa-seeded — script defaults apply unless added to /root/.barracuda.cnf by hand. There is deliberately no /24 aggregation knob: this botnet class rides ISP-dispersed CGNAT space where a /24 holds real users. clearwebbans clears this detector's window (and the HTTP/1.0 one) along with the ban logs, so an operator unban is not undone by carried-forward state.

Crawler-fleet fingerprint refusal

The one detector on this page that is not part of scan_nginx. The crawler-fleet refusal lives in its own per-minute job, /var/xdrago/nginx_fleet.sh, which declares a (vhost, user agent) fingerprint and renders the Nginx maps that answer its members 429 — see request guards for the enforcement and the ban pipeline for the generator. Its knobs are read from /root/.barracuda.cnf the same way, and every one of them is validated: a non-numeric value, or one outside the range below, is discarded with a CONFIG line in /var/xdrago/monitor/log/fleet.log and the shipped default is used, so a typo can never turn a gate into a hair trigger.

The refusal is ON by default, on every box, in BOTH scopes. There is no REPORT soak and no per-box arming step: _NGINX_FLEET_ACTION ships as BAN and _NGINX_FLEET_CRAWLER_ACTION inherits it. Action values are case-insensitive, and an invalid address action falls back to the shipped BAN with a CONFIG line rather than switching the protection off — a typo must never disarm it. An invalid crawler action inherits the (already validated) address action.

These knobs exist for reactive loosening after a confirmed legitimate report, not for arming. Loosen the one scope that produced the report, leave the other refusing.

The shipped roster exempts the search engines and their special-case fetchers, the social and messaging link previewers, the uptime monitors, and the AI classes that are allowed by default — the ones the AI crawler policy governs with its own per-vendor aggregate limits. Those agents are never declared as a fleet, whatever their volume; a declared class that matches the roster is logged EXEMPT and skipped.

Two more bounds are internal, not knobs: a user agent that cannot be carried as an exact map key (the printable-ASCII grammar, or longer than the key limit the master render's map_hash_bucket_size allows) is reported UNBANNABLE and never stored, so it cannot occupy a _NGINX_FLEET_MAX_FP slot a refusable fleet needs; and one pass records at most 2000 addresses per fingerprint.

Not autoupboa-seeded — the script's defaults apply unless the variable is added to /root/.barracuda.cnf by hand.

Tier B — i18n flood + FPM saturation (alert-only)

These two paths alert and snapshot only — no per-IP bans. A translation flood spreads across thousands of IPs at one or two requests each, so per-IP banning is futile; the value is the early alert plus a forensic snapshot of top talkers, UAs and path classes.

Alerts land in /var/xdrago/monitor/log/i18n_flood.log; snapshots, the cross-run window.state and the fpm_maxchildren.pos byte-offset file live under /var/xdrago/monitor/log/i18n_flood/.

Exemptions

These two knobs exempt at different scopes:

• _NGINX_DOS_IGNORE_PATHS is tested at loop scope before any detector runs (_is_ignored_request … && continue), so it exempts the line from all six detectors and the Tier-B i18n-flood tally at once. The two passes that never ride the loop stay out of its reach: the Tier-B FPM-saturation trigger tails the PHP-FPM error logs, and the post-loop harvest pass reads its own bounded tail and exempts by UA (_NGINX_HARVEST_UA_EXEMPT), not by path.
• _NGINX_DOS_IGNORE is tested inside _process_ip and only suppresses the per-IP counter for that line — every other detector still sees it.

The path-exemption mechanism (the laundering-proof URI parse) is documented in detail in The exemption gate; these are the configuration rows.

_NGINX_DOS_IGNORE_PATHS="/shopify/webhook /quickbooks/webhook /stripe/webhook /paypal/webhook /github/webhook /gitlab/webhook /graphql /public-api /oauth2"

_NGINX_DOS_IGNORE_PATHS rules:

• Paths are space-separated, each a leading-slash absolute path with no trailing slash (/shopify/webhook, not /shopify/webhook/).
• Each entry matches that exact path or any sub-path under it (/graphql exempts /graphql/api/endpoint).
• The match is against the real $request URI only — query stripped, any .. or %-escape refused — so a token in a User-Agent, Referer, or query string can never launder an exemption (see page 01 for why).
• The override in /root/.barracuda.cnf replaces the default list, so include every endpoint the box needs. An empty value disables the feature.

These exist because machine/API endpoints authenticate per request at the application layer (HMAC, OAuth), not by IP — counting them per-IP self-bans a legitimate webhook provider or API client. The defaults are shipped in the script (not only the per-box override) so the exemption survives a /root/.barracuda.cnf regeneration.

Where these are set

All of the above are read by scan_nginx.sh — bar the _NGINX_FLEET_* family, read by nginx_fleet.sh — and both source /root/.barracuda.cnf, so any of them can be overridden there.

The consolidated _NGINX_* knob list with types and source references is in the Variables reference; the control-file format and the broader DoS-protection family sit in the control files & INI topic.

Once an IP is scored over _NGINX_DOS_LIMIT, enforcement proceeds through the ban pipeline and the request guards.

Related

• scan_nginx scoring engine — the detector logic these knobs tune.
• The ban pipeline — the .instant.csf.block / .full.csf.cleanup markers and the escalation thresholds.
• Operations + tuning — applying these overrides in practice and enabling debug output.
• Variables reference — the consolidated _NGINX_* table.