Google сообщил, что 1 июня клиент Google Cloud Armor подвергся самой крупной из зарегистрированных DDoS-атак седьмого уровня. Пик достиг 46 миллионов HTTPS-запросов в секунду — это как если бы все ежедневные запросы к Википедии пришли за десять секунд. Атака была как минимум на 76% больше предыдущего рекорда.

Разберём, как это произошло, чем L7-атаки отличаются от объёмных и как защищать сервисы.

Что такое DDoS седьмого уровня

Модель OSI делит сеть на уровни. Четвёртый — транспортный (TCP/UDP), седьмой — прикладной (HTTP/HTTPS). Объёмные атаки забивают канал мусорным трафиком; L7-атаки выглядят как обычные запросы и нагружают серверы приложений.

Их сложнее отфильтровать: запрос может быть синтаксически корректным, с валидным TLS-соединением. Защита требует анализа поведения, а не только размера пакета.

# посмотреть нагрузку на веб-сервер
sudo tail -f /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head
# текущие соединения
ss -s
ss -tan state established | wc -l

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

В 9:45 по тихоокеанскому времени атака началась с 10 000 запросов в секунду, нацеленных на HTTP(S)-балансировщик клиента. В течение восьми минут она выросла до 100 000 запросов в секунду. Затем достигла полного размаха — 46 миллионов.

Cloud Armor Adaptive Protection обнаружил аномалию на ранней стадии, проанализировал трафик по нескольким признакам и сгенерировал предупреждение с рекомендациями. Клиент развернул правила, и атака была заблокирована. Сайт остался в сети.

# пример анализа всплеска в логах nginx
awk '{print $4}' /var/log/nginx/access.log | cut -d: -f1-2 | sort | uniq -c | tail -20
# топ User-Agent
awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

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

46 миллионов запросов в секунду — не просто рекорд. Это показывает, насколько доступными стали ботнеты и как легко направить огромный трафик на одного клиента. Для небольшой компании такая атака может быть фатальной.

Кроме того, L7-атаки сложнее заметить: они не всегда видны в сетевых метриках, потому что соединения устанавливаются нормально. Нагрузка проявляется на CPU, памяти и времени ответа приложения.

# мониторинг времени ответа
curl -s -o /dev/null -w "%{time_total}\n" https://example.com
# проверка лимитов и очередей
nginx -T 2>/dev/null | grep -E "limit_req|limit_conn|worker_connections"

Как защищаться

  1. Используйте CDN или облачный WAF с защитой от DDoS.
  2. Настройте ограничение частоты запросов на уровне приложения.
  3. Кэшируйте статические ресурсы.
  4. Разделяйте критичные сервисы по инфраструктуре.
  5. Имейте план масштабирования и аварийный статический сайт.
  6. Мониторьте аномалии и автоматизируйте реакцию.
# пример ограничения в nginx
# в http {}
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
# в location /
limit_req zone=api burst=20 nodelay;
# ограничение соединений
limit_conn_zone $binary_remote_addr zone=addr:10m;
limit_conn addr 20;

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

Роль провайдера и облака

Домашний или небольшой сервер не выдержит атаку в миллионы запросов. Защита должна быть выше по стеку: у провайдера, CDN или облачного сервиса. Ваша задача — правильно настроить правила и не открывать лишние порты.

Если вы используете Cloudflare, AWS Shield, Google Cloud Armor или аналоги, проверьте, что защита включена для всех доменов и что правила не отключены «на время отладки».

# проверить, что трафик идёт через CDN
dig +short example.com
curl -sI https://example.com | grep -iE "server|cf-ray|x-cache"

Что делать во время атаки

Включите защиту, ограничьте подозрительные источники, переключитесь на статическую версию сайта, если возможно. Не пытайтесь «переждать»: атака может длиться часами.

# быстрый способ ограничить всех, кроме известных адресов (пример iptables)
sudo iptables -A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW -m limit --limit 20/s -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j DROP

Осторожно с блокировками по IP: ботнет использует тысячи адресов, а легитимные пользователи могут попасть под раздачу. Лучше фильтровать по поведению и использовать готовые сервисы защиты.

Уроки для архитектуры

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

И следите за зависимостями: если ваш DNS-провайдер или CDN падает, сайт недоступен, даже если сервер работает. Резервирование важно на всех уровнях.

# проверить DNS и время ответа
dig example.com +stats | grep -E "Query time|SERVER"
curl -s -o /dev/null -w "dns:%{time_namelookup} connect:%{time_connect} total:%{time_total}\n" https://example.com

Как отличить атаку от вирусного трафика

Всплеск может быть результатом публикации в СМИ, а не DDoS. Смотрите на распределение источников, набор URL, поведение клиентов и наличие валидных сессий. Атака часто бьёт в дорогие endpoints — поиск, авторизацию, API — и не запрашивает статику.

awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

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

Итог

Атака на клиента Google Cloud Armor показала новый масштаб L7-DDoS: 46 миллионов запросов в секунду. Защита требует CDN/WAF, ограничения частоты, кэширования и плана деградации. Не рассчитывайте только на свой сервер: на таком объёме он не справится. Настройте правила заранее и проверяйте, что защита действительно включена.

Насколько публикация полезна?

Нажмите на звезду, чтобы оценить!

Средняя оценка 0 / 5. Количество оценок: 0

Оценок пока нет. Поставьте оценку первым.

Поделиться: Telegram ВКонтакте