Атака на уровне приложения (Layer 7)

Почему это самая сложная для фильтрации категория DDoS

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

Где здесь пригождается WAF

Web application firewall размещается перед приложением специально для проверки и ограничения такого трафика по паттернам запросов, и это отличается от задачи firewall на уровне сети, который видит только соединения, а не сами запросы внутри них.

Ограничение частоты и фильтрацию для такого трафика разбирает материал: руководство по защите от DDoS-атак для малого бизнеса.

Как найти атакуемую страницу в журналах

Атака на уровне приложения проявляется как закономерность в запросах, поэтому лучший инструмент здесь журнал доступа. В стандартном формате combined nginx адрес клиента стоит в первом поле, а путь запроса в седьмом, так что хватает двух однострочников:

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

Первая команда ранжирует клиентов, вторая пути. Поток обычно выглядит как несколько дорогих адресов, например поиск, вход или некэшируемый отчёт, получающих гораздо больше обращений, чем остальной сайт. Чтобы увидеть, какие страницы не просто популярны, а медленны, добавьте $request_time (время обработки запроса в секундах, стандартная переменная модуля журналирования nginx) в собственный log_format и отсортируйте по нему. Сделайте это до любых изменений, потому что найденная страница определяет решение: закэшировать её, поставить на неё лимит или спрятать за авторизацию. Как превратить такую проверку из разовой в постоянную, показано в руководстве по мониторингу логов.

Ограничения nginx против флуда на уровне L7

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

limit_req_zone $binary_remote_addr zone=search:10m rate=2r/s;
limit_conn_zone $binary_remote_addr zone=perip:10m;

location /search {
    limit_req zone=search burst=10;
    limit_req_status 429;
    limit_req_dry_run on;
    limit_conn perip 20;
}

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

Медленные атаки не шлют много запросов, а удерживают соединения. В основном модуле значения по умолчанию для client_header_timeout и client_body_timeout равны 60 секундам, и меньшее значение быстрее закрывает зависшие соединения ответом 408. Сочетайте эти меры с fail2ban и, для фильтрации по шаблонам, с WAF.

Связанные термины: WAF, Rate limiting, Протокольная атака, limit_req, SQL-инъекция, CORS (cross-origin resource sharing).