Как правильно подойти к вопросу: iIS/Lansweeper сильно тормозит из-за аномального числа логонов, внутренний DDoS?

Ссылка скопирована
1 ответ

Нужна помощь в разборе ситуации с 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?

По вводным: буду признателен за советы и опыт, как правильно отлавливать такие сценарии.

Нужно решить такую задачу?

Опишите проблему, и специалист поможет с настройкой, исправлением ошибки или доработкой сайта. Подберём понятный план работ без лишней переписки.

Заказать помощь
Лучший ответ
1
Mobile-редакция Ответ

Если IIS/Lansweeper тормозит из-за аномального числа логонов, сначала не называйте это DDoS. Внутри сети чаще встречается не атака, а неправильный polling, повторные попытки авторизации, сломанный сервисный аккаунт, сканирование диапазонов или проблема с SQL/AD. Нужно собрать факты: кто логинится, куда, с какой частотой и каким результатом.

Начните с Windows Event Viewer на сервере IIS/Lansweeper и контроллерах домена. Ищите события 4624, 4625, 4648, 4771, 4776. Важны account name, source workstation, logon type, status/substatus.

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddHours(-2)} |
  Select-Object TimeCreated, Id, ProviderName, Message |
  Select-Object -First 20

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddHours(-2)} | Select-Object TimeCreated, Id, ProviderName, Message | Select-Object -First 20

Дальше проверьте настройки Lansweeper: scanning targets, credentials, schedules, failed credentials, IP ranges. Если указан большой диапазон и неверный пароль сервисного аккаунта, система может создавать тысячи неуспешных логонов.

  • проверьте, не истек ли пароль сервисного аккаунта;
  • разделите scan ranges и уменьшите частоту сканирования;
  • исключите несуществующие/недоступные подсети;
  • посмотрите нагрузку SQL: блокировки, долгие запросы, размер базы;
  • проверьте IIS logs на частые запросы к одному endpoint.

Если источник один хост, временно ограничьте его firewall-правилом и посмотрите, исчезает ли нагрузка. Если источников много, анализируйте расписание сканирования и AD-аутентификацию. Для SQL полезно посмотреть wait stats и active sessions. В большинстве случаев помогает корректировка credentials/schedule в Lansweeper и чистка неактуальных scan targets, а не расширение ресурсов сервера.

Другие ответы (0)

Пока нет других ответов. Будьте первым, кто поможет автору.

Ответить на вопрос

комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Вам также может быть интересно