OGOwnGate

Атака на веб-панели: как отсечь подбор паролей на внутренние сервисы

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

Эшелонированная защита от брутфорса и Password Spraying

Откройте логи любого вашего веб-сервиса, имеющего белый 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 берёт на себя весь удар внешних атак, превращая агрессивный шторм ботнетов в тихий и безопасный ручей проверенных сессий.

← Все статьи