Почему на NginX и Lighttpd не влияет Slowloris?

23

Я исследую уязвимость для Slowloris и думаю, что понимаю, как и почему работает такая атака.

Что я не понимаю, так это то, почему Lighttpd и NginX не затрагиваются (согласно той же статье, что и ссылка выше). Что они делают такими разными?

— Шуррик
источник

25

У Apache есть теория «Максимум клиентов»

Это количество одновременных соединений, которые он может обработать. То есть, если для сервера apache ограничение «максимальное количество клиентов» составляет 100, а для выполнения каждого запроса требуется 1 секунда, он может обрабатывать не более 100 запросов в секунду.

Приложение, такое как SlowLoris, заполняет сервер соединениями, в нашем примере, если SlowLoris отправляет 200 соединений в секунду, а Apache может обрабатывать только 100 соединений в секунду, очередь подключений будет увеличиваться и использовать всю память на машине, в результате чего Хаот. Это похоже на то, как работает анонимный LOIC.

NGINX и Lighttpd (помимо прочего) не имеют максимального количества соединений, вместо этого они используют рабочие потоки, поэтому теоретически не существует ограничений на количество соединений, которые они могут обрабатывать.
Если вы наблюдаете за своими соединениями Apache, вы увидите, что большинство активных соединений являются «отправляющими» или «получающими» данные от клиента. В NGINX / Lighttpd они просто игнорируют эти запросы и позволяют им работать в фоновом режиме, не используя системные ресурсы, и ему нужно только обрабатывать соединения с чем-то происходящим (синтаксический анализ ответов, чтение данных с внутренних серверов и т. Д.)

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

— мазаться
источник

Хороший и очень подробный ответ. +1

— Oldskool

6

Незначительное исправление: nginx не использует рабочие потоки для достижения большого количества соединений. От nginx.org : «Nginx не полагается на потоки для обработки запросов. Вместо этого он использует гораздо более масштабируемую архитектуру, управляемую событиями (асинхронную)»

— День

2

Хотя возможный побочный эффект, цель Slowloris состоит не в том, чтобы «использовать всю память на машине», а в том, чтобы исчерпать максимальную емкость соединения, не позволяя последующим соединениям преуспеть.

— wulfgarpro

@Day Nginx использует рабочие потоки для поддержки своей асинхронной работы. Полезная схема архитектуры приложения представлена здесь: aosabook.org/en/nginx.html#fig.nginx.arch

— Терри Бертон,

13

Nginx на самом деле уязвим для медленной атаки. Недостаточный ресурс - это максимальное количество одновременных рабочих соединений. Это число может быть вычислено как worker_connections * worker_processes и равно 512 в конфигурации nginx по умолчанию. Таким образом, довольно легко удалить незащищенный nginx с помощью таких инструментов, как goloris .

— valyala
источник

golorisвыглядит как инструмент, который мне нужен, чтобы убедиться, что моя реализация / настройка работает как положено!

— Алексис Уилк

8

Комментарий валяла должен быть принят как ответ.

Большинство серверов nginx используют конфигурации по умолчанию и поэтому уязвимы для медленной атаки. Я использовал slowloris, чтобы отключить некоторые из сайтов nginx моего друга, используя только мой ноутбук, и обычно это занимало менее 5 минут (мои друзья попросили меня сделать это).

Как заявляет Вальяла, технически nginx не подвержен slowloris, но настройки по умолчанию ограничивают максимальное количество соединений, поэтому, когда число соединений превышает это число, nginx отбрасывает новый запрос, что приводит к отказу в обслуживании.

Известные способы защиты nginx от slowloris включают ограничение количества подключений с одного IP-адреса и увеличение конфигурации worker_connections. Атака может все еще работать, но она становится сложнее (может быть, более 5 минут?: D)

— Нгуен Фан Тан
источник