Astra/nginx-analize
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

init

Browse Source
This commit is contained in:
Redsandyg
2026-06-15 06:31:35 +03:00
commit fcc9139361
50 changed files with 5400 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

547
docs/Требования_безопасности_для_включения_в_ТУ_—_проверка.md Normal file
View File

@@ -0,0 +1,547 @@
# Требования безопасности для включения в ТУ — результаты проверки
**Дата проверки:** 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.