Я исследую уязвимость для Slowloris и думаю, что понимаю, как и почему работает такая атака.
Что я не понимаю, так это то, почему Lighttpd и NginX не затрагиваются (согласно той же статье, что и ссылка выше). Что они делают такими разными?
Я исследую уязвимость для Slowloris и думаю, что понимаю, как и почему работает такая атака.
Что я не понимаю, так это то, почему Lighttpd и NginX не затрагиваются (согласно той же статье, что и ссылка выше). Что они делают такими разными?
У Apache есть теория «Максимум клиентов»
Это количество одновременных соединений, которые он может обработать. То есть, если для сервера apache ограничение «максимальное количество клиентов» составляет 100, а для выполнения каждого запроса требуется 1 секунда, он может обрабатывать не более 100 запросов в секунду.
Приложение, такое как SlowLoris, заполняет сервер соединениями, в нашем примере, если SlowLoris отправляет 200 соединений в секунду, а Apache может обрабатывать только 100 соединений в секунду, очередь подключений будет увеличиваться и использовать всю память на машине, в результате чего Хаот. Это похоже на то, как работает анонимный LOIC.
NGINX и Lighttpd (помимо прочего) не имеют максимального количества соединений, вместо этого они используют рабочие потоки, поэтому теоретически не существует ограничений на количество соединений, которые они могут обрабатывать.
Если вы наблюдаете за своими соединениями Apache, вы увидите, что большинство активных соединений являются «отправляющими» или «получающими» данные от клиента. В NGINX / Lighttpd они просто игнорируют эти запросы и позволяют им работать в фоновом режиме, не используя системные ресурсы, и ему нужно только обрабатывать соединения с чем-то происходящим (синтаксический анализ ответов, чтение данных с внутренних серверов и т. Д.)
Я фактически ответил на аналогичный вопрос сегодня днем, так что информация там также может быть вам интересна. Уменьшение очереди запросов Apache.
Nginx на самом деле уязвим для медленной атаки. Недостаточный ресурс - это максимальное количество одновременных рабочих соединений. Это число может быть вычислено как worker_connections * worker_processes и равно 512 в конфигурации nginx по умолчанию. Таким образом, довольно легко удалить незащищенный nginx с помощью таких инструментов, как goloris .
источник
goloris
выглядит как инструмент, который мне нужен, чтобы убедиться, что моя реализация / настройка работает как положено!Комментарий валяла должен быть принят как ответ.
Большинство серверов nginx используют конфигурации по умолчанию и поэтому уязвимы для медленной атаки. Я использовал slowloris, чтобы отключить некоторые из сайтов nginx моего друга, используя только мой ноутбук, и обычно это занимало менее 5 минут (мои друзья попросили меня сделать это).
Как заявляет Вальяла, технически nginx не подвержен slowloris, но настройки по умолчанию ограничивают максимальное количество соединений, поэтому, когда число соединений превышает это число, nginx отбрасывает новый запрос, что приводит к отказу в обслуживании.
Известные способы защиты nginx от slowloris включают ограничение количества подключений с одного IP-адреса и увеличение конфигурации worker_connections. Атака может все еще работать, но она становится сложнее (может быть, более 5 минут?: D)
источник