IIS/Lansweeper сильно тормозит из-за аномального числа логонов, внутренний DDoS?
Коллеги, нужна помощь в разборе ситуации с Lansweeper.
Симптомы:
После повторного развёртывания сервер Lansweeper работает очень медленно.
При открытии веб-интерфейса страницы грузятся по несколько минут. Когда ответ наконец приходит — он быстрый.
Задержки также наблюдаются при загрузке изображений на сайте.
Что проверено:
AppInsight for SQL → база данных работает нормально, задержек нет.
Проблема не в SQL, фокус на IIS.
Включили мониторинг AppInsight for IIS → обнаружены аномально большие значения:
Более 750 тыс. логон-аттемптов с момента запуска сайта.
За полчаса количество попыток выросло ещё на 3 тыс., явно не похоже на ручную активность.
Логи IIS (C:\inetpub\logs\LogFiles\W3SVC3):
Круглосуточно идут обращения к 3–4 страницам.
Ответы — код 200 (не перебор паролей, а именно успешные запросы).
Аутентификация у нас теперь через веб-страницу, поэтому 200 коды возможны даже при «спаме логонами».
Источник трафика:
Запросы идут изнутри сети, не извне:
Машина из подсети поддержки (в VLAN, куда подключаются ПК клиентов на ремонте).
Машина из офисной пользовательской подсети.
Адрес из пула VPN для пользователей.
Проверка показала, что один из этих адресов принадлежит рабочей станции сотрудника.
Ещё два адреса (172.21.103.166 и 172.20.2.185) продолжают активно долбить сервер прямо сейчас.
Дополнительно:
По сетевой статистике видно: за 9 дней сервер принял ~200 ГБ входящего трафика и отправил только 7 ГБ.
Сервер выполняет роль только веб-хоста, вся служебная работа идёт на БД и приложения.
По факту сервер заспамлен изнутри огромным количеством запросов.
Вопрос:
Куда дальше копать и как правильно ограничить/отфильтровать такие внутренние «DDoS»-подобные запросы?
Стоит ли включать в IIS Dynamic IP Restrictions или есть другие практики именно для Lansweeper/IIS?
Буду признателен за советы и опыт, как правильно отлавливать такие сценарии.
Вообще, нужно разобраться какого типа DDoS атака и уже, исходя из этого, строить стратегию.
Технически, нужен физически отдельный прокси сервер перед вашим IIS, чтобы можно было анализировать трафик, и фильтровать запросы, которые будут использовать уже ресурсы IIS.