Что вы реально можете против DDoS на своём сервере, а что нет

MAATRIX

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

Почему один сервер — это не про объём атаки

У любого сервера, арендованного или своего, есть аплинк — физический канал, которым он подключён к сети провайдера. У бюджетного VPS это обычно 100 Мбит/с — 1 Гбит/с, у выделенного сервера — чаще 1 Гбит/с, иногда 10 Гбит/с за отдельную доплату. Это жёсткий потолок, и он не имеет никакого отношения к тому, что написано в вашем firewall.

Если на этот канал приходит поток мусорного трафика больше его пропускной способности, канал забивается физически — пакеты сталкиваются друг с другом и теряются ещё на уровне порта коммутатора, до того как дойдут до сетевой карты вашей машины. В этот момент неважно, насколько умно настроен iptables или nginx: правила фильтрации применяются к пакетам, которые уже добрались до сервера, а забитый канал их туда просто не пропускает. Легитимный трафик тонет вместе с мусорным — сервер физически не видит разницы, потому что не видит вообще ничего лишнего сверх канала.

Это ключевое разграничение, вокруг которого строится вся статья:

• Объёмные атаки (L3/L4) — забивают канал или исчерпывают сетевые ресурсы (SYN-флуд, UDP-флуд, амплификация через DNS/NTP). Решаются только выше сервера: у провайдера, на магистрали, через anti-DDoS сеть.
• Атаки прикладного уровня (L7) — выглядят как обычные HTTP-запросы, но перегружают приложение или базу данных дорогой обработкой. Их можно и нужно смягчать настройками сервера и кода.

Дальше по каждому типу отдельно — что реально в ваших руках, а что нет.

Объёмные атаки: где заканчивается ваша зона ответственности

Возьмём конкретный пример. У вас VPS с портом 1 Гбит/с. Атакующий (или ботнет, которым он управляет) генерирует поток в 5-10 Гбит/с UDP-мусора или SYN-пакетов, направленный на ваш IP. Этот трафик физически не помещается в ваш канал независимо от того, что вы настроите на сервере — он забивает канал провайдера ещё до вашей сетевой карты.

Что не поможет вообще:

• Правила iptables/nftables — они обрабатывают пакеты, которые уже пришли, а забитый канал их просто не доставляет.
• Увеличение лимитов nginx или resource limits приложения — узкое место не в приложении, а в физической полосе.
• Более мощный сервер (больше CPU, больше RAM) — при объёмной атаке процессор и память вообще не успевают стать проблемой, канал забивается раньше.
• fail2ban и подобные инструменты — они банят по поведению в логах приложения, а объёмная атака до логов приложения обычно не доходит, потому что душит канал раньше.

Что реально можно сделать на своей стороне — это снизить последствия для соседей по хостингу (если вы отвечаете за инфраструктуру целиком) и не усугублять ситуацию:

# Включить SYN cookies — помогает при SYN-флуде умеренного объёма,
# который ещё помещается в канал, но исчерпывает таблицу соединений
sysctl -w net.ipv4.tcp_syncookies=1

# Увеличить таблицу conntrack, если атака не забивает канал,
# а просто плодит полуоткрытые соединения
sysctl -w net.netfilter.nf_conntrack_max=262144

Это работает только для атак, которые помещаются в ваш канал по объёму, но пытаются исчерпать не полосу, а состояние (таблицы соединений, память ядра). Как только речь идёт о полноценном объёмном флуде в несколько гигабит — единственный работающий шаг это обращение к провайдеру или подключение anti-DDoS фильтрации, о которой ниже. Если у вас уже есть первичный опыт паники в момент атаки, разбор первых действий есть в статье DDoS-атака: первые действия — там про то, что делать в первые минуты, пока вы ещё не понимаете тип атаки.

L7-атаки: здесь у вас реально есть рычаги

Атака прикладного уровня выглядит как легитимный HTTP-трафик — тысячи браузеров или ботов открывают страницы, отправляют формы, дёргают API. По объёму такой трафик часто не забивает канал (десятки-сотни Мбит/с вместо гигабит), но каждый запрос заставляет ваш сервер делать дорогую работу: рендерить страницу без кеша, бить в базу тяжёлым запросом, генерировать PDF или обрабатывать загрузку файла.

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

1. Rate limiting — ограничение частоты запросов с одного источника.
2. Кеширование — снятие нагрузки с дорогих операций за счёт отдачи готового ответа.
3. Оптимизация дорогих запросов — чтобы даже пропущенный запрос стоил дёшево.
4. Фильтрация по паттернам — блокировка явно ботовских user-agent, отсутствующих заголовков, подозрительных путей.

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

Rate limiting на практике: конфиги и границы метода

В nginx базовый rate limiting настраивается через limit_req_zone и limit_conn_zone:

# в http {}
limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=conn_limit:10m;

server {
    location / {
        limit_req zone=general burst=20 nodelay;
        limit_conn conn_limit 20;
        proxy_pass http://backend;
    }

    # более жёсткий лимит на дорогие эндпоинты — поиск, авторизация, форма
    location /search {
        limit_req zone=general burst=5 nodelay;
        proxy_pass http://backend;
    }
}

Это ограничивает число запросов с одного IP в секунду и число одновременных соединений. Работает хорошо против одиночных ботов и небольших скриптов. Но у метода есть честные ограничения:

• Ограничение по IP слепнет за NAT. Если атака (или просто волна легитимных пользователей) идёт из-за корпоративного NAT, десятки реальных людей делят один IP — жёсткий лимит бьёт по ним так же, как по атакующему. Подробный разбор — в статье Как работает rate limiting и почему честные клиенты страдают первыми.
• Распределённая атака с тысяч уникальных IP обходит лимит по определению. Если с каждого IP приходит 2-3 запроса в секунду, а IP тысячи — суммарная нагрузка огромная, а под лимит на уровне одного IP атака не подпадает вообще.
• Rate limiting не бесплатен по ресурсам. Каждая проверка — это память под zone и вычисления на каждый запрос; при очень большом числе уникальных IP zone может исчерпаться раньше времени.

Практический вывод: rate limiting — первый и обязательный слой защиты для L7, но не решение против распределённой атаки. Он останавливает наивных ботов и случайный самопроизвольный шторм запросов (например, от сломанного клиента, который ретраит без паузы), но не спасает от организованного ботнета с большим пулом IP.

Кеширование и оптимизация: снижаем цену каждого запроса

Если атакующий не может обойти rate limiting по числу запросов, следующий его ход — бить по самым дорогим URL: поиск с сложным SQL-запросом, страница с десятком неоптимизированных join, генерация отчёта, страница товара без кеша. Здесь работает второй рычаг — сделать так, чтобы даже пропущенный запрос стоил сервера копейки, а не секунды CPU.

Кеширование на уровне nginx для статики и полу-статичных страниц:

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=main_cache:50m max_size=2g inactive=30m;

server {
    location / {
        proxy_cache main_cache;
        proxy_cache_valid 200 5m;
        proxy_cache_use_stale error timeout updating http_500 http_502 http_503;
        proxy_cache_lock on;
        add_header X-Cache-Status $upstream_cache_status;
        proxy_pass http://backend;
    }
}

Ключевая директива здесь — proxy_cache_use_stale updating в связке с proxy_cache_lock: при всплеске одинаковых запросов к одному URL только первый реально уходит на backend, остальные получают закешированный (пусть и чуть устаревший) ответ, пока идёт обновление. Это резко снижает эффект «атака попала точно в момент истечения кеша и обрушила базу» — так называемый thundering herd. Подробнее конфигурация и типовые ошибки разобраны в статье Как установить и настроить кеширование Nginx на VPS.

Дальше — оптимизация того, что кешировать нельзя (персонализированные страницы, авторизованные API):

• Индексы на колонках поиска и фильтрации — без них даже 10 запросов в секунду на таблицу в миллион строк утягивают CPU базы в потолок.
• Пагинация и лимиты в API по умолчанию — эндпоинт без LIMIT на большой таблице это готовая точка для L7-атаки без всякого злого умысла атакующего.
• Очереди для тяжёлых операций (отчёты, экспорт, письма) — синхронный дорогой запрос блокирует воркер, асинхронная постановка в очередь не даёт атаке напрямую забить пул воркеров.
• Отдельный лимит на аутентификацию — логин и восстановление пароля обычно самые дорогие по CPU эндпоинты (bcrypt/argon2 намеренно медленные), и именно туда чаще всего бьют L7-атаки, замаскированные под перебор.

Это работа не одного дня и не только про DDoS — те же меры заодно улучшают производительность сайта в обычном режиме, и именно они делают разницу между «атака прошла незамеченной» и «сайт лёг от тысячи запросов в секунду».

Когда без внешней защиты не обойтись

Граница простая: если атака помещается в ваш канал и её можно смягчить на уровне HTTP/приложения — справляетесь сами. Если атака объёмная (забивает канал) или распределена настолько, что rate limiting по IP бесполезен — нужна защита выше сервера. Вариантов по факту два, и они решают разные задачи:

Частый недосмотр: вы поставили CDN, но сервер продолжает принимать подключения напрямую по IP (старый IP не менялся, часть резолверов ещё помнит его в кеше) — атакующий, знающий реальный IP, обходит CDN полностью. Смена IP после подключения CDN — обязательный шаг, а не паранойя. Пошаговая настройка — в статье Настройка CDN перед сервером.

Для несайтовых сервисов (игровые серверы на UDP, VoIP, кастомные TCP-протоколы) CDN не подходит вообще — там нужен scrubbing-сервис или защита провайдера, анонсирующая ваш IP через свою анти-DDoS сеть. Уточняйте это у хостера заранее: подключение защиты требует времени на анонс маршрутов и не включается мгновенно.

Честные ожидания от бюджетного VPS

Если вы арендуете недорогой VPS без выделенной anti-DDoS защиты, полезно заранее понимать реалистичную картину, а не рассчитывать на чудо:

• Против единичного скрипт-кидди с одним-двумя источниками — справитесь настройками из этой статьи: rate limiting, кеш, fail2ban на явные паттерны сканирования. Про фильтры для nginx конкретно — в статье Fail2ban для Nginx: настройка правил.
• Против короткой волны из небольшого ботнета — сервер, скорее всего, просядет на время атаки (повышенные задержки, часть запросов отвалится), но не обязательно ляжет полностью, если кеш и лимиты настроены заранее, а не по факту атаки.
• Против организованной объёмной атаки в несколько гигабит — бюджетный VPS ляжет практически гарантированно, и это не про плохую настройку, а про физику канала. Здесь единственный рабочий шаг — обращение в поддержку хостинга по факту атаки (часть провайдеров временно нуль-роутит атакуемый IP, чтобы не класть соседей по сети) и последующее подключение защиты уровня CDN или scrubbing.
• Бюджетный тариф почти никогда не включает anti-DDoS фильтрацию на уровне провайдера по умолчанию — это отдельная услуга или отдельный тариф. Если для вашего проекта риск атаки реален (публичный сервис, конкуренты, история инцидентов), закладывайте это в выбор тарифа заранее, а не после первого простоя.

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

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