Налаштування rate limiting у Nginx для захисту від простих DDoS-атак

Практично будь-який веб-сайт рано чи пізно стикається з різким зростанням кількості запитів. Іноді причина цілком приємна - просто одна з публікацій несподівано набула популярності, і на сайт одночасно завітали тисячі відвідувачів. Шкода, але таке трапляється не так часто, як хотілося б. Набагато частіше сплеск створюють автоматичні сканери, настирливі боти або прості DDoS-атаки. Їхньої потужності зазвичай недостатньо, щоб вплинути на великі інфраструктури, зате невеликий VPS або окремий веб-сервер вони цілком здатні завантажити майже до межі.

Зменшити таке навантаження можна досить простим способом. Для цього у веб-сервері Nginx є механізм rate limiting, який обмежує частоту запитів від одного клієнта. Повноцінний захист від DDoS він, звичайно, не замінить, але здатний відсіяти значну частину небажаного трафіку ще на рівні веб-сервера. До додатка ці запити вже не дійдуть, а отже, процесор, пам’ять та інші ресурси витрачатимуться набагато економніше.

Що таке rate limiting

Rate limiting - це обмеження кількості запитів, які один клієнт може надіслати за певний проміжок часу. Зазвичай Nginx відстежує клієнтів за IP-адресою, хоча за потреби можна використовувати й інші параметри.

Є проста аналогія. Уявіть невелике кафе з однією касою. Якщо відвідувачі підходять по черзі, то все працює спокійно. Але варто одній великій групі одночасно зайняти чергу, як решта починає чекати. Приблизно так само поводиться й сервер під високим навантаженням. Rate limiting обмежує швидкість запитів від кожного джерела, тому один клієнт уже не може зайняти всі доступні ресурси.

Такий механізм допомагає в найрізноманітніших ситуаціях. Наприклад, він зменшує наслідки від:

• простих HTTP-флуд-атак;
• спроб підбору паролів;
• автоматичного сканування сайту ботами;
• занадто агресивних парсерів.

І якщо обмеження підібрані розумно, то звичайні відвідувачі їх навіть не помітять. Зате підозріла активність почне натрапляти на встановлений ліміт ще до того, як створить серйозне навантаження на ваш сервер.

Як працює обмеження запитів у Nginx

Механізм обмеження запитів у Nginx базується на двох директивах: limit_req_zone та limit_req. Перша визначає зону пам’яті, де сервер зберігає інформацію про те, як часто кожен клієнт звертається до сайту.

Наприклад:

limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

Тут використовується кілька параметрів:

• $binary_remote_addr - це ідентифікатор клієнта, яким зазвичай стає його IP-адреса у двійковому форматі;
• zone=api_limit:10m - це ім’я зони та обсяг пам’яті, виділений для зберігання статистики;
• rate=10r/s - ліміт у десять запитів на секунду для кожного клієнта.

Але одного цього правила само по собі недостатньо, оскільки воно лише створює зону з налаштуваннями. А щоб обмеження почало діяти, його потрібно прив’язати до потрібного блоку location, server або навіть до всього http.

Наприклад:

location / {

    limit_req zone=api_limit burst=20 nodelay;

}

Тут з’являються ще два параметри.

• burst=20 - дозволяє короткочасне перевищення основного ліміту. Це корисно під час звичайної роботи сайту, оскільки браузер рідко завантажує сторінку одним запитом, і зазвичай одночасно запитуються HTML-документ, таблиці стилів, JavaScript, зображення та інші ресурси, яких іноді буває кілька десятків.

• nodelay - змінює поведінку при перевищенні ліміту. Якщо цей параметр вказано, зайві запити відхиляються одразу, а без нього Nginx спробує ненадовго поставити їх у чергу й обробити пізніше, якщо це дозволить задана швидкість.

Які значення обирати

Найчастіше проблеми виникають не через занадто м’які налаштування, а через занадто жорсткі. Бажання максимально обмежити потік запитів цілком зрозуміле, але найчастіше прагнення до цього нерідко починає заважати звичайним відвідувачам.

Наприклад, обмеження 2r/s виглядає безпечним, але насправді часто виявляється занадто жорстким, адже навіть без будь-якої атаки користувач може швидко оновити сторінку, відкрити кілька вкладок або виконати кілька дій поспіль у веб-інтерфейсі. А в результаті частина запитів отримає відповідь 429 Too Many Requests, хоча жодної шкідливої активності не відбувалося.

Для більшості проєктів можна орієнтуватися на такі значення:

• корпоративний сайт - 5–10 запитів на секунду;
• інтернет-магазин - 10–20 запитів на секунду;
• REST API - зазвичай 20–50 запитів на секунду, якщо операції не надто ресурсомісткі;
• адміністративна панель - 2–5 запитів на секунду з невеликим значенням burst.

ВАЖЛИВО! Ці цифри не можна вважати універсальними, але вони допомагають обрати початкову конфігурацію. А далі вже варто переглянути реальні журнали Nginx, характер навантаження та поведінку користувачів, після чого прийняти рішення щодо зміни лімітів у той чи інший бік. Іноді після кількох днів спостережень стає зрозуміло, що ліміт можна підвищити, а буває й навпаки.

Захист сторінки авторизації

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

Приклад налаштування для такої сторінки може виглядати приблизно так:

location = /login {

    limit_req zone=login_limit burst=5 nodelay;

}

З таким правилом одна IP-адреса вже не зможе без пауз надсилати величезну кількість спроб авторизації. Частина запитів одразу отримуватиме відмову, а додаток не перевірятиме логін і пароль у базі даних щоразу.

У такому випадку навантаження помітно зменшується. До того ж метод «brute force» стає менш зручним для зловмисника, адже швидкість перебору зменшується до неприйнятної, а підозрілі запити легше помітити в логах веб-сервера.

Чого rate limiting не вміє

Але, як і у будь-якого іншого механізму, у rate limiting є свої обмеження. Він досить добре справляється з простими сценаріями, але ось проти деяких типів атак його можливостей уже стає недостатньо.

Наприклад, якщо запити надходять одночасно з десятків тисяч IP-адрес, а кожне джерело вкладається у встановлений ліміт, то Nginx не побачить у цьому нічого незвичайного. Для протидії розподіленим DDoS-атакам такого масштабу зазвичай використовують CDN, системи очищення трафіку або спеціалізовані Anti-DDoS-сервіси.

До речі, є ще один важливий момент. Rate limiting стежить лише за частотою звернень, а вміст HTTP-запитів він не аналізує взагалі, тому виявити складні атаки на рівні додатка, такі як спроби експлуатації вразливостей або шкідливі послідовності запитів, цей механізм не зможе.

Тому rate limiting краще розглядати як один із захисних рубежів, який сам по собі не вирішить усіх проблем, але в поєднанні з іншими засобами безпеки помітно знижує ризики та допомагає серверу витримати багато простих атак без серйозних наслідків.

Корисні рекомендації

Ефективність rate limiting багато в чому залежить від того, наскільки ретельно підібрані налаштування. Універсальних значень, як ми вже згадували вище, тут немає, зате є кілька практичних правил, які допомагають уникнути типових помилок.

По-перше, не варто вмикати обмеження для всіх запитів без винятку. Статичні файли, такі як зображення, таблиці стилів, JavaScript тощо, рідко стають причиною серйозного навантаження самі по собі. Набагато корисніше обмежувати сторінки авторизації, API, форми пошуку та інші точки, до яких найчастіше звертаються боти.

Після зміни конфігурації варто кілька днів поспостерігати за логами Nginx. Якщо код відповіді 429 Too Many Requests починає регулярно з’являтися у звичайних користувачів (таке іноді трапляється після занадто агресивних налаштувань), тоді ліміти краще переглянути.

І ще один важливий момент. Rate limiting добре працює разом з іншими засобами захисту. Такі інструменти, як брандмауер, Fail2Ban, WAF, правильно налаштовані тайм-аути з’єднань - усі вони доповнюють один одного. У підсумку сервер стає набагато стійкішим до автоматичних атак і сплесків небажаного трафіку.

Висновок

Налаштувати rate limiting у Nginx можна буквально за кілька хвилин. При цьому ефект виявляється цілком відчутним одразу, оскільки сервер починає краще справлятися з простими DDoS-атаками, масовим скануванням та настирливими ботами. А додаткових ресурсів цей механізм майже не вимагає.

Для VPS таке налаштування вже давно стало доброю практикою. Воно знижує ймовірність того, що одне джерело зможе створити надмірне навантаження на ваш сервер, чим допомагає зберегти запас продуктивності в моменти різкого зростання кількості запитів.

Звісно, rate limiting не замінює повноцінний захист від розподілених DDoS-атак. Але разом із брандмауером, Fail2Ban, WAF та іншими засобами безпеки він створює додатковий рубіж, який відсікає значну частину небажаного трафіку ще до того, як запити потраплять у додаток. А якщо ліміти підібрано правильно, звичайні відвідувачі, швидше за все, навіть не помітять роботи цього механізму.