Назад | Перейти на главную страницу

DOS-атака «медленная публикация»: как предотвратить в IIS

У меня есть общедоступный веб-сервер IIS 7.5, на котором работает единственный веб-сайт ASP.NET, который только что провалил одно из наших сканирований безопасности из-за уязвимости "медленной публикации".

Пытался уменьшить значение времени ожидания выполнения httpruntime в файле web.config для сайта, но сайт по-прежнему не проходит проверку безопасности.

У кого-нибудь есть рекомендации по настройкам / конфигурации IIS для предотвращения медленных атак post dos?

Редактировать: Я думаю, что единственный способ предотвратить это - сделать это в приложении, глядя на заголовки в подпрограмме beginrequest в global.asx и в зависимости от типа содержимого, заканчивая / закрывая ответ ...

Инструмент рекомендует проверить уязвимость следующим образом: https://www.owasp.org/index.php/OWASP_HTTP_Post_Tool Но я на самом деле просто пытаюсь определить, есть ли какая-либо конфигурация iis, которая может ее исправить.

Медленный пост: " Как работает DDOS-атака HTTP POST (HTTP / 1.0) (продолжение)

  1. Например, Content-Length = 1000 (байтов). Тело сообщения HTTP правильно закодировано URL-адресом, но ..
  2. ..... отправляется снова, например, 1 байт за 110 секунд.
  3. Умножьте количество таких подключений на 20 000, и ваш веб-сервер IIS будет DDOS.
  4. Большинство веб-серверов могут принимать до 2 ГБ контента в одном запросе HTTP POST.

ссылка: https://media.blackhat.com/bh-dc-11/Brennan/BlackHat_DC_2011_Brennan_Denial_Service-Slides.pdf

IIS не имеет никакого регулирования скорости изначально (или я предполагаю, что в данном случае это отрицательное регулирование скорости). Вы можете проверить модуль динамических ограничений IP (http://www.iis.net/download/DynamicIPRestrictions). Я не верю, что он будет это специально проверять, но стоит взглянуть.

Проверки этого могут иметь больше шансов на фильтрацию IDS вашего брандмауэра. Там может быть поддержка для проверки этого типа атаки.

Ваше сканирование безопасности должно сказать вам, на чем оно сработало.

Насколько низко вы установили тайм-аут выполнения? Что-то еще, что нужно уменьшить (оно должно быть довольно низким, чтобы смягчить эту атаку ...), - это тайм-аут соединения.

Но особенность этих смягчений заключается в том, что они не предотвращают атаку сразу, а просто делают ее менее мощной в зависимости от объема атакующих ресурсов; пороговое значение для вашего сканирования безопасности, вероятно, является довольно произвольным числом, и попадание ниже этого числа не означает, что вы защищены от атаки.

В наших тестах мы обнаружили, что Qualys помечает URL-адрес, потому что сервер поддерживает соединение открытым в течение 500 секунд ожидая завершения запроса.

Параметр, который мы отредактировали, чтобы соединение оставалось открытым во время медленного отклика: minBytesPerSecond. значение по умолчанию - 250. Мы установили его на 400.

Предотвращение атаки отказа в обслуживании (DoS) уязвимости Slow HTTP POST

Это может быть OTT и может даже не делать то, что вы хотите, но, возможно, стоит взглянуть http://www.snort.org/ http://www.sans.org/security-resources/idfaq/snort.php