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 до инцидента, а не во время. - Блокировки по большим подсетям — крайняя мера: они молча режут настоящих клиентов.