Pingveraблог ← Блог
Главная › Блог › Защита сайта от DDoS-атак: что сделать интернет-магазину до «Чёрной пятницы»

Защита сайта от DDoS-атак: что сделать интернет-магазину до «Чёрной пятницы»

26 октября 2026 · 11 мин чтения

Защита сайта от DDoS-атак: что сделать интернет-магазину до «Чёрной пятницы»

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

До 11.11 осталось две недели, до «Чёрной пятницы» 27 ноября около месяца. Этого хватит, чтобы выяснить, что уже есть у хостинга, закрыть дыры в настройках и проверить, что фильтр не отрезает ваш же полезный трафик: уведомления платёжного сервиса, обмен с 1С и роботов Яндекса. Ниже порядок действий, таблица ответственности и шаблон письма хостингу.

Коротко

Почему это важно сейчас

Атаки на магазины растут именно в сезоны распродаж. Несколько цифр из открытых отчётов StormWall (это данные клиентов одного провайдера защиты, а не всего рынка):

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

Что такое DDoS-атака на сайт, в двух абзацах

DDoS-атака на сайт означает, что на него одновременно идёт трафик с тысяч устройств, и сервер или канал перестаёт обслуживать настоящих покупателей. Атаки на уровнях L3–L4 забивают канал или сетевой стек пакетами (SYN-флуд, UDP-флуд). Против них работает фильтрация у провайдера: ваш сервер эту волну даже не видит.

Атака на уровне L7 выглядит как обычные HTTP-запросы. Боты открывают поиск, фильтры каталога, страницы с пагинацией, добавляют товары в корзину. Каждый запрос легальный, но дорогой для базы данных. Такой поток провайдерская фильтрация уровня L3–L4 не видит. Например, в документации Yandex Cloud сказано, что базовая DDoS Protection рассчитана на объёмные атаки и не предназначена для атак с валидными TCP-соединениями и HTTP/HTTPS-запросами. Для L7 там есть отдельная расширенная защита, которую подключают через поддержку.

Пошаговая подготовка: что сделать на этой неделе

1. Узнайте, что уже есть у хостинга

Откройте договор или страницу тарифа и задайте поддержке вопросы из шаблона ниже. Главное: на каком уровне работает защита, включена ли она по умолчанию, как подключается L7-фильтрация и меняется ли при этом IP-адрес. В Yandex Cloud, например, базовую защиту можно включить только при создании ресурса или резервировании статического адреса, а переход на расширенную требует отключить базовую, и публичный IP меняется. У других провайдеров условия свои, поэтому выясните их сейчас, а не в день атаки.

2. Решите, где будет фильтроваться L7

Варианты: расширенная защита хостинга, отдельный сервис защиты с проксированием трафика (DNS переключается на его адреса) или WAF перед сайтом. Если выбираете проксирование, подключите его до пика, а не держите «на всякий случай». Переключение DNS во время атаки упирается в TTL записей, а прямой IP сервера к тому моменту уже известен атакующим.

После подключения проксирования закройте прямой доступ к серверу: разрешите входящие соединения на 80/443 только с адресов сервиса защиты. Иначе атакующий пойдёт мимо фильтра на старый IP.

3. Поставьте ограничения на тяжёлые страницы

Даже без внешнего сервиса можно снизить ущерб от L7-атаки. Ограничьте частоту запросов с одного IP к поиску, фильтрам каталога, входу и восстановлению пароля. В nginx это делает модуль limit_req. По умолчанию он отвечает на отклонённые запросы кодом 503, код можно сменить директивой limit_req_status. Пример ниже, в разделе с артефактами. Пороги подбирайте по своим логам за обычный день, иначе вы заблокируете покупателей за одним NAT (офис, мобильный оператор).

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

4. Составьте белый список полезного трафика

Это шаг, который чаще всего пропускают. Выпишите всех, кто ходит на сайт не из браузера:

Для каждого запишите адрес, на который он приходит, и диапазоны IP, если провайдер их публикует. Внесите их в исключения фильтра и лимитов. С поисковыми роботами осторожно: User-Agent легко подделать. Яндекс рекомендует проверять робота по обратному DNS-запросу (имя хоста должно оканчиваться на yandex.ru, yandex.net или yandex.com) и прямым запросом убеждаться, что имя указывает на тот же IP.

5. Подготовьте режим работы во время атаки

Этот план стоит встроить в общий план непрерывности онлайн-продаж.

6. Проверьте наблюдение

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

Таблица: риски, ответственные и проверки

Риск Кто отвечает Как проверить Когда
Защита хостинга не покрывает L7 Владелец, хостинг Письменный ответ поддержки по шаблону ниже Один раз до 11.11
Прямой IP сервера доступен мимо фильтра Разработчик, админ Запрос на IP сервера с заголовком Host вашего домена не должен отдавать сайт После подключения прокси, затем раз в месяц
Фильтр блокирует платёжные уведомления Разработчик Тестовая оплата, статус заказа сменился на «оплачен» После каждого изменения правил
Фильтр блокирует обмен с 1С и фид Разработчик, контент-менеджер Время последнего обмена, статус фида в кабинете Ежедневно в сезон
Лимиты режут живых покупателей Разработчик Число ответов 429/503 в логах за день Ежедневно в сезон
Нет плана на день атаки Владелец Заглушка и контакты лежат в общем доступе До 11.11

Шаблон письма хостингу или сервису защиты

Скопируйте и отправьте сегодня. Ответы сохраните рядом с планом на день атаки.

Тема: Защита от DDoS для [домен] перед распродажами

Здравствуйте! В ноябре у нас пик продаж (11.11 и 27.11). Подскажите, пожалуйста:

1. Какая защита от DDoS включена в наш тариф сейчас и на каких уровнях (L3/L4/L7)?
2. Включена ли она по умолчанию или её нужно подключить? Меняется ли при этом IP-адрес?
3. Есть ли фильтрация HTTP-запросов (L7)? Как подключается, сколько стоит, за какой срок?
4. Что вы делаете с нашим сервером, если атака превышает возможности тарифа
   (ограничиваете трафик, отключаете IP)? Как и когда нас уведомят?
5. Можно ли добавить в исключения фильтра адреса, с которых приходят
   уведомления платёжного сервиса [название] и обмен с 1С?
6. Как связаться с дежурным инженером во время атаки (телефон, срок реакции)?

Спасибо!

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

http {
    limit_req_zone $binary_remote_addr zone=search:10m rate=2r/s;
    limit_req_zone $binary_remote_addr zone=login:10m rate=10r/m;
    limit_req_status 429;

    server {
        location /search/ {
            limit_req zone=search burst=10 nodelay;
            # ...
        }
        location /login/ {
            limit_req zone=login burst=5;
            # ...
        }
        # адреса для уведомлений платёжного сервиса и обмена с 1С
        # в лимиты не включайте
    }
}

Пример: защита включилась, а оплаты перестали подтверждаться

Это условный пример, собранный из типовой ситуации, а не история конкретного клиента.

Магазин на WooCommerce в пятницу вечером получает поток запросов к фильтрам каталога. Сайт отвечает по 15–20 секунд. Разработчик подключает сервис защиты с проверкой браузера (JavaScript-проверкой) для всего сайта. Через полчаса страницы открываются нормально, команда выдыхает.

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

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

Частые ошибки

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

Вопросы и ответы

Нужна ли защита от DDoS небольшому магазину?

Базовая защита на уровне L3–L4 обычно уже есть у крупных хостингов, проверьте это письмом. Отдельная L7-защита стоит денег, поэтому сравните её цену со стоимостью простоя в пиковые дни. Как считать стоимость простоя, описано в статье «Как посчитать стоимость простоя сайта».

Как понять, что идёт атака, а не наплыв покупателей?

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

Повредит ли DDoS-атака позициям в Яндексе?

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

Источники

Проверено: 26 октября 2026 года.

Шаг 6 из подготовки можно автоматизировать в Pingvera: сервис раз в минуту проверяет доступность сайта из нескольких регионов, а для WooCommerce следит за потоком заказов и поднимает алерт «сайт работает, а заказов нет», если после включения защиты оплаты перестали доходить. Бесплатно до 5 сайтов, разовая проверка без регистрации доступна на pingvera.ru/check.

Узнавайте о проблеме раньше клиента

Pingvera следит за сайтами клиентов «снаружи и изнутри» — доступность из регионов, формы, оплата, домен, SSL, сервер — и предупреждает в Telegram, email и Max раньше, чем напишет клиент.

Попробовать Pingvera бесплатно

Читайте также: Технический долг интернет-магазина · Как выбрать платформу интернет-магазина · Как выбрать подрядчика для интернет-магазина · Защита аккаунтов покупателей от взлома · Бесплатно проверить сайт.

← Все статьи · Политика конфиденциальности · pingvera.ru · Telegram-канал