Як протистояти DDoS-атакам за допомогою NGINX і NGINX Plus +14
- 14.01.16 11:17 •
- 1cloud •
- # 275107 •
- Хабрахабр •
- Переклад •
- 5 •
- 15200
- такий же як Forbes, тільки краще.
Введення: що таке DDoS
Distributed Denial of Service attack - «розподілена атака на сервіс з метою його відмови від обслуговування» - це спроба зробити будь-який сервіс, зазвичай веб-сайт, недоступним, шляхом бомбардування його трафіком з багатьох джерел. В результаті сервер, його обслуговуючий, просто перестає нормально працювати, не справляючись з перевантаженнями.
Стандартна схема в цій справі - «замучити» систему такою кількістю нових з'єднань і запитів, щоб мережа перестала справлятися з їх потоком, або стала настільки повільної, що з нею неможливо працювати.
Технічні характеристики DDoS-атаки
На прикладному рівні DDoS-атака проводиться спеціальними програмами (ботами), які можуть використовувати уразливості в конкретній системі. Наприклад, система, яка не заточена під управління великим числом паралельних з'єднань, може бути виведена з ладу шляхом створення великого числа таких «коннектов». В активному стані їх можна підтримувати, час від часу засилаючи через них невеликі обсяги трафіку. Інший варіант - завалювати систему великою кількістю запитів або робити ці запити досить важкими. Адже мова йде не про актуальні з'єднаннях, тому через боти дуже легко відправляти величезна кількість запитів і швидко створювати безліч нових з'єднань.
Нижче наведені технічні характеристики DDoS-атак, за якими їх можна розпізнати, і, з огляду на які, з ними впоратися:
Можливості NGINX і NGINX Plus по боротьби з DDoS-атаками
Багато характеристики NGINX і NGINX Plus можуть надати неоціненну допомогу при вирішенні питань, як впоратися з DDoS-атакою. Працює це за двома напрямками: через управління входять трафіком і через контроль його розподілу по внутрішніх серверів.
Обмеження частоти запитів
Ви можете відрегулювати частоту вхідних запитів через NGINX і NGINX Plus до значення, характерного для реальних користувачів. Наприклад, ви вважаєте, що на вашу головну сторінку користувачі заходять кожні дві секунди. Ви можете налаштувати обладнання на цю частоту запитів на сторінку - 30 в хвилину.
Обмеження числа з'єднань
Закриття повільних з'єднань
Ви можете закрити з'єднання, які посилають дані надто рідко, що може бути ознакою того, що їх головна мета - бути відкритими протягом довгого часу і перешкоджати новим з'єднанням. Цей тип програми для атаки називають Slowloris. Директива client_body_timeout контролює час очікування NGINX між записами в тілі клієнта. Директива client_header_timeout робить те ж для заголовків. За замовчуванням в обох випадках ставиться 60 секунд. У наступному прикладі цей інтервал встановлюється на значенні 5 секунд.
Кешування для запобігання стрибків трафіку
Ви можете налаштувати NGINX і NGINX Plus, щоб вони поглинали скачки трафіку під час атаки через кешування і пропис його параметрів, вони будуть ігнорувати зворотні запити. Це можна зробити наступними варіантами:
Параметр поновлення в proxy_cache_use_stale повідомляє NGINX, що, коли йому необхідно провести оновлення застарілих об'єктів в кеші, йому слід відправляти лише один запит і тримати відкритим доступ до таких об'єктів для клієнтів, поки оновлення з внутрішніх серверів ніхто не почув.
Key defined by the proxy_cache_key зазвичай складається з вбудованих варіацій (default key. $ Scheme $ proxy_host $ request_uri має три варіації). Якщо значення включає $ query_string. то атака, що посилає рідкісні рядки запитів, може привести до надмірного кешуванню. Не рекомендується включати цей варіант в ключ, якщо в цьому немає нагальної потреби.
Блокування запитів
Ви можете налаштувати NGINX і NGINX Plus для блокування наступних видів запитів:
- Запити до певного URL, яке може бути під загрозою.
- Запити, де заголовки User-Agent мають значення, яке не відповідає звичайному клієнтського трафіку.
- Запити, в яких заголовки Referer можуть бути визначені, як пов'язані з атакою.
- Запити, в яких інші заголовки здаються підозрілими.
Наприклад, якщо ви вирішили, що атака націлена на URL /foo.php, можете заблокувати всі запити на сторінку:
Якщо ви з'ясували, що запити DDoS-атаки мають значення foo або bar в заголовках User Agent, можете заблокувати і їх:
За таким же принципом можна працювати з іншими заголовками, які мають значення, що вказують на загрозу атаки.
Обмеження з'єднань до внутрішніх серверів
NGINX і NGINX Plus можуть одночасно управлятися з великим числом з'єднань, ніж дозволяють собі внутрішні сервери. За допомогою NGINX Plus ви можете обмежити кількість з'єднань до кожного з внутрішніх серверів. Припустимо, ви хочете обмежити число підключень до двох внутрішніх серверів групи, яка обслуговує сайт, числом 200:
Параметр max_conns встановлює для кожного сервера максимальне число підключень, відкритих NGINX Plus. Директива queue обмежує число запитів знаходяться в черзі, якщо всі сервери групи перевищили свій ліміт. У цьому ж рядку прописано час перебування запиту в черзі - 30 секунд.
Range-Based-атаки
Як справлятися з великими завантаженнями
DDoS-атаки зазвичай ведуть до критичного підвищення рівня завантаження. Почитати про те, як навчити NGINX і NGINX Plus і ОС справлятися з цією проблемою, можна тут.
Виявлення DDoS-атаки
До сих пір ми обговорювали, як можна використовувати NGINX і NGINX Plus, щоб пом'якшити наслідки DDoS-атаки. Але чи можна за допомогою цих серверів виявити саму атаку? Модуль NGINX Plus Status надає детальні метричні показники трафіку, який був розподілений по внутрішніх серверів. Цей інструмент дозволяє розпізнати ненормальні стану трафіку. NGINX Plus має функцію панелі управлінні сторінкою сайту, де відображаються графіки поточного стану роботи його системи (приклад можна подивитися тут: demo.nginx.com/status.html). Ті ж самі показники доступні через API, їх можна вбудувати в власну або сторонню систему моніторингу, і відслідковувати в часі зміни трафіку, попереджаючи незвичайні його стану.
NGINX і NGINX Plus можуть надати неоціненну допомогу при вирішенні питань, як лікувати DDoS-атаки. При цьому NGINX Plus володіє додатковими властивостями для захисту від подібного роду атак, що попереджають їх появу.
Чому не написали про 444 код
що на основі скоріговой системи можнло Залогуватися і блогіровать через ipset або iptables raw
set $ add 1;
location /index.php limit_except GET POST deny all;
>
set $ ban "";
if ($ http_referer = "")
if ($ request_method = POST)
if ($ query_string = «action = login»)
if ($ ban = 111) access_log / var / log / [133] nginx / ban IP;
return 444;
>
proxy_pass 127.0.0.1: 8000;
>
ну і метрик для скорингу накрутити
ні слова про тюнінг ядра ... хоч це безпосередньо до нгінксу і не відноситься тему можна було б висвітлити.
Директива client_body_timeout контролює час очікування NGINX між записами в тілі клієнта. Директива client_header_timeout робить те ж для заголовків. За замовчуванням в обох випадках ставиться 60 секунд. У наступному прикладі цей інтервал встановлюється на значенні 5 секунд.
Акуратніше з такими значеннями. Можна легко так пустити під ніж мобільних клієнтів.