Только разрешённые HTTP‑методы проходят: блокировка шумных запросов Nginx 405/444 [ r1 ]

Только разрешённые HTTP‑методы проходят: блокируем шумные запросы Nginx 405/444

Во время работы с веб‑приложением, наблюдая за логами, иногда встречаются такие моменты.

\n
• Я думал, что использую только GET / POST / PUT / DELETE
\n
• В логах появляется неизвестный метод
\n

Например, в логах может появиться PROPFIND – метод WebDAV. Приложение, конечно, отреагирует как «неподдерживаемый метод», но важно то, что происходит.

Нужно ли заставлять серьёзное приложение обрабатывать лишний шум?\nОтвет обычно «нет». Поэтому удобно позволять только нужные методы, а остальные блокировать на уровне Nginx.

Почему стоит блокировать на Nginx

Блокировать можно и на уровне приложения, но к тому моменту запрос уже пришёл, и уже возникли расходы.

\n
• Вход в WSGI/ASGI
\n
• Запуск некоторых middleware/логирования/аутентификации
\n
• Загрязнение логов приложения «настоящими» проблемами
\n
• При росте трафика накапливается лишняя нагрузка
\n

Если блокировать на Nginx:

\n
• Сразу завершаем на первом уровне → минимальные расходы
\n
• Логи приложения остаются чистыми → упрощается эксплуатация
\n
• Уменьшается поверхность атаки → лишние методы просто не видны
\n

В одном предложении:

\n

Приложение создаёт продукт, а Nginx играет роль стража.

\n

Необычные методы в логах обычно не «нормальный» трафик

Методы вроде PROPFIND – типичный пример.

\n
• Сканирование, чтобы проверить, включён ли WebDAV
\n
• Если по ошибке открыты PUT/MKCOL, пытаются перейти к следующему шагу
\n
• Иногда видны паттерны с пустым User‑Agent или «плохим» HTTP/1.0
\n

Главный вывод:

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

Стратегия проста: работа по списку разрешённых

Принцип – «открыть только то, что нужно, и закрыть всё остальное».

\n
• Статические страницы/ресурсы: обычно достаточно GET, HEAD
\n
• API: ограничиваем POST/PUT/PATCH/DELETE только нужными эндпоинтами
\n

И все остальные методы (например, PROPFIND, MKCOL, LOCK и т.д.)\nесли мы их не используем, блокируем полностью – это самый удобный способ управления.

405 против 444: какой ответ использовать

Есть два основных способа блокировки.

1) 405 Method Not Allowed

\n
• Стандартный и понятный
\n
• Сообщает клиенту, что метод недоступен
\n

2) 444 (Nginx‑специфичный: закрыть соединение без ответа)

\n
• Полностью разрывает соединение
\n
• Не даёт подсказок сканерам/ботам
\n
• В эксплуатации тихий и чистый подход («убираем шум»)
\n

На практике часто применяют так:

\n
• Для «неполезных» методов в открытом вебе – 444
\n
• Для клиентских ошибок, где пользователь может ошибиться – 405
\n

Пример конфигурации Nginx: «разрешить только нужные методы» – два шаблона

Ниже приведены готовые примеры, которые можно сразу копировать.

Шаблон A) Базовый: только GET/HEAD, API – дополнительные методы

server {\n    # ... listen/server_name и т.д. ...\n\n    # 1) Базовый: веб/статические – только GET/HEAD\n    location / {\n        if ($request_method !~ ^(GET|HEAD)$) { return 444; }  # или 405\n        proxy_pass http://app;\n    }\n\n    # 2) API: разрешаем нужные методы\n    location /api/ {\n        if ($request_method !~ ^(GET|HEAD|POST|PUT|PATCH|DELETE|OPTIONS)$) { return 444; }\n        proxy_pass http://app;\n    }\n}\n

\n
• / обычно обслуживает только страницы, поэтому GET/HEAD достаточно.
\n
• /api/ может потребовать OPTIONS из‑за CORS.
\n

Шаблон B) «Блокируем только подозрительные методы» (легкое начало)

location / {\n    if ($request_method ~ ^(PROPFIND|PROPPATCH|MKCOL|COPY|MOVE|LOCK|UNLOCK)$) { return 444; }\n    proxy_pass http://app;\n}\n

\n
• Убирает шумные методы, которые обычно видны в логах.
\n
• В долгосрочной перспективе лучше использовать Allowlist (шаблон A).
\n

\n

Примечание: хотя в Nginx часто предупреждают о злоупотреблении if, простые условия с return широко применяются в практике. Если нужна более строгая реализация, можно использовать limit_except.

\n

Вывод: «Разрешить только нужные» упрощает эксплуатацию

Ключевые моменты:

\n
• Необычные методы почти всегда не «нормальный» трафик
\n
• Отправка в приложение создаёт лишние расходы и загрязняет логи
\n
• Блокируем всё, кроме разрешённых методов, на уровне Nginx (405/444)
\n

Применив один из этих шаблонов, вы получите:

\n
• Меньше нагрузки на приложение
\n
• Чистые логи
\n
• Упрощённую эксплуатацию
\n