Когда сайт тонет в трафике: как вовремя распознать DDoS и спасти продажи сегодня

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

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

Почему это больно для бизнеса, а не только для серверов

Падение сайта — это обрыв пути клиента к оплате. Непройденная корзина превращается в незавершённый заказ, а несостоявшаяся заявка — в конкурента, который оказался доступнее. Чем длиннее простой, тем заметнее провал в отчётах по выручке, конверсиям и ретаргетингу.

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

DDOS атака: что это и с чем её едят

Если коротко, DDoS — это попытка лишить ваш ресурс доступности за счёт перегрузки. В отличие от одиночного злонамеренного запроса, распределённая атака исходит сразу из множества источников, часто из заражённых устройств по всему миру. Внешне это похоже на резкий наплыв «посетителей», которые ничего не покупают, но занимают все ресурсы.

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

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

DDoS-атака: как понять, что ваш сайт уже теряет клиентов, и что делать прямо сейчас

Самый надёжный индикатор — метрики конверсии и скорости. Когда графики трафика растут, а конверсии падают, скорее всего пользователи упираются в ошибки или бесконечную загрузку. Если к этому добавляются всплески 502, 503 или 504, дело пахнет перегрузкой, а не разовым сбоем.

Ещё один признак — резкая смена географии посетителей и всплеск однотипных user-agent. Часто возникают сотни тысяч коротких сессий без поведенческих следов, много незавершённых TCP-соединений, быстрый рост SYN или UDP-пакетов. Прикладные атаки заметны по аномальному числу запросов к тяжёлым эндпоинтам, где каждая страница требует много ресурсов.

Как понять, что сайт под DDoS: ранние признаки и чёткие проверки

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

Сетевой уровень выдаёт себя количеством SYN в секунду, ростом неполных TCP-handshake, взрывом UDP-пакетов на нестандартные порты. На прикладном уровне настораживают частые запросы к поиску, корзине, PDF-генерации, любым ресурсно затратным операциям, особенно если реальных пользователей сейчас меньше, чем запросов.

Симптомы в браузере тоже важны. Пользователи сообщают, что сайт не открывается из за DDoS, хотя мониторинги показывают «зелёный» статус. Проверьте из нескольких провайдеров и через мобильную сеть, сравните результаты cURL и браузера, взгляните на тайминги TLS-рукопожатия и DNS.

Когда «сайт не открывается из-за DDoS»: отличаем атаку от внутренней ошибки

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

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

Если трафик идёт мимо CDN на прямой IP, значит кто-то знает адрес вашего источника и бьёт по нему. В этом случае отключение DNS мало помогает, пока не спрячете origin и не включите фильтрацию. Это частая причина затяжных простоев.

Что делать, если атакуют сайт: пошаговые действия первого часа

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

1. Включите защитный режим в CDN или WAF: challenge по поведенческим признакам, агрессивное кеширование, временные заглушки на тяжёлых маршрутах.
2. Ограничьте скорость на уровне балансовщика: rate limit по IP, по токену, по маршруту. Для публичных API включите burst-квоты.
3. Закройте «дорогие» эндпоинты временными правилами или упростите их ответ. Например, отключите сложные фильтры, временно сократите выдачу.
4. Включите гео- и ASN-фильтры, если видна выраженная страна или автономная система источника. Делайте это осторожно, чтобы не отрезать легитимных клиентов.
5. Поднимите уровень кеширования в CDN, добавьте stale-while-revalidate и serve-stale при ошибках. Это снижает давление на origin.
6. Спрячьте источник: смените IP или ограничьте доступ к origin только из подсетей вашего CDN. Закройте все обходные домены.
7. Свяжитесь с провайдером: попросите включить очистку трафика или маршрутизацию через скраббинг-центр. Обсудите blackhole для неиспользуемых адресов.
8. Сообщите клиентам на статус-странице и в соцсетях, что идёт атака и вы её локализуете. Это снижает нагрузку на поддержку и сохраняет доверие.

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

Защита от DDoS атак как постоянная практика, а не разовая акция

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

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

Сетевой и транспортный уровни: держим канал и соединения

Используйте провайдера с Anycast и скраббинг-центрами, это распределяет удар по точкам присутствия. Включайте SYN cookies, повышайте пределы conntrack, следите за pps и bps на периметре. Откажитесь от открытых неиспользуемых портов, применяйте ACL на бордере.

Если у вас свой AS, готовьте FlowSpec и чёткий плейбук по blackhole для адресов, которые можно временно погасить. Для компаний без собственного BGP хорошо работает арендованный защищённый канал через партнёра. Не забудьте про ограничение ICMP и UDP там, где это безопасно.

Прикладной уровень: экономим CPU каждого запроса

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

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

Сократите «дорогие» операции. Индексация полнотекстового поиска, массовые агрегации в базе, генерация файлов — всё это нельзя открывать в публичный интернет без ограничений. Делайте очереди, бэкграундные задачи и pre-render там, где это возможно.

Архитектурные приёмы: прочный каркас вместо хрупкой стены

Распределяйте нагрузку по регионам, держите несколько независимых точек входа, используйте health-check и circuit breaker, чтобы не тянуть весь кластер вниз. Применяйте очереди для тяжелых задач, возвращайте быстрые ответы, а работу доделывайте асинхронно.

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

Личный опыт: как мы вытянули интернет-магазин из-под волны

Несколько лет назад я помогал среднему магазину электроники, который внезапно получил десятикратный рост трафика ночью. RPS на каталог взлетел, корзина отвечала через раз, а панель аналитики показывала странное распределение по странам. Телефоны горячей линии не замолкали.

Мы быстро включили «подозрительный» режим в CDN, завернули кеширование на HTML гостевых страниц, заблокировали два ASN с основной массой источников, а эндпоинт поиска закрыли временной заглушкой. Через 20 минут сайт снова начал открываться, а через час мы подправили правила так, чтобы не задевать реальных покупателей из ближних стран.

За ночь настроили отдельный пул для корзины и оплаты, а на следующий день добавили поведенческую защиту в WAF и pre-render для самых тяжелых страниц каталога. С тех пор у магазина ещё бывали атаки, но ни одна не выключила продажи надолго.

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

Соберите короткую, но полезную приборную панель. Пускай там живут RPS, p95 и p99 задержки, доля 5xx, активные соединения, SYN/s, pps, загрузка CPU и сети на балансировщике и на источнике. Отдельно выведите «дорогие» эндпоинты и их вклад в CPU.

Добавьте географию, распределение по ASN, карточку с топ-10 user-agent и IP по запросам. Это быстро подсказывает, что резать в первую очередь. Логируйте причины блокировок в WAF и сводите статистику по триггерам.

Коммуникации: как говорить с клиентами, командой и руководством

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

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

Подготовка «на берегу»: роли, плейбуки и учения

Плейбук должен быть под рукой, а не в архиве. Кому звонить у провайдера, какие тумблеры включать в CDN, какие эндпоинты можно временно отключить — всё это должно быть описано и проверено. Раз в квартал проводите учения, пусть даже на стенде.

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

Защита сайта от атак: выбираем инструменты с умом

Если у вас нет штатного SOC, выбирайте сервисы, которые берут на себя фильтрацию и дают понятные отчёты. Хороший признак — наличие Anycast, гибких правил, поведенческой защиты и чётких SLA на время смягчения.

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

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

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

«Увеличим сервера и переживём». Без фильтрации вы лишь оплатите больший счёт и получите тот же исход. «Откроем капчу всем и сразу». Работает минуту, потом падает конверсия, а атака меняет тактику.

Юридические и организационные вопросы, о которых вспоминают в последнюю очередь

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

Если у вас есть договор на «защиту от DDoS», проверьте, что именно покрывается. Часто мелким шрифтом указано, что включена только очистка по L3/L4, а прикладные волны — по другой ставке. Уточняйте заранее.

Тестирование и профилактика: готовимся без стресса

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

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

Набор проверок, который стоит держать под рукой

• Доступность из трёх разных сетей: домашний провайдер, мобильная сеть, внешний мониторинг.
• Графики RPS, p95/p99, 5xx по сервисам, активные соединения, SYN/s и pps.
• Топ-эндоинты по CPU и времени ответа, наличие кеширования и TTL.
• Правила WAF и rate limit, список временных заглушек и фич-флагов.
• Контакты NOC провайдера, шаблоны запросов на скраббинг и blackhole.
• Готовая статус-страница и шаблон сообщения для пользователей.

Как говорить о деньгах: оценка потерь и обоснование инвестиций

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

Сравните это с ценой «страховки»: услуги по фильтрации, CDN, время инженеров на внедрение. Деньги любят тишину, но здесь они как раз объясняют, почему защита — это не роскошь. Хорошая аргументация экономит время на внутренних спорах.

Примеры правил и приёмов, которые работают на практике

Rate limit на эндпоинт поиска с учётом cookie гостя и IP блокирует волны без ущерба для авторизованных. Ограничение на генерацию PDF и экспортов в минуту убирает возможность выжечь CPU одним видом запроса. Правила по аномальным user-agent отсеивают часть ботов ещё до тяжёлых проверок.

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

Ответ на главный вопрос: что делать, если атакуют сайт, прямо сейчас

Сконцентрируйтесь на трёх шагах. Сначала включите всё, что фильтрует и кеширует: WAF, режим повышенной защиты, агрессивные TTL. Затем ограничьте «дорогие» маршруты и скоростные лимиты, отрежьте очевидные источники по ASN и гео.

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

Чтобы не забыть: короткий взгляд вперёд

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

Если подытожить, ddos атака что это — это проверка вашей готовности держать удар. Как понять что сайт под ddos — смотреть на метрики и поведение, а не на догадки. Защита сайта от атак строится слоями, и чем раньше вы начнёте, тем меньше поводов для экстренных ночных совещаний.

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

MacnetSEO

Этому сайту 17 лет. Сайт используется для экспериментов. Тексты могут быть написаны нейросетью. Автор в основном находится в Московской области, Одинцово или в Крыму.

• Напишите мне через Мессенджер Max
• liv-orlov@yandex.ru
• +7 (926) 226-42-46 только для ламповых SMS