Astra/nginx-analize
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
fcc9139361700a8b87aae5dff7462130e91e4346
nginx-analize/docs/функции безопасности — проверка.md
Redsandyg fcc9139361 init
2026-06-15 06:31:35 +03:00

70 KiB
Raw Blame History

Функции безопасности nginx — результаты проверки

Дата проверки: 10.06.2026
Объект проверки: upstream nginx (официальная документация nginx.org)
Метод: анализ официальной документации и составление примеров конфигурации (без практических тестов на работающем экземпляре)

Сводная таблица

№ Функция безопасности Статус Модуль / механизм
1.1 Ограничение доступа по IP-адресу Подтверждено ngx_http_access_module; allow; deny
1.2 Аутентификация по имени пользователя и паролю Подтверждено ngx_http_auth_basic_module; auth_basic; auth_basic_user_file
1.3 Аутентификация по клиентскому TLS-сертификату Подтверждено с оговорками ngx_http_ssl_module; ssl_verify_client
1.4 Авторизация через внешний сервис Подтверждено с оговорками ngx_http_auth_request_module; auth_request
1.5 Комбинирование нескольких проверок доступа Подтверждено satisfy; access; auth_basic; auth_request
2.1 Разделение правил по виртуальным серверам и путям Подтверждено ngx_http_core_module; server; location
2.2 Ограничение HTTP-методов Подтверждено ngx_http_core_module; limit_except
2.3 Запрет доступа к служебным и скрытым файлам Подтверждено location; deny all
2.4 Запрет прямого доступа к внутренним ресурсам Подтверждено ngx_http_core_module; internal
3.1 Поддержка HTTPS/TLS Подтверждено с оговорками ngx_http_ssl_module; ssl_certificate
3.2 Ограничение версий TLS и шифров Подтверждено ngx_http_ssl_module; ssl_protocols; ssl_ciphers
3.3 Проверка клиентского сертификата Подтверждено ssl_client_certificate; ssl_verify_client
3.4 Принудительное использование HTTPS Подтверждено return 301/308; Strict-Transport-Security
4.1 Журналирование HTTP-запросов Подтверждено ngx_http_log_module; access_log
4.2 Журналирование ошибок Подтверждено error_log
4.3 Настройка формата журналов Подтверждено log_format
4.4 Передача журналов в syslog Подтверждено access_log syslog; error_log syslog
5.1 Ограничение частоты запросов Подтверждено ngx_http_limit_req_module; limit_req
5.2 Ограничение количества соединений Подтверждено ngx_http_limit_conn_module; limit_conn
5.3 Ограничение размера клиентского запроса Подтверждено ngx_http_core_module; client_max_body_size
5.4 Ограничение скорости отдачи данных Подтверждено ngx_http_core_module; limit_rate
5.5 Настройка таймаутов соединений Подтверждено client_*_timeout; send_timeout; keepalive_timeout
6.1 Сокрытие версии nginx Подтверждено server_tokens off
6.2 Управление страницами ошибок Подтверждено error_page
6.3 Управление листингом директорий Подтверждено ngx_http_autoindex_module; autoindex
7.1 Обратное проксирование HTTP/HTTPS Подтверждено ngx_http_proxy_module; proxy_pass
7.2 Балансировка и группы upstream Подтверждено ngx_http_upstream_module; upstream
7.3 Управление заголовками при проксировании Подтверждено proxy_set_header
8.1 Задание корневой директории сайта Подтверждено ngx_http_core_module; root
8.2 Задание альтернативного пути для location Подтверждено ngx_http_core_module; alias
8.3 Проверка существования файлов и маршрутизация Подтверждено ngx_http_core_module; try_files
8.4 Ограничение доступа к произвольным каталогам ОС Подтверждено root; alias; location; права ФС
9.1 Исключение неиспользуемых модулей Подтверждено configure; load_module
9.2 Отключение неиспользуемых возможностей конфигурацией Подтверждено конфигурация nginx
9.3 Контроль целостности конфигурации и разрешённых директорий Не применимо к nginx напрямую (внешняя мера) afick или иной FIM

  • 1. Идентификация и аутентификация

    • 1.1 Ограничение доступа по IP-адресу
      • Описание реализации: nginx позволяет ограничивать доступ к ресурсам по IP-адресам клиентов. Для этого используются правила разрешения и запрета доступа.
      • Модуль / механизм: ngx_http_access_module; директивы allow, deny
      • Комментарий: Подтверждено официальной документацией nginx: модуль предназначен для ограничения доступа по адресам клиентов.
      • Проверка:
        • Статус: Подтверждено
        • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. Модуль ngx_http_access_module входит в стандартную сборку nginx.
        • Источник: https://nginx.org/en/docs/http/ngx_http_access_module.html
        • Результат: Модуль ngx_http_access_module входит в стандартную сборку nginx. Директивы allow и deny задают правила доступа по IP-адресу, сети CIDR, all или unix:. Правила обрабатываются последовательно; первое совпавшее правило определяет результат.
        • Пример конфигурации: 
          location /admin/ {
    allow 192.168.1.0/24;
    allow 10.0.0.1;
    deny all;
}
    • 1.2 Аутентификация по имени пользователя и паролю
      • Описание реализации: nginx поддерживает HTTP Basic Authentication: пользователь вводит имя и пароль, nginx проверяет их по файлу пользователей.
      • Модуль / механизм: ngx_http_auth_basic_module; директивы auth_basic, auth_basic_user_file
      • Комментарий: Подтверждено официальной документацией nginx: модуль валидирует имя пользователя и пароль по протоколу HTTP Basic Authentication.
      • Проверка:
        • Статус: Подтверждено
        • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. Модуль ngx_http_auth_basic_module реализует HTTP Basic Authentication.
        • Источник: https://nginx.org/en/docs/http/ngx_http_auth_basic_module.html
        • Результат: Модуль ngx_http_auth_basic_module реализует HTTP Basic Authentication. Директива auth_basic включает аутентификацию и задаёт текстовое сообщение для диалога; auth_basic_user_file указывает файл с парами «пользователь:хеш_пароля» (формат htpasswd).
        • Пример конфигурации: 
          location /secure/ {
    auth_basic           "Restricted Area";
    auth_basic_user_file /etc/nginx/htpasswd;
}
        • Примечание: Файл паролей создаётся утилитой htpasswd (пакет apache2-utils или httpd-tools).
    • 1.3 Аутентификация по клиентскому TLS-сертификату
      • Описание реализации: nginx может запрашивать и проверять клиентский сертификат при HTTPS-соединении.
      • Модуль / механизм: ngx_http_ssl_module; директивы ssl_client_certificate, ssl_verify_client, ssl_verify_depth
      • Комментарий: Реализуется через SSL/TLS-модуль nginx. Сам SSL-модуль требует включения при сборке и использует OpenSSL.
      • Проверка:
        • Статус: Подтверждено с оговорками
        • Ревью функции: Описание и механизм в целом адекватны; учтены оговорки сборки, конфигурации или эксплуатации. Модуль ngx_http_ssl_module поддерживает проверку клиентских сертификатов.
        • Источник: https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_verify_client
        • Результат: Модуль ngx_http_ssl_module поддерживает проверку клиентских сертификатов. Директива ssl_verify_client on требует обязательного предъявления и проверки сертификата; ssl_client_certificate задаёт файл доверенного CA; ssl_verify_depth ограничивает глубину цепочки. Модуль требует сборки с --with-http_ssl_module и библиотекой OpenSSL.
        • Пример конфигурации: 
          server {
    listen 443 ssl;
    ssl_certificate     /etc/nginx/ssl/server.crt;
    ssl_certificate_key /etc/nginx/ssl/server.key;
    ssl_client_certificate /etc/nginx/ssl/ca.crt;
    ssl_verify_client on;
    ssl_verify_depth 2;
}
        • Примечание: Акцент на идентификации клиента; для контекста защиты канала см. также п. 3.3.
    • 1.4 Авторизация через внешний сервис
      • Описание реализации: nginx может выполнять подзапрос во внешний сервис авторизации и разрешать или запрещать доступ по результату ответа.
      • Модуль / механизм: ngx_http_auth_request_module; директивы auth_request, auth_request_set
      • Комментарий: Модуль официально поддерживается, но в upstream nginx не собирается по умолчанию и должен включаться параметром сборки --with-http_auth_request_module.
      • Проверка:
        • Статус: Подтверждено с оговорками
        • Ревью функции: Описание и механизм в целом адекватны; учтены оговорки сборки, конфигурации или эксплуатации. Модуль ngx_http_auth_request_module выполняет подзапрос к указанному URI;
        • Источник: https://nginx.org/en/docs/http/ngx_http_auth_request_module.html
        • Результат: Модуль ngx_http_auth_request_module выполняет подзапрос к указанному URI; доступ разрешается при ответе 2xx, запрещается при 401/403. Директива auth_request_set позволяет передать значения из заголовков ответа авторизационного сервиса в переменные nginx. В официальной сборке модуль включается флагом --with-http_auth_request_module; в большинстве дистрибутивных пакетов он уже присутствует.
        • Пример конфигурации: 
          location = /auth {
    internal;
    proxy_pass              http://auth-service:8080/validate;
    proxy_pass_request_body off;
    proxy_set_header        Content-Length "";
    proxy_set_header        X-Original-URI $request_uri;
}

location / {
    auth_request /auth;
    proxy_pass http://backend;
}
        • Примечание: См. Требования безопасности для включения в ТУ — проверка.md п. 4; Минимизация поверхности атаки nginx — проверка.md п. 4.
    • 1.5 Комбинирование нескольких проверок доступа
      • Описание реализации: nginx позволяет комбинировать несколько механизмов проверки доступа, например ограничение по IP и Basic Authentication.
      • Модуль / механизм: satisfy; совместно с access, auth_basic, auth_request
      • Комментарий: В документации nginx указано, что одновременное ограничение доступа по адресу, паролю и подзапросу управляется директивой satisfy.
      • Проверка:
        • Статус: Подтверждено
        • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. Директива satisfy управляет логикой комбинирования проверок allow/deny, auth_basic и auth_request.
        • Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html#satisfy
        • Результат: Директива satisfy управляет логикой комбинирования проверок allow/deny, auth_basic и auth_request. Значение all (по умолчанию) требует прохождения всех проверок; значение any — достаточно одной успешной.
        • Пример конфигурации: 
          location /admin/ {
    satisfy all;
    allow 192.168.1.0/24;
    deny all;
    auth_basic           "Admin Area";
    auth_basic_user_file /etc/nginx/htpasswd;
}
        • Примечание: См. Требования безопасности для включения в ТУ — проверка.md п. 4; Минимизация поверхности атаки nginx — проверка.md п. 4.

  • 2. Разграничение доступа к ресурсам

    • 2.1 Разделение правил по виртуальным серверам и путям
      • Описание реализации: nginx позволяет задавать разные правила обработки и доступа для разных виртуальных серверов и URL-путей.
      • Модуль / механизм: ngx_http_core_module; блоки server, location
      • Комментарий: Это базовый механизм конфигурации nginx. Используется для разделения публичных, служебных и закрытых разделов сайта.
      • Проверка:
        • Статус: Подтверждено
        • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. Блоки server определяют виртуальные хосты (по listen, server_name), блоки location — правила для URI-префиксов, регулярных выражений и точных совпадений.
        • Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html#server , https://nginx.org/en/docs/http/ngx_http_core_module.html#location
        • Результат: Блоки server определяют виртуальные хосты (по listen, server_name), блоки location — правила для URI-префиксов, регулярных выражений и точных совпадений. Это базовый механизм разграничения доступа и обработки запросов.
        • Пример конфигурации: 
          server {
    listen 80;
    server_name public.example.com;
    location / {
        root /var/www/public;
    }
}

server {
    listen 80;
    server_name admin.example.com;
    location / {
        allow 10.0.0.0/8;
        deny all;
        root /var/www/admin;
    }
}
    • 2.2 Ограничение HTTP-методов
      • Описание реализации: nginx позволяет задавать отдельные правила доступа для методов, отличных от явно разрешённых.
      • Модуль / механизм: ngx_http_core_module; директива limit_except
      • Комментарий: Используется для ограничения методов вроде PUT, DELETE, если они не требуются приложению.
      • Проверка:
        • Статус: Подтверждено
        • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. Директива limit_except задаёт методы, для которых применяются вложенные директивы доступа.
        • Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html#limit_except
        • Результат: Директива limit_except задаёт методы, для которых применяются вложенные директивы доступа. Методы, не перечисленные в limit_except, обрабатываются без дополнительных ограничений внутри данного блока.
        • Минимальный аудит конфигурации:

nginx -T 2>/dev/null | grep -E 'limit_except|request_method' - **Пример конфигурации:**nginx location /uploads/ { limit_except GET HEAD { deny all; } } ```

  • 2.3 Запрет доступа к служебным и скрытым файлам

    • Описание реализации: nginx позволяет запрещать доступ к отдельным путям и шаблонам URI через правила location и deny all.
    • Модуль / механизм: location, регулярные выражения, deny all
    • Комментарий: Это не отдельный модуль безопасности, а конфигурационный механизм безопасной настройки.
    • Проверка:
      • Статус: Подтверждено
      • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. Комбинация location с регулярными выражениями и deny all позволяет блокировать доступ к скрытым файлам (`.
      • Источник: https://nginx.org/en/docs/http/ngx_http_access_module.html , https://nginx.org/en/docs/http/ngx_http_core_module.html#location
      • Результат: Комбинация location с регулярными выражениями и deny all позволяет блокировать доступ к скрытым файлам (.git, .env, .htaccess и т.п.). Это стандартный конфигурационный паттерн безопасности.
      • Пример конфигурации: 
        location ~ /\. {
    deny all;
    access_log off;
    log_not_found off;
}

location ~* \.(bak|sql|log|conf)$ {
    deny all;
}

  • 2.4 Запрет прямого доступа к внутренним ресурсам

    • Описание реализации: nginx поддерживает внутренние location-блоки, которые недоступны напрямую клиенту и могут использоваться только для внутренних перенаправлений.
    • Модуль / механизм: ngx_http_core_module; директива internal
    • Комментарий: Применяется для скрытия служебных маршрутов и файлов от прямого обращения пользователя.
    • Проверка:
      • Статус: Подтверждено
      • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. Директива internal ограничивает доступ к location только для внутренних запросов (error_page, rewrite, auth_request, X-Accel-Redirect и др.
      • Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html#internal
      • Результат: Директива internal ограничивает доступ к location только для внутренних запросов (error_page, rewrite, auth_request, X-Accel-Redirect и др.). Прямые клиентские запросы к такому location возвращают 404.
      • Пример конфигурации: 
        location /protected-files/ {
    internal;
    alias /var/data/files/;
}

location /download {
    # Клиент обращается сюда; nginx внутренне отдаёт файл
    rewrite ^ /protected-files/document.pdf last;
}

  • 3. Защита соединения и передаваемых данных

    • 3.1 Поддержка HTTPS/TLS
      • Описание реализации: nginx поддерживает HTTPS при наличии SSL-модуля. Можно задавать сертификаты, ключи, версии TLS и наборы шифров.
      • Модуль / механизм: ngx_http_ssl_module; ssl_certificate, ssl_certificate_key, ssl_protocols, ssl_ciphers
      • Комментарий: SSL-модуль nginx предоставляет поддержку HTTPS, требует OpenSSL и должен быть включён при сборке.
      • Проверка:
        • Статус: Подтверждено с оговорками
        • Ревью функции: Описание и механизм в целом адекватны; учтены оговорки сборки, конфигурации или эксплуатации. Модуль ngx_http_ssl_module обеспечивает HTTPS.
        • Источник: https://nginx.org/en/docs/http/ngx_http_ssl_module.html
        • Результат: Модуль ngx_http_ssl_module обеспечивает HTTPS. Директивы ssl_certificate и ssl_certificate_key задают серверный сертификат и ключ; ssl_protocols и ssl_ciphers — параметры TLS. Модуль требует OpenSSL и включения при сборке (--with-http_ssl_module).
        • Пример конфигурации: 
          server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/nginx/ssl/example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;
}
    • 3.2 Ограничение версий TLS и шифров
      • Описание реализации: nginx позволяет задавать допустимые версии TLS и наборы шифров.
      • Модуль / механизм: ngx_http_ssl_module; ssl_protocols, ssl_ciphers
      • Комментарий: Для ТУ/ПМИ нужно отдельно фиксировать допустимую криптографическую политику.
      • Проверка:
        • Статус: Подтверждено
        • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. Директива ssl_protocols задаёт разрешённые версии протокола (TLSv1.
        • Источник: https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols , https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_ciphers
        • Результат: Директива ssl_protocols задаёт разрешённые версии протокола (TLSv1.2, TLSv1.3 и др.); ssl_ciphers — список шифронаборов в формате OpenSSL. Дополнительно доступны ssl_prefer_server_ciphers и параметры для TLS 1.3 (ssl_conf_command в новых версиях).
        • Пример конфигурации: 
          ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers on;
        • Примечание: Конкретная криптографическая политика должна быть зафиксирована в ТУ/ПМИ отдельно.
    • 3.3 Проверка клиентского сертификата
      • Описание реализации: nginx может проверять клиентские TLS-сертификаты по доверенному центру сертификации.
      • Модуль / механизм: ssl_client_certificate, ssl_verify_client
      • Комментарий: Может использоваться как механизм строгой аутентификации клиента.
      • Проверка:
        • Статус: Подтверждено
        • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. Директива ssl_verify_client поддерживает значения on, off, optional, optional_no_ca.
        • Источник: https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_verify_client
        • Результат: Директива ssl_verify_client поддерживает значения on, off, optional, optional_no_ca. При on клиент обязан предъявить сертификат, подписанный доверенным CA из ssl_client_certificate. Режим optional запрашивает сертификат, но не прерывает соединение при его отсутствии.
        • Пример конфигурации: 
          server {
    listen 443 ssl;
    ssl_certificate         /etc/nginx/ssl/server.crt;
    ssl_certificate_key     /etc/nginx/ssl/server.key;
    ssl_client_certificate  /etc/nginx/ssl/client-ca.crt;
    ssl_verify_client       optional;
    ssl_verify_depth        3;
}
        • Примечание: В отличие от п. 1.3, здесь акцент на защите канала и политике доверия к клиентским сертификатам.
    • 3.4 Принудительное использование HTTPS
      • Описание реализации: nginx может перенаправлять HTTP-запросы на HTTPS и добавлять заголовки безопасности.
      • Модуль / механизм: return 301/308; add_header Strict-Transport-Security
      • Комментарий: HSTS реализуется через HTTP-заголовок, а не отдельным модулем безопасности.
      • Проверка:
        • Статус: Подтверждено
        • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. Редирект HTTP→HTTPS реализуется директивой return (301 или 308).
        • Источник: https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#return , https://nginx.org/en/docs/http/ngx_http_headers_module.html#add_header
        • Результат: Редирект HTTP→HTTPS реализуется директивой return (301 или 308). Заголовок HSTS (Strict-Transport-Security) добавляется через add_header в HTTPS-блоке. Отдельного модуля HSTS в nginx нет.
        • Пример конфигурации: 
          server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

  • 4. Регистрация событий и аудит

    • 4.1 Журналирование HTTP-запросов
      • Описание реализации: nginx ведёт журнал HTTP-запросов в настраиваемом формате.
      • Модуль / механизм: ngx_http_log_module; access_log, log_format
      • Комментарий: Официальный модуль nginx записывает request logs в заданном формате.
      • Проверка:
        • Статус: Подтверждено
        • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. Модуль ngx_http_log_module записывает access log.
        • Источник: https://nginx.org/en/docs/http/ngx_http_log_module.html
        • Результат: Модуль ngx_http_log_module записывает access log. Директива access_log задаёт путь (или syslog) и формат; по умолчанию используется формат combined. Журналирование можно отключить (access_log off) на уровне server/location.
        • Пример конфигурации: 
          http {
    access_log /var/log/nginx/access.log combined;
}
    • 4.2 Журналирование ошибок
      • Описание реализации: nginx ведёт журнал ошибок, где фиксируются проблемы обработки запросов, конфигурации и взаимодействия с backend.
      • Модуль / механизм: error_log
      • Комментарий: Официальная документация указывает, что nginx пишет error log и позволяет задавать место и уровень журналирования.
      • Проверка:
        • Статус: Подтверждено
        • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. Директива error_log задаёт файл (или syslog) и уровень детализации: debug, info, notice, warn, error, crit, alert, emerg.
        • Источник: https://nginx.org/en/docs/ngx_core_module.html#error_log
        • Результат: Директива error_log задаёт файл (или syslog) и уровень детализации: debug, info, notice, warn, error, crit, alert, emerg. Уровень по умолчанию — error.
        • Пример конфигурации: 
          error_log /var/log/nginx/error.log warn;
    • 4.3 Настройка формата журналов
      • Описание реализации: nginx позволяет задавать собственный формат access log с нужными полями.
      • Модуль / механизм: log_format
      • Комментарий: Для ПМИ можно проверять наличие обязательных полей в журнале.
      • Проверка:
        • Статус: Подтверждено
        • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. Директива log_format определяет именованный формат с произвольным набором переменных ($remote_addr, $request, $status, $body_bytes_sent, $http_user_agent и др.
        • Источник: https://nginx.org/en/docs/http/ngx_http_log_module.html#log_format
        • Результат: Директива log_format определяет именованный формат с произвольным набором переменных ($remote_addr, $request, $status, $body_bytes_sent, $http_user_agent и др.). Формат применяется в access_log.
        • Пример конфигурации: 
          log_format audit '$remote_addr - $remote_user [$time_local] '
                 '"$request" $status $body_bytes_sent '
                 '"$http_referer" "$http_user_agent" '
                 '$request_time $upstream_response_time';

access_log /var/log/nginx/audit.log audit;
    • 4.4 Передача журналов в syslog
      • Описание реализации: nginx поддерживает запись access_log и error_log в syslog.
      • Модуль / механизм: access_log syslog:...; error_log syslog:...
      • Комментарий: Подтверждено официальной документацией nginx по syslog.
      • Проверка:
        • Статус: Подтверждено
        • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. nginx поддерживает запись access_log и error_log в syslog с параметрами server, facility, tag, severity.
        • Источник: https://nginx.org/en/docs/syslog.html
        • Результат: nginx поддерживает запись access_log и error_log в syslog с параметрами server, facility, tag, severity. Формат: syslog:server=address[,parameter=value].
        • Пример конфигурации: 
          error_log syslog:server=192.168.1.1:514,facility=local7,tag=nginx,severity=error;

access_log syslog:server=192.168.1.1:514,facility=local7,tag=nginx,severity=info combined;
        • Примечание: См. ПМИ п. 14 в Проверочные мероприятия для ПМИ — проверка.md; Контроль целостности хранимого кода и конфигурации — проверка.md п. 13; Минимально необходимые полномочия nginx — проверка.md п. 5.

  • 5. Ограничение нагрузки и защита от избыточных запросов

    • 5.1 Ограничение частоты запросов
      • Описание реализации: nginx может ограничивать частоту обработки запросов по заданному ключу, например по IP-адресу клиента.
      • Модуль / механизм: ngx_http_limit_req_module; limit_req_zone, limit_req
      • Комментарий: Модуль использует метод leaky bucket и официально предназначен для ограничения request rate.
      • Проверка:
        • Статус: Подтверждено
        • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. Модуль ngx_http_limit_req_module реализует алгоритм leaky bucket.
        • Источник: https://nginx.org/en/docs/http/ngx_http_limit_req_module.html
        • Результат: Модуль ngx_http_limit_req_module реализует алгоритм leaky bucket. limit_req_zone определяет зону и ключ (например, $binary_remote_addr); limit_req применяет ограничение с параметрами rate и burst.
        • Пример конфигурации: 
          http {
    limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;

    server {
        location / {
            limit_req zone=one burst=20 nodelay;
        }
    }
}
        • Примечание: См. Требования безопасности для включения в ТУ — проверка.md п. 15; Проверочные мероприятия для ПМИ — проверка.md п. 15.
    • 5.2 Ограничение количества соединений
      • Описание реализации: nginx может ограничивать количество соединений по заданному ключу, например по IP-адресу клиента.
      • Модуль / механизм: ngx_http_limit_conn_module; limit_conn_zone, limit_conn
      • Комментарий: Официальный модуль ограничивает количество соединений per defined key.
      • Проверка:
        • Статус: Подтверждено
        • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. Модуль ngx_http_limit_conn_module ограничивает число одновременных соединений по ключу.
        • Источник: https://nginx.org/en/docs/http/ngx_http_limit_conn_module.html
        • Результат: Модуль ngx_http_limit_conn_module ограничивает число одновременных соединений по ключу. limit_conn_zone задаёт зону; limit_conn применяет лимит.
        • Пример конфигурации: 
          http {
    limit_conn_zone $binary_remote_addr zone=addr:10m;

    server {
        location / {
            limit_conn addr 10;
        }
    }
}
        • Примечание: См. Требования безопасности для включения в ТУ — проверка.md п. 16; Проверочные мероприятия для ПМИ — проверка.md п. 16.
    • 5.3 Ограничение размера клиентского запроса
      • Описание реализации: nginx позволяет ограничивать максимальный размер тела клиентского запроса.
      • Модуль / механизм: ngx_http_core_module; client_max_body_size
      • Комментарий: Используется для защиты от чрезмерно больших запросов и нежелательных загрузок.
      • Проверка:
        • Статус: Подтверждено
        • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. Директива client_max_body_size задаёт максимальный размер тела запроса.
        • Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size
        • Результат: Директива client_max_body_size задаёт максимальный размер тела запроса. Значение по умолчанию — 1m. При превышении nginx возвращает 413 (Request Entity Too Large).
        • Пример конфигурации: 
          server {
    client_max_body_size 10m;
}
        • Примечание: См. Требования безопасности для включения в ТУ — проверка.md п. 15; Проверочные мероприятия для ПМИ — проверка.md п. 15.
    • 5.4 Ограничение скорости отдачи данных
      • Описание реализации: nginx позволяет ограничивать скорость передачи ответа клиенту.
      • Модуль / механизм: ngx_http_core_module; limit_rate
      • Комментарий: Используется для управления нагрузкой и потреблением ресурсов.
      • Проверка:
        • Статус: Подтверждено
        • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. Директива limit_rate ограничивает скорость отдачи ответа клиенту (байт/с).
        • Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html#limit_rate
        • Результат: Директива limit_rate ограничивает скорость отдачи ответа клиенту (байт/с). Дополнительно limit_rate_after позволяет отдавать начальный объём без ограничения.
        • Пример конфигурации: 
          location /downloads/ {
    limit_rate 500k;
}
        • Примечание: См. Требования безопасности для включения в ТУ — проверка.md п. 16; Проверочные мероприятия для ПМИ — проверка.md п. 16.
    • 5.5 Настройка таймаутов соединений
      • Описание реализации: nginx позволяет задавать таймауты чтения заголовков, тела запроса, отправки ответа и keepalive.
      • Модуль / механизм: client_header_timeout, client_body_timeout, send_timeout, keepalive_timeout
      • Комментарий: Снижает риск удержания ресурсов медленными или зависшими соединениями.
      • Проверка:
        • Статус: Подтверждено
        • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. Директивы client_header_timeout, client_body_timeout, send_timeout и keepalive_timeout задают таймауты на разных этапах обработки соединения.
        • Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html
        • Результат: Директивы client_header_timeout, client_body_timeout, send_timeout и keepalive_timeout задают таймауты на разных этапах обработки соединения. Значения по умолчанию: 60s для header/body/send, 75s для keepalive.
        • Пример конфигурации: 
          http {
    client_header_timeout 10s;
    client_body_timeout   10s;
    send_timeout          10s;
    keepalive_timeout     30s;
}

  • 6. Управление раскрытием информации

    • 6.1 Сокрытие версии nginx
      • Описание реализации: nginx позволяет отключить отображение версии сервера в стандартных ответах.
      • Модуль / механизм: server_tokens off
      • Комментарий: Важно: server_tokens off скрывает версию, но не всегда полностью скрывает сам факт использования nginx.
      • Проверка:
        • Статус: Подтверждено
        • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. Директива server_tokens off убирает номер версии из заголовка Server и со страниц ошибок nginx.
        • Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html#server_tokens
        • Результат: Директива server_tokens off убирает номер версии из заголовка Server и со страниц ошибок nginx. Заголовок Server по-прежнему содержит слово «nginx».
        • Минимальный аудит конфигурации:

nginx -T 2>/dev/null | grep server_tokens - **Пример конфигурации:**nginx http { server_tokens off; } ``` - Примечание: Для полного сокрытия идентификатора сервера требуются дополнительные меры (например, заголовки через more_clear_headers в сторонних модулях).

  • 6.2 Управление страницами ошибок
    • Описание реализации: nginx позволяет задавать собственные страницы ошибок и внутренние перенаправления.
    • Модуль / механизм: error_page
    • Комментарий: Позволяет не раскрывать технические детали пользователю.
    • Проверка:
      • Статус: Подтверждено
      • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. Директива error_page перенаправляет обработку указанных кодов ошибок на URI, именованный location или внешний адрес.
      • Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html#error_page
      • Результат: Директива error_page перенаправляет обработку указанных кодов ошибок на URI, именованный location или внешний адрес. Позволяет показывать пользовательские страницы вместо стандартных сообщений nginx.
      • Пример конфигурации: 
        error_page 404 /custom_404.html;
error_page 500 502 503 504 /custom_50x.html;

location = /custom_404.html {
    root /var/www/errors;
    internal;
}
  • 6.3 Управление листингом директорий
    • Описание реализации: nginx может формировать листинг директорий через autoindex, если режим включён.
    • Модуль / механизм: ngx_http_autoindex_module; autoindex
    • Комментарий: Модуль официально формирует directory listing для запросов, оканчивающихся /, когда не найден индексный файл. Для безопасной конфигурации должен быть отключён, если не требуется.
    • Проверка:
      • Статус: Подтверждено
      • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. Модуль ngx_http_autoindex_module включается директивой autoindex on и формирует HTML-листинг каталога при отсутствии индексного файла.
      • Источник: https://nginx.org/en/docs/http/ngx_http_autoindex_module.html
      • Результат: Модуль ngx_http_autoindex_module включается директивой autoindex on и формирует HTML-листинг каталога при отсутствии индексного файла. По умолчанию autoindex off. Для безопасной конфигурации рекомендуется явно отключать или не включать.
      • Минимальный аудит конфигурации:

nginx -T 2>/dev/null | grep autoindex - **Пример конфигурации:**nginx location /public-files/ { autoindex off; root /var/www/files; } ```

  • 7. Обратное проксирование и изоляция backend-сервисов

    • 7.1 Обратное проксирование HTTP/HTTPS
      • Описание реализации: nginx может принимать клиентские запросы и передавать их внутренним backend-сервисам.
      • Модуль / механизм: ngx_http_proxy_module; proxy_pass
      • Комментарий: Официальный модуль proxy передаёт запросы другому серверу.
      • Проверка:
        • Статус: Подтверждено
        • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. Модуль ngx_http_proxy_module передаёт HTTP-запросы на backend через proxy_pass.
        • Источник: https://nginx.org/en/docs/http/ngx_http_proxy_module.html
        • Результат: Модуль ngx_http_proxy_module передаёт HTTP-запросы на backend через proxy_pass. Поддерживается проксирование на HTTP и HTTPS upstream.
        • Пример конфигурации: 
          location /api/ {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}
    • 7.2 Балансировка и группы upstream
      • Описание реализации: nginx позволяет определять группы backend-серверов и использовать их для proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass, grpc_pass.
      • Модуль / механизм: ngx_http_upstream_module; upstream
      • Комментарий: Документация nginx описывает upstream как механизм групп серверов для разных pass-директив.
      • Проверка:
        • Статус: Подтверждено
        • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. Блок upstream определяет группу backend-серверов с методами балансировки (round-robin по умолчанию, least_conn, ip_hash, hash).
        • Источник: https://nginx.org/en/docs/http/ngx_http_upstream_module.html
        • Результат: Блок upstream определяет группу backend-серверов с методами балансировки (round-robin по умолчанию, least_conn, ip_hash, hash). Используется с proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass, grpc_pass.
        • Пример конфигурации: 
          upstream backend {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    keepalive 32;
}

server {
    location / {
        proxy_pass http://backend;
    }
}
    • 7.3 Управление заголовками при проксировании
      • Описание реализации: nginx позволяет явно задавать заголовки, передаваемые backend-сервису.
      • Модуль / механизм: proxy_set_header
      • Комментарий: Важно для корректной передачи адреса клиента и исключения нежелательных/подменённых заголовков.
      • Проверка:
        • Статус: Подтверждено
        • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. Директива proxy_set_header задаёт или переопределяет заголовки запроса к backend.
        • Источник: https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_set_header
        • Результат: Директива proxy_set_header задаёт или переопределяет заголовки запроса к backend. По умолчанию nginx передаёт ряд заголовков, но Host и Connection могут требовать явной настройки. proxy_pass_request_headers управляет передачей клиентских заголовков.
        • Пример конфигурации: 
          location / {
    proxy_pass http://backend;
    proxy_set_header Host              $host;
    proxy_set_header X-Real-IP         $remote_addr;
    proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

  • 8. Управление статическим содержимым и директориями веб-приложений

    • 8.1 Задание корневой директории сайта
      • Описание реализации: nginx обслуживает файлы из директории, заданной директивой root.
      • Модуль / механизм: ngx_http_core_module; root
      • Комментарий: Используется для определения разрешённой области веб-контента.
      • Проверка:
        • Статус: Подтверждено
        • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. Директива root задаёт корневую директорию для запросов в данном server/location.
        • Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html#root
        • Результат: Директива root задаёт корневую директорию для запросов в данном server/location. Путь к файлу формируется как root + URI.
        • Пример конфигурации: 
          server {
    root /var/www/example.com;
    location / {
        index index.html;
    }
}
    • 8.2 Задание альтернативного пути для location
      • Описание реализации: nginx позволяет сопоставлять URI с другой директорией файловой системы через alias.
      • Модуль / механизм: ngx_http_core_module; alias
      • Комментарий: Требует осторожной настройки, чтобы не открыть произвольные каталоги ОС.
      • Проверка:
        • Статус: Подтверждено
        • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. Директива alias заменяет часть URI на указанный путь файловой системы.
        • Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html#alias
        • Результат: Директива alias заменяет часть URI на указанный путь файловой системы. При некорректной настройке (особенно с регулярными выражениями) возможен path traversal.
        • Пример конфигурации: 
          location /images/ {
    alias /var/www/static/images/;
}
        • Примечание: Для location с регулярным выражением alias должен содержать захватывающие группы; завершающий слэш обязателен.
    • 8.3 Проверка существования файлов и маршрутизация
      • Описание реализации: nginx позволяет проверять наличие файлов и выполнять внутреннюю маршрутизацию через try_files.
      • Модуль / механизм: ngx_http_core_module; try_files
      • Комментарий: Используется для контроля, какой файл или маршрут будет обработан.
      • Проверка:
        • Статус: Подтверждено
        • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. Директива try_files проверяет существование файлов/каталогов в указанном порядке и выполняет внутреннее перенаправление на последний параметр при отсутствии совпадений.
        • Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html#try_files
        • Результат: Директива try_files проверяет существование файлов/каталогов в указанном порядке и выполняет внутреннее перенаправление на последний параметр при отсутствии совпадений.
        • Пример конфигурации: 
          location / {
    root /var/www/html;
    try_files $uri $uri/ /index.html;
}
    • 8.4 Ограничение доступа к произвольным каталогам ОС
      • Описание реализации: nginx должен быть настроен так, чтобы обслуживать файлы только из разрешённых директорий.
      • Модуль / механизм: root, alias, location, deny all, права ФС
      • Комментарий: Это не отдельный модуль nginx, а требование безопасной конфигурации.
      • Проверка:
        • Статус: Подтверждено
        • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. nginx обслуживает только те пути, которые явно заданы через root/alias в location.
        • Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html#root , https://nginx.org/en/docs/http/ngx_http_access_module.html
        • Результат: nginx обслуживает только те пути, которые явно заданы через root/alias в location. Безопасная конфигурация ограничивает location /, запрещает доступ к системным путям и сочетается с правами файловой системы (процесс nginx не должен иметь доступ к чувствительным каталогам).
        • Пример конфигурации: 
          server {
    root /var/www/site;
    location / {
        try_files $uri =404;
    }
    location ~ ^/(\.\.|etc|proc|sys) {
        deny all;
    }
}
        • Примечание: Дополнительно на уровне ОС следует ограничить права пользователя, от которого работает nginx. См. Минимально необходимые полномочия nginx — проверка.md п. 3; Контроль выполнения кода — проверка.md п. 14.

  • 9. Минимизация поверхности атаки

    • 9.1 Исключение неиспользуемых модулей
      • Описание реализации: nginx может собираться с разным составом модулей; неиспользуемые модули могут быть исключены из сборки или не загружаться.
      • Модуль / механизм: Параметры сборки; dynamic modules; load_module
      • Комментарий: Это проектная мера снижения поверхности атаки.
      • Проверка:
        • Статус: Подтверждено
        • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. При сборке nginx параметры ./configure позволяют включать/отключать модули (--without-http_autoindex_module, --with-http_ssl_module и др.
        • Источник: https://nginx.org/en/docs/configure.html , https://nginx.org/en/docs/ngx_core_module.html#load_module
        • Результат: При сборке nginx параметры ./configure позволяют включать/отключать модули (--without-http_autoindex_module, --with-http_ssl_module и др.). Динамические модули подключаются через load_module в конфигурации; неиспользуемые модули можно не загружать.
        • Пример конфигурации: 
          # Загрузка только необходимых динамических модулей
load_module modules/ngx_http_geoip_module.so;

# Статические модули определяются при сборке:
# ./configure --without-http_autoindex_module --with-http_ssl_module
        • Примечание: См. Минимизация поверхности атаки nginx — проверка.md п. 1–2.
    • 9.2 Отключение неиспользуемых возможностей конфигурацией
      • Описание реализации: Неиспользуемые возможности должны быть отключены в конфигурации: autoindex, лишние методы, лишние proxy/FastCGI-направления.
      • Модуль / механизм: Конфигурация nginx
      • Комментарий: Это не отдельная функция nginx, а требование безопасной эксплуатации.
      • Проверка:
        • Статус: Подтверждено
        • Ревью функции: Описание реализации и заявленный механизм соответствуют документации nginx. Неиспользуемые возможности отключаются конфигурацией: autoindex off, ограничение методов через limit_except, удаление неиспользуемых location с proxy_pass/fastcgi_pass.
        • Источник: https://nginx.org/en/docs/http/ngx_http_autoindex_module.html , https://nginx.org/en/docs/http/ngx_http_core_module.html#limit_except
        • Результат: Неиспользуемые возможности отключаются конфигурацией: autoindex off, ограничение методов через limit_except, удаление неиспользуемых location с proxy_pass/fastcgi_pass. Это требование безопасной эксплуатации, а не отдельный модуль.
        • Пример конфигурации: 
          server {
    autoindex off;

    location / {
        limit_except GET HEAD POST {
            deny all;
        }
    }

    # Неиспользуемые направления не включаются в конфигурацию
    # location /legacy-api/ { proxy_pass http://old-backend; }
}
        • Примечание: См. Минимизация поверхности атаки nginx — проверка.md п. 4–10.
    • 9.3 Контроль целостности конфигурации и разрешённых директорий
      • Описание реализации: Конфигурация nginx и разрешённые директории веб-контента должны контролироваться внешним механизмом целостности.
      • Модуль / механизм: afick или иной утверждённый механизм
      • Комментарий: nginx не выполняет контроль целостности сам. Это внешняя мера, требуемая для сертификационной логики.
      • Проверка:
        • Статус: Не применимо к nginx напрямую (внешняя мера)
        • Ревью функции: Корректно отнесено к внешней мере: nginx не реализует функцию напрямую. nginx не реализует контроль целостности файлов (FIM).
        • Источник: https://nginx.org/en/docs/ (функция FIM в nginx не описана)
        • Результат: nginx не реализует контроль целостности файлов (FIM). Данное требование выполняется внешними средствами: afick, AIDE, OSSEC или иным утверждённым механизмом. Контролируемые объекты: /etc/nginx/ (конфигурация), директории root/alias веб-контента.
        • Пример реализации: 
          # /etc/afick.conf (фрагмент)
/etc/nginx/               R
/var/www/                 R
        • Примечание: См. Минимизация поверхности атаки nginx — проверка.md п. 4–10.
        • Примечание: Для ПМИ проверяется наличие и работоспособность внешнего средства, а не конфигурация nginx. Статус отражает внешнюю меру (см. Контроль целостности хранимого кода и конфигурации — проверка.md; ПМИ п. 24; Контроль выполнения кода — проверка.md п. 15–16).
Reference in New Issue View Git Blame Copy Permalink