Как защитить VPS от DDoS-атак — практическое руководство

Защитить VPS от DDoS-атак можно на нескольких уровнях — от правил iptables на самом сервере до провайдерского scrubbing-центра, который чистит трафик до того, как он доберётся до вашего канала. Какой уровень нужен конкретно вам — зависит от типа атаки и мощности. В этом руководстве разберём каждый инструмент: когда хватит iptables, когда подключить Cloudflare, и когда без провайдерского Anti-DDoS уже не обойтись.

Какие бывают DDoS-атаки: три уровня, которые ломают VPS

Прежде чем настраивать защиту, нужно понять, на каком уровне идёт атака. Инструменты для L3 и L7 совершенно разные — конфигурация iptables не поможет при медленной HTTP-атаке, а Nginx rate limiting бессилен против volumetric-флуда на 50 Гбит/с.

L3/L4: атаки на канал и TCP-стек

L3-атаки (volumetric) — это ICMP-флуд и UDP-флуд, которые заполняют входящий канал мусорными пакетами. VPS без защиты умирает уже при 500 Мбит/с такого трафика: канал забит, сервер недоступен, хотя CPU простаивает.

SYN-флуд (L4) работает иначе: атакующий отправляет миллионы TCP-запросов на установку соединения, не завершая handshake. Ядро накапливает half-open connections в очереди, пока не исчерпывает ресурсы. Типичная картина: load average растёт, CPU пустой, в логах — тысячи SYN_RECV в выводе ss -nt.

L7: HTTP-флуд и медленные атаки

L7-атаки сложнее отфильтровать на сетевом уровне, потому что с точки зрения TCP-стека каждый пакет легитимен. Slow Loris держит соединения открытыми, отправляя HTTP-заголовки по одному байту — веб-сервер ждёт завершения запроса и постепенно исчерпывает пул воркеров.

HTTP-флуд бьёт по тяжёлым endpoint’ам: поиск по сайту, страница авторизации, корзина интернет-магазина. Тысячи запросов к /search/?q=... нагружают БД и PHP-интерпретатор, даже если каждый запрос выглядит как обычный браузерный.

Первый рубеж — настройка iptables на VPS

iptables (и его современная замена nftables) — первое, что нужно настроить на любом VPS. Правила работают на уровне ядра, до того как трафик дойдёт до Nginx или приложения. Это не спасёт от volumetric-атаки на 10 Гбит/с, но надёжно закроет SYN-флуд и ограничит количество соединений с одного IP.

Ограничение новых соединений (connlimit)

Правило ниже блокирует IP, который открывает более 50 новых TCP-соединений одновременно. Порог 50 — баланс: легитимный браузер открывает 6–10 параллельных соединений, агрессивный сканер или флудер — сотни.

# Ограничение одновременных TCP-соединений с одного IP
iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 50 -j REJECT --reject-with tcp-reset

# Ограничение новых соединений: не более 30 в секунду с одного IP
iptables -A INPUT -p tcp --syn -m limit --limit 30/s --limit-burst 60 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

SYN-куки и защита TCP-стека

SYN cookies — механизм ядра, который позволяет обрабатывать SYN-флуд без переполнения очереди half-open connections. При активации ядро перестаёт хранить состояние до завершения handshake. Настраивается через sysctl:

# /etc/sysctl.d/99-ddos.conf
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 3
net.core.somaxconn = 4096

Применить без перезагрузки: sysctl -p /etc/sysctl.d/99-ddos.conf

Блокировка UDP-флуда и ICMP-лимиты

# Лимит ICMP (ping): 1 пакет в секунду, burst до 5
iptables -A INPUT -p icmp -m limit --limit 1/s --limit-burst 5 -j ACCEPT
iptables -A INPUT -p icmp -j DROP

# Блокировка входящего UDP на нестандартных портах (если UDP не нужен)
iptables -A INPUT -p udp --dport 1:1023 -j DROP

Nginx как фильтр L7-атак

Когда атака проходит сетевой уровень и добирается до веб-сервера, в дело вступает Nginx. Модуль ngx_http_limit_req_module позволяет ограничить количество запросов с одного IP по заданной зоне. По данным нагрузочных тестов, Nginx rate limiting снижает нагрузку на приложение при HTTP-флуде до приемлемого уровня при атаках до 10 000 RPS при правильно настроенных зонах. Полная документация модуля limit_req доступна на официальном сайте.

Rate limiting по IP

http {
    # Зона для общих запросов: 10 МБ памяти под счётчики, 30 req/min с одного IP
    limit_req_zone $binary_remote_addr zone=general:10m rate=30r/m;

    # Зона для API: жёстче — 10 req/min
    limit_req_zone $binary_remote_addr zone=api:10m rate=10r/m;

    server {
        location / {
            # burst=20 — допускает всплески до 20 запросов сверх нормы
            # nodelay — не ставить в очередь, сразу обрабатывать burst
            limit_req zone=general burst=20 nodelay;
        }

        location /api/ {
            limit_req zone=api burst=5 nodelay;
        }
    }
}

Параметр burst — это запас, который Nginx разрешает «потратить» при всплеске. Без nodelay запросы из burst-квоты ставятся в очередь и обрабатываются постепенно. С nodelay они проходят немедленно, но лимит квоты снижается — защита от лавинообразных атак становится строже.

Защита тяжёлых endpoint’ов

http {
    # Отдельная жёсткая зона для уязвимых URL
    limit_req_zone $binary_remote_addr zone=sensitive:10m rate=5r/m;

    server {
        # WordPress: страница входа и XML-RPC — топ целей для брутфорса и флуда
        location ~ ^/(wp-login\.php|xmlrpc\.php) {
            limit_req zone=sensitive burst=3 nodelay;
        }

        # Поиск — тяжёлый запрос к БД
        location /search/ {
            limit_req zone=sensitive burst=5 nodelay;
        }
    }
}

Блокировка пустых User-Agent и странных заголовков

server {
    # Боты без User-Agent: код 444 закрывает соединение без ответа
    if ($http_user_agent = "") {
        return 444;
    }

    # Блокировка известных атакующих User-Agent (пример)
    if ($http_user_agent ~* (sqlmap|nikto|masscan|nmap)) {
        return 444;
    }
}

Код 444 — специфика Nginx: соединение разрывается без отправки HTTP-ответа, что снижает нагрузку по сравнению с return 403.

Cloudflare как прокси — быстрый способ закрыть L7

Бесплатный план Cloudflare закрывает большинство L7-атак: HTTP-флуд, медленные атаки, боты без User-Agent. Принцип работы — трафик идёт через серверы Cloudflare, которые фильтруют запросы до того, как они дойдут до вашего VPS. Если вы только переехали с виртуального хостинга — читайте инструкцию как перенести сайт на VPS перед настройкой Cloudflare.

Что Cloudflare Free не закрывает: volumetric-атаки L3/L4 на IP-адрес VPS. Если злоумышленник знает реальный IP сервера и бьёт напрямую — Cloudflare в стороне. Для защиты от этого нужен либо провайдерский Anti-DDoS, либо смена IP с сохранением его в тайне. Подробно: официальная документация Cloudflare по DDoS.

Настройка за 15 минут

1. Зарегистрироваться на cloudflare.com, добавить домен
2. Сменить NS-серверы у регистратора на выданные Cloudflare
3. В DNS-записях включить проксирование (оранжевое облако) для A-записи сайта
4. Security → Settings → Security Level установить «High» или «I’m Under Attack»
5. Firewall Rules: заблокировать трафик из нерелевантных стран (если аудитория локальная) или по подозрительным ASN

Режим «I’m Under Attack» включает JS Challenge для каждого посетителя — браузер выполняет JavaScript-проверку перед загрузкой страницы. Боты и скрипты без JS-движка отфильтровываются автоматически.

Ограничения бесплатного плана

Free plan не защищает UDP и TCP-трафик (актуально для игровых серверов, торговых терминалов, нестандартных протоколов). Нет расширенной фильтрации по payload, нет Bot Management с машинным обучением, нет WAF-правил для конкретных CMS. Для этих сценариев нужен Business ($200/мес) или Enterprise план, либо специализированное WAF-решение.

Провайдерский Anti-DDoS — что это и когда без него не обойтись

Если на ваш IP идёт volumetric-атака 10–50 Гбит/с, ни iptables, ни Cloudflare не помогут: канал провайдера физически забивается до сервера. В этом случае нужна VPS с защитой от DDoS — провайдер фильтрует трафик upstream, на уровне BGP-маршрутизации, и передаёт на ваш сервер только чистый поток.

Провайдеры, которые работают с VPS в России и включают Anti-DDoS в тарифы, как правило, строят защиту на собственных или арендованных scrubbing-центрах.

Как работает scrubbing-центр

Схема работы: входящий трафик перенаправляется через BGP anycast в scrubbing-центр, где аномальные потоки отсеиваются по сигнатурам и поведенческим паттернам. Чистый трафик передаётся обратно на сервер через GRE-туннель или прямой канал. Задержка при очистке — 5–15 мс в зависимости от географии центра.

При экстремально высоком объёме атаки (сотни Гбит/с) провайдер может применить black hole routing — полную блокировку IP. Это крайняя мера: сервер недоступен, но атака не влияет на соседей в ЦОД.

Провайдеры с Anti-DDoS на free-hosting.ru

В каталоге VPS с защитой от DDoS собраны провайдеры с различными уровнями фильтрации. Из тех, что редакция рекомендует для большинства задач:

• Aeza — защита включена в базовые тарифы, инфраструктура в нескольких странах
• Selectel — российский провайдер, Anti-DDoS до 1 Тбит/с на старших тарифах
• AdminVPS — специализируется на защищённых VPS для высоконагруженных проектов

Fail2ban — автоматическая блокировка по логам

Fail2ban читает логи сервисов и блокирует IP через iptables при превышении порога ошибок. Это не замена rate limiting — fail2ban реагирует на уже случившиеся атаки, а не предотвращает их. Но для автоматизации бана перебора паролей по SSH и HTTP-флуда по access-логам — незаменим.

# Установка (Debian/Ubuntu)
apt install fail2ban

# Запуск и автозапуск
systemctl enable --now fail2ban

Настройка jail для Nginx

Создаём фильтр, который ловит строки limiting requests в access-логе Nginx — именно так выглядят записи при срабатывании limit_req:

# /etc/fail2ban/filter.d/nginx-req-limit.conf
[Definition]
failregex = limiting requests, excess:.* by zone .*, client: <HOST>
ignoreregex =

# /etc/fail2ban/jail.local
[nginx-req-limit]
enabled  = true
port     = http,https
filter   = nginx-req-limit
logpath  = /var/log/nginx/error.log
maxretry = 5
bantime  = 3600
findtime = 600

Параметры: maxretry = 5 — бан после 5 срабатываний в окне findtime = 600 секунд. bantime = 3600 — блокировка на час. После применения проверить: fail2ban-client status nginx-req-limit.

Интеграция с iptables и nftables

Fail2ban поддерживает несколько backend’ов: iptables, nftables, ipset. На современных ядрах (Ubuntu 22.04+, Debian 12) рекомендуем nftables — он быстрее при большом количестве правил и не создаёт дополнительных цепочек в iptables-legacy.

# /etc/fail2ban/jail.local
[DEFAULT]
banaction = nftables-multiport
banaction_allports = nftables-allports

Мониторинг трафика в реальном времени

Настроенная защита полезна только если вы знаете, что происходит с трафиком. Набор инструментов для мониторинга на VPS под Linux:

• iftop — интерактивный вывод трафика по соединениям в реальном времени (iftop -i eth0)
• nethogs — трафик по процессам, полезно найти, какой демон генерирует нагрузку
• vnstat — статистика трафика по дням и месяцам, хранит историю
• tcpdump — захват пакетов для детального анализа аномалий

Если атака уже идёт — первые пять команд в консоли:

# 1. Смотрим топ IP по количеству соединений
ss -nt | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

# 2. Сколько SYN_RECV — признак SYN-флуда
ss -nt state syn-recv | wc -l

# 3. Трафик по интерфейсу
iftop -i eth0 -n

# 4. Смотрим, что забивает канал (top-10 IP)
tcpdump -i eth0 -nn -c 1000 | awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -rn | head -10

# 5. Быстрая блокировка IP (пока разбираемся)
iptables -A INPUT -s АТАКУЮЩИЙ_IP -j DROP

Защита на уровне ОС настроена — следующий шаг: базовая конфигурация VPS. Читайте руководство как настроить VPS с нуля.

Защитные меры по уровням атак — сводная таблица

Ну и в заключение: чеклист — VPS защищён, проверяем за 10 минут

Быстрый аудит: если всё из списка выполнено — базовый уровень защиты достигнут.

1. SSH только по ключу — парольная аутентификация отключена в /etc/ssh/sshd_config (PasswordAuthentication no)
2. Нестандартный порт SSH — не 22, иначе в логах постоянный перебор
3. iptables активен — iptables -L -n показывает правила, connlimit и SYN-лимиты настроены
4. SYN cookies включены — sysctl net.ipv4.tcp_syncookies возвращает 1
5. Fail2ban запущен — systemctl status fail2ban, jail для SSH и Nginx активны
6. Nginx rate limiting настроен — зоны для общих запросов и чувствительных endpoint’ов
7. Cloudflare включён — A-запись домена с оранжевым облаком, JS Challenge для подозрительных запросов
8. Реальный IP сервера скрыт — не светится в заголовках, почтовых записях SPF, исторических DNS
9. Мониторинг настроен — vnstat или netdata, алерты на аномальный трафик
10. Провайдер с Anti-DDoS — если сервис критичный или уже были атаки

Если у вашего хостера нет встроенного Anti-DDoS — каталог VPS с защитой от DDoS поможет выбрать провайдера с нужным уровнем фильтрации. Там же — фильтр по каналу и типу защиты.

Для сравнения тарифов по всему рынку — каталог VPS-хостингов с фильтрами по характеристикам.