Запустили акцию, через полчаса сайт начинает тормозить, а на графике трафика вертикальная стена. Первое желание — позвонить админам и попросить «включить защиту, всё подозрительное порезать». Иногда это правильный ход. Но довольно часто под фильтр уходят те самые покупатели, за которых только что заплатили рекламой.
Мы в ITSumma круглосуточно поддерживаем инфраструктуру клиентов, и такие звонки нам знакомы. Ниже разбираем, как понять, что на самом деле происходит с сайтом, что делать, если это всё-таки атака, и чем отличаются две модели защиты — Always-On и On-Demand. Комментарии к части про выбор защиты дал Денис Сивцов из DDoS-Guard.
Резкий рост трафика сам по себе ничего не доказывает. Вот что чаще всего выглядит как DDoS, но им не является.
Ваша же реклама. Рассылка ушла по всей базе, баннер вышел на крупной площадке, блогер выложил ссылку. Запросов за пару минут стало в разы больше — на графике это неотличимо от атаки. Особенно если техподдержку о кампании никто не предупредил, а сервер рассчитан на обычный будний день.
Сайт просто вырос. Трафик прибавлялся месяцами, понемногу, и однажды сервер перестал справляться. Запросы встают в очередь, страницы открываются дольше, люди жмут «обновить» — и нагрузка растёт уже лавиной. Это не атака. Это сигнал, что инфраструктуру пора масштабировать.
Боты, которых вы позвали сами. Поменяли структуру URL, открыли API, выложили пару тысяч новых карточек товаров — и на сайт пришли поисковые роботы, парсеры, агрегаторы. Трафик формально ботовый, но злого умысла в нём нет: так экосистема реагирует на изменения.
Мониторинг, который кладёт сайт. Звучит как анекдот, но встречается регулярно. Если проверки доступности идут слишком часто и каждая открывает тяжёлую страницу с запросами к базе данных, мониторинг сам превращается в источник нагрузки. Сайт по сути атакует собственный инструмент.
Поломки внутри. Неудачная cron-задача, бесконечный редирект, два микросервиса, которые гоняют друг другу запросы по кругу, утечка соединений к базе. Графики горят красным, только злоумышленника снаружи нет.
Ответ почти всегда лежит в логах сервера. Вот на что стоит попросить посмотреть техническую команду:
Блокировать что-либо имеет смысл только после того, как атака подтверждена.
Простое правило, которое снимает много ложных тревог: предупреждайте техподдержку о кампаниях заранее. Дата, примерный охват, откуда пойдёт трафик. Инженеры успеют подготовить сервер, а в день запуска не примут ваших покупателей за ботов.
Всё зависит от того, что было подключено до инцидента.
Защита по требованию (On-Demand). Её нужно активировать: трафик переключается на фильтрующие узлы провайдера, дальше он берёт работу на себя. Пока переключения нет, сайт под ударом, поэтому шаблоны фильтрации и резервные каналы лучше подготовить заранее. Без них переключение растягивается.
Постоянная защита (Always-On). Трафик и так всё время идёт через фильтры, атака отсекается автоматически. Команде остаётся проверить, что вместе с ботами не отрезали живых пользователей, и при необходимости поправить белые списки вместе с провайдером.
Внешней защиты нет. Тогда отбиваются своими силами, и многое зависит от сложности атаки.
Простую атаку — с ограниченного набора адресов, по одной странице, с одинаковыми заголовками — инженеры обычно гасят на самом сервере. Ограничивают частоту запросов с одного IP в nginx, фильтруют по User-Agent, блокируют адреса через iptables, настраивают автоматический бан по правилам через fail2ban. Есть и жёсткий вариант: nginx разрывает соединение без ответа (код 444). Работает, но агрессивные правила нередко задевают реальных пользователей, так что к нему прибегают всё реже.
Сложная атака меняет IP-адреса и паттерны и неплохо притворяется людьми. Серверных средств против неё хватает ненадолго, и надёжный выход остаётся один — срочно подключать внешний сервис. Если это случилось в разгар акции, сценарий выходит самым дорогим из возможных.
Приём из нашей практики. Когда атаки раз за разом бьют по главной странице, помогает заранее подготовленная её статическая HTML-копия: скрипт генерирует её по расписанию, а в момент атаки трафик уводят на неё. Тяжёлая динамика разгружается, остальные страницы сайта продолжают работать.
После атаки сайт обычно восстанавливается сам: очищаются очереди, восстанавливаются соединения, перезапускаются процессы. Чем мощнее была атака, тем дольше это длится. С Always-On делать ничего не нужно, сервис продолжает фильтровать трафик. С On-Demand защиту выключают вручную, и тут возможна небольшая задержка. А если отбивались без внешней защиты, к восстановлению почти наверняка придётся подключать инженеров.
Сложные атаки сегодня стали почти нормой, поэтому вопрос уже не в том, нужна ли защита, а в том, какая именно.
Главное отличие — в режиме работы. Always-On фильтрует весь трафик постоянно. On-Demand включается, когда атака уже обнаружена.
Провайдеры могут вкладывать в эти термины немного разный смысл. У DDoS-Guard, например, это ещё и разные модели оплаты: Always-On оплачивается помесячно, On-Demand — пакетами по 24 часа.
Экономия понятна: платите только тогда, когда на вас нападают. Слабое место — промежуток между началом атаки и включением защиты. Атаку нужно заметить, решить, что пора переключаться, и развернуть фильтрацию. Всё это время сайт открыт, и этот промежуток ведёт к даунтайму.
Пример. Идёт HTTP-флуд на 10 000 запросов в секунду, а защита срабатывает через 5 секунд. К этому моменту сервер, скорее всего, уже перегружен.
Отдельная история — атаки типа pulse wave, когда вредоносный трафик приходит короткими мощными всплесками. Пока трафик перенаправляют на фильтры, первая волна уже схлынула. Защиту выключили — пришла следующая. И так по кругу.
Хуже всего защита по требованию справляется со сложными атаками на прикладном уровне (L7): запросы имитируют обычных пользователей, объём небольшой, паттерны меняются. Такие атаки долго остаются незамеченными, а значит, и защита включается поздно.
Плюс очевидный: окна уязвимости нет. Фильтрация работает до атаки, во время и после, ничего переключать не нужно. У таких решений обычно есть запас мощности на крупные атаки, поэтому их выбирают банки, интернет-магазины, SaaS-сервисы — все, у кого даже короткий сбой бьёт по деньгам или репутации.
Минусов два. Первый — цена. Постоянная фильтрация всего трафика требует от провайдера серьёзных ресурсов, и это отражается в счёте. Для проекта, который атакуют раз в год, такая защита может оказаться лишней статьёй расходов.
Второй менее очевиден. Атака может быть направлена не на вас, а на другого клиента того же провайдера, но оказаться настолько мощной, что заденет сеть защитника и всех, кто за ней стоит.
Выбор между On-Demand и Always-On напрямую определяет, сколько бизнес потеряет под атакой. При этом On-Demand остаётся разумным вариантом для 70–80% проектов, которые атакуют реже раза в квартал. [⚠️ ФАКТ-ЧЕК]
Решение обычно складывается из трёх вещей.
Сколько стоит час простоя. Для маркетинга это считается довольно просто: оборот за час в пиковый день плюс рекламный бюджет, который в этот час слили на неработающий сайт. Если сумма ощутимая — смотрите в сторону Always-On. Если потери терпимы, хватит On-Demand.
Какой у вас трафик. API с жёсткими таймингами, например биржевые торги, требует Always-On с узлами, которые дают минимальные задержки. Лендингам и блогам обычно достаточно On-Demand в связке с CDN.
Есть ли кому нажать кнопку. On-Demand нужно включать, а значит, нужны DevOps-специалисты, которые следят за угрозами и активируют защиту вовремя. Если такой команды нет, Always-On надёжнее: он работает без участия людей.
Защита по требованию подходит не только небольшим проектам.
Always-On разумно выбирать тем, для кого простой критичен и кого атакуют часто:
Выбирая такого провайдера, стоит смотреть, насколько географически распределены его центры очистки трафика — от этого зависят задержки. И регулярно проверять правила фильтрации, чтобы защита не блокировала, скажем, легитимные платежи из-за «подозрительного» IP.
On-Demand закрывает задачи бизнеса с выраженной сезонностью, некритичной инфраструктурой и ограниченным бюджетом, а также тех, кого атакуют редко. Несколько примеров:
Если бизнес живёт от акции к акции, логичная схема — On-Demand с заранее настроенными шаблонами фильтрации плюс календарь кампаний, согласованный с техподдержкой.
DDoS давно стал фоновым явлением, примерно как спам в почте, а защита от него — такой же базовой вещью, как резервное копирование или мониторинг. Для маркетинга отсюда простой практический вывод: календарь акций должен быть не только у вас, но и у тех, кто отвечает за сервер.