MAATRIX / Блог / Защита от DDoS на уровне сервера

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

Блог MAATRIX · 2026-07-07

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

Содержание

  1. Что реально может сервер
  2. Рубеж 1: тюнинг ядра
  3. Рубеж 2: лимиты в iptables
  4. Рубеж 3: rate limiting в nginx
  5. Скрытие origin и кэш
  6. Частые ошибки

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

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

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK и США. Оплата картой РФ и по СБП.

Арендовать стабильный VPS

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

['SYN-флуд — классика: злоумышленник открывает массу полуоткрытых соединений, исчерпывая очередь. Включаем SYN cookies и увеличиваем очереди соединений.', '
sysctl -w net.ipv4.tcp_syncookies=1\nsysctl -w net.ipv4.tcp_max_syn_backlog=4096\nsysctl -w net.core.somaxconn=1024\nsysctl -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 \\\n  --connlimit-above 50 --connlimit-mask 32 -j REJECT\niptables -A INPUT -p tcp --dport 443 -m connlimit \\\n  --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;\nlimit_conn_zone $binary_remote_addr zone=conn:10m;\n\nserver {\n    location / {\n        limit_req zone=req burst=20 nodelay;\n        limit_conn conn 10;\n    }\n}
', 'Здесь: не больше 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 выявит источники флуда. Своевременно замеченная атака гасится куда проще, чем запущенная.']

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK и США. Оплата картой РФ и по СБП.

Арендовать стабильный VPS

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

Защитит ли это от атаки в 100 Гбит/с?

Нет. Объёмные атаки забивают канал до сервера, их фильтруют вышестоящие сети и CDN. Настройки сервера спасают от прикладного (L7) и умеренного флуда.

Стоит ли ставить Cloudflare?

Для публичных сайтов — да, он прячет origin и берёт на себя фильтрацию. Сервер при этом всё равно нужно закрыть фаерволом, чтобы принимать трафик только от прокси.

Как понять, что идёт DDoS?

Резкий рост числа соединений и запросов при неизменной аудитории, всплеск нагрузки CPU и сети. Помогают ss -s, htop и логи nginx с частотой запросов по IP.

Читайте также