Как медленно HTTP может сбить сервер?

31.12.2019GBlog, Продвинутые компьютерные предметы

Медленный HTTP — это атаки типа «отказ в обслуживании» (DoS) на уровне приложений, которые могут привести к сбивке сервера с ограниченными ресурсами. Из-за характера атаки (медленная скорость и низкая громкость) их трудно обнаружить, и они могут нанести такой же ущерб, как DDoS с большой громкостью. В этом посте я поделюсь своим опытом с этими атаками

Вступление

Как объясняется в WiKi , медленные атаки HTTP основаны на том факте, что протокол HTTP по своей природе требует, чтобы запросы полностью принимались сервером перед их обработкой. Если HTTP-запрос не завершен или если скорость передачи очень низкая, сервер будет занят своими ресурсами в ожидании оставшихся данных. Если сервер удерживает слишком много ресурсов, это создает отказ в обслуживании. [Источник: https://github.com/shekyan/slowhttptest/wiki ]

Медленные HTTP-атаки в основном бывают трех типов.

Медленные заголовки (он же Slowloris)
Эта атака работает, открывая большое количество соединений с веб-сервером и поддерживая их, замедляя отправку бесконечных заголовков. Сервер не закроет соединения, так как запрос не выполнен, и в конечном итоге он исчерпает все ресурсы на сервере, блокируя законные запросы.
Медленное тело (он же RU-Dead-Yet)
RU-Dead-все же работает так же, как Slowloris, но вместо того, чтобы отправлять бесконечные заголовки, он отправляет бесконечное тело POST, заставляя сервер поддерживать соединения открытыми. Когда все ресурсы сервера заняты, он не может обслуживать законные запросы.
Медленное чтение
Вышеупомянутые атаки используют веб-сервер, отправляя медленные запросы, однако, эксплойт медленного чтения основан на очень медленном чтении ответов с сервера. Он работает, сообщая об очень низком размере буфера приема клиента, вызывая большой отклик от сервера и считывая минуты, чтобы прочитать один ответ. Когда несколько таких соединений создаются одновременно, это может потреблять все ресурсы сервера и приводить к DoS. Это не может быть объяснено лучше, чем сам автор этой атаки в этом посте .
Архитектура Nginx

Nginx имеет главный процесс и ряд вспомогательных процессов (включая рабочие процессы). Главный процесс управляет всеми привилегированными операциями, тогда как рабочие процессы выполняют фактическую работу и обрабатывают соединения. Архитектура Nginx принципиально отличается от архитектуры Apache. Apache создает блокирующий поток для каждого нового соединения , тогда как Nginx основан на неблокирующей управляемой событиями архитектуре.
Диаграмма ниже суммирует поток:
Эта архитектура в некоторой степени обеспечивает врожденную защиту от медленных HTTP-атак, поскольку рабочий процесс не блокируется при вводе-выводе. Он может продолжать обслуживать другие запросы. Однако это не является полным доказательством и зависит также от параметров конфигурации Nginx.
Вот некоторые из общих параметров конфигурации, предоставляемых Nginx для предотвращения таких атак:
1) limit_req — ограничить скорость запросов с одного IP
2) limit_conn — ограничить количество подключений с одного IP
3) client_body_timeout — закрыть соединения с медленным телом
4) client_header_timeout — закрывать соединения с медленными заголовками
5) send_timeout — если клиент в течение этого времени ничего не получает, соединение закрывается.

Вывод
Медленные HTTP-атаки могут быть такими же жестокими, как и объемные DDoS-атаки, если они не выполняются должным образом. Более того, в конфигурации Nginx много движущихся частей, и мы должны правильно их понять, прежде чем делать случайные изменения при копировании / вставке.

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

Ссылки
1) SlowHTTPTest
2) Готовы ли вы к медленному чтению
3) Внутри Nginx
4) Ссылка на Nginx
5) Nginx DDOS смягчение

Эта статья предоставлена Сакет Кумар . Если вы как GeeksforGeeks и хотели бы внести свой вклад, вы также можете написать статью с помощью contribute.geeksforgeeks.org или по почте статьи contribute@geeksforgeeks.org. Смотрите свою статью, появляющуюся на главной странице GeeksforGeeks, и помогите другим вундеркиндам.

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