DDoS-защита на ZevsHost
Все серверы ZevsHost защищены от DDoS-атак на уровнях L3, L4 и (в дата-центрах USA и OVH) L7. Цель атаки — не украсть данные, а сделать сервис недоступным для обычных посетителей за счёт исчерпания какого-то ресурса: полосы канала, вычислительных мощностей сервера или лимита одновременных соединений.
DDoS расшифровывается как Distributed Denial of Service — распределённый отказ в обслуживании. Ключевое слово «распределённый»: атака идёт не с одного адреса, который можно просто заблокировать, а с тысяч или миллионов заражённых устройств одновременно (ботнета). Именно поэтому защита строится на анализе паттернов трафика, а не на списке конкретных вредоносных IP.
Уровни защиты
- L3 — фильтрация вредоносного трафика на уровне сети (IP-адреса, протоколы)
- L4 — защита на уровне транспортного протокола (TCP/UDP flood)
- L7 — защита на уровне приложений (HTTP-флуд, slowloris)
Как выглядят типовые атаки
| Тип атаки | Уровень | Признак в логах или мониторинге |
|---|---|---|
| SYN flood | L4 | Много полуоткрытых TCP-соединений в состоянии SYN_RECV |
| UDP amplification (DNS, NTP) | L3/L4 | Резкий рост входящего трафика с чужих открытых DNS/NTP-серверов |
| HTTP flood | L7 | Тысячи однотипных GET-запросов с разных IP на один и тот же URL |
| Slowloris | L7 | Много открытых соединений, которые держатся, но почти не передают данные |
Уровни L3 и L4 фильтруются на границе сети провайдера до того, как трафик доходит до вашего сервера. Уровень L7 требует понимания логики протокола HTTP, поэтому доступен только на площадках с соответствующим оборудованием — см. таблицу выше.
Как отличить атаку от органического всплеска
Не любой резкий рост трафика — это атака. Разница видна по паттерну запросов:
- Органический всплеск (например, после публикации в СМИ) — разные URL, разные User-Agent, поведение похоже на обычных посетителей.
- Атака — однотипные запросы на один URL или endpoint, аномально маленький разброс по времени между запросами, много запросов с подсетей, не характерных для вашей аудитории.
Автоматическая фильтрация иногда ошибается в обе стороны: пропускает медленную, растянутую во времени атаку под видом обычной нагрузки или временно замедляет ответ легитимным пользователям во время резкого всплеска интереса к сайту. Полностью исключить ложные срабатывания нельзя — задача системы защиты в том, чтобы их было заметно меньше, чем реального вреда от пропущенной атаки.
Что происходит при атаке
- Система автоматически обнаруживает аномальный трафик
- Вредоносные пакеты фильтруются до достижения сервера
- Легитимный трафик проходит без задержек
- Служба мониторинга оповещает команду о крупных атаках
Чего DDoS-защита не покрывает
- Брутфорс пароля от одного или нескольких IP небольшим числом запросов — это не DDoS по объёму, от него защищает fail2ban и лимит попыток входа, а не сетевой фильтр.
- Уязвимость в коде приложения, которую эксплуатируют единичными запросами — фильтрация трафика не проверяет логику вашего кода.
- Перегрузку от собственного легитимного роста аудитории — здесь нужен масштабируемый сервер и кэширование, а не защита от атак.
При атаке
Создайте тикет в поддержку — мы можем применить дополнительные правила фильтрации.
Пока тикет обрабатывается, часть мер можно применить самостоятельно, если у вас есть доступ к серверу и, если он используется, к панели Cloudflare:
- Включите режим Under Attack Mode в Cloudflare, если домен уже подключён — он добавляет промежуточную проверку браузера перед каждым запросом.
- Временно ограничьте число одновременных соединений с одного IP на Nginx через
limit_conn, чтобы снизить нагрузку от отдельных агрессивных клиентов, пока фильтрация не заработает в полную силу. - Зафиксируйте точное время начала атаки и сохраните образец логов — это ускорит разбор на стороне поддержки и подбор точных правил фильтрации.
Как проверить, что фильтрация действительно работает
- Посмотрите заголовки ответа сервера при обычном запросе — на площадках с L7 через Cloudflare в них присутствует
cf-ray, что подтверждает прохождение трафика через фильтрующий узел. - Во время реальной атаки сверьте объём входящего трафика на сетевом интерфейсе (
vnstatили панель мониторинга) с нагрузкой на сам сервис — при работающей фильтрации сервис остаётся отзывчивым даже при большом входящем объёме. - После инцидента запросите у поддержки отчёт о фильтрации — легитимные обращения не должны попадать в число отброшенных пакетов.
Как настроить дополнительный уровень защиты через прокси перед сервером — в статье DDoS-защита Nginx и Cloudflare, а базовые правила файрвола — в разборе UFW на VPS.
Частые вопросы
Нужно ли отдельно подключать или оплачивать DDoS-защиту на серверах ZevsHost?
Отдельно подключать защиту не нужно: уровни L3 и L4 работают автоматически на каждом сервере ZevsHost без дополнительной настройки. Уровень L7 доступен не везде — он зависит от дата-центра и требует соответствующего оборудования для анализа HTTP-трафика. Поэтому его наличие определяется выбранной площадкой размещения сервера, а не отдельной покупкой или настройкой клиента.
Что делать, если фильтрация случайно замедляет доступ обычным посетителям?
Полностью избежать ложных срабатываний невозможно: во время резкого всплеска интереса к сайту фильтрация иногда ненадолго замедляет ответ даже обычным посетителям. Если задержки заметны и держатся долго, разумно создать тикет в поддержку — специалисты скорректируют правила фильтрации вручную и снизят число подобных ошибок, не дожидаясь, пока нагрузка спадёт сама.
Защищает ли DDoS-защита от взлома через уязвимость в коде сайта?
Нет. Сетевая фильтрация трафика анализирует только паттерны запросов и их объём, а не логику вашего приложения, поэтому уязвимость, которую эксплуатируют единичными обращениями, она не обнаруживает и не закрывает. От таких атак защищают обновление кода, аудит безопасности и мониторинг логов самого приложения — это отдельная задача от сетевой защиты.
Что можно сделать самостоятельно, пока тикет в поддержку ещё не обработан?
Пока тикет обрабатывается, можно включить режим Under Attack Mode в Cloudflare, если домен уже подключён к этой панели, — он добавляет дополнительную проверку браузера перед каждым запросом. На Nginx стоит временно ограничить число соединений с одного адреса, а также зафиксировать точное время начала атаки и сохранить образец логов для поддержки.