Cap how wide a single auto-registered IP block may be
docker-build-push / build-push (push) Successful in 5s
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:
1 parent
57234ca548
commit
147673fd49
3 files changed
+131
-4
No files matched your search
@@ -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)
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
Reference in new issue
Block a user