# Требования безопасности для включения в ТУ — результаты проверки **Дата проверки:** 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`, что полностью соответствует формулировке требования. - **Пример конфигурации:** ```nginx 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` обеспечивают проверку учётных данных пользователя при доступе к защищаемым ресурсам. - **Пример конфигурации:** ```nginx 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. - **Пример конфигурации:** ```nginx 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 должен быть зафиксирован в ТУ. - **Пример конфигурации:** ```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` — при успехе всех. - **Пример конфигурации:** ```nginx 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 для задания разных правил доступа на разных серверах и разделах сайта. - **Пример конфигурации:** ```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` задаёт методы, для которых применяются вложенные правила доступа. Методы, не перечисленные в блоке, обрабатываются без дополнительных ограничений. - **Пример конфигурации:** ```nginx location /uploads/ { limit_except GET HEAD { deny all; } } ``` - **Минимальный аудит конфигурации:** ```bash 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. - **Пример конфигурации:** ```nginx 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. - **Пример конфигурации:** ```nginx 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 обеспечивает возможность задания, а конкретные значения определяются политикой. - **Минимальный аудит конфигурации:** ```bash 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. 11. **Принудительное использование 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-блоке. - **Пример конфигурации:** ```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; } ``` 12. **Журналирование 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 и др.). - **Пример конфигурации:** ```nginx 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; ``` 13. **Журналирование ошибок** - Требование для ТУ: Веб-сервер должен обеспечивать регистрацию ошибок обработки запросов и ошибок конфигурации. - Механизм 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. - **Пример конфигурации:** ```nginx error_log /var/log/nginx/error.log warn; ``` 14. **Передача журналов во внешнюю систему** - Требование для ТУ: Веб-сервер должен обеспечивать возможность передачи журналов во внешнюю систему журналирования. - Механизм 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`, что обеспечивает централизованный сбор событий во внешней системе журналирования. - **Пример конфигурации:** ```nginx 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; ``` 15. **Ограничение частоты запросов** - Требование для ТУ: Веб-сервер должен обеспечивать возможность ограничения частоты запросов от клиента. - Механизм 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. - **Пример конфигурации:** ```nginx http { limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s; server { location / { limit_req zone=one burst=20 nodelay; } } } ``` 16. **Ограничение количества соединений** - Требование для ТУ: Веб-сервер должен обеспечивать возможность ограничения количества одновременных соединений. - Механизм 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` ограничивает число одновременных соединений по заданному ключу, что соответствует требованию ТУ. - **Пример конфигурации:** ```nginx http { limit_conn_zone $binary_remote_addr zone=addr:10m; server { location / { limit_conn addr 10; } } } ``` 17. **Ограничение размера клиентского запроса** - Требование для ТУ: Веб-сервер должен обеспечивать возможность ограничения размера тела клиентского запроса. - Механизм 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). - **Пример конфигурации:** ```nginx server { client_max_body_size 10m; } ``` 18. **Настройка таймаутов соединений** - Требование для ТУ: Веб-сервер должен обеспечивать возможность настройки таймаутов обработки клиентских соединений. - Механизм 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` позволяют задавать таймауты на разных этапах обработки клиентского соединения. - **Пример конфигурации:** ```nginx http { client_header_timeout 10s; client_body_timeout 10s; send_timeout 10s; keepalive_timeout 30s; } ``` 19. **Сокрытие версии веб-сервера** - Требование для ТУ: Веб-сервер должен обеспечивать возможность отключения раскрытия версии 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. - **Минимальный аудит конфигурации:** ```bash nginx -T 2>/dev/null | grep server_tokens ``` - **Пример конфигурации:** ```nginx http { server_tokens off; } ``` 20. **Управление страницами ошибок** - Требование для ТУ: Веб-сервер должен обеспечивать возможность настройки пользовательских страниц ошибок. - Механизм nginx: error_page - Комментарий: Позволяет не раскрывать технические детали пользователю. - Проверка: - **Статус:** Подтверждено - **Ревью требования:** Формулировка требования согласуется с возможностями nginx. Директива `error_page` перенаправляет обработку указанных кодов ошибок на пользовательские страницы, скрывая технические детали nginx. - **Вывод для ТУ:** Требование может быть включено в ТУ — nginx обеспечивает настройку пользовательских страниц ошибок. - **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html#error_page - **Результат:** Директива `error_page` перенаправляет обработку указанных кодов ошибок на пользовательские страницы, скрывая технические детали nginx. - **Пример конфигурации:** ```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; } ``` 21. **Управление листингом директорий** - Требование для ТУ: Веб-сервер должен обеспечивать возможность отключения листинга директорий. - Механизм nginx: autoindex off - Комментарий: В безопасной конфигурации листинг директорий должен быть отключён, если не требуется. - Проверка: - **Статус:** Подтверждено - **Ревью требования:** Формулировка требования согласуется с возможностями nginx. По умолчанию `autoindex off`. Директива `autoindex off` явно отключает формирование листинга каталога, что соответствует требованию безопасной конфигурации. - **Вывод для ТУ:** Требование может быть включено в ТУ — nginx позволяет отключить листинг директорий. - **Источник:** https://nginx.org/en/docs/http/ngx_http_autoindex_module.html - **Результат:** По умолчанию `autoindex off`. Директива `autoindex off` явно отключает формирование листинга каталога, что соответствует требованию безопасной конфигурации. - **Минимальный аудит конфигурации:** ```bash nginx -T 2>/dev/null | grep autoindex ``` - **Пример конфигурации:** ```nginx server { autoindex off; root /var/www/html; } ``` - **Примечание:** См. `Минимизация поверхности атаки nginx — проверка.md` п. 10; `Проверочные мероприятия для ПМИ — проверка.md` п. 21. 22. **Обратное проксирование 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 может быть недоступен напрямую извне при правильной сетевой архитектуре. - **Пример конфигурации:** ```nginx 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; } ``` 23. **Управление директориями веб-контента** - Требование для ТУ: Веб-сервер должен обеспечивать возможность задания разрешённых директорий веб-контента. - Механизм 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 нет — перечень разрешённых директорий фиксируется в ТУ и реализуется конфигурацией. - **Пример конфигурации:** ```nginx server { root /var/www/app/public; location / { try_files $uri =404; } location ~ /\. { deny all; } } ``` - **Примечание:** В ТУ зафиксировать перечень разрешённых директорий веб-контента. См. `Минимизация поверхности атаки nginx — проверка.md` п. 10; `Проверочные мероприятия для ПМИ — проверка.md` п. 21. 24. **Минимизация поверхности атаки** - Требование для ТУ: Поставка и конфигурация веб-сервера должны обеспечивать возможность минимизации поверхности атаки за счёт исключения, отделения или незагрузки неиспользуемых модулей и функциональных возможностей. - Механизм 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`). Конкретный перечень мер определяется целевой конфигурацией и должен быть зафиксирован в ТУ. - **Пример конфигурации:** ```nginx # Загрузка только утверждённых динамических модулей # load_module modules/ngx_http_geoip_module.so; http { autoindex off; server_tokens off; # Неиспользуемые proxy/fastcgi-направления не включаются } ``` - **Примечание:** В ТУ указать: состав модулей поставки, запрет загрузки неутверждённых `.so`, перечень отключённых возможностей конфигурации. См. `Минимизация поверхности атаки nginx — проверка.md` п. 1–15.