Как защитить сайт от DDoS-атак в 2026 году: пошаговый чек-лист для бизнеса

DDoS-атака может остановить работу сайта без взлома админки, вирусов и доступа к данным. Для бизнеса это быстро превращается в конкретные потери:

• клиенты не открывают каталог и карточки товаров;
• формы заявок, корзина или личный кабинет работают с ошибками;
• рекламный бюджет ведёт людей на недоступные страницы;
• менеджеры получают жалобы вместо обращений.

В 2026 году защита от DDoS актуальна не только для банков и крупных сервисов. Под удар могут попасть интернет-магазины, сайты услуг, B2B-порталы, медиа, корпоративные сайты и проекты на 1С-Битрикс с интеграциями и личными кабинетами.

В статье разберём, как защитить сайт от DDoS-атак заранее, как отличить атаку от обычного сбоя, что делать во время инцидента и как подготовить сайт, команду и подрядчиков к нестандартной нагрузке.

Кратко: как защитить сайт от DDoS-атак

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

Базовый набор действий выглядит так:

• выбрать хостинг или облако с Anti-DDoS-защитой;
• подключить CDN и защищённый DNS;
• настроить WAF для фильтрации подозрительных запросов к сайту, формам, API и админке;
• ограничить частоту обращений к чувствительным страницам: авторизации, поиску, корзине, фильтрам каталога;
• оптимизировать сайт, сервер и базу данных, чтобы проект выдерживал нормальные пики нагрузки;
• закрыть лишние порты, служебные разделы и административные URL;
• настроить мониторинг доступности, ошибок и нагрузки;
• заранее определить, кто связывается с хостингом, кто проверяет сайт, кто управляет рекламой и кто принимает решения во время атаки.

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

Что такое DDoS-атака простыми словами

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

Как работает DDoS-атака

У сайта есть ограниченные ресурсы: пропускная способность канала, мощность сервера, память, процессор, база данных, возможности CMS и веб-приложения. Когда запросов становится слишком много, одна из этих частей начинает не справляться.

Чаще всего страдают:

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

Почему сайт может перестать работать без взлома

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

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

Чем DDoS отличается от обычного всплеска трафика

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

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

Почему защита от DDoS-атак особенно важна в 2026 году

В 2026 году DDoS-атаки стали регулярным риском для коммерческих сайтов. Под нагрузку всё чаще попадает уровень приложения: каталог, поиск, корзина, авторизация, API, личный кабинет.

По данным Kaspersky DDoS Protection, с января по май 2026 года число DDoS-атак в России и странах СНГ выросло на 27% к аналогичному периоду 2025 года. Мощность отдельных атак увеличилась на 173%, а атаки свыше 200 Гбит/с участились на 215%.

Атаки становятся мощнее и сложнее

Современная атака может одновременно давить на канал, DNS, сервер и отдельные функции сайта. Проект выглядит “почти живым”, но пользователь не может отправить форму, оформить заказ, войти в личный кабинет или воспользоваться поиском.

Под ударом не только крупные компании

Риск есть у любого сайта, где простой быстро превращается в деньги: заявки, заказы, рекламный трафик, онлайн-оплата, личные кабинеты, интеграции с 1С и CRM.

По данным «Солар», в I квартале 2026 года на одну российскую организацию в среднем пришлось не менее 106 DDoS-атак; среди часто атакуемых отраслей назывались нефтегаз, ритейл, энергетика и промышленность.

Почему нельзя откладывать защиту на потом

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

Заранее стоит определить:

• какие сервисы защищают сайт;
• кто отвечает за инфраструктуру, CMS и рекламу;
• где хранятся доступы и логи;
• какие страницы и функции критичны для бизнеса;
• какой порядок действий включается при недоступности сайта.

Цель защиты — снизить риск простоя, быстрее распознать проблему и сохранить управление ситуацией.

Кто и зачем устраивает DDoS-атаки

Мотив DDoS-атаки чаще связан не с техническим интересом, а с давлением на бизнес. Сайт становится удобной точкой воздействия: его видно клиентам, он связан с заявками, продажами, рекламой, личными кабинетами и репутацией компании.

Вымогательство

Один из распространённых сценариев — атака с требованием заплатить за её прекращение. Расчёт простой: если сайт приносит заказы или обслуживает клиентов, простой быстро становится болезненным. Особенно уязвимы проекты, где каждая минута недоступности влияет на выручку: интернет-магазины, сервисы бронирования, B2B-порталы, сайты с онлайн-оплатой.

Конкурентное давление

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

• заявки перестают доходить до отдела продаж;
• рекламные кампании ведут трафик на нестабильный сайт;
• клиенты уходят к конкурентам;
• команда тратит время на аварийное восстановление вместо работы с продажами.

Хактивизм, репутационные атаки и случайные цели

Иногда сайт атакуют из-за отрасли, публичной позиции компании, региона, инфоповода или принадлежности к определённому рынку. Бывают и случайные попадания: автоматизированные атаки выбирают цели по доступности, слабой защите или похожим техническим признакам.

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

Чем DDoS-атака опасна для бизнеса

Главный ущерб от DDoS-атаки — не технический факт перегрузки сервера, а остановка бизнес-процессов, которые завязаны на сайт. Чем больше сайт участвует в продажах, рекламе, обработке заявок и обслуживании клиентов, тем дороже обходится даже короткий простой.

Простои сайта и потеря заявок

Если сайт недоступен, пользователь не может выполнить целевое действие: отправить форму, оформить заказ, записаться на консультацию, скачать прайс, войти в личный кабинет или проверить статус обращения.

Особенно критичны DDoS-атаки для проектов, где сайт работает как часть операционной системы бизнеса:

• интернет-магазинов с корзиной и онлайн-оплатой;
• сайтов услуг с формами заявок и квизами;
• B2B-порталов с личными кабинетами;
• сервисов бронирования и записи;
• сайтов с интеграциями с CRM, 1С и службами доставки.

В такой ситуации компания теряет не абстрактный “трафик”, а конкретные обращения, заказы и повторные касания с клиентами.

Потеря рекламного бюджета

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

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

Снижение конверсии

DDoS-атака не всегда полностью “кладёт” сайт. Иногда он работает нестабильно: главная открывается, а каталог тормозит; карточки товаров загружаются через раз; форма отправляется с ошибкой; личный кабинет зависает после авторизации.

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

Риски для SEO

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

Для SEO опасны:

• частые ошибки 5xx;
• нестабильная скорость ответа сервера;
• недоступность важных страниц;
• сбои в индексации;
• ухудшение пользовательского опыта.

Поэтому защита от DDoS связана не только с безопасностью, но и с техническим состоянием сайта в целом.

Репутационные и операционные проблемы

Во время атаки нагрузка ложится не только на сервер. Страдает команда: менеджеры получают жалобы, маркетолог не понимает, останавливать ли рекламу, разработчики разбирают логи, руководитель ждёт понятного ответа по срокам восстановления.

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

Какие бывают DDoS-атаки

DDoS-атаки различаются по тому, на какой уровень инфраструктуры идёт нагрузка. Для бизнеса важна не столько техническая классификация, сколько понимание, где именно может возникнуть отказ: на уровне канала, DNS, сервера, CMS, базы данных или конкретной функции сайта.

Сетевые атаки L3/L4

Такие атаки давят на сетевой уровень: канал связи, маршрутизаторы, балансировщики, серверные ресурсы. Их цель — забить инфраструктуру трафиком так, чтобы нормальные запросы пользователей не проходили или обрабатывались с большой задержкой.

К этой группе относятся, например, SYN flood и UDP flood. Обычно защита от таких атак находится в зоне хостинга, облачного провайдера или Anti-DDoS-сервиса, потому что фильтровать большой объём мусорного трафика на уровне самого сайта уже поздно.

Атаки уровня приложения L7

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

Чаще всего под нагрузку попадают:

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

Такая атака может не “забить” весь канал, зато перегрузит CMS, базу данных или отдельный модуль. Снаружи сайт иногда выглядит частично рабочим: главная открывается, а каталог, корзина или форма заявки постоянно зависают.

DNS-атаки

DNS отвечает за то, чтобы пользователь попадал на сайт по доменному имени. Если DNS-инфраструктура недоступна или работает нестабильно, посетитель может не открыть сайт даже при исправном сервере.

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

Многовекторные атаки

В 2026 году всё чаще встречается сценарий, когда атака идёт сразу по нескольким направлениям: сетевой уровень, DNS, веб-приложение, отдельные URL и API. Это усложняет диагностику: одна часть сайта может падать из-за перегрузки базы, другая — из-за фильтрации на стороне провайдера, третья — из-за проблем с DNS.

Поэтому защита сайта от DDoS должна быть многоуровневой. Один firewall или одна настройка в CMS не закрывают все возможные сценарии.

Как понять, что сайт атакуют, а не просто случился сбой

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

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

Внешние признаки для пользователя

Пользователь обычно видит не “DDoS”, а последствия:

• сайт долго открывается или не открывается совсем;
• периодически появляются ошибки 502, 503, 504;
• не работает форма заявки, корзина, поиск или авторизация;
• страницы загружаются через раз;
• личный кабинет зависает после входа;
• часть сайта доступна, а отдельные разделы постоянно падают.

Если проблема затрагивает только одну функцию, например поиск или фильтр каталога, это может быть L7-атака на конкретный сценарий. Такая же картина бывает при ошибке в коде или тяжёлом запросе к базе, поэтому нужны логи и метрики.

Технические признаки

На уровне сервера и приложения стоит смотреть не только общий трафик, но и его структуру. Для DDoS характерны:

• резкий рост количества запросов за короткий период;
• много однотипных обращений к одним и тем же URL;
• необычная география или источники трафика;
• высокая нагрузка на CPU, RAM, веб-сервер или базу данных;
• рост ошибок 5xx;
• большое количество запросов к тяжёлым страницам: поиску, фильтрам, корзине, авторизации, API.

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

Какие данные нужны для первичной диагностики

Чтобы быстрее понять причину, заранее полезно иметь доступ к нескольким источникам данных:

• логам веб-сервера;
• графикам нагрузки CPU, RAM, диска и сети;
• логам ошибок CMS и приложения;
• статистике по кодам ответа;
• данным Яндекс Метрики или другой аналитики;
• информации о последних релизах, изменениях на сервере и рекламных запусках.

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

Как защитить сайт от DDoS-атак заранее

Эффективная защита сайта от DDoS-атак строится слоями. Часть нагрузки должен принимать провайдер инфраструктуры, часть — CDN, WAF и Anti-DDoS-сервисы, часть — настройки самого сайта. Чем лучше подготовлены сервер, CMS, база данных и критичные сценарии, тем выше шанс сохранить доступность сайта даже при резком росте вредоносного трафика.

Выбрать хостинг или облако с Anti-DDoS-защитой

Для коммерческого сайта хостинг лучше выбирать не только по цене и объёму диска. Важно уточнить:

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

Если сайт приносит заявки, заказы или обслуживает клиентов через личный кабинет, экономия на инфраструктуре быстро становится рискованной. При атаке слабое место проявится там, где меньше всего запаса: в канале, CPU, памяти, базе данных или сетевых настройках.

Подключить CDN и защищённый DNS

CDN помогает распределить нагрузку и отдавать статические файлы через сеть промежуточных серверов. Это снижает давление на основной сервер и ускоряет загрузку страниц для пользователей из разных регионов.

Защищённый DNS нужен, чтобы домен не стал отдельной точкой отказа. Если DNS работает нестабильно, пользователь может не попасть на сайт даже при исправном сервере и рабочей CMS.

Для бизнес-сайта стоит проверить:

• кто управляет DNS-записями;
• есть ли резервные NS-серверы;
• насколько быстро можно изменить записи при аварии;
• используется ли CDN для статики и публичных страниц;
• скрыт ли реальный IP сервера там, где это возможно.

Настроить WAF и фильтрацию трафика

WAF защищает уровень приложения: формы, авторизацию, API, корзину, поиск, админку и другие динамические участки сайта. Это особенно важно при L7-атаках, когда запросы внешне похожи на обычные действия пользователя.

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

Использовать rate limiting, firewall и CAPTCHA там, где это уместно

Ограничение частоты запросов помогает сдерживать нагрузку на уязвимые сценарии: форму входа, поиск, корзину, фильтры, API, отправку заявок. Главное — настраивать ограничения аккуратно, чтобы не мешать реальным пользователям.

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

Оптимизировать сайт, сервер и базу данных

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

Особое внимание стоит уделить страницам, которые создают высокую нагрузку:

• поиск;
• умные фильтры;
• сортировки и подборки;
• корзина и оформление заказа;
• личный кабинет;
• страницы с большим количеством динамических блоков;
• API и обмены с внешними системами.

Закрыть лишние порты, служебные разделы и админку

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

Минимальный набор действий:

• закрыть неиспользуемые порты;
• ограничить доступ к административным разделам;
• настроить доступ по IP там, где это возможно;
• убрать тестовые файлы и временные скрипты;
• проверить права пользователей и технических аккаунтов;
• отключить лишние публичные endpoints.

Настроить мониторинг доступности и нагрузки

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

Отслеживать стоит не только главную страницу. Для бизнеса важнее контролировать ключевые сценарии:

• открывается ли каталог;
• работает ли форма заявки;
• доступна ли корзина;
• проходит ли авторизация;
• отвечает ли API;
• выполняется ли обмен с CRM или 1С;
• не растёт ли количество ошибок 5xx.

Подготовить план реагирования

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

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

Главный принцип: защита должна срабатывать до того, как вредоносный трафик доберётся до самых дорогих для сайта ресурсов — базы данных, CMS, корзины, поиска, личного кабинета и API.

Как выбрать уровень защиты для сайта

Защита от DDoS должна соответствовать роли сайта в бизнесе. Небольшому корпоративному сайту и интернет-магазину с каталогом, оплатой, 1С и личным кабинетом нужны разные уровни подготовки. Ориентироваться стоит не только на размер компании, но и на стоимость простоя.

Базовая защита для корпоративного сайта

Базовый уровень подходит сайтам услуг, корпоративным сайтам и проектам, где нет сложной пользовательской логики, онлайн-оплаты и постоянного потока заявок.

Минимальный набор:

• надёжный хостинг с базовой Anti-DDoS-защитой;
• защищённый DNS;
• резервные копии;
• закрытая админка и служебные разделы;
• базовый мониторинг доступности;
• обновления CMS и модулей.

Такой уровень не делает сайт неуязвимым, но снижает риск простоя из-за типовых атак и слабой инфраструктуры.

Усиленная защита для сайта с рекламным трафиком

Если сайт получает заявки из Яндекс Директа, SEO, email-рассылок или партнёрских размещений, требования выше. Здесь важна не только доступность главной страницы, но и стабильность посадочных страниц, форм, квизов, калькуляторов и интеграций с CRM.

Для усиленного уровня стоит добавить:

• CDN для статики и публичных страниц;
• WAF для защиты форм, авторизации и API;
• ограничения частоты запросов к чувствительным URL;
• мониторинг ключевых сценариев: формы, корзины, личного кабинета;
• регламент по рекламе на случай недоступности сайта.

Главный вопрос: что произойдёт, если сайт будет нестабилен 30 минут, 2 часа или весь рабочий день. Если ответ — “мы потеряем заявки и рекламный бюджет”, базовой защиты уже мало.

Профессиональная защита для интернет-магазина, портала и личного кабинета

Профессиональный уровень нужен проектам, где сайт является частью операционной системы бизнеса. Это интернет-магазины, B2B-порталы, сервисы с авторизацией, личные кабинеты, сайты с онлайн-оплатой, обменом с 1С, CRM, складами и службами доставки.

Здесь важно защищать не только входящий трафик, но и самые дорогие для системы участки:

• каталог и фильтры;
• поиск;
• корзину и оформление заказа;
• авторизацию;
• API;
• обмены с внешними системами;
• административную часть.

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

Когда нужен отдельный Anti-DDoS-провайдер

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

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

Особенности защиты сайта на 1С-Битрикс

Сайты на 1С-Битрикс часто используются для интернет-магазинов, B2B-порталов, корпоративных сайтов с личными кабинетами и проектов с интеграциями. Поэтому при DDoS-атаке важно защищать не только сервер, но и те части сайта, которые создают высокую нагрузку на CMS, базу данных и внешние системы.

Кэширование и производительность

Для Битрикс-проекта кэширование — один из ключевых элементов устойчивости. Если страницы, компоненты и запросы к базе данных не оптимизированы, сайт может тормозить даже при обычной нагрузке. При DDoS или резком всплеске трафика такие слабые места проявляются быстрее.

Что стоит проверить:

• включён ли и корректно ли работает кэш компонентов;
• настроен ли композитный режим там, где он уместен;
• нет ли тяжёлых SQL-запросов на популярных страницах;
• не создают ли шаблоны компонентов лишнюю нагрузку;
• что показывает «Монитор производительности» Битрикс;
• хватает ли серверу CPU, RAM и дисковой производительности.

DDoS-защита будет эффективнее, если сайт сам по себе не расходует слишком много ресурсов на каждое действие пользователя.

Каталог, фильтры, поиск и корзина

У интернет-магазинов и B2B-каталогов самые чувствительные зоны — фильтры, поиск, сортировки, карточки товаров, корзина и оформление заказа. Именно эти сценарии часто создают обращения к базе данных и могут стать целью L7-атаки.

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

Для таких разделов полезно заранее настроить:

• кэширование результатов там, где это возможно;
• ограничения частоты запросов;
• защиту форм и авторизации;
• оптимизацию SQL-запросов;
• контроль медленных страниц;
• мониторинг ошибок оформления заказа.

Интеграции с 1С, CRM и внешними сервисами

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

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

Агенты, cron и фоновые задачи

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

Что стоит проверить:

• какие агенты работают на сайте;
• какие задачи вынесены в cron;
• не запускаются ли тяжёлые процессы в пиковые часы;
• нет ли зависших или слишком частых фоновых операций;
• можно ли временно отключить второстепенные задачи при аварии.

Цель — не остановить развитие сайта, а сделать нагрузку предсказуемой. Тогда во время инцидента команда понимает, какие процессы критичны, а какие можно безопасно ограничить.

Админка, API и служебные разделы

Административная часть, API и служебные URL не должны быть открыты “на всякий случай”. Чем больше публичных технических точек доступно извне, тем сложнее контролировать нагрузку и безопасность.

Для сайта на Битрикс стоит заранее ограничить доступ к административным и служебным разделам:

• закрыть админку дополнительными правилами доступа;
• ограничить вход по IP там, где это возможно;
• защитить API от частых и однотипных запросов;
• отключить неиспользуемые endpoints;
• проверить права пользователей и технических аккаунтов;
• убрать тестовые скрипты, временные файлы и старые служебные страницы.

Для Битрикс-проекта DDoS-защита должна идти вместе с технической поддержкой: оптимизацией производительности, контролем интеграций, проверкой безопасности, мониторингом и понятным планом действий при сбоях.

Кто отвечает за защиту сайта от DDoS-атак

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

Для устойчивой защиты нужны несколько участников: хостинг или облачный провайдер, Anti-DDoS-сервис, техническая поддержка сайта, маркетолог и владелец бизнеса. У каждого своя роль.

За что отвечает хостинг

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

Заранее стоит уточнить:

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

За что отвечает Anti-DDoS-сервис

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

До подключения важно понять, какие уровни защиты доступны: L3/L4, L7, WAF, защита от ботов, отчёты по атаке, ручная настройка правил, аварийный режим и поддержка при инциденте.

За что отвечает техническая поддержка сайта

Техническая поддержка отвечает за сам сайт: CMS, серверные настройки, кэширование, логи, тяжёлые страницы, интеграции, админку, API и ошибки приложения.

Именно поддержка помогает понять, где слабое место:

• в коде;
• в базе данных;
• в настройках Битрикса;
• в фильтрах каталога;
• в интеграции с 1С или CRM;
• в API;
• в серверной конфигурации.

Также техническая команда взаимодействует с хостингом и Anti-DDoS-провайдером: передаёт логи, атакуемые URL, данные по нагрузке и список критичных функций сайта.

Что должен контролировать владелец бизнеса

Владелец бизнеса или руководитель проекта не обязан разбираться в фильтрации трафика, но должен контролировать организационную сторону:

• у кого есть доступы к домену, DNS, хостингу и сайту;
• кто отвечает за сайт во время аварии;
• кто принимает решение об остановке рекламы;
• какие функции сайта критичны для продаж;
• какой порядок действий включается при недоступности сайта;
• кто сообщает статус руководству, отделу продаж и клиентскому сервису.

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

Хорошая схема работы — когда у бизнеса есть единая точка координации. Это может быть технический подрядчик, project-менеджер или внутренняя IT-команда. Главное, чтобы при атаке не приходилось собирать “антикризисный штаб” с нуля.

Что подготовить заранее для хостинга, разработчика и Anti-DDoS-провайдера

Когда сайт уже недоступен, любое уточнение занимает больше времени: где DNS, у кого доступ к серверу, какие страницы критичны, кто может остановить рекламу, где смотреть логи. Эти данные лучше собрать до инцидента и хранить в одном понятном месте.

Доступы, домены и DNS

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

Заранее стоит зафиксировать:

• где зарегистрирован домен;
• кто управляет DNS-записями;
• где размещён сайт;
• у кого есть доступ к хостингу, серверу, панели управления и CDN;
• какие подрядчики имеют технические доступы;
• есть ли резервные контакты на случай отпуска или увольнения ответственного.

Это снижает риск ситуации, когда сайт лежит, а команда ищет доступы в старых переписках.

Список критичных страниц и функций сайта

Anti-DDoS-провайдеру и технической поддержке важно понимать, какие части сайта нельзя отключать даже временно. Для одного проекта это форма заявки, для другого — корзина, для третьего — личный кабинет или API.

В список критичных элементов стоит включить:

• главную страницу и основные посадочные;
• каталог, карточки товаров, фильтры и поиск;
• корзину и оформление заказа;
• формы заявок, квизы, калькуляторы;
• личный кабинет и авторизацию;
• API и обмены с 1С, CRM, складом, платёжными системами;
• административные и служебные разделы.

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

Контакты ответственных специалистов

Во время атаки важно не просто “написать кому-нибудь”, а быстро попасть к тому, кто может действовать. В аварийный список стоит добавить контакты:

• хостинга или облачного провайдера;
• Anti-DDoS-сервиса;
• технической поддержки сайта;
• разработчика или администратора сервера;
• маркетолога, который управляет рекламой;
• руководителя, который принимает бизнес-решения.

Для каждого контакта лучше указать канал связи, часы доступности и зону ответственности.

Логи, метрики и история нагрузки

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

Минимальный набор для диагностики:

• логи веб-сервера;
• графики CPU, RAM, диска и сети;
• статистика кодов ответа;
• данные по ошибкам CMS и приложения;
• аналитика трафика и конверсий;
• история релизов и технических изменений.

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

План действий при недоступности сайта

План реагирования должен быть коротким и применимым на практике. В нём стоит заранее описать:

• кто первым проверяет доступность сайта;
• кто смотрит сервер, логи и нагрузку;
• кто связывается с хостингом и Anti-DDoS-провайдером;
• кто принимает решение по рекламе;
• какие функции можно временно ограничить;
• кто сообщает статус руководству и отделу продаж.

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

Что делать, если DDoS-атака уже началась

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

Быстро подтвердить проблему

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

Проверить стоит:

• открывается ли сайт из разных сетей и регионов;
• какие страницы недоступны: весь сайт, каталог, корзина, форма, личный кабинет;
• какие ошибки видят пользователи: 502, 503, 504, таймауты, пустые страницы;
• есть ли резкий рост нагрузки на сервер, базу данных или сеть;
• были ли в последние часы релизы, обновления, изменения DNS, запуск рекламы или массовая рассылка.

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

Собрать данные для диагностики

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

Минимальный набор:

• время начала проблемы;
• список недоступных страниц и функций;
• коды ошибок;
• графики трафика, CPU, RAM, диска и сети;
• логи веб-сервера;
• логи приложения и CMS;
• список URL, на которые идёт основная нагрузка;
• данные по источникам трафика;
• изменения, которые проводились перед сбоем.

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

Связаться с хостингом или Anti-DDoS-провайдером

После первичной проверки нужно передать провайдеру конкретную информацию, а не общее сообщение “сайт не работает”. В обращении лучше сразу указать:

• домен и IP сайта;
• время начала проблемы;
• симптомы для пользователей;
• графики нагрузки, если они есть;
• атакуемые URL;
• коды ошибок;
• критичные функции, которые нужно сохранить доступными;
• какие действия уже были выполнены.

Если Anti-DDoS-защита подключена заранее, можно запросить усиление фильтрации или аварийный режим. Если защиты нет, провайдер подскажет, какие меры доступны на текущем тарифе и можно ли временно перенаправить трафик через защитный сервис.

Временно ограничить тяжёлые функции

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

Под ограничение могут попасть:

• поиск по сайту;
• сложные фильтры каталога;
• сортировки и подборки;
• частые API-запросы;
• импорт и экспорт товаров;
• тяжёлые фоновые задачи;
• второстепенные виджеты и внешние скрипты;
• формы, на которые идёт подозрительная активность.

Такие меры нужно применять аккуратно. Цель — сохранить критичные бизнес-сценарии: открытие сайта, просмотр ключевых страниц, отправку заявки, оформление заказа, авторизацию для важных пользователей.

Проверить рекламные кампании

Если сайт недоступен или нестабильно работает, рекламные кампании нужно проверить сразу. Особенно если трафик идёт на страницы, которые выдают ошибки или не принимают заявки.

Возможные действия:

• временно остановить кампании на недоступные посадочные страницы;
• снизить бюджеты до восстановления стабильности;
• отключить объявления на проблемные разделы;
• проверить цели в аналитике и фактическое поступление заявок;
• предупредить менеджеров, что часть обращений могла не дойти.

Реклама во время DDoS требует отдельного контроля: клики могут продолжать списываться, а пользовательский сценарий уже не работает.

Что не стоит делать во время атаки

Главная ошибка во время инцидента — менять всё подряд без фиксации действий. Это усложняет диагностику и может увеличить время восстановления.

Не стоит:

• хаотично менять DNS-записи без понимания последствий;
• удалять логи, которые нужны для анализа;
• отключать все функции сайта без приоритизации;
• переносить сайт на другой хостинг без диагностики;
• обновлять CMS и модули “на всякий случай” прямо во время атаки;
• оставлять рекламу без контроля;
• вести обсуждение в нескольких чатах без единого ответственного.

Лучше назначить одного координатора, который собирает информацию, фиксирует решения и держит связь с хостингом, Anti-DDoS-провайдером, разработчиками и бизнес-командой.

Что делать после DDoS-атаки

Когда сайт снова доступен, работу нельзя заканчивать на фразе “всё восстановили”. После атаки важно разобрать, что произошло, какие части сайта пострадали и что нужно усилить, чтобы следующий инцидент не повторился по тому же сценарию.

Оценить последствия

Сначала нужно понять бизнес-ущерб. Для этого стоит собрать данные за период атаки и восстановления:

• сколько времени сайт был полностью или частично недоступен;
• какие страницы, формы и функции не работали;
• были ли потеряны заявки, заказы, оплаты или обращения;
• продолжала ли работать реклама;
• были ли жалобы клиентов;
• возникли ли ошибки в CRM, 1С, платёжных системах или службах доставки.

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

Разобрать логи и сценарий атаки

После восстановления нужно сохранить и проанализировать технические данные: логи веб-сервера, графики нагрузки, коды ответов, атакуемые URL, источники запросов, состояние базы данных и серверных ресурсов.

Важно понять, что стало слабым местом:

• канал или сервер;
• DNS;
• CMS;
• база данных;
• поиск, фильтры или корзина;
• API;
• форма авторизации;
• внешняя интеграция.

Если сайт на Битрикс просел из-за тяжёлого фильтра, одной общей Anti-DDoS-защиты может быть недостаточно. Нужно дорабатывать конкретный сценарий: кэширование, запросы к базе, ограничения частоты обращений, правила WAF.

Усилить защиту

По итогам разбора нужно обновить технические настройки. Обычно в план доработок попадают:

• подключение или усиление Anti-DDoS-защиты;
• настройка CDN и защищённого DNS;
• доработка WAF-правил;
• ограничения на частые запросы к чувствительным URL;
• оптимизация тяжёлых страниц;
• настройка мониторинга;
• защита админки, API и служебных разделов;
• проверка рекламных посадочных страниц.

Приоритет стоит отдавать тем участкам, которые уже показали слабость во время атаки.

Обновить план реагирования

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

После атаки полезно обновить:

• список ответственных;
• контакты хостинга и Anti-DDoS-провайдера;
• порядок проверки сайта;
• правила остановки рекламы;
• список критичных страниц и функций;
• инструкции для менеджеров и клиентской поддержки.

Так инцидент превращается в управляемый опыт: бизнес понимает свои слабые места и готовится к следующей нестандартной нагрузке уже осознанно.

Заключение: что важно запомнить

DDoS-атаку нельзя полностью исключить, зато можно подготовить сайт так, чтобы инцидент не превращался в долгий простой, потерю заявок и хаотичное восстановление. Для этого защита должна охватывать несколько уровней: инфраструктуру, DNS, CDN, WAF, сервер, CMS, базу данных, мониторинг и организационный план действий.

Для бизнеса особенно важны четыре вывода:

• защиту от DDoS лучше настраивать до атаки, а не в момент, когда сайт уже недоступен;
• слабые места часто находятся не только в хостинге, но и в самом сайте: тяжёлых страницах, фильтрах, поиске, корзине, API и интеграциях;
• при атаке нужно быстро отличить DDoS от обычного сбоя, собрать данные и подключить нужных специалистов;
• после восстановления стоит разобрать логи, оценить ущерб и усилить именно те участки, которые не выдержали нагрузку.

Если сайт работает на 1С-Битрикс, связан с 1С, CRM, каталогом, корзиной или личным кабинетом, его устойчивость к нагрузкам лучше проверять заранее. В «Профиткит» можно заказать технический аудит сайта, чтобы найти слабые места в производительности, безопасности, серверных настройках и критичных пользовательских сценариях.

Если сайту нужна постоянная защита от сбоев, обновления, мониторинг, резервное копирование и помощь разработчиков, подключите техническую поддержку сайта. Команда «Профиткит» поможет следить за стабильностью проекта, устранять ошибки, дорабатывать функциональность и готовить сайт к нестандартным нагрузкам.

Для проектов на 1С-Битрикс мы также помогаем с разработкой и доработкой сайтов на Битрикс: оптимизируем производительность, настраиваем интеграции с 1С и CRM, улучшаем архитектуру и закрываем технические риски, которые могут мешать продажам и продвижению.

А если во время сбоев сайт продолжает получать платный трафик, стоит отдельно проверить контекстную рекламу в Яндекс Директ и посадочные страницы. Это поможет не тратить бюджет на неработающие сценарии и быстрее восстановить поток заявок после технических проблем.

Больше практических разборов о сайтах, SEO, Битриксе и интернет-маркетинге публикуем в Telegram-канале Profitkit — подписывайтесь, чтобы не пропустить новые материалы.