Администратор смотрит на дашборд — процессор в норме, канал не забит, ошибок почти нет. А сайт при этом тормозит: корзины бросают на середине оформления, а форма входа иногда просто не отвечает. Это типичная картина атаки седьмого уровня, той самой, которую сложно поймать именно потому, что она не выглядит как атака.
Чем L7 отличается от “обычного” DDoS
Атаки на сетевом уровне (L3-L4) — это про объём: миллионы пакетов в секунду, которые нужно отфильтровать по количеству и происхождению. С L7 сложнее. Запрос выглядит как настоящий HTTP или HTTPS-запрос от браузера: те же заголовки, тот же TLS-handshake, а иногда и валидная сессия. Отличить его от запроса живого пользователя по одному признаку почти невозможно, особенно если трафик идёт по HTTPS.
Ещё одна особенность: такой атаке не нужен огромный объём трафика. Обработка HTTP и HTTPS сама по себе требует ресурсов сервера: расшифровка, генерация страницы, обращение к базе. Поэтому достаточно относительно небольшого, но правильно нацеленного потока запросов, чтобы сервер начал захлёбываться.
Как это делают на практике
Один вариант — грубая сила: сервер закидывают бессмысленными запросами к страницам сайта, карточке товара, поиску, генерации отчёта или PDF-счёта. Такие страницы требуют реальных вычислений на бэкенде, а не просто отдаются из кэша, поэтому даже относительно скромный поток запросов способен вывести сервер из строя, если атакующий точно знает, куда бить.
Другой вариант — действовать медленно и тихо. Атакующий открывает HTTP-соединение и растягивает его во времени: отправляет данные по крошечным порциям, с паузами, никогда не завершая запрос до конца. Формально это выглядит как обычный, просто очень медленный пользователь. На деле сервер вынужден держать такие соединения открытыми, и пул доступных подключений постепенно заканчивается — новые, легитимные посетители просто не могут достучаться до сайта.
Третий сценарий — когда за атакой стоит не только техническая, но и идеологическая мотивация. В таких случаях несколько техник обычно комбинируют сразу, а сама атака нередко сопровождается попытками взлома или кражи данных — DDoS здесь используется как способ привлечь внимание к цели, а не как самоцель. Время для удара в таких историях часто выбирают не случайно, а в периоды максимальной публичности, например, в разгар праздничных распродаж.
Что это значит для бизнеса
Первое время метрики инфраструктуры могут выглядеть спокойно, нагрузка растёт постепенно, без резкого скачка, который включил бы тревогу. А бизнес в это время теряет деньги вполне конкретно: растёт время отклика страницы оформления заказа, падает конверсия, форма поиска отвечает с задержкой в несколько секунд, следовательно, часть пользователей уходит к конкуренту.
Есть и отложенные последствия. Если сайт был недоступен или медленно работал во время обхода поисковым роботом, это может сказаться на позициях в выдаче. А клиент, который во время распродажи наткнулся на зависшую форму оплаты, не всегда возвращается — даже если через полчаса всё снова заработало штатно. Добавьте сюда расходы на устранение последствий и, если инцидент публичный, удар по репутации — и картина становится куда серьёзнее, чем «сайт немного тормозил».
Почему обычная защита здесь не справляется
Файрвол на уровне хостинга или локальное анти-DDoS оборудование обычно пропускают такой трафик — для них это легитимные HTTP-запросы, просто с необычным паттерном. Чтобы отличить вредоносный запрос от настоящего, нужно смотреть на поведение: как часто один и тот же клиент обращается к одной странице, совпадает ли его маршрут по сайту с реальным пользовательским сценарием, откуда физически приходит трафик и совпадает ли это с тем, что заявлено в заголовках. У локальной инфраструктуры для такого анализа обычно не хватает ни мощности, ни постоянно обновляемой экспертизы.
Телеком-операторы, как правило, неплохо справляются с атаками на сетевом уровне, но с L7 — заметно хуже, а полная зависимость от одного провайдера ещё и создаёт единую точку отказа.
Как это устроено в CURATOR
CURATOR.ANTIDDOS перехватывает трафик ещё до того, как он доходит до сервера клиента, — через сеть фильтрации, размещённую в узлах подключения к Tier-1 и крупным региональным провайдерам. Если один из центров фильтрации выходит из строя, трафик автоматически перенаправляется на другие — без ручного вмешательства.
Внутри сети трафик анализируется на всех уровнях модели OSI одновременно, включая L7, где решение принимается не по объёму запросов, а по совокупности поведенческих признаков. Важный момент, фильтрация HTTPS-трафика при этом не требует передавать приватные SSL-ключи, то есть конфиденциальность соединения не нарушается ради его проверки. Всё это работает без CAPTCHA. Блокировка происходит на уровне анализа трафика, а не за счёт дополнительной проверки, которую видит и обычный пользователь. Подключение — через DNS или BGP, в зависимости от того, нужна ли точечная защита конкретного домена или всей инфраструктуры целиком.