Главная/ Услуги/ Защита сайта от DDoS-атак
Anti-DDoS • Cloudflare • WAF • L7 • защита origin

Защита сайта от DDoS-атак

Обновлено:

Диагностика и настройка Cloudflare, WAF, Rate Limiting и защиты origin-сервера — с контролем доступности сайта для реальных пользователей и поисковых роботов.

Если сайт уже атакуют или вы хотите заранее усилить защиту, разберу фактическую схему трафика и точки обхода. Настрою внешний контур через Cloudflare, проверю DNS и раскрытие реального IP, правила WAF и ограничения запросов, а при наличии доступа — помогу закрыть прямое обращение к веб-серверу.

  • не просто «подключить Cloudflare» — проверяю, можно ли обойти защиту напрямую через origin;
  • разбираю HTTP/L7-нагрузку, атакуемые URL, коды 403/429/5xx, логи и поведение сервера;
  • настраиваю правила так, чтобы не превратить защиту в бесконечную CAPTCHA для нормальных посетителей;
  • учитываю Googlebot, ЯндексБот, рекламу, API, формы и другие легитимные сценарии.
Диагностика от 5 000 ₽ Настройка от 20 000 ₽ Cloudflare WAF / Rate Limiting SEO-контроль
Для первичной оценки достаточно домена и краткого описания проблемы. Если есть — приложите график нагрузки, скрин Cloudflare Security Events или фрагмент access log без паролей и секретных ключей.
Аварийный сценарий

Если DDoS-атака уже идёт

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

  • проверяю, идёт ли веб-трафик через Cloudflare или часть запросов попадает прямо на сервер;
  • смотрю атакуемые URL, частоту запросов, страны / ASN / IP и повторяющиеся признаки;
  • оцениваю нагрузку на веб-сервер, PHP, базу данных и ресурсоёмкие обработчики;
  • после этого усиливаю правила и контролирую, не ломают ли они нормальную работу сайта.

Что прислать первым сообщением

  • домен;
  • что сейчас не работает;
  • есть ли Cloudflare;
  • есть ли SSH / панель хостинга;
  • скрин нагрузки или Security Events — если есть.

Что входит в настройку защиты сайта от DDoS

Состав зависит от инфраструктуры и типа атаки. Ниже — основные зоны, которые проверяются и настраиваются при работе с веб-сайтом.

01

Диагностика атаки

Атакуемые URL, HTTP-методы, источники, повторяемость, 4xx/5xx, динамика запросов, серверные и Cloudflare-события.

02

DNS и Cloudflare

Проксирование записей, режимы SSL/TLS, настройки зоны, DDoS Protection и базовая проверка обхода защитного контура.

03

WAF и правила

Custom Rules, Managed Challenge, блокировки и исключения по URL, методам и другим признакам трафика.

04

Rate Limiting

Ограничения на ресурсоёмкие и атакуемые сценарии: авторизация, поиск, API, формы, динамические обработчики.

05

Защита origin

Проверка раскрытия реального IP, DNS-only поддоменов и прямой доступности HTTP/HTTPS в обход Cloudflare.

06

Firewall сервера

При наличии доступа — ограничения входящего трафика, контроль портов и разрешение нужного трафика без блокировки Cloudflare.

07

Кэш и снижение нагрузки

Кэширование там, где оно безопасно, и уменьшение числа обращений к PHP, CMS и базе данных при массовом трафике.

08

Контроль ложных блокировок

Проверка пользователей, поисковых роботов, рекламы, API, платёжных интеграций, форм и других доверенных сценариев.

DDoS L3/L4 и L7 — это разные задачи

До настройки важно определить уровень атаки. Универсального правила, которое одинаково хорошо решает сетевой flood и сложный HTTP-flood, не существует.

L3 — Network

Сетевой уровень

Атаки на IP и сетевую инфраструктуру. Здесь ключевую роль играет внешний Anti-DDoS-контур провайдера/CDN, а не PHP-код сайта.

L4 — Transport

TCP / UDP и транспортный уровень

Например, SYN/ACK/UDP-flood. Если атакующий насыщает канал или неприкрытый сервис, может потребоваться защита хостинга или специализированного провайдера.

Граница услуги: я настраиваю и усиливаю защиту веб-сайта и его окружения. Если проблема находится на сетевом канале, в BGP, на неприкрытых TCP/UDP-сервисах или требует собственного scrubbing-центра, предложу подключить профильного Anti-DDoS-провайдера, а не имитировать такую инфраструктуру правилами веб-сервера.

Многоуровневая схема защиты

Смысл настройки — сделать так, чтобы вредоносный поток отсеивался как можно раньше, а до приложения доходило меньше лишней работы.

1. ИнтернетПользователи, роботы и атакующий трафик.
2. CloudflareDDoS Protection, proxy, edge-фильтрация и кэш.
3. WAF / Rate LimitПравила, Challenge, ограничения опасных сценариев.
4. Origin / FirewallЗакрытый прямой доступ, разрешённый защитный контур.
5. Сайт / AntiPFПриложение и дополнительный анализ автоматизированного трафика.
Главная идея: не переносить всю борьбу с атакой на WordPress, Bitrix, PHP или nginx. Чем раньше запрос можно безопасно остановить, тем меньше ресурсов он успеет потребить на origin.

Защита от DDoS с помощью Cloudflare

Cloudflare предоставляет автоматическую DDoS-защиту для своих тарифов, включая защиту L3/L4 и L7. Но для реального проекта важно не только включение зоны, а корректная настройка всей цепочки.

Что настраивается в Cloudflare

  • DNS и проксирование нужных записей;
  • SSL/TLS и корректная связь с origin;
  • DDoS-защита и Security Events;
  • Custom Rules и Managed Challenge;
  • Rate Limiting для опасных точек;
  • кэширование и Cache Rules там, где это допустимо;
  • исключения для легитимных интеграций;
  • контроль 403/429 и ложных срабатываний.

Почему «просто подключить Cloudflare» бывает мало

Если реальный IP сервера известен, атакующий может попробовать отправлять запросы напрямую, минуя защитный proxy. Кроме того, слишком широкие правила могут блокировать посетителей, API и поисковых роботов.

Поэтому я отдельно проверяю архитектуру, DNS, origin и фактическое поведение правил, а не считаю смену NS окончанием задачи.

Защита реального IP и origin-сервера

Это одна из самых важных частей схемы. Если origin остаётся доступен напрямую, часть преимуществ Cloudflare можно обойти.

Где может раскрыться origin

  • DNS-only записи;
  • поддомены mail, ftp, dev, api, old и похожие;
  • старые конфигурации DNS;
  • сервисы, которые обращаются к серверу напрямую;
  • другие домены и виртуальные хосты на том же IP;
  • прямой ответ веб-сервера по IP.

Что делается после проверки

  • по возможности закрывается прямой HTTP/HTTPS-доступ к origin;
  • разрешается необходимый трафик Cloudflare;
  • проверяются служебные интеграции и мониторинг;
  • отдельно тестируется доступность сайта после firewall-изменений;
  • если IP уже активно атакуется, обсуждается смена origin-IP с хостером.
Важно: firewall нельзя «закручивать» механически. Ошибка в allowlist может полностью отрезать сайт от Cloudflare, SSH, панели, мониторинга или нужных интеграций. Изменения делаются с резервным способом доступа и проверкой.

WAF, Rate Limiting и Challenge для защиты от L7

На прикладном уровне задача часто сводится не к блокировке «всего подозрительного», а к точечному ограничению тех сценариев, которыми реально злоупотребляют.

WAF / Custom Rules

Правила по URI, методу, источнику, известным признакам и контексту запроса. Для подозрительных запросов можно применять Block или Managed Challenge, если это оправдано.

Rate Limiting

Ограничение частоты запросов на дорогие точки: поиск, авторизация, API, корзина, фильтры, XML/JSON-обработчики и другие ресурсоёмкие URL.

Challenge

Дополнительная проверка клиента там, где жёсткая блокировка слишком рискованна. После включения обязательно проверяется пользовательский путь и доля ложных срабатываний.

Не использую правило «заблокировать страну / User-Agent / весь ASN и забыть» как универсальное решение. Такие меры иногда полезны, но должны соответствовать фактическому трафику сайта и риску ложных блокировок.

Защита без потери поискового трафика

Слишком агрессивная фильтрация может решить проблему нагрузки, но создать новую: поисковые роботы начнут получать Challenge, 403 или 429 вместо страниц сайта.

Почему SEO-экспертиза здесь полезна

Я занимаюсь поисковой оптимизацией с апреля 2009 года, поэтому при настройке безопасности отдельно смотрю на то, как правила влияют на доступность и индексирование страниц.

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

Cloudflare + AntiPF: дополнительный уровень анализа трафика

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

Роли не нужно смешивать

Cloudflare — внешний контур: CDN/proxy, автоматическая DDoS-защита, WAF, Challenge и ограничения запросов.

AntiPF — мой программный комплекс для дополнительного анализа и управления подозрительным HTTP-трафиком на уровне сайта и накопленного риска.

AntiPF не заменяет Cloudflare или специализированный Anti-DDoS. Его задача — дополнять внешний защитный контур там, где полезны локальные сигналы, история событий и поведенческая логика.
1Cloudflare edge
DDoS Protection, proxy, кэш.
2WAF / Rate Limiting
Раннее ограничение вредоносных запросов.
3Origin firewall
Защита прямого доступа к веб-серверу.
4AntiPF / приложение
Дополнительный анализ локального риска и автоматизации.

Чем эта услуга отличается от обычной настройки Cloudflare

На сайте уже есть отдельная услуга по подключению и базовой настройке Cloudflare. Новая страница решает другой, более узкий и более сложный запрос — защиту от DDoS и вредоносной нагрузки.

ЗадачаЗащита от DDoSБазовая настройка Cloudflare
Основная цельСнизить влияние атаки и закрыть обходы защитного контураПодключить Cloudflare, SSL и базовые параметры
Анализ текущей атакиДаНе является основной задачей
Проверка origin IPДа, одна из ключевых зонПо ситуации
WAF / Rate LimitingПроектируются под фактический вредоносный трафикБазовая настройка / по задаче
Серверный firewallПри наличии доступа и необходимостиОбычно не требуется
Контроль SEO и ложных блокировокОбязательная часть проверкиБазовая проверка доступности
Если вам нужно просто подключить CDN/SSL и базово настроить Cloudflare без активной атаки, рациональнее использовать отдельную услугу настройки Cloudflare.

Как проходит работа

При активной атаке этапы могут выполняться быстрее и параллельно. В профилактической настройке можно спокойно пройти всю цепочку и протестировать изменения.

01

Получаю вводные

Домен, симптомы, текущий Cloudflare/хостинг, доступность SSH или панели, последние изменения и имеющиеся логи.

02

Определяю точку нагрузки

Смотрю Cloudflare, DNS, ответы сервера, access/error logs, ресурсы и конкретные URL. Отделяю сетевую проблему от HTTP/L7 и обычной перегрузки приложения.

03

Закрываю быстрые обходы

Проксирование, раскрытые DNS-записи, прямой origin, слишком широкие доступы и другие очевидные пути обхода — если они подтверждаются.

04

Настраиваю фильтрацию

WAF, Custom Rules, Rate Limiting, Challenge, кэш и серверные ограничения — в объёме, который нужен конкретному сайту.

05

Проверяю легитимный трафик

Основные страницы, формы, API, поисковые роботы, реклама и другие важные сценарии не должны ломаться из-за усиленной защиты.

06

Фиксирую результат и дальнейшие меры

Какие правила включены, что остаётся риском, что стоит наблюдать и требуется ли дополнительная защита хостинга, провайдера или AntiPF.

Стоимость защиты сайта от DDoS

Стоимость зависит от текущего состояния Cloudflare, характера атаки, доступа к серверу, количества сервисов и того, нужно ли работать в аварийном режиме.

Первичная диагностика

от 5 000 ₽

Для определения характера проблемы, точки нагрузки, текущих обходов и плана дальнейших действий.

Основной формат

Настройка защиты

от 20 000 ₽

Cloudflare, WAF, Rate Limiting, origin, firewall и тестирование — состав определяется после диагностики инфраструктуры.

Активная атака

после оценки

При аварийной работе заранее фиксируем первый объём диагностики, затем согласуем продолжение по фактической ситуации.

Отдельно: платные тарифы Cloudflare, хостинг, CDN, специализированные Anti-DDoS-сервисы и другие сторонние продукты оплачиваются напрямую их поставщикам, если они необходимы.

Кто настраивает защиту

Диагностику сайта, Cloudflare, поисковые риски и основную логику правил веду лично.

Алексей Солтык

Работаю с SEO и веб-проектами с апреля 2009 года. Помимо поисковой оптимизации занимаюсь техническими задачами, автоматизацией и разработкой собственных инструментов, включая AntiPF и SEO Semantic Lab.

В DDoS-защите не продаю абстрактное обещание «защитить от любой атаки». Сначала определяю, где находится проблема: Cloudflare, origin, HTTP/L7, приложение, хостинг или сетевой уровень — и предлагаю меры в границах реально доступной инфраструктуры.

Веб-практикаSEO и сайты с апреля 2009 года
Свой продуктAntiPF
Подходдиагностика → защита → проверка

Частые вопросы о защите от DDoS

Можно ли защитить сайт от DDoS через Cloudflare?

Да. Cloudflare автоматически защищает проксируемый трафик от ряда DDoS-атак. Но для конкретного проекта важно проверить DNS, origin, WAF, Rate Limiting и ложные блокировки. Сам факт подключения домена к Cloudflare ещё не означает, что атакующий не может обойти proxy.

Можно ли сделать DDoS-защиту бесплатно?

Стандартная DDoS-защита Cloudflare доступна и на Free-плане. Это не делает бесплатной работу по диагностике и настройке конкретного сайта: правила, DNS, firewall, origin и проверку ложных срабатываний всё равно нужно настраивать под инфраструктуру.

Что делать, если сайт атакуют прямо сейчас?

Сначала нужно определить путь вредоносного трафика: через Cloudflare или напрямую, на какие URL он приходит и что именно создаёт нагрузку. После этого можно принимать точечные меры — от правил на edge до закрытия origin и ограничений на сервере.

Что такое защита от DDoS L7?

L7 — прикладной уровень. Для веб-сайта это обычно HTTP/HTTPS-запросы, которые могут выглядеть нормальными, но массово нагружают динамические страницы, API, поиск, авторизацию, корзину или другие обработчики. Здесь особенно важны WAF, Rate Limiting, Challenge и анализ профиля трафика.

Чем WAF отличается от Anti-DDoS?

Anti-DDoS отвечает за обнаружение и смягчение массовых атак, а WAF применяет правила безопасности к веб-запросам. На уровне L7 эти механизмы часто работают вместе: DDoS-защита снижает общий поток, а WAF и Rate Limiting помогают точечно ограничить вредоносные сценарии.

Почему важно скрывать IP origin-сервера?

Если атакующий знает реальный IP и сервер принимает веб-запросы напрямую, Cloudflare можно попытаться обойти. Поэтому после подключения proxy важно проверить DNS и ограничить прямой доступ к веб-серверу там, где это технически возможно.

Не заблокирует ли Cloudflare Googlebot или ЯндексБот?

Ошибочно настроенные правила могут затронуть любой легитимный трафик. Поэтому после настройки проверяю ответы важных URL, Security Events, 403/429/5xx, доступ поисковых роботов и ключевые пользовательские сценарии.

Можно ли защитить VPS или сервер от DDoS?

Если речь о веб-сайте, защиту можно заметно усилить через Cloudflare, firewall и закрытие origin. Но если атака насыщает сетевой канал или идёт на неприкрытые TCP/UDP-сервисы, нужна помощь хостинга или Anti-DDoS-провайдера на сетевом уровне.

AntiPF заменяет Cloudflare?

Нет. AntiPF — дополнительный слой анализа автоматизированного HTTP-трафика и накопленного риска на стороне сайта. Он может дополнять Cloudflare, но не заменяет внешнюю DDoS-инфраструктуру и сетевую фильтрацию.

Сколько стоит защита сайта от DDoS?

Первичная диагностика — от 5 000 ₽. Настройка защиты сайта — от 20 000 ₽. При активной атаке итог зависит от характера нагрузки, текущего Cloudflare, доступа к серверу, количества сервисов и требуемого объёма изменений.

Пришлите сайт — посмотрю, с чего рациональнее начать

Если атака уже идёт, напишите это прямо в сообщении. Для первого разбора достаточно домена и симптомов; доступы и логи можно передать после того, как станет понятно, что именно нужно проверять.

Cloudflare WAF / Rate Limiting Origin / Firewall SEO-контроль AntiPF Самозанятый / НПД
Что лучше прислать
  • URL сайта;
  • идёт ли атака сейчас;
  • подключён ли Cloudflare и какой тариф;
  • какой хостинг / VPS используется;
  • есть ли SSH или панель управления;
  • что именно происходит: 502/504, CPU 100%, медленные страницы, массовые 404, всплеск запросов и т. п.
Не присылайте пароли и секретные ключи в первом сообщении. Для первичной оценки они не нужны.
Быстрая заявка

Укажите контакты, сайт и коротко опишите симптомы. Если атака идёт сейчас — напишите это первой строкой.