Тема
Режим
Язык
Тема
Режим
Язык
Консультация
FREE Бесплатный аудит сайта за 15 мин Заказать →
NEW Остановили 2 млн атак credential stuffing Кейс →
Разборы атак и инструменты Telegram →
70% трафика могут быть ботами Проверить →
SOS Сайт под атакой? Поможем за 30 мин SOS →

Анатомия DDoS-атаки: 60 минут из жизни интернет-магазина

Детальная реконструкция реальной атаки на e-commerce проект. Хронология событий, ошибки защиты, работа нашей команды. Разбор с логами и схемами.

14 февраля 2024, 11:23. Интернет-магазин подарков готовится к пиковому дню продаж. Трафик в 3 раза выше обычного. В 11:36 всё изменится.

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

47
минут простоя
до полного восстановления
18
Гбит/с на пике
входящего трафика
340K
рублей потерь
за время атаки
99.2%
отфильтровано
вредоносных запросов
01

Разведка: за 48 часов до атаки

Что происходит до первого пакета

Большинство атак начинаются с разведки. Атакующий изучает цель: определяет IP-адреса, хостинг-провайдера, наличие защиты.

В нашем случае разведка показала критические уязвимости:

Что увидел атакующий
Сервер напрямую в интернете без CDN. Реальный IP виден в DNS. WAF отсутствует. Канал 100 Мбит/с — легко перегрузить. Мониторинг не настроен — долго не заметят.
flowchart TB
    subgraph RECON[Разведка]
        R1[DNS lookup] --> R2[Определение IP]
        R2 --> R3[Сканирование портов]
        R3 --> R4[Проверка WAF/CDN]
    end
    subgraph ANALYSIS[Анализ]
        A1[Оценка пропускной способности] --> A2[Поиск уязвимых endpoint]
        A2 --> A3[Выбор вектора атаки]
    end
    subgraph RESULT[Вывод]
        V1[Цель уязвима]
        V2[Рекомендуемый вектор: L7 HTTP Flood]
    end
    RECON --> ANALYSIS --> RESULT
Типичный процесс разведки перед атакой
02

Удар: первые 15 минут

Хронология атаки
HTTP Flood

HTTP Flood: 127,000 запросов в секунду

Боты-браузеры
Headless Chrome
HTTP Requests
Backend
DB
Онлайн

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

Каждый запрос проходит через веб-сервер → приложение → базу данных. CPU и RAM растут.

Приложение перестаёт отвечать. 502/503 для всех пользователей. Бизнес теряет деньги.

Поведенческий анализ, JS-challenge и rate limiting фильтруют ботов от людей.

nginx error.log
$ tail -f /var/log/nginx/access.log
192.168.1.1 - - [14/Feb/2026:01:00:00] "GET /api" 200
03

Потерянное время: 11 минут без реакции

Почему мониторинг не сработал

С момента начала атаки до первой реакции прошло 11 минут. За это время:

  • 340+ посетителей увидели ошибку и ушли
  • 47 заказов не были оформлены
  • 3 корпоративных клиента не смогли войти в личный кабинет

Причина задержки — отсутствие автоматических алертов. Единственный канал уведомлений — email, который проверяют раз в час.

Без защиты
200 RPS запросов/сек
CPU 15% нагрузка
80ms latency
12 Мбит/с трафик
С защитой
127,000 RPS x635
CPU 100% перегрузка
timeout отказ
18 Гбит/с x1500
04

Подключение команды защиты

Как мы отбивали атаку

В 11:52 клиент связался с нашей командой. Время реакции — 4 минуты до начала активных действий.

Первичная диагностика показала:

  • Атака типа HTTP Flood (L7)
  • Источники — ботнет из 8,400 IP-адресов
  • География — преимущественно Юго-Восточная Азия
  • Паттерн — запросы к каталогу товаров с рандомными параметрами
1
Анализ трафика
2
Перенаправление трафика
3
Настройка правил фильтрации
4
Защита origin-сервера
5
Мониторинг и донастройка
flowchart LR
    subgraph ATTACK[Атакующий трафик]
        BOT[Ботнет 8.4K IP]
    end
    subgraph FILTER[Инфраструктура фильтрации]
        EDGE[Edge-сервер] --> JS{JS Challenge}
        JS --> |Не прошёл| BLOCK[Заблокировано]
        JS --> |Прошёл| RL{Rate Limit}
        RL --> |Превышен| BLOCK
        RL --> |OK| GEO{GeoIP}
        GEO --> |Подозрительный| BLOCK
        GEO --> |Чистый| PASS[Пропущено]
    end
    subgraph ORIGIN[Сервер клиента]
        PASS --> WEB[Nginx]
    end
    BOT --> EDGE
Архитектура фильтрации: многоуровневая защита
Статистика фильтрации за время атаки
$ tail -f /var/log/nginx/access.log
192.168.1.1 - - [14/Feb/2026:01:00:00] "GET /api" 200
05

Финансовые последствия

Во что обошлись 47 минут простоя
47
потерянных заказов
средний чек 7,200 руб
340K
рублей прямых потерь
недополученная выручка
890
ушедших посетителей
увидели ошибку 502

Косвенные потери

  • Падение позиций в поисковой выдаче на 8 позиций (восстановление заняло 2 недели)
  • 11 негативных отзывов в первые сутки
  • Потеря доверия B2B-клиентов — 2 запросили SLA-гарантии

Если бы защиты не было

Атака продолжалась 2 часа. При полном простое потери составили бы 1.2+ млн рублей только в прямой выручке, не считая репутационного ущерба.

06

Что изменили после инцидента

Рекомендации нашей команды

После инцидента мы провели полный аудит инфраструктуры и внедрили комплекс мер:

Внедрённые меры защиты

Используйте Let's Encrypt или Cloudflare для бесплатных сертификатов
Лимитируйте /login, /api, /search — основные точки атак
Cloudflare WAF, ModSecurity или аналоги
Снижает нагрузку на origin в 5-10 раз
Grafana + Prometheus или встроенный в CDN
Быстрое переключение при атаке на основной
Телефон техподдержки для экстренных случаев
Блокировка регионов откуда не ждёте трафик
hCaptcha или Cloudflare Turnstile
Telegram/Slack уведомления при аномалиях
💡
Совет
Результат: За 8 месяцев после внедрения защиты было отражено 12 атак различной интенсивности. Ни одна не привела к простою. Суммарно предотвращено потерь на 4+ млн рублей.

Не ждите, пока атака покажет слабые места

Проведём аудит вашей инфраструктуры и составим план защиты до того, как это сделают атакующие

Получите план защиты под ваш сайт

Оставьте контакт и адрес сайта — пришлём план защиты и список приоритетных шагов.

  • Приоритетные шаги на 7 дней
  • Быстрая обратная связь
  • План в удобном формате
Без спама. Можно указать Telegram (@username) или email.
Написать в Telegram