Чому Sginloris не впливає на NginX та Lighttpd?

23

Я розслідую вразливість до Slowloris і, думаю, я розумію, як і чому працює така атака.

Я не розумію, чому Lighttpd і NginX не впливають (відповідно до тієї ж статті, що і вище). Що вони роблять настільки різними?

— Шурик
джерело

25

Apache має теорію "максимальних клієнтів"

Це кількість одночасних з'єднань, з якими вона може працювати. Тобто, якщо сервер apache має обмеження "максимум клієнтів" 100, і для кожного запиту потрібно 1 секунда, він може обробляти максимум 100 запитів в секунду.

Такий додаток, як SlowLoris, затопить сервер із з'єднаннями, у нашому прикладі, якщо SlowLoris надсилає 200 з'єднань в секунду, а Apache може обробляти лише 100 з'єднань в секунду, черга на з'єднання буде збільшуватися та використовувати всю пам'ять на машині, що приводить її до халат. Це схоже на те, як працює LOIC Anonymous '.

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 насправді вразливий до нападу уповільнення. Дефіцитний ресурс - це максимальна кількість одночасних робочих з'єднань. Ця кількість може бути обчислена як робочі_з'єднання * робочі_процеси і дорівнює 512 у налаштуваннях nginx за замовчуванням. Отже, зняти незахищений nginx за допомогою таких інструментів, як goloris, досить легко .

— валяла
джерело

golorisвиглядає як інструмент, який мені потрібен, щоб переконатися, що моя реалізація / налаштування працює так, як очікувалося!

— Алексіс Вілке

8

коментар valyala слід сприймати як відповідь.

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

Як зазначав Валяла, технічно nginx не вразливий для уповільнення, але конфігурації за замовчуванням обмежують максимальну кількість з'єднань, тому коли з'єднання перевищують це число, nginx скидає новий запит, що призводить до відмови в обслуговуванні.

Відомі способи захисту nginx від slowloris включають обмеження кількості з'єднань з одного і того ж IP, а також збільшення конфігурації Working_connections. Атака все ще може працювати, але стає важче (можливо, це займе більше 5 хвилин?: D)

— Нгуен Фан Тан
джерело