Атака на веб-панели: как отсечь подбор паролей на внутренние сервисы
Выставить корпоративную почту, VPN-портал или GitLab наружу без шлюза — значит гарантировать круглосуточный обстрел ботнетами через Password Spraying. Разбираем, почему fail2ban не спасает от умного перебора и как отсекать атаки централизованно.

Откройте логи любого вашего веб-сервиса, имеющего белый IP-адрес в интернете, и наберите простую команду:
grep -i "login\|failed\|auth" /var/log/nginx/access.log | wc -l
Если вы не смотрели туда пару месяцев, цифра вас неприятно удивит: десятки и сотни тысяч попыток входа каждую неделю.
Китайские ботнеты, сканеры уязвимостей, автоматизированные фермы из скомпрометированных роутеров Mikrotik и умных телевизоров непрерывно, 24 часа в сутки, 7 дней в неделю методично простукивают формы входа вашей компании.
Но самая большая опасность кроется в том, что большинство сисадминов до сих пор защищаются от атак образца 2010 года, полностью пропуская современные методы взлома.
---
Почему классический Fail2ban больше не работает
Большинство инженеров уверены, что поставив утилиту fail2ban на сервер с Nginx, они решили вопрос безопасности: *«Три неверных попытки — бан IP на час через iptables, всё надежно!»*.
В реальности эта защита рассыпается от первой же серьезной атаки:
1. Переход от Brute-Force к Password Spraying
Классический брутфорс (когда бот берёт одного пользователя admin и перебирает 10 000 паролей из словаря) практически умер. На смену ему пришла техника распыления паролей (Password Spraying):
- Ботнет парсит список сотрудников компании из LinkedIn или корпоративной почты (например, 200 логинов);
- Берёт ровно один пароль, сезонно актуальный прямо сейчас: например,
Autumn2026!; - Делает ровно одну попытку входа для каждого из 200 сотрудников с интервалом в две минуты.
Что видит ваш сервер? Ни для одной учетной записи лимит ошибок не превышен. Учетки в Active Directory не блокируются. А Fail2ban молчит, потому что с одного IP прилетает один безобидный запрос раз в полчаса.
При этом в компании из 200 человек хотя бы один обязательно поставил себе сезонный пароль. Доступ получен.
2. Тысячи распределённых IP-адресов
Атака идёт не с одного выделенного сервера, а с ботнетов размером в 50 000 зараженных устройств по всему миру. Каждый запрос летит с уникального IP. Бан одного адреса не даёт ровным счётом ничего.
3. Задержка реакции и нагрузка на iptables
Fail2ban работает реактивно: сервис сначала пишет строчку в лог на диске, демон парсит регулярное выражение, находит совпадение и вызывает системную команду iptables.
Когда в таблице фаервола накапливается 15 000 заблокированных IP, производительность сетевого стека ядра Linux начинает деградировать, а сервер тратит процессорные циклы на обработку правил бана вместо работы полезных сервисов.
---
Как построить непробиваемую стену: подход OwnGate
Чтобы защитить внутренние веб-панели от интеллектуального перебора, фильтрация должна происходить в памяти шлюза доступа ещё до того, как запрос коснется целевых приложений.
В шлюзе доступа OwnGate реализован многоуровневый защитный комплекс:
1. Прогрессивное замедление (Exponential Backoff)
Вместо мгновенного жесткого бана (который злоумышленник легко детектирует и обходит сменой IP) шлюз применяет математическое замедление:
- Первая ошибка ввода — ответ за стандартные 100 мс;
- Вторая ошибка — искусственная задержка в 1 секунду;
- Третья ошибка — задержка 4 секунды;
- Пятая ошибка — 16 секунд.
Для живого человека, опечатавшегося в одной букве, задержка в пару секунд незаметна. Для автоматизированного скрипта, планировавшего перебрать миллион комбинаций, скорость атаки падает до нуля. Ботнет просто захлёбывается в таймаутах соединений.
2. Глобальный счётчик распыления (Cross-Account Defense)
Шлюз отслеживает аномалии не только в разрезе одного аккаунта, но и по всему пространству пользователей:
- Если с пула адресов фиксируется серия одиночных попыток входа в разные учетные записи с одним паттерном — шлюз идентифицирует атаку Password Spraying;
- Включается временный повышенный уровень проверок для подозрительной подсети без блокировки учетных записей легитимных сотрудников в AD.
3. Интеграция с DDoS-Guard на периметре
Шлюз OwnGate разворачивается с защитой от DDoS-атак и сканирования на сетевом уровне:
- Отсечение мусорного трафика ботнетов до поступления на веб-сервер;
- Проверка сигнатур браузеров и поведенческий анализ без навязчивых графических капч.
4. Непробиваемый второй фактор (TOTP)
И самое главное: даже если пароль пользователя скомпрометирован или угадан через распыление, атакующий моментально упирается в требование 6-значного кода второго фактора.
Подбор 6-значного TOTP-кода с 30-секундным окном жизни и лимитом в 3 попытки математически невозможен.
---
Резюме
Выставлять административные панели сервисов (GitLab, Grafana, почту, VPN) наружу с надеждой на «сложный пароль и fail2ban» — это вопрос времени до первого взлома.
Единый шлюз доступа OwnGate берёт на себя весь удар внешних атак, превращая агрессивный шторм ботнетов в тихий и безопасный ручей проверенных сессий.