feat(gateway): temporary IP ban (fail2ban) fed by rejections + honeypot/honeytoken
CI / changes (pull_request) Successful in 3s
CI / unit (pull_request) Successful in 11s
CI / integration (pull_request) Successful in 17s
CI / ui (pull_request) Successful in 53s
CI / gate (pull_request) Successful in 0s
CI / deploy (pull_request) Successful in 1m11s
CI / changes (pull_request) Successful in 3s
CI / unit (pull_request) Successful in 11s
CI / integration (pull_request) Successful in 17s
CI / ui (pull_request) Successful in 53s
CI / gate (pull_request) Successful in 0s
CI / deploy (pull_request) Successful in 1m11s
Add a prod-only, in-memory IP ban enforced at the edge, fed by three signals:
sustained rate-limiter rejections (the IP-keyed public/email/admin classes — the
user class stays the backend soft-flag's concern), a honeypot decoy-path hit (the
contour caddy tags decoys with X-Scrabble-Honeypot and routes them to the gateway),
and a honeytoken (a planted bearer, GATEWAY_HONEYTOKEN). A banned IP is refused with
429 by the abuseGuard middleware before any work — covering the Connect edge, the
live stream and the static SPA/landing the per-op limiter never gated.
The ban is off by default: it keys by the real client IP the shared-NAT test contour
does not expose, so a ban there would be self-inflicted; detection still logs in the
contour, only the ban action is gated (GATEWAY_ABUSE_BAN_ENABLED). Rejection bans last
GATEWAY_ABUSE_BAN_DURATION; tripwire/honeytoken hits are near-zero-false-positive and
earn longer fixed bans. Each ban increments gateway_abuse_banned_total{reason}.
Operators see and lift active bans on the admin console's Throttled page; the gateway
syncs its active set to the backend every 30s (POST /api/v1/internal/bans/sync,
backend/internal/banview) and applies the operator unbans the response returns.
PRERELEASE phase AG. Docs baked into ARCHITECTURE / FUNCTIONAL (+ru) / both READMEs.
This commit is contained in:
@@ -303,7 +303,14 @@ Telegram-identity) или **отправить пост в игровой кан
|
||||
флагом**. Аккаунт, устойчиво превышающий настраиваемый порог отказов, помечается
|
||||
автоматически — маркер обратим, виден бейджем в списке пользователей и на карточке
|
||||
аккаунта и **никогда не блокирует игру**; оператор рассматривает и снимает его с
|
||||
карточки пользователя. Автоматического бана нет.
|
||||
карточки пользователя. Сам флаг аккаунта баном не является. В **проде** та же
|
||||
страница дополнительно перечисляет **активные баны по IP**, которые применяет gateway:
|
||||
временную блокировку IP клиента, превысившего порог наплыва, либо задевшего скрытую
|
||||
**honeypot**-ловушку или подброшенный **honeytoken** — высокодостоверный признак
|
||||
сканера или враждебного бота, но не нормального игрока. У каждого бана показаны причина
|
||||
и срок, рядом действие **Unban**; баны истекают сами, а оператор может снять бан раньше.
|
||||
Баны по IP — защита только для прода: общий тестовый контур не различает своих клиентов,
|
||||
поэтому там не применяется.
|
||||
|
||||
Консоль также позволяет оператору **вручную заблокировать** аккаунт — жёсткий аналог мягкого
|
||||
high-rate флага. С карточки пользователя оператор блокирует аккаунт **навсегда** или **до даты**
|
||||
|
||||
Reference in New Issue
Block a user