DDoS-атака на сайт: как защититься и что делать во время атаки

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

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

Что такое DDoS-атака и почему сайт перестаёт работать

Аббревиатура DDoS означает распределённый отказ в обслуживании. Множество устройств одновременно отправляют обращения к одному ресурсу. Сервер пытается обработать их как обычных посетителей, исчерпывает доступные ресурсы и начинает отвечать медленно либо вовсе не отвечает.

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

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

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

Какие виды атак опасны для бизнеса

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

Перегрузка канала и сетевой инфраструктуры

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

Атаки на соединения

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

Атаки на уровень сайта

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

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

Как понять, что это именно атака, а не проблема хостинга

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

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

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

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

Что делать во время DDoS-атаки: порядок первых действий

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

1. Подтвердите инцидент. Проверьте сайт из двух независимых сетей, мониторинг и панель хостинга. Зафиксируйте начало, симптомы и затронутые функции.
2. Обратитесь к провайдеру. Сообщите домен, время начала, признаки перегрузки и попросите проверить DDoS на своей стороне. Уточните, включена ли защита в вашем тарифе и какие ограничения доступны прямо сейчас.
3. Включите фильтрацию. Если предусмотрена защита сети доставки контента, межсетевой экран или режим проверки посетителей, активируйте его по согласованной инструкции. Временно ограничьте подозрительные адреса и частые обращения к тяжёлым страницам.
4. Снизьте нагрузку приложения. На время отключите необязательные виджеты, тяжёлый поиск, импорт данных и фоновые задачи. Не отключайте оплату или личный кабинет без оценки последствий, если это ключевой путь клиента.
5. Сохраните коммуникацию с клиентами. Разместите короткое нейтральное сообщение на доступном канале: телефоне, мессенджере, карточке компании. Укажите альтернативный способ заказа, не называя неподтверждённые причины.
6. Проверьте восстановление. После спада трафика убедитесь, что формы, корзина, оплата, письма и интеграции действительно работают, а не только открывается главная страница.

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

Защита от DDoS: из каких слоёв она состоит

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

Инфраструктура и фильтрация до сервера

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

Настройка веб-сервера и приложения

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

Мониторинг и резервный сценарий

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

Защита от DDoS не заменя��т общую безопасность. Устаревшая система управления сайтом, слабые пароли и уязвимые расширения создают другие риски. Базовые меры разобраны в статье «Безопасность сайта: как защититься от взлома и вирусов».

Сколько стоят защита и восстановление после атаки

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

Разовая диагностика, настройка правил, кэширования и мониторинга в типичном небольшом проекте занимает от нескольких часов до 2-3 рабочих дней. Доработка тяжёлого каталога, перенос инфраструктуры или внедрение резервной схемы требуют отдельного обследования и могут занять 1-3 недели. Точная смета после брифа, доступа к текущей конфигурации и понимания допустимого времени простоя.

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

Типичные ошибки, которые продлевают простой

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

• Блокировка всех зарубежных адресов без проверки. Это может отсечь часть атаки, но одновременно лишить доступа клиентов, партнёров, сотрудников в поездке и сервисы интеграций.
• Отключение сайта вместо фильтрации. Режим обслуживания допустим только как крайняя короткая мера. Он не помогает принять заказы и даёт атакующему нужный результат.
• Изменения прямо на рабочем сайте без резервной копии. Непроверенное правило или обновление может сделать недоступными реальные формы и оплату.
• Отсутствие владельца процесса. Маркетолог ждёт разработчика, разработчик ждёт хостинг, руководитель узнаёт о простое от клиента. Нужен короткий регламент и список контактов.
• Игнорирование журналов после восстановления. Без разбора нельзя понять, какая точка была уязвима и что надо изменить до следующей волны.

Ещё одна ошибка, путать DDoS с ботами, накручивающими формы или собирающими цены. Эти проблемы могут идти одновременно, но требуют разных правил. Сначала нужно установить источник нагрузки и её уровень, затем выбирать меру защиты.

Как подготовить сайт заранее, до первого инцидента

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

1. Запишите контакты хостинга, регистратора домена, разработчика, ответственного за рекламу и руководителя, который принимает решения.
2. Проверьте, включён ли мониторинг и кому приходят уведомления. Протестируйте, видит ли он недоступность не только главной страницы.
3. Уточните у провайдера условия защиты от DDoS, доступные лимиты и процедуру экстренного обращения.
4. Проверьте резервные копии: где они лежат, как часто создаются и можно ли восстановить сайт на отдельной среде.
5. Ограничьте автоматические запросы к формам, входу, поиску и тяжёлым страницам, если это оправдано бизнес-процессом.
6. Подготовьте сообщение для клиентов и альтернативный канал заказов. Убедитесь, что менеджеры знают, куда направлять обращения.

Если на сайте собираются заявки, телефоны и другие персональные данные, резервны�� сценарий тоже должен быть законным. Например, временная форма в мессенджере не отменяет обязанность корректно информировать пользователя об обработке данных. Полезные требования собраны в мат��риале «Сайт и 152-ФЗ: какие документы, согласия и cookie нужны бизнесу».

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

Можно ли полностью защитить сайт от DDoS-атаки?

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

Поможет ли обычный хостинг?

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

Нужно ли менять домен во время атаки?

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

Может ли DDoS привести к утечке данных?

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

Надо ли останавливать рекламу, если сайт недоступен?

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

Что делать: короткий план

1. Проверьте недоступность сайта из разных сетей и зафиксируйте время, ошибки, затронутые страницы.
2. Свяжитесь с хостингом или администратором, запросите проверку трафика, нагрузки и журналов.
3. Включите доступную сетевую фильтрацию, ограничьте подозрительные частые запросы, временно отключите необязательные тяжёлые функции.
4. Переведите клиентов на резервные каналы и приостановите рекламу, если заказы нельзя принять.
5. После восстановления протестируйте формы, оплату, письма, личный кабинет и интеграции.
6. Разберите причину, настройте мониторинг, защитные правила, резервные копии и понятный регламент реакции.

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