Cap how wide a single auto-registered IP block may be
docker-build-push / build-push (push) Successful in 5s

ipapi.is reports the flagged address's whole ASN route, and register_ip_block
blocked it whatever its width. That is the right unit for hosting space, where
a repeat bad actor comes back from a different address in the same VPS block.
It is badly wrong for an ISP aggregate, and the route cache holds routes as
wide as /8, /9 and /11: one `abuser` flag on a residential or mobile address
inside one of those would have walled off millions of consumer addresses.

That was not hypothetical -- 197.211.32.0/19 is registered against
GLOMOBILE-GPRS, a Benin mobile carrier, from a single `abuser` flag: 8,192
addresses of consumer mobile space.

Anything wider than /24 (v4) or /48 (v6) now falls back to blocking the single
address. This costs blocking strength against large hosting allocations -- an
OVH /16 blocks one address now, so a repeat offender from that block needs a
fresh block each time -- and in exchange makes the collateral-damage case
impossible. Both ceilings are env-tunable.

The cap applies to what gets BLOCKED, not to what gets CACHED: the wide route
is still the right cache key, since it genuinely belongs to one operator and
one lookup answers for the whole of it. Narrowing the cache key would multiply
provider lookups for no benefit.

Applied at registration time, so blocks already in force are untouched.
This commit is contained in:
pmb committed 2026-09-13 16:08:37 -07:00
1 parent 57234ca548
commit 147673fd49
3 files changed
+131 -4

No files matched your search

+23
View File
@@ -259,6 +259,29 @@ BLOCKS_API_PUBLIC_URL=https://hooks.yttrx.com
# caching costs nothing.
BLOCKS_API_CACHE_SECONDS=300
# Widest network a single auto-registered IP block may cover, as a prefix
# length. ipapi.is reports the flagged address's whole ASN route. That is the
# right unit for hosting space — a bad actor comes back from a different
# address in the same VPS block — but wrong for an ISP aggregate: routes as
# wide as /8, /9 and /11 turn up, and one `abuser` flag on a residential or
# mobile address inside one of those would wall off millions of consumer
# addresses. Anything wider than this ceiling falls back to blocking the
# single address.
#
# /24 costs real blocking strength against large hosting allocations (an OVH
# /16 now blocks one address, not the range, so a repeat offender out of that
# block needs a fresh block each time) in exchange for making the
# mobile/residential collateral-damage case impossible. Raise toward /16 to
# trade back the other way.
#
# Applied at registration time, not retroactively: blocks already in force
# keep whatever width they were registered with.
IP_SCRUTINY_MAX_BLOCK_PREFIX_V4=24
# The v6 ceiling. /48 is the standard end-site allocation — the rough
# equivalent of what a /24 represents in v4.
IP_SCRUTINY_MAX_BLOCK_PREFIX_V6=48
# ---------------------------------------------------------------------------
# Reputation query API (pre-signup pre-blocking)
# ---------------------------------------------------------------------------