Защита от DDoS на уровне сервера

Полностью погасить мощный DDoS в одиночку сложно, но от типовых атак малой и средней силы сервер можно защитить настройками ядра, nginx и фаервола.

Что реально может сервер

DDoS бывает разным: объёмный флуд, забивающий канал; перегрузка процессора тяжёлыми запросами; исчерпание числа соединений и сокетов. Против объёмных атак в десятки и сотни Гбит/с помогает только внешняя фильтрация у провайдера или CDN — трафик просто не доходит до сервера в исходном виде. Но большинство атак на небольшие сайты — это тысячи «дешёвых» HTTP-запросов, которые вполне гасятся на самом сервере.

Задача уровня сервера — не допустить исчерпания ресурсов: сокетов, воркеров веб-сервера, оперативной памяти. Разберём три рубежа обороны: ядро, фаервол и веб-сервер. Быстрый NVMe и производительные ядра AMD EPYC у MAATRIX дают запас прочности, чтобы сервер держал повышенную нагрузку дольше и не падал при первом же всплеске.

Важно заранее знать нормальный профиль трафика вашего проекта — сколько запросов в секунду и соединений создаёт обычный пользователь. Без этого легко выставить лимиты, которые перекроют кислород реальной аудитории вместе с ботами.

Рубеж 1: тюнинг ядра

SYN-флуд — классика: злоумышленник открывает массу полуоткрытых соединений, исчерпывая очередь. Включаем SYN cookies и увеличиваем очереди соединений.

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=4096
sysctl -w net.core.somaxconn=1024
sysctl -w net.ipv4.tcp_synack_retries=2

Чтобы настройки пережили перезагрузку, впишите их в /etc/sysctl.d/99-hardening.conf и примените командой sysctl -p /etc/sysctl.d/99-hardening.conf. SYN cookies позволяют серверу отвечать на новые соединения без хранения состояния для каждого недозавершённого хендшейка — это и обезвреживает SYN-флуд.

Рубеж 2: лимиты в iptables

Ограничим число одновременных соединений с одного IP на веб-порт — это отсекает ботов, открывающих сотни сокетов, чтобы забить пул соединений.

iptables -A INPUT -p tcp --dport 80 -m connlimit \
  --connlimit-above 50 --connlimit-mask 32 -j REJECT
iptables -A INPUT -p tcp --dport 443 -m connlimit \
  --connlimit-above 50 --connlimit-mask 32 -j REJECT

Порог 50 подберите под реальность: за одним корпоративным NAT может сидеть много легитимных пользователей с одного адреса, и слишком жёсткий лимит их заблокирует. Модуль connlimit считает активные соединения, а не запросы, поэтому хорошо ловит именно паразитные удержания сокетов.

Рубеж 3: rate limiting в nginx

nginx умеет ограничивать частоту запросов и число соединений на клиента. Это лучший рубеж против прикладного (L7) HTTP-флуда, когда каждый запрос выглядит легитимным.

limit_req_zone $binary_remote_addr zone=req:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=conn:10m;

server {
    location / {
        limit_req zone=req burst=20 nodelay;
        limit_conn conn 10;
    }
}

Здесь: не больше 10 запросов в секунду с одного IP (с всплеском до 20 благодаря burst) и не больше 10 одновременных соединений. Параметр nodelay позволяет обрабатывать всплеск сразу, а не растягивать его. Отдельно можно защитить чувствительные точки — форму входа или API — более строгими зонами.

Скрытие origin и кэш

• Прячьте реальный IP сервера за CDN или обратным прокси — атакующий не должен знать адрес origin, иначе обойдёт защиту напрямую.
• Кэшируйте статику и тяжёлые страницы, чтобы флуд не доходил до бэкенда и базы данных.
• Отдавайте статику напрямую nginx, минуя PHP или приложение — это радикально снижает стоимость каждого запроса.

На быстром NVMe у MAATRIX кэш отдаётся почти мгновенно, что резко снижает эффект флуда на динамические страницы. Чем дешевле сервер обрабатывает типичный запрос, тем более мощную атаку он переживёт без деградации для реальных пользователей.

Частые ошибки

• Слишком жёсткий rate limit, который режет реальных пользователей и поисковых ботов Google и Yandex.
• Надежда только на настройки сервера против объёмной L3/L4-атаки — тут нужен провайдер или CDN.
• Отсутствие мониторинга: атаку замечают, когда сайт уже недоступен.
• Открытый реальный IP origin при подключённом CDN — атака идёт мимо защиты.

Для быстрой диагностики держите под рукой команды: ss -s покажет сводку по сокетам, htop — нагрузку, а анализ логов nginx с группировкой по IP выявит источники флуда. Своевременно замеченная атака гасится куда проще, чем запущенная.

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