Rate limiting по IP-адресу: как проектировать лимиты для сред с общими IP

Rate limiting — один из базовых механизмов защиты веб-приложений и API от злоупотреблений, исчерпания ресурсов и атак типа denial-of-service. Самый простой и распространенный подход — считать количество запросов с каждого IP-адреса. Но в современных сетях эта схема быстро дает сбой: слишком часто один IP оказывается общим для множества пользователей.

Общие IP встречаются повсюду: корпоративные NAT, сети мобильных операторов, публичный Wi‑Fi, VPN, proxy и выходные узлы TOR. Если считать исходный IP надежным признаком уникального пользователя или сущности, система неизбежно начнет либо блокировать легитимных клиентов (false positives), либо пропускать более подготовленных злоумышленников, которые обходят ограничения за счет ротации общих IP (false negatives).

В этой статье разберем, как проектировать rate limits, более устойчивые к средам с общими IP, и почему простого подсчета по /32 или /128 уже недостаточно.

The Core Problem: IP Address != User

Исторически IP-адрес часто действительно неплохо соотносился с одним пользователем или небольшой группой пользователей за статическим NAT. Сегодня это предположение все чаще не работает:

• Mobile Carriers: тысячи, а иногда и десятки тысяч пользователей могут выходить в интернет через один публичный IPv4-адрес благодаря Carrier-Grade NAT (CGNAT).
• Enterprise Networks: крупные компании нередко направляют весь исходящий трафик через ограниченный пул публичных IP.
• Public Wi-Fi/Hotspots: множество пользователей одновременно подключаются через один gateway IP.
• Proxies, VPNs, TOR: такие сервисы специально объединяют пользователей за общими IP — ради приватности или обхода ограничений. Злоумышленники используют это для анонимности и распределения нагрузки по большому числу адресов.
• Cloud Providers/Data Centers: нагрузки, запущенные в облаках и дата-центрах, часто приходят из крупных, хорошо известных IP-диапазонов, которыми пользуются множество арендаторов.

Когда большое число легитимных пользователей делит один IP, простой лимит «на IP» быстро срабатывает и блокирует всех сразу. И наоборот: атакующий может прокручивать пул proxy IP, каждый из которых по отдельности остается ниже порога, но в сумме позволяет значительно превысить задуманный лимит.

Beyond Simple IP: Augmenting Rate Limiting Signals

Чтобы сделать rate limiting устойчивее, нужно учитывать дополнительные сигналы, а не только непосредственный source IP.

1. User-Centric Identifiers

Когда это возможно и уместно, привязывайте лимиты к user ID, а не только к IP. Для действий авторизованных пользователей это обычно лучший вариант.

• Session ID/Cookie: отслеживайте запросы в разрезе сессии. Это помогает увидеть повторяющиеся действия в рамках одной и той же сессии.