DDoS-захист виділеного сервера: L3, L4, L7

Захист від DDoS працює на трьох рівнях. L3 і L4 фільтрують пакетне сміття — UDP-флуд, відбиті відповіді, SYN-флуд — і робиться це на боці мережі провайдера, до вашого порту. L7 розбирає вже встановлені HTTP-запити й відсікає тих, хто імітує браузер. Перші два рівні рятують канал, третій — застосунок, і замінити один одним не вийде.

На майданчиках у Німеччині та США працює фільтрація L3/L4; на тарифах Pro і вище додається L7.
У Франції стоїть Anti-DDoS Arbor — він знімає об'ємні атаки на рівні мережі.
Сервер не може захистити себе від об'ємної атаки сам: якщо канал забитий, ваші правила вже не допоможуть.

Чим відрізняються рівні

Рівень	Типові атаки	Де фільтрується	Що ламається без захисту
L3 (мережа)	ICMP-флуд, IP-фрагменти, відбиття через відкриті сервіси	Мережа провайдера, до порту сервера	Канал забитий, сервер недоступний цілком
L4 (транспорт)	SYN-флуд, ACK-флуд, UDP-флуд, amplification	Мережа провайдера плюс ядро сервера	Переповнення таблиці з'єднань, відмова в нових сесіях
L7 (застосунок)	HTTP-флуд, повільні запити, перебір важких сторінок	Reverse proxy, WAF, сам застосунок	Процесор і база йдуть у полицю за скромного трафіку

Різниця в цифрах: об'ємна L3/L4-атака вимірюється в гігабітах і мільйонах пакетів за секунду, а L7-атаці вистачає 3–5 тисяч запитів за секунду, щоб покласти сайт на динаміці. Як співвідносяться швидкість порту й реальне навантаження, розібрано в статті про канал сервера й ліміти трафіку.

Що включено на майданчиках ZevsHost

Локація	Базовий захист	L7
Німеччина (Дюссельдорф)	L3/L4	На Dedicated Pro DE і вище
США	L3/L4	На Dedicated Pro US та Enterprise US
Франція (Страсбург)	Anti-DDoS Arbor	Фільтрація на рівні мережі

Базовий рівень L3/L4 є на всіх тарифах, включно з Dedicated Start DE за $49 і Dedicated Start US за $59. Розбір конфігурацій за тарифами — на сторінці виділених серверів.

Як відрізнити атаку від напливу відвідувачів

Наплив дає зростання запитів за нормального розподілу адрес, реферерів і кодів відповіді. Атака майже завжди видна перекосом: один URL, один User-Agent, однакова довжина запиту або тисячі напіввідкритих з'єднань.

# розподіл з'єднань за станами: багато SYN-RECV — це SYN-флуд
ss -ant | awk '{print $1}' | sort | uniq -c | sort -rn

# топ-20 адрес за кількістю з'єднань
ss -ant | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

# пакети й байти за секунду по інтерфейсу
sar -n DEV 1 5
ip -s link show eth0

Повний набір інструментів для розбору мережевих проблем описано в статті про діагностику мережі в Linux.

Що налаштувати на своєму боці

Ядро: стійкість до SYN-флуду

cat << 'EOF' > /etc/sysctl.d/90-antiddos.conf
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_synack_retries = 2
net.core.somaxconn = 8192
net.netfilter.nf_conntrack_max = 524288
EOF

sysctl --system
sysctl net.ipv4.tcp_syncookies net.core.somaxconn

Пакетні ліміти

# nftables: обмежити темп нових SYN і кількість з'єднань з адреси
nft add table inet ddos
nft add chain inet ddos input '{ type filter hook input priority -10 ; policy accept ; }'
nft add rule inet ddos input tcp flags syn limit rate over 2000/second drop
nft add rule inet ddos input tcp dport 443 ct state new meter conns '{ ip saddr limit rate over 50/second }' drop

Застосунок: ліміти в nginx

# у http-секції
limit_req_zone $binary_remote_addr zone=perip:20m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=connperip:20m;

# у server-секції
limit_req zone=perip burst=30 nodelay;
limit_conn connperip 20;
limit_req_status 429;

# перевірка конфігу й перечитування без обриву з'єднань
nginx -t && systemctl reload nginx

Не блокуйте атаку за країнами й великими підмережами на живому сервері. За одним /16 часто стоїть мобільний оператор або хмарний провайдер, через якого до вас ідуть звичайні клієнти, платіжні вебхуки й перевірки моніторингу. Блокування такого блоку виглядає як «атака припинилася», а насправді ви відрізали частину виручки й не побачите цього в логах, бо запити до вебсервера вже не доходять. Правильний порядок: спершу ліміт за темпом (limit_req, limit rate), потім точковий бан за конкретними адресами, і лише потім — широкі блоки, на час і з записом у календарі. Перевірка, що ви не відрізали своїх: частка відповідей 429 і 403 в лозі не вища за кілька відсотків, а curl із зовнішньої точки в кожній цільовій країні віддає 200.

Коли потрібен зовнішній шар

Якщо атака йде по HTTP і ваші ліміти вже ріжуть живих користувачів, навантаження виносять на зовнішній фільтр: він приймає трафік на себе, а до сервера йдуть лише перевірені запити. Налаштування такої схеми розібрано в статті про захист від DDoS через Cloudflare.

При цьому походження сервера має бути закрите: якщо реальна IP відома, атака піде повз фільтр навпростець. Закривайте порти 80 і 443 для всіх джерел, крім мереж фільтра, і не лишайте стару адресу в DNS-записах піддоменів, у заголовках пошти та в SSL-сертифікатах, випущених на пряму IP.

Коротко

L3/L4 рятують канал і фільтруються в мережі провайдера; L7 рятує застосунок і налаштовується у вас.
У Німеччині та США працює L3/L4, на Pro і вище додається L7; у Франції — Anti-DDoS Arbor.
Увімкніть tcp_syncookies, ліміти за темпом у nftables і limit_req у nginx до інциденту, а не під час.
Блокування за великими підмережами — крайній захід: вони мовчки ріжуть справжніх клієнтів.

DDoS-захист виділеного сервера: рівні L3, L4 і L7