Перебор пароля админки с 200 адресов: почему лимит по IP не спас и что помогло

Кейс из практики. Проект — финансовый онлайн-сервис с личными кабинетами, приёмом платежей, чатом поддержки и админ-панелью. Мы ведём его безопасность и инфраструктуру. Название проекта, адреса и даты не раскрываем; технические детали обобщены настолько, чтобы их нельзя было использовать для атаки.

Форма входа в админ-панель была защищена «как положено»: не больше пяти попыток в минуту с одного адреса, после этого — 429. За час атаки этот лимит не сработал ни разу, хотя форму штурмовали.

Что увидели в логах

В течение часа на адрес входа пришло около двухсот запросов, каждый — с нового IP-адреса. Адреса из разных стран и сетей: домашние подключения, мобильные операторы, хостинги. Объединяли запросы два признака: одинаковый усечённый заголовок браузера, которого настоящий браузер не отправляет, и равномерный ритм независимо от часового пояса «посетителя».

Так выглядит перебор через ботнет или арендованные прокси: список паролей раздаётся по сотням адресов, каждый проверяет один вариант. Все попытки получили 401 — успешных входов не было.

Почему лимит по адресу не работает

Лимит «N запросов с IP» защищает от одного настойчивого клиента. Против распределённой атаки он бесполезен по определению: каждый адрес укладывается в норму. Блокировать адреса по одному тоже бессмысленно — завтра придут другие двести.

Что мы сделали

1. Общий лимит на вход в админку. В веб-сервере добавлена зона, где ключ — не адрес клиента, а сам сервер: вся форма входа принимает не больше 20 попыток в минуту. Для нескольких администраторов это незаметно, а перебор замедляется до бессмысленной скорости.
2. Фильтр по подписи бота. Запросы с пустым или усечённым заголовком браузера получают 403 ещё до приложения. Это не защита сама по себе — заголовок легко сменить, — но он отрезал текущую волну и разгрузил логи.
3. Проверили второй фактор. Даже верный пароль не даёт входа без одноразового кода. Мы сверили журнал успешных входов: все проходили второй фактор и совпадали с известными сессиями владельца.
4. Проверили сравнение секретов. Пароль и код сравниваются функцией постоянного времени, ответ при неверном логине и неверном пароле одинаковый.

Как настроить у себя

# nginx: общий лимит на вход в админку (ключ — сервер, а не клиент)
limit_req_zone $server_name zone=admin_global:1m rate=20r/m;

location = /api/admin/login {
    limit_req zone=admin_global burst=5 nodelay;
    limit_req zone=admin_ip burst=3 nodelay;   # прежний лимит по адресу оставляем
    proxy_pass http://app;
}

• Включите второй фактор для всех учётных записей с правами администратора — без исключений.
• Настройте уведомление о всплеске неуспешных входов: двадцать 401 за минуту — повод посмотреть логи.
• Если сервис за CDN, убедитесь, что веб-сервер видит настоящие адреса клиентов, иначе лимиты по IP считаются по узлам CDN.
• По возможности закройте админку списком доверенных адресов или VPN — это снимает проблему целиком.