Защита от DDoS на выделенном сервере

MAATRIX

DDoS перестал быть проблемой только крупных банков и игровых студий. Сегодня положить сайт или API мусорным трафиком стоит копейки, а страдают обычные проекты: интернет-магазин в сезон, корпоративный портал, игровой сервер. Выделенный сервер даёт вам полный контроль над стеком защиты — от ядра до аплинка. Разберём по шагам, что настраивается на самой машине, где её возможности заканчиваются и когда без внешней фильтрации не обойтись.

Что такое DDoS и почему одиночный сервер уязвим

DDoS (Distributed Denial of Service) — это распределённая атака, когда на вашу машину одновременно шлют запросы тысячи или миллионы заражённых устройств. Цель одна: исчерпать какой-то ресурс, чтобы легитимные пользователи не смогли подключиться.

Ресурс, который выбивают, бывает разным. Иногда это полоса канала: сервер получает 20 Гбит/с мусора при аплинке в 1 Гбит/с — и канал забит ещё до того, как пакеты дойдут до вашего фаервола. Иногда это процессор или память: атака тонкая, трафика немного, но каждый запрос заставляет сервер делать дорогую работу. Понимание того, какой именно ресурс под ударом, определяет всю стратегию защиты — универсального рубильника нет.

Ключевая мысль: пока атака помещается в ваш канал и в мощность железа, вы отбиваетесь сами. Как только объём превышает пропускную способность аплинка — локальные настройки бесполезны, спасает только фильтрация выше по сети, у провайдера.

Три типа атак: волюметрические, протокольные, прикладные

Атаки делятся на три уровня, и защита от каждого своя.

Волюметрические (L3/L4). Задача — забить канал. UDP-флуд, ICMP-флуд, а особенно амплификация: атакующий шлёт мелкий запрос на открытый DNS/NTP/memcached-сервер с подменённым обратным адресом, а тот отвечает жертве пакетом в десятки раз крупнее. Измеряются в Гбит/с и Mpps. Отбить на самом сервере почти невозможно — канал забивается до вас.

Протокольные (L4). Бьют по стеку TCP/IP и таблицам состояний. Классика — SYN-флуд: злоумышленник открывает полусоединения и не завершает их, переполняя очередь. Сюда же атаки на conntrack и на балансировщики. Трафика может быть немного, но сервер захлёбывается в служебных структурах.

Прикладные (L7). Самые коварные. Внешне это обычные HTTP-запросы, но их поток вымывает ресурсы: тяжёлые страницы, поиск по базе, перебор форм. Отличить бота от живого посетителя сложно — здесь работают лимиты, анализ поведения и капча, а не блокировка по IP.

Базовая защита в ядре Linux

Первый рубеж — настройки самого ядра. Они бесплатны, включаются за минуты и снимают значительную долю простых атак. Начните с защиты от SYN-флуда через SYN cookies и с разумных лимитов:

# /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_fin_timeout = 15
net.core.somaxconn = 4096
net.ipv4.conf.all.rp_filter = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1

Примените без перезагрузки: sysctl -p /etc/sysctl.d/99-ddos.conf. SYN cookies позволяют серверу отвечать на SYN-запросы без хранения состояния, поэтому очередь полусоединений не переполняется. Обратный путь (rp_filter) отсекает пакеты с явно поддельными адресами. Это не панацея, но простой SYN-флуд средней силы такие настройки гасят полностью.

Фаервол и ограничение частоты

Следующий слой — nftables (или iptables) с лимитами частоты. Идея не «заблокировать всех», а ограничить, сколько новых соединений и пакетов в секунду принимается с одного адреса. Пример на nftables:

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    ip protocol icmp limit rate 5/second accept
    tcp dport 22 ct state new limit rate 10/minute accept
    tcp dport { 80, 443 } ct state new limit rate 50/second accept
    tcp dport { 80, 443 } accept
  }
}

Здесь новые SSH-подключения ограничены десятью в минуту, новые веб-соединения — пятьюдесятью в секунду с общим лимитом, а всё установленное проходит свободно. Для агрессивных источников подключите модуль подсчёта соединений на адрес и блокируйте тех, кто держит их слишком много. Такой фаервол убирает грубые протокольные атаки, но против настоящей волюметрики он тоже бессилен — канал забьётся раньше.

Защита веб-приложения на уровне L7

Прикладные атаки не отфильтровать по IP — нужен анализ на уровне HTTP. Основной инструмент здесь Nginx. Ограничьте частоту запросов и число одновременных соединений с адреса:

# http {}
limit_req_zone $binary_remote_addr zone=web:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=conn:10m;

# server {} или location {}
limit_req zone=web burst=20 nodelay;
limit_conn conn 20;
client_body_timeout 10s;
client_header_timeout 10s;

Зона limit_req сглаживает всплески: до 10 запросов в секунду плюс запас в 20, дальше — код 503. Таймауты на тело и заголовки закрывают медленные атаки вроде Slowloris, когда соединение держат открытым, отправляя данные по байту. Тяжёлые эндпоинты (поиск, вход, корзину) выносите в отдельные, более строгие зоны. Для отсева ботов подключите проверку через JS-челлендж или капчу на подозрительных маршрутах, а статику кэшируйте, чтобы флуд по ней не доходил до бэкенда.

Когда локальной защиты мало: внешний scrubbing

Честно о пределе: если атака больше вашего канала, ни одна строчка в sysctl не поможет. Аплинк в 1 Гбит/с забьётся флудом в 5 Гбит/с целиком, и сервер станет недоступен, даже будучи полностью исправным. Здесь вступает фильтрация на стороне сети.

Внешняя очистка (scrubbing) работает так: трафик к вашему серверу заворачивается на фильтрующие узлы провайдера, где мусор отбрасывается, а к вам приходит только чистый поток. Второй механизм — BGP blackhole (RTBH): при сверхмощной атаке провайдер объявляет атакуемый адрес «чёрной дырой» на уровне магистралей, жертвуя одним IP ради работоспособности остальной сети. Выделенный сервер выигрывает и тут: у вас обычно широкий аплинк, отдельная IP-подсеть и возможность подключить защиту у провайдера, тогда как на дешёвом shared-хостинге вы делите и канал, и последствия чужих атак.

Мониторинг и план реагирования

Защита без наблюдения слепа. Настройте базовый мониторинг полосы и pps на интерфейсе — так вы отличите наплыв реальных клиентов от атаки. Быстрый снимок трафика в реальном времени:

# кто больше всех шлёт пакетов прямо сейчас
iftop -nNP -i eth0
# срез по соединениям
ss -s
# топ адресов в логе Nginx за сегодня
awk '{print 
Нужен сервер под эту задачу?
Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США и РФ. Оплата картой РФ и по СБП.
Выбрать выделенный сервер
Базовая защита в ядре Linux
Первый рубеж — настройки самого ядра. Они бесплатны, включаются за минуты и снимают значительную долю простых атак. Начните с защиты от SYN-флуда через SYN cookies и с разумных лимитов:
# /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_fin_timeout = 15
net.core.somaxconn = 4096
net.ipv4.conf.all.rp_filter = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
Примените без перезагрузки: sysctl -p /etc/sysctl.d/99-ddos.conf. SYN cookies позволяют серверу отвечать на SYN-запросы без хранения состояния, поэтому очередь полусоединений не переполняется. Обратный путь (rp_filter) отсекает пакеты с явно поддельными адресами. Это не панацея, но простой SYN-флуд средней силы такие настройки гасят полностью.
Фаервол и ограничение частоты
Следующий слой — nftables (или iptables) с лимитами частоты. Идея не «заблокировать всех», а ограничить, сколько новых соединений и пакетов в секунду принимается с одного адреса. Пример на nftables:
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    ip protocol icmp limit rate 5/second accept
    tcp dport 22 ct state new limit rate 10/minute accept
    tcp dport { 80, 443 } ct state new limit rate 50/second accept
    tcp dport { 80, 443 } accept
  }
}
Здесь новые SSH-подключения ограничены десятью в минуту, новые веб-соединения — пятьюдесятью в секунду с общим лимитом, а всё установленное проходит свободно. Для агрессивных источников подключите модуль подсчёта соединений на адрес и блокируйте тех, кто держит их слишком много. Такой фаервол убирает грубые протокольные атаки, но против настоящей волюметрики он тоже бессилен — канал забьётся раньше.
Защита веб-приложения на уровне L7
Прикладные атаки не отфильтровать по IP — нужен анализ на уровне HTTP. Основной инструмент здесь Nginx. Ограничьте частоту запросов и число одновременных соединений с адреса:
# http {}
limit_req_zone $binary_remote_addr zone=web:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=conn:10m;

# server {} или location {}
limit_req zone=web burst=20 nodelay;
limit_conn conn 20;
client_body_timeout 10s;
client_header_timeout 10s;
Зона limit_req сглаживает всплески: до 10 запросов в секунду плюс запас в 20, дальше — код 503. Таймауты на тело и заголовки закрывают медленные атаки вроде Slowloris, когда соединение держат открытым, отправляя данные по байту. Тяжёлые эндпоинты (поиск, вход, корзину) выносите в отдельные, более строгие зоны. Для отсева ботов подключите проверку через JS-челлендж или капчу на подозрительных маршрутах, а статику кэшируйте, чтобы флуд по ней не доходил до бэкенда.
Когда локальной защиты мало: внешний scrubbing
Честно о пределе: если атака больше вашего канала, ни одна строчка в sysctl не поможет. Аплинк в 1 Гбит/с забьётся флудом в 5 Гбит/с целиком, и сервер станет недоступен, даже будучи полностью исправным. Здесь вступает фильтрация на стороне сети.
Внешняя очистка (scrubbing) работает так: трафик к вашему серверу заворачивается на фильтрующие узлы провайдера, где мусор отбрасывается, а к вам приходит только чистый поток. Второй механизм — BGP blackhole (RTBH): при сверхмощной атаке провайдер объявляет атакуемый адрес «чёрной дырой» на уровне магистралей, жертвуя одним IP ради работоспособности остальной сети. Выделенный сервер выигрывает и тут: у вас обычно широкий аплинк, отдельная IP-подсеть и возможность подключить защиту у провайдера, тогда как на дешёвом shared-хостинге вы делите и канал, и последствия чужих атак.
Мониторинг и план реагирования
Защита без наблюдения слепа. Настройте базовый мониторинг полосы и pps на интерфейсе — так вы отличите наплыв реальных клиентов от атаки. Быстрый снимок трафика в реальном времени:
# кто больше всех шлёт пакетов прямо сейчас
iftop -nNP -i eth0
# срез по соединениям
ss -s
# топ адресов в логе Nginx за сегодня
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head
Заранее заготовьте план: пороги, при которых поднимаете строгие лимиты; контакт поддержки провайдера для включения scrubbing; готовые правила фаервола, которые применяются одной командой. Во время атаки времени на импровизацию нет. И помните честное правило: защита от DDoS — это не «включил и забыл», а слоёная система, где ядро, фаервол, Nginx и сеть провайдера закрывают разные уровни. Выделенный сервер даёт вам контроль над всеми слоями сразу — от этого и стоит отталкиваться.
Нужен сервер под эту задачу?
Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США и РФ. Оплата картой РФ и по СБП.
Выбрать выделенный сервер
}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

Заранее заготовьте план: пороги, при которых поднимаете строгие лимиты; контакт поддержки провайдера для включения scrubbing; готовые правила фаервола, которые применяются одной командой. Во время атаки времени на импровизацию нет. И помните честное правило: защита от DDoS — это не «включил и забыл», а слоёная система, где ядро, фаервол, Nginx и сеть провайдера закрывают разные уровни. Выделенный сервер даёт вам контроль над всеми слоями сразу — от этого и стоит отталкиваться.

Частые вопросы