Атаки на машину: що робимо ми і що можете ви

Слово «атака» звучить однаково у двох абсолютно різних ситуаціях: коли ваш канал забиває сміттєвий трафік і коли кілька сотень запитів за секунду кладуть ваш застосунок. Поводяться з ними по-різному, і перше, що треба зробити, — з'ясувати, з чим саме ви зіткнулися.

Як відрізнити одне від одного

Подивіться на графіки процесора, пам'яті та трафіку в «Огляді» за адресою /hosting/vds/m/<id> за останні 24 години. Якщо трафік нормальний, а процесор упирається в стелю — це навантаження застосунку, і розбиратися з ним потрібно на вашому боці.

Що ви можете зробити

Обмеження частоти запитів у nginx:

limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=conn:10m;

server {
    limit_req zone=perip burst=20 nodelay;
    limit_conn conn 20;
    client_body_timeout 10s;
    client_header_timeout 10s;
}

Обмеження з'єднань у фаєрволі:

ufw limit 22/tcp

Гнучкіші правила — у статті про nftables: там також можна обмежувати частоту нових з'єднань і вести список заблокованих адрес із часом життя.

Знайдіть джерело в логах:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
ss -tn state established | awk '{print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head

Одноразове блокування адреси або мережі:

ufw deny from 203.0.113.0/24

fail2ban може автоматизувати блокування на основі логів.

Що робимо ми

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

Чого захист на рівні вузла не робить: він не аналізує логіку вашого застосунку. Запити, які ззовні виглядають нормально, доходять до вашої машини, і захищає від них лише ваша власна конфігурація.

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

Кешування та статичні файли

Найдієвіший прийом проти шквалу запитів — не обчислювати те саме двічі:

location /static/ {
    expires 30d;
    add_header Cache-Control "public";
}

Кешуйте важкі сторінки на боці застосунку. Запит, відданий із кешу, коштує в сотні разів дешевше.

Типові помилки

• Налаштування limit_req без burst — звичайні користувачі, чия сторінка тягне два десятки файлів, відсікаються.
• Блокування адрес по одній вручну під час розподіленої атаки: їх тисячі, і ви не встигнете.
• Повне блокування ICMP — це ламає узгодження розміру пакетів, див. MTU.
• Плутанина власного бага з атакою: цикл у коді, пошуковий бот, що обходить каталог, який ви забули виключити, нескінченні повторні спроби клієнта.

Налаштуйте ліміти заздалегідь, на спокійній машині. Під час шквалу запитів ви не зможете підібрати значення rate і burst: редагуватимете конфіг наосліп і уривками.