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

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

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

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

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

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

Commandbox 광고

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

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

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

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

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

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

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

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

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

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

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

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

Commandbox 광고

nginx как охранник, управляющий входом

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

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

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

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

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

1) 405 Method Not Allowed

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

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

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

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

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

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

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

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

server {
    # ... listen/server_name и т.д. ...

    # 1) Базовый: веб/статические – только GET/HEAD
    location / {
        if ($request_method !~ ^(GET|HEAD)$) { return 444; }  # или 405
        proxy_pass http://app;
    }

    # 2) API: разрешаем нужные методы
    location /api/ {
        if ($request_method !~ ^(GET|HEAD|POST|PUT|PATCH|DELETE|OPTIONS)$) { return 444; }
        proxy_pass http://app;
    }
}
  • / обычно обслуживает только страницы, поэтому GET/HEAD достаточно.
  • /api/ может потребовать OPTIONS из‑за CORS.

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

location / {
    if ($request_method ~ ^(PROPFIND|PROPPATCH|MKCOL|COPY|MOVE|LOCK|UNLOCK)$) { return 444; }
    proxy_pass http://app;
}
  • Убирает шумные методы, которые обычно видны в логах.
  • В долгосрочной перспективе лучше использовать Allowlist (шаблон A).

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

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

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

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

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

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