Защита от DDoS-атак на уровне L7: когда бот косит под человека

Вы когда-нибудь смотрели в лог веб-сервера и видели тысячи запросов к одной и той же странице, с разных IP, с идеально одинаковыми интервалами? Сервер греется, база данных стонет, а в Яндекс.Метрике - 500 "посетителей", которые ничего не покупают, не листают и не кликают. Это не сбой и не нашествие конкурентов. Это L7 DDoS-атака. Меня, когда я впервые столкнулся с таким, трясло от бессилия: объём трафика не зашкаливал, канал был свободен, но сайт еле дышал. Пришлось учиться защищаться по-новому.

Что такое L7 DDoS-атака простым языком и почему обычный фаервол тут бессилен

Сетевые атаки (L3/L4) можно сравнить с обстрелом из гранатомета: грубо, громко, но если у тебя есть бетонная стена (анти-DDoS-сервис с большой мощностью), ты выстоишь. L7-атака - это как если бы шпион переоделся в твою униформу, выучил все пароли и начал отдавать приказы твоей охране. Она не забивает канал, а выцеливает самую слабую логику веб-приложения.

Технически L7 (прикладной уровень модели OSI) - это уровень, на котором работают ваши HTTP/HTTPS-запросы, API, поиск, формы заказа. Атака на этом уровне не требует терабитов. Достаточно нескольких тысяч хорошо построенных запросов в секунду, чтобы уложить сервер. Коварство в том, что каждый запрос по отдельности выглядит как от обычного посетителя: правильный User-Agent, реальный заголовок Referer, даже куки поддерживаются. Бюджетные системы защиты (вроде limit_req в Nginx) часто бессильны, потому что боты приходят с тысяч разных IP, и число запросов с каждого IP не превышает порогов.

В 2025 году доля L7-атак среди всех DDoS-инцидентов перевалила за 60%. Самые частые цели: страницы входа, формы поиска, корзина, API, XML-RPC в старых версиях WordPress. Особенно болезненны атаки на расчёт доставки или подбор промокодов - каждая такая попытка заставляет сервер выполнять тяжёлые SQL-запросы, а бот делает их тысячами в секунду.

Почему стандартный фаервол не спасает? Потому что он смотрит на порты и протоколы, а здесь порт 80/443 открыт, протокол HTTP/HTTPS - легитимный. Фаервол не может отличить добросовестного клиента от бота, если они оба шлют одинаковые корректные запросы. Нужен фильтр более высокого уровня - и тут на сцену выходят WAF и поведенческий анализ.

Типичные L7-атаки: от Slowloris до HTTP/2 Rapid Reset

Давайте разберем несколько популярных техник, чтобы вы знали, с чем имеете дело. Я специально приведу примеры из логов, чтобы вы смогли их идентифицировать.

HTTP-флуд - самая примитивная, но от того не менее опасная. Бот долбит одну страницу (обычно тяжёлую - каталог со сложными фильтрами) с частотой 100-200 запросов в секунду с каждого IP. Суммарно может быть 10 000 RPS. Сервер тратит CPU на генерацию динамического контента и запросы к БД. Эффект: сайт тормозит, а потом падает. В логах access вы увидите строчки вроде "GET /catalog?filter=price&sort=desc HTTP/1.1" с разными IP, но все запросы идут на один URL. Нормальные пользователи никогда не повторяют один и тот же запрос тысячи раз с одинаковым интервалом.

Slowloris - изящная атака из прошлого, но всё ещё живая. Бот открывает множество соединений к веб-серверу и отправляет заголовки по частям, с задержками, никогда не завершая запрос. Сервер держит сокеты открытыми, пока не закончится пул воркеров. В логах вы почти ничего не видите, зато netstat показывает тысячи соединений в состоянии ESTABLISHED с нулевым трафиком. Slowloris особенно эффективен против Apache, который выделяет отдельный поток на каждое соединение. Nginx справляется лучше, но тоже может захлебнуться.

HTTP/2 Rapid Reset - современный монстр. Использует уязвимость протокола HTTP/2: клиент отправляет запрос и тут же отменяет его фреймом RST_STREAM. Сервер тратит ресурсы на обработку отмены, а поток уже занят. При высокой частоте (миллионы RST в секунду) сервер падает. В 2023 году так атаковали многих крупных провайдеров. Пик атаки достигал 31,4 Тбит/с в терминах RPS, но реальный объём трафика был небольшим. Это идеальный пример L7-атаки нового поколения.

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

Атака на API через дорогие эндпоинты. Например, если у вас есть эндпоинт "/api/user/orders", который делает три джойна и обрабатывает многобайтовые строки, бот может дёргать его с разными параметрами, в том числе с каталогами на 1000 товаров. Сервер тратит ресурсы на генерацию ответа, который никогда не понадобится. Эффективно защищает кэширование ответов (например, через Redis), но не всегда возможно.

WordPress-специфичные атаки. Устаревшие плагины оставляют открытыми эндпоинты вроде "/wp-json/wc/v3/products" без авторизации. Бот может перебирать ID товаров, запрашивая каждый, что вызывает кучу запросов к БД. Ещё популярны атаки через комментарии - бот отправляет POST на "/wp-comments-post.php" со спамом, и каждый раз выполняется проверка на дубликаты.

Как понять, что атакуют именно L7, а не что-то другое

Первые звоночки я описал выше. Но давайте детальнее. Если вы видите в логах access тысячи повторяющихся POST-запросов к /wp-login.php или /api/v1/search при том, что обычная посещаемость низкая - это почти наверняка брутфорс или флуд на поиск. Статус ответа 200 OK означает, что запрос обработан, но нагрузка на CPU при этом аномально высокая.

Сравните процент ошибок: при L7-атаке доля ответов 503 (Service Unavailable) может резко возрасти, потому что сервер не справляется. Но в отличие от L3-атаки, входящий трафик остаётся в нормальных пределах (например, 50 Мбит/с вместо обычных 30). Это ключевое отличие: канал не забит, а сервер "висит".

В системном логе (/var/log/messages или Event Viewer) могут появляться записи о нехватке памяти или о том, что пул PHP-FPM исчерпан. Команда

покажет аномально много соединений в состоянии TIME_WAIT или CLOSE_WAIT. А медленные атаки Slowloris оставляют соединения в ESTABLISHED без передачи данных.

Ещё один тест: попробуйте отдать статический файл, например, image.jpg или styles.css. Если он грузится быстро, а динамическая страница - нет, то атака целенаправленно бьёт по бэкенду (PHP/Node.js/Python). Если же статика тоже тормозит, то, возможно, проблема на уровне сетевого соединения или самого веб-сервера.

Полезно использовать утилиту goaccess для анализа логов в реальном времени. Запустив goaccess на access.log, вы сразу увидите топ URL, топ IP, количество запросов по статусам. Если один URL лидирует с огромным отрывом - это сигнал. Также стоит настроить сбор метрик PPS (packets per second) на интерфейсе и сравнивать с динамикой RPS. Аномалия: низкий PPS, но высокий RPS - явно L7.

Иногда помогает анализ User-Agent. Если вы видите, что 80% запросов приходят с одного и того же подозрительного агента типа "python-requests/2.28.1", можно заблокировать его на время. Но злоумышленники быстро подстраиваются и копируют реальные браузерные строки.

Методы защиты от L7 DDoS: от рейт-лимитинга до поведенческого анализа

Теперь перейдём к самому главному: как строить оборону. Универсального рецепта нет, но комбинация описанных ниже методов даёт отличный результат. Я разбил их на несколько уровней, от самых простых до профессиональных.

Рейт-лимитинг (rate limiting) на уровне веб-сервера. В Nginx это директивы limit_req_zone и limit_req. Например, можно ограничить один IP до 30 запросов в минуту к странице входа. Это отсечет брутфорс и часть простых флудов. Но для атак с тысяч IP этого недостаточно - каждый отдельный IP делает мало запросов. Поэтому рейт-лимитинг нужно комбинировать с другими методами. Важно: настраивать limit_req следует аккуратно, чтобы не заблокировать реальных пользователей за прокси или NAT. Используйте зону с burst и nodelay, чтобы разрешить небольшую очередь.

Капча и JS-челленджи. При подозрении на бота показывайте невидимую капчу или выполняйте JavaScript-тест. Но капча не останавливает продвинутых ботов, которые умеют решать капчу через сервисы распознавания. И она раздражает реальных людей, если срабатывает часто. Рекомендуется показывать капчу только после того, как система накопила достаточно факторов риска (например, несколько запросов с одного IP за короткое время).

WAF (Web Application Firewall) с правилами на сигнатуры атак. Хороший WAF (например, ModSecurity с правилами OWASP Core Rule Set) блокирует запросы, содержащие SQL-инъекции, XSS, подозрительные User-Agent. Но L7-атаки часто не содержат явных сигнатур. Поэтому одного WAF недостаточно. Более современные WAF используют поведенческий анализ и машинное обучение. Такие есть у Cloudflare (WAF Managed Rules), у стендовых решений типа Imperva.

Поведенческий анализ (bot mitigation). Это уже высший пилотаж. Система собирает данные о каждом посетителе: скорость заполнения форм, движения мыши, скроллинг, тайминги между действиями. На основе обучения с учителем (ML) она вычисляет вероятность, что запрос сделан ботом. Такие решения есть у Cloudflare (Bot Management), Variti (Active Bot Protection) и некоторых других провайдеров. Они работают на ура, но стоят дорого. Например, Cloudflare Bot Management добавляет к тарифу Business еще 1-2 тысячи долларов в месяц. Однако для крупных e-commerce проектов это окупается, потому что спасает от парсинга и накрутки.

Кэширование динамических страниц. Если страница генерируется не для каждого пользователя (не персонализирована), её можно кэшировать даже на несколько секунд. Varnish, Nginx cache, Redis – ваши друзья. L7-атака на закэшированную страницу просто получит копию из кэша, не нагружая бэкенд. Но если атака идёт на форму отправки или на API с уникальными параметрами, кэш не спасёт. В таких случаях поможет микро-кэш с инвалидацией по параметрам. Например, в Nginx можно настроить кэш с ключом $request_uri, и каждый GET-запрос с разными параметрами будет кэшироваться отдельно.

Ограничение сложности запросов. Например, поиск по каталогу - частое узкое место. Если добавить капчу на поиск или ограничить глубину фильтров, боты не смогут генерировать тяжелые запросы. Или, скажем, отключать поиск для неавторизованных пользователей. В API можно добавить ограничение на частоту вызова эндпоинтов в зависимости от роли пользователя. Для дорогих эндпоинтов (например, генерация отчёта) полезно использовать асинхронную очередь: клиент отправляет задачу и получает уведомление позже, а не ждёт ответа синхронно.

Проактивная фильтрация на уровне CDN. Многие CDN-провайдеры (Cloudflare, Akamai, Fastly) имеют встроенные механизмы защиты от L7 атак. Они анализируют трафик на своих границах и могут блокировать подозрительные паттерны, не доводя до вашего сервера. Плюс CDN кэширует статику, снижая нагрузку. Рекомендуется использовать CDN даже для небольших проектов - это и скорость, и безопасность.

Облачные анти-DDoS-сервисы как спасение от L7

Встроенными средствами сервера сложно защититься от распределённых L7-атак. Поэтому лучший вариант - использовать облачного провайдера с собственной сетью фильтрации. Cloudflare (даже бесплатный тариф, но при этом помните, что этот сервис не подходит для российского трафика) имеет базовый WAF и правила рейт-лимитинга. StormWall, DDoS-Guard, Variti предлагают более глубокую кастомизацию и поведенческий анализ.

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

Минус: если трафик шифрованный (HTTPS), некоторые провайдеры требуют передачи SSL-сертификатов, что может быть небезопасно. Однако есть решения, фильтрующие по метаданным TLS (JA3/JA4), не раскрывая ключи. Уточняйте этот момент при выборе. Также облачные сервисы добавляют небольшую задержку (около 10-30 мс), что для большинства проектов незаметно.

В 2025 году я сам перевёл крупный интернет-магазин на облачный WAF + антибот. Результат: нагрузка на сервер упала на 70%, даже незначительные L7-атаки перестали быть заметны. Стоимость услуги оказалась ниже, чем увольнение двух программистов, которые пытались чинить баги своими силами.

При выборе облачного провайдера обратите внимание на следующие параметры:

• Поддержка анализа HTTPS без раскрытия ключей (фильтрация по JA3/JA4).
• Наличие поведенческого модуля (bot score).
• Возможность создавать кастомные правила WAF (например, блокировать эндпоинт /api/old/version).
• Скорость применения новых правил (в реальном времени или с задержкой).
• Бесплатный пробный период.

Как настроить L7-защиту на своём сервере (подробные примеры)

Если вы хотите попробовать защититься самостоятельно, вот несколько конкретных примеров для Nginx. Я даю их как базу, но под вашу архитектуру они могут потребовать адаптации.

Рейт-лимитинг для формы комментариев:

Это разрешит не более 5 комментариев в минуту с одного IP, с пакетом burst в 3 запроса.

Блокировка по User-Agent подозрительных ботов:

Но учтите, что многие боты подменяют User-Agent на легитимный.

Ограничение количества одновременных соединений (защита от Slowloris):

Это запретит одному IP держать более 10 соединений одновременно.

Базовая защита от HTTP-флуда через ограничение частоты запросов на уровень location:

Это ограничит 30 запросов в секунду с одного IP к каталогу. Burst 50 позволяет кратковременные всплески.

Блокировка стран через geoip (если атака идёт из регионов, где у вас нет клиентов):

Осторожно: такая блокировка может быть излишней, если у вас есть клиенты из этих стран.

Защита от Slowloris через настройки keepalive и client_header_timeout:

Уменьшите таймауты, чтобы сервер быстрее закрывал "висящие" соединения.

Эти настройки - только первый шаг. Для серьёзной защиты всё равно придётся подключать облачный сервис или ставить специализированное ПО типа ModSecurity с динамическими правилами. И не забывайте, что после изменения конфигурации нужно тестировать: нет ли ложных срабатываний, не заблокировали ли вы поисковых роботов (Googlebot, Яндекс.Паук).

Распространённые ошибки при защите от L7 DDoS

За годы я насмотрелся на множество граблей. Перечислю главные, чтобы вы не наступали на те же грабли.

Ошибка 1: полагаться только на блокировку по IP. При L7-атаке IP меняются каждые секунды (через прокси или ботнет). К тому времени, как вы добавите 1000 IP в чёрный список, атака уже закончится или сменит IP. Блокировка по IP имеет смысл только для краткосрочного облегчения, но не как основная стратегия.

Ошибка 2: слишком агрессивный рейт-лимитинг. Если вы настроите 1 запрос в минуту, реальные пользователи с одного IP (например, в офисе за NAT) будут страдать. Всегда делайте запас и мониторьте ложные срабатывания. Хорошей практикой является начинать с лимита 30 запросов в минуту и смотреть по статистике ошибок.

Ошибка 3: игнорировать кэширование. Многие L7-атаки нацелены на страницы, которые можно было бы закэшировать на 1-5 секунд. Включите микро-кэш, и нагрузка упадёт в разы. Пример: страница каталога интернет-магазина почти не меняется в течение секунд. Кэш на 2 секунды не даст боту повторить запрос моментально.

Ошибка 4: не мониторить логи регулярно. Без анализа вы не узнаете о новой атаке, пока не ляжет сайт. Настройте отправку логов в Elasticsearch или используйте сервисы типа Graylog. Следите за аномальными всплесками определённых URL. Автоматизируйте: например, если за минуту на один URL пришло более 1000 запросов с разных IP, отправьте себе уведомление.

Ошибка 5: использовать WAF без обновления правил. Базы сигнатур устаревают. Если вы не обновляете ModSecurity, то через месяц он пропустит новые векторы атак. Настройте cron для автоматической загрузки последних правил OWASP CRS. Для облачных WAF обычно обновления происходят автоматически.

Ошибка 6: забывать о защите API. Часто разработчики защищают веб-формы, но оставляют открытыми API-эндпоинты, которые могут вызываться без авторизации. Все API, особенно те, что используют дорогие операции (запись в БД, генерация отчетов), должны быть защищены токенами и рейт-лимитами.

Ошибка 7: не проводить нагрузочное тестирование. Вы узнаете о слабом месте своего приложения только во время реальной атаки, когда уже поздно. Периодически проводите стресс-тесты (например, с помощью Apache Bench или JMeter), чтобы понять, сколько запросов в секунду выдерживает ваш бэкенд без защиты. Так вы сможете настроить пороги срабатывания защиты.

Избежать этих ошибок поможет регулярный аудит безопасности и взаимодействие с профессиональными анти-DDoS-провайдерами. Не стесняйтесь просить их о помощи в настройке правил под ваш трафик.

Заключение: L7-защита требует нового мышления

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

Чтобы защититься от L7 DDoS, нужно комбинировать технические меры: рейт-лимитинг, WAF, поведенческий анализ, кэширование и, самое главное, подключать облачные сервисы с распределённой сетью фильтрации. Не забывайте про мониторинг и регулярно анализируйте логи. А главное – не стесняйтесь привлекать экспертов, если чувствуете, что собственных сил не хватает. Одна атака может стоить вам месячных продаж, а профессиональная защита часто обходится дешевле.

Вот краткий чек-лист, с которого можно начать уже сегодня:

• Включите рейт-лимитинг для всех критических эндпоинтов (логин, поиск, комментарии).
• Настройте кэширование динамических страниц хотя бы на 1-5 секунд.
• Установите и настройте ModSecurity с OWASP CRS.
• Подключите бесплатный тариф Cloudflare для базовой фильтрации.
• Настройте мониторинг аномалий через ELK или Graylog.
• Проведите нагрузочное тестирование вашего приложения.

Удачи. И пусть ваш сервер всегда отвечает 200 OK.