К основному содержимому

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

Выделенные серверы · 24.09.2026
Иллюстрация к статье «DDoS-защита выделенного сервера: уровни L3, L4 и L7»

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