Astra/nginx-analize
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
master
nginx-analize/docs/Требования_безопасности_для_включения_в_ТУ_—_проверка.md
Redsandyg fcc9139361 init
2026-06-15 06:31:35 +03:00

48 KiB
Raw Permalink Blame History

Требования безопасности для включения в ТУ — результаты проверки

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

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

№ Требование Статус Механизм nginx
1 Ограничение доступа по IP-адресу Подтверждено ngx_http_access_module; allow; deny
2 Аутентификация по имени пользователя и паролю Подтверждено ngx_http_auth_basic_module
3 Аутентификация по клиентскому TLS-сертификату Подтверждено с оговорками ngx_http_ssl_module
4 Авторизация через внешний сервис Подтверждено с оговорками ngx_http_auth_request_module
5 Комбинирование механизмов доступа Подтверждено satisfy
6 Разграничение доступа по URL и виртуальным серверам Подтверждено server; location
7 Ограничение HTTP-методов Подтверждено limit_except
8 Запрет прямого доступа к внутренним ресурсам Подтверждено internal
9 Защита соединения с использованием TLS Подтверждено с оговорками ngx_http_ssl_module
10 Ограничение версий TLS и наборов шифров Подтверждено ssl_protocols; ssl_ciphers
11 Принудительное использование HTTPS Подтверждено return; add_header (HSTS)
12 Журналирование HTTP-запросов Подтверждено access_log; log_format
13 Журналирование ошибок Подтверждено error_log
14 Передача журналов во внешнюю систему Подтверждено syslog
15 Ограничение частоты запросов Подтверждено ngx_http_limit_req_module
16 Ограничение количества соединений Подтверждено ngx_http_limit_conn_module
17 Ограничение размера клиентского запроса Подтверждено client_max_body_size
18 Настройка таймаутов соединений Подтверждено client_*_timeout; send_timeout; keepalive_timeout
19 Сокрытие версии веб-сервера Подтверждено server_tokens off
20 Управление страницами ошибок Подтверждено error_page
21 Управление листингом директорий Подтверждено autoindex off
22 Обратное проксирование backend-сервисов Подтверждено proxy_pass; proxy_set_header
23 Управление директориями веб-контента Подтверждено root; alias; location; try_files
24 Минимизация поверхности атаки Подтверждено с оговорками configure; load_module; конфигурация

  1. Ограничение доступа по IP-адресу

    • Требование для ТУ: Веб-сервер должен обеспечивать возможность ограничения доступа к защищаемым ресурсам по IP-адресу клиента.
    • Механизм nginx: ngx_http_access_module; allow; deny
    • Комментарий: Проверяется через настройку разрешённых и запрещённых IP-адресов.
    • Проверка:
      • Статус: Подтверждено
      • Ревью требования: Формулировка требования согласуется с возможностями nginx.
      • Вывод для ТУ: Требование может быть включено в ТУ — nginx обеспечивает ограничение доступа по IP-адресу клиента.
      • Источник: https://nginx.org/en/docs/http/ngx_http_access_module.html
      • Результат: Модуль ngx_http_access_module входит в стандартную сборку nginx. Директивы allow и deny позволяют задавать правила доступа по IP-адресу, сети CIDR или all, что полностью соответствует формулировке требования.
      • Пример конфигурации: 
        location /admin/ {
    allow 192.168.1.0/24;
    allow 10.0.0.1;
    deny all;
}

  2. Аутентификация по имени пользователя и паролю

    • Требование для ТУ: Веб-сервер должен обеспечивать возможность аутентификации пользователей по имени пользователя и паролю при доступе к защищаемым ресурсам.
    • Механизм nginx: ngx_http_auth_basic_module; auth_basic; auth_basic_user_file
    • Комментарий: Реализуется через HTTP Basic Authentication.
    • Проверка:
      • Статус: Подтверждено
      • Ревью требования: Формулировка требования согласуется с возможностями nginx.
      • Вывод для ТУ: Требование может быть включено в ТУ — nginx поддерживает аутентификацию по имени пользователя и паролю.
      • Источник: 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 обеспечивают проверку учётных данных пользователя при доступе к защищаемым ресурсам.
      • Пример конфигурации: 
        location /secure/ {
    auth_basic           "Restricted Area";
    auth_basic_user_file /etc/nginx/htpasswd;
}

  3. Аутентификация по клиентскому TLS-сертификату

    • Требование для ТУ: Веб-сервер должен обеспечивать возможность проверки клиентского TLS-сертификата при доступе к защищаемым ресурсам.
    • Механизм nginx: ngx_http_ssl_module; ssl_client_certificate; ssl_verify_client
    • Комментарий: Применяется при использовании HTTPS и доверенного центра сертификации.
    • Проверка:
      • Статус: Подтверждено с оговорками
      • Ревью требования: Описание и механизм в целом адекватны; учтены оговорки сборки, конфигурации или эксплуатации.
      • Вывод для ТУ: Требование может быть включено в ТУ — nginx обеспечивает проверку клиентского TLS-сертификата при использовании HTTPS.
      • Источник: https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_verify_client
      • Результат: Модуль ngx_http_ssl_module поддерживает проверку клиентских сертификатов через ssl_verify_client и ssl_client_certificate. Требуется сборка с SSL-модулем и настроенный HTTPS.
      • Пример конфигурации: 
        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-модуля и доверенного CA.

  4. Авторизация через внешний сервис

    • Требование для ТУ: Веб-сервер должен обеспечивать возможность принятия решения о доступе на основании ответа внешнего сервиса авторизации.
    • Механизм nginx: ngx_http_auth_request_module; auth_request
    • Комментарий: Наличие модуля зависит от состава сборки nginx.
    • Проверка:
      • Статус: Подтверждено с оговорками
      • Ревью требования: Описание и механизм в целом адекватны; учтены оговорки сборки, конфигурации или эксплуатации.
      • Вывод для ТУ: Требование может быть включено в ТУ при условии наличия модуля auth_request в поставке nginx.
      • Источник: https://nginx.org/en/docs/http/ngx_http_auth_request_module.html
      • Результат: Модуль ngx_http_auth_request_module выполняет подзапрос к внешнему сервису авторизации и разрешает или запрещает доступ по коду ответа (2xx — разрешено, 401/403 — запрещено). Состав сборки nginx должен быть зафиксирован в ТУ.
      • Пример конфигурации: 
        location = /auth {
    internal;
    proxy_pass              http://auth-service:8080/validate;
    proxy_pass_request_body off;
    proxy_set_header        Content-Length "";
}

location / {
    auth_request /auth;
}
      • Примечание: В ТУ указать требование включения --with-http_auth_request_module или подтверждение наличия модуля в дистрибутивном пакете.

  5. Комбинирование механизмов доступа

    • Требование для ТУ: Веб-сервер должен обеспечивать возможность совместного применения нескольких механизмов контроля доступа.
    • Механизм nginx: satisfy; allow; deny; auth_basic; auth_request
    • Комментарий: Например, доступ по IP или по паролю.
    • Проверка:
      • Статус: Подтверждено
      • Ревью требования: Формулировка требования согласуется с возможностями nginx.
      • Вывод для ТУ: Требование может быть включено в ТУ — nginx позволяет комбинировать механизмы контроля доступа.
      • Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html#satisfy
      • Результат: Директива satisfy управляет логикой совместного применения allow/deny, auth_basic и auth_request. Значение any позволяет доступ при успехе любой проверки; all — при успехе всех.
      • Пример конфигурации: 
        location /admin/ {
    satisfy any;
    allow 10.0.0.0/8;
    deny all;
    auth_basic           "Admin";
    auth_basic_user_file /etc/nginx/htpasswd;
}

  6. Разграничение доступа по URL и виртуальным серверам

    • Требование для ТУ: Веб-сервер должен обеспечивать возможность задания разных правил доступа для разных виртуальных серверов и разделов сайта.
    • Механизм nginx: server; location
    • Комментарий: Используется для разделения публичных, служебных и закрытых ресурсов.
    • Проверка:
      • Статус: Подтверждено
      • Ревью требования: Формулировка требования согласуется с возможностями nginx.
      • Вывод для ТУ: Требование может быть включено в ТУ — nginx поддерживает разграничение по виртуальным серверам и URL.
      • Источник: 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 определяют виртуальные хосты, блоки location — правила для URI-путей. Это базовый механизм nginx для задания разных правил доступа на разных серверах и разделах сайта.
      • Пример конфигурации: 
        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;
    }
}

  7. Ограничение HTTP-методов

    • Требование для ТУ: Веб-сервер должен обеспечивать возможность ограничения использования HTTP-методов для защищаемых ресурсов.
    • Механизм nginx: limit_except
    • Комментарий: Позволяет ограничивать методы PUT, DELETE и другие методы, если они не требуются.
    • Проверка:
      • Статус: Подтверждено
      • Ревью требования: Формулировка требования согласуется с возможностями nginx.
      • Вывод для ТУ: Требование может быть включено в ТУ — nginx позволяет ограничивать HTTP-методы.
      • Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html#limit_except
      • Результат: Директива limit_except задаёт методы, для которых применяются вложенные правила доступа. Методы, не перечисленные в блоке, обрабатываются без дополнительных ограничений.
      • Пример конфигурации: 
        location /uploads/ {
    limit_except GET HEAD {
        deny all;
    }
}
      • Минимальный аудит конфигурации: 
        nginx -T 2>/dev/null | grep -E 'limit_except|request_method'
      • Примечание: См. Минимизация поверхности атаки nginx — проверка.md п. 11; Проверочные мероприятия для ПМИ — проверка.md п. 7.

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

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

  9. Защита соединения с использованием TLS

    • Требование для ТУ: Веб-сервер должен обеспечивать возможность защиты сетевого соединения с использованием TLS.
    • Механизм nginx: ngx_http_ssl_module; ssl_certificate; ssl_certificate_key
    • Комментарий: Используется для HTTPS-соединений.
    • Проверка:
      • Статус: Подтверждено с оговорками
      • Ревью требования: Описание и механизм в целом адекватны; учтены оговорки сборки, конфигурации или эксплуатации. Модуль ngx_http_ssl_module обеспечивает HTTPS через ssl_certificate и ssl_certificate_key.
      • Вывод для ТУ: Требование может быть включено в ТУ — nginx обеспечивает защиту соединения с использованием TLS.
      • Источник: https://nginx.org/en/docs/http/ngx_http_ssl_module.html
      • Результат: Модуль ngx_http_ssl_module обеспечивает HTTPS через ssl_certificate и ssl_certificate_key. Требуется сборка с --with-http_ssl_module и библиотека OpenSSL.
      • Пример конфигурации: 
        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;
}

  10. Ограничение версий TLS и наборов шифров

    • Требование для ТУ: Веб-сервер должен обеспечивать возможность задания допустимых версий TLS и наборов шифров.
    • Механизм nginx: ssl_protocols; ssl_ciphers
    • Комментарий: Конкретные допустимые значения должны определяться политикой безопасности.
    • Проверка:
      • Статус: Подтверждено
      • Ревью требования: Формулировка требования согласуется с возможностями nginx. Директивы ssl_protocols и ssl_ciphers позволяют ограничить версии протокола и наборы шифров.
      • Вывод для ТУ: Требование может быть включено в ТУ — nginx позволяет задавать допустимые версии TLS и шифры; конкретные значения фиксируются в политике безопасности ТУ.
      • Источник: 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 и ssl_ciphers позволяют ограничить версии протокола и наборы шифров. Формулировка требования ТУ корректна: nginx обеспечивает возможность задания, а конкретные значения определяются политикой.
      • Минимальный аудит конфигурации:

nginx -T 2>/dev/null | grep -E 'limit_except|request_method' - **Пример конфигурации:**nginx ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256; ssl_prefer_server_ciphers on; ``` - Примечание: В ТУ отдельно зафиксировать допустимую криптографическую политику (версии TLS, список шифров). См. Минимизация поверхности атаки nginx — проверка.md п. 11; Проверочные мероприятия для ПМИ — проверка.md п. 7.

  1. Принудительное использование HTTPS

    • Требование для ТУ: Веб-сервер должен обеспечивать возможность перенаправления HTTP-запросов на HTTPS.
    • Механизм nginx: return 301/308; Strict-Transport-Security
    • Комментарий: HSTS реализуется через HTTP-заголовок.
    • Проверка:
      • Статус: Подтверждено
      • Ревью требования: Формулировка требования согласуется с возможностями nginx. Редирект HTTP→HTTPS реализуется директивой return 301 или 308.
      • Вывод для ТУ: Требование может быть включено в ТУ — nginx обеспечивает перенаправление HTTP на HTTPS и заголовок HSTS.
      • Источник: 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. Заголовок Strict-Transport-Security добавляется через add_header в HTTPS-блоке.
      • Пример конфигурации: 
        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;
}

  2. Журналирование HTTP-запросов

    • Требование для ТУ: Веб-сервер должен обеспечивать регистрацию HTTP-запросов пользователей.
    • Механизм nginx: access_log; log_format
    • Комментарий: В журнале должны фиксироваться параметры, необходимые для анализа событий.
    • Проверка:
      • Статус: Подтверждено
      • Ревью требования: Формулировка требования согласуется с возможностями nginx. Модуль ngx_http_log_module записывает access log.
      • Вывод для ТУ: Требование может быть включено в ТУ — nginx обеспечивает регистрацию HTTP-запросов в настраиваемом формате.
      • Источник: https://nginx.org/en/docs/http/ngx_http_log_module.html
      • Результат: Модуль ngx_http_log_module записывает access log. Директива log_format позволяет задать поля, необходимые для анализа событий безопасности (IP, время, запрос, статус, user-agent и др.).
      • Пример конфигурации: 
        log_format security '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent"';

access_log /var/log/nginx/access.log security;

  3. Журналирование ошибок

    • Требование для ТУ: Веб-сервер должен обеспечивать регистрацию ошибок обработки запросов и ошибок конфигурации.
    • Механизм nginx: error_log
    • Комментарий: Используется для диагностики и анализа событий безопасности.
    • Проверка:
      • Статус: Подтверждено
      • Ревью требования: Формулировка требования согласуется с возможностями nginx. Директива error_log задаёт файл журнала и уровень детализации (warn, error, crit и др.
      • Вывод для ТУ: Требование может быть включено в ТУ — nginx обеспечивает регистрацию ошибок.
      • Источник: https://nginx.org/en/docs/ngx_core_module.html#error_log
      • Результат: Директива error_log задаёт файл журнала и уровень детализации (warn, error, crit и др.). Ошибки обработки запросов, конфигурации и взаимодействия с backend фиксируются в error log.
      • Пример конфигурации: 
        error_log /var/log/nginx/error.log warn;

  4. Передача журналов во внешнюю систему

    • Требование для ТУ: Веб-сервер должен обеспечивать возможность передачи журналов во внешнюю систему журналирования.
    • Механизм nginx: syslog в access_log/error_log
    • Комментарий: Используется для централизованного сбора событий.
    • Проверка:
      • Статус: Подтверждено
      • Ревью требования: Формулировка требования согласуется с возможностями nginx. nginx поддерживает запись access_log и error_log в syslog с параметрами server, facility, tag, severity, что обеспечивает централизованный сбор событий во внешней системе журналирования.
      • Вывод для ТУ: Требование может быть включено в ТУ — nginx поддерживает передачу журналов в syslog.
      • Источник: https://nginx.org/en/docs/syslog.html
      • Результат: nginx поддерживает запись access_log и error_log в syslog с параметрами server, facility, tag, severity, что обеспечивает централизованный сбор событий во внешней системе журналирования.
      • Пример конфигурации: 
        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 security;

  5. Ограничение частоты запросов

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

    server {
        location / {
            limit_req zone=one burst=20 nodelay;
        }
    }
}

  6. Ограничение количества соединений

    • Требование для ТУ: Веб-сервер должен обеспечивать возможность ограничения количества одновременных соединений.
    • Механизм nginx: limit_conn_zone; limit_conn
    • Комментарий: Снижает риск исчерпания ресурсов.
    • Проверка:
      • Статус: Подтверждено
      • Ревью требования: Формулировка требования согласуется с возможностями nginx. Модуль ngx_http_limit_conn_module ограничивает число одновременных соединений по заданному ключу, что соответствует требованию ТУ.
      • Вывод для ТУ: Требование может быть включено в ТУ — nginx обеспечивает ограничение количества соединений.
      • Источник: https://nginx.org/en/docs/http/ngx_http_limit_conn_module.html
      • Результат: Модуль ngx_http_limit_conn_module ограничивает число одновременных соединений по заданному ключу, что соответствует требованию ТУ.
      • Пример конфигурации: 
        http {
    limit_conn_zone $binary_remote_addr zone=addr:10m;

    server {
        location / {
            limit_conn addr 10;
        }
    }
}

  7. Ограничение размера клиентского запроса

    • Требование для ТУ: Веб-сервер должен обеспечивать возможность ограничения размера тела клиентского запроса.
    • Механизм nginx: client_max_body_size
    • Комментарий: Используется для защиты от чрезмерно больших запросов и нежелательных загрузок.
    • Проверка:
      • Статус: Подтверждено
      • Ревью требования: Формулировка требования согласуется с возможностями nginx. Директива client_max_body_size задаёт максимальный размер тела запроса.
      • Вывод для ТУ: Требование может быть включено в ТУ — nginx обеспечивает ограничение размера тела запроса.
      • Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size
      • Результат: Директива client_max_body_size задаёт максимальный размер тела запроса. При превышении nginx возвращает 413 (Request Entity Too Large).
      • Пример конфигурации: 
        server {
    client_max_body_size 10m;
}

  8. Настройка таймаутов соединений

    • Требование для ТУ: Веб-сервер должен обеспечивать возможность настройки таймаутов обработки клиентских соединений.
    • Механизм nginx: client_header_timeout; client_body_timeout; send_timeout; keepalive_timeout
    • Комментарий: Снижает риск удержания ресурсов медленными соединениями.
    • Проверка:
      • Статус: Подтверждено
      • Ревью требования: Формулировка требования согласуется с возможностями nginx. Директивы client_header_timeout, client_body_timeout, send_timeout и keepalive_timeout позволяют задавать таймауты на разных этапах обработки клиентского соединения.
      • Вывод для ТУ: Требование может быть включено в ТУ — nginx обеспечивает настройку таймаутов соединений.
      • Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html
      • Результат: Директивы client_header_timeout, client_body_timeout, send_timeout и keepalive_timeout позволяют задавать таймауты на разных этапах обработки клиентского соединения.
      • Пример конфигурации: 
        http {
    client_header_timeout 10s;
    client_body_timeout   10s;
    send_timeout          10s;
    keepalive_timeout     30s;
}

  9. Сокрытие версии веб-сервера

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

nginx -T 2>/dev/null | grep server_tokens - **Пример конфигурации:**nginx http { server_tokens off; } ```

  1. Управление страницами ошибок

    • Требование для ТУ: Веб-сервер должен обеспечивать возможность настройки пользовательских страниц ошибок.
    • Механизм nginx: error_page
    • Комментарий: Позволяет не раскрывать технические детали пользователю.
    • Проверка:
      • Статус: Подтверждено
      • Ревью требования: Формулировка требования согласуется с возможностями nginx. Директива error_page перенаправляет обработку указанных кодов ошибок на пользовательские страницы, скрывая технические детали nginx.
      • Вывод для ТУ: Требование может быть включено в ТУ — nginx обеспечивает настройку пользовательских страниц ошибок.
      • Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html#error_page
      • Результат: Директива error_page перенаправляет обработку указанных кодов ошибок на пользовательские страницы, скрывая технические детали 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;
}

  2. Управление листингом директорий

    • Требование для ТУ: Веб-сервер должен обеспечивать возможность отключения листинга директорий.
    • Механизм nginx: autoindex off
    • Комментарий: В безопасной конфигурации листинг директорий должен быть отключён, если не требуется.
    • Проверка:
      • Статус: Подтверждено
      • Ревью требования: Формулировка требования согласуется с возможностями nginx. По умолчанию autoindex off. Директива autoindex off явно отключает формирование листинга каталога, что соответствует требованию безопасной конфигурации.
      • Вывод для ТУ: Требование может быть включено в ТУ — nginx позволяет отключить листинг директорий.
      • Источник: https://nginx.org/en/docs/http/ngx_http_autoindex_module.html
      • Результат: По умолчанию autoindex off. Директива autoindex off явно отключает формирование листинга каталога, что соответствует требованию безопасной конфигурации.
      • Минимальный аудит конфигурации:

nginx -T 2>/dev/null | grep autoindex - **Пример конфигурации:**nginx server { autoindex off; root /var/www/html; } ``` - Примечание: См. Минимизация поверхности атаки nginx — проверка.md п. 10; Проверочные мероприятия для ПМИ — проверка.md п. 21.

  1. Обратное проксирование backend-сервисов

    • Требование для ТУ: Веб-сервер должен обеспечивать возможность изоляции backend-сервисов через обратное проксирование.
    • Механизм nginx: proxy_pass; proxy_set_header
    • Комментарий: Backend-сервисы не должны быть доступны напрямую, если это предусмотрено архитектурой.
    • Проверка:
      • Статус: Подтверждено
      • Ревью требования: Формулировка требования согласуется с возможностями nginx. Модуль ngx_http_proxy_module передаёт запросы на внутренние backend-сервисы.
      • Вывод для ТУ: Требование может быть включено в ТУ — nginx обеспечивает изоляцию backend через обратное проксирование.
      • Источник: https://nginx.org/en/docs/http/ngx_http_proxy_module.html
      • Результат: Модуль ngx_http_proxy_module передаёт запросы на внутренние backend-сервисы. proxy_set_header позволяет корректно передавать адрес клиента. Backend может быть недоступен напрямую извне при правильной сетевой архитектуре.
      • Пример конфигурации: 
        location /api/ {
    proxy_pass http://127.0.0.1:8080;
    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;
}

  2. Управление директориями веб-контента

    • Требование для ТУ: Веб-сервер должен обеспечивать возможность задания разрешённых директорий веб-контента.
    • Механизм nginx: root; alias; location; try_files
    • Комментарий: Требует безопасной настройки, чтобы исключить доступ к произвольным каталогам ОС.
    • Проверка:
      • Статус: Подтверждено
      • Ревью требования: Формулировка требования согласуется с возможностями nginx. Директивы root, alias, location и try_files позволяют ограничить область обслуживаемого контента.
      • Вывод для ТУ: Требование может быть включено в ТУ — nginx позволяет задавать разрешённые директории веб-контента через конфигурацию.
      • Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html#root , https://nginx.org/en/docs/http/ngx_http_core_module.html#alias
      • Результат: Директивы root, alias, location и try_files позволяют ограничить область обслуживаемого контента. Встроенного allowlist нет — перечень разрешённых директорий фиксируется в ТУ и реализуется конфигурацией.
      • Пример конфигурации: 
        server {
    root /var/www/app/public;

    location / {
        try_files $uri =404;
    }

    location ~ /\. {
        deny all;
    }
}
      • Примечание: В ТУ зафиксировать перечень разрешённых директорий веб-контента. См. Минимизация поверхности атаки nginx — проверка.md п. 10; Проверочные мероприятия для ПМИ — проверка.md п. 21.

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

    • Требование для ТУ: Поставка и конфигурация веб-сервера должны обеспечивать возможность минимизации поверхности атаки за счёт исключения, отделения или незагрузки неиспользуемых модулей и функциональных возможностей.
    • Механизм nginx: параметры сборки; dynamic modules; load_module; конфигурация nginx
    • Комментарий: Конкретные меры определяются по составу поставки и целевой конфигурации.
    • Проверка:
      • Статус: Подтверждено с оговорками
      • Ревью требования: Описание и механизм в целом адекватны; учтены оговорки сборки, конфигурации или эксплуатации. nginx позволяет исключать модули при сборке (`.
      • Вывод для ТУ: Требование может быть включено в ТУ как проектно-эксплуатационное — nginx предоставляет механизмы минимизации поверхности атаки; конкретные меры фиксируются в ТУ по составу поставки.
      • Источник: https://nginx.org/en/docs/configure.html , https://nginx.org/en/docs/ngx_core_module.html#load_module
      • Результат: nginx позволяет исключать модули при сборке (./configure --without-...), не загружать неиспользуемые динамические модули (load_module) и отключать возможности конфигурацией (autoindex off, удаление лишних location). Конкретный перечень мер определяется целевой конфигурацией и должен быть зафиксирован в ТУ.
      • Пример конфигурации: 
        # Загрузка только утверждённых динамических модулей
# load_module modules/ngx_http_geoip_module.so;

http {
    autoindex off;
    server_tokens off;
    # Неиспользуемые proxy/fastcgi-направления не включаются
}
      • Примечание: В ТУ указать: состав модулей поставки, запрет загрузки неутверждённых .so, перечень отключённых возможностей конфигурации. См. Минимизация поверхности атаки nginx — проверка.md п. 1–15.
Reference in New Issue View Git Blame Copy Permalink