Проверочные мероприятия для ПМИ — результаты проверки

Дата проверки: 10.06.2026
Объект проверки: upstream nginx + методика ПМИ
Метод: ревью пригодности мероприятий, подтверждение по документации nginx, примеры конфигурации и команд испытания (без проведения испытаний на стенде)

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

№	Проверяемое требование	Статус	Механизм
1	Ограничение доступа по IP-адресу	Пригодно с оговорками	allow; deny
2	Аутентификация по имени пользователя и паролю	Пригодно для ПМИ	auth_basic; auth_basic_user_file
3	Проверка клиентского TLS-сертификата	Пригодно с оговорками	ssl_verify_client; ssl_client_certificate
4	Авторизация через внешний сервис	Пригодно с оговорками	auth_request
5	Комбинирование проверок доступа	Пригодно для ПМИ	satisfy
6	Разграничение доступа по URL	Пригодно для ПМИ	server; location
7	Ограничение HTTP-методов	Пригодно для ПМИ	limit_except
8	Запрет прямого доступа к внутренним ресурсам	Пригодно для ПМИ	internal
9	Защита соединения TLS	Пригодно с оговорками	listen 443 ssl; ssl_certificate
10	Ограничение версий TLS и шифров	Пригодно для ПМИ	ssl_protocols; ssl_ciphers
11	Принудительное использование HTTPS	Пригодно для ПМИ	return 301/308; HSTS
12	Журналирование HTTP-запросов	Пригодно для ПМИ	access_log; log_format
13	Журналирование ошибок	Пригодно для ПМИ	error_log
14	Передача журналов в syslog	Требует внешних средств	syslog
15	Ограничение частоты запросов	Пригодно для ПМИ	limit_req_zone; limit_req
16	Ограничение количества соединений	Пригодно для ПМИ	limit_conn_zone; limit_conn
17	Ограничение размера запроса	Пригодно для ПМИ	client_max_body_size
18	Настройка таймаутов	Пригодно с оговорками	client_*_timeout; send_timeout
19	Сокрытие версии nginx	Пригодно для ПМИ	server_tokens off
20	Управление страницами ошибок	Пригодно для ПМИ	error_page
21	Отключение листинга директорий	Пригодно для ПМИ	autoindex off
22	Обратное проксирование backend	Пригодно с оговорками	proxy_pass
23	Ограничение директорий веб-контента	Пригодно для ПМИ	root; alias; location
24	Контроль целостности	Требует внешних средств	afick или иной механизм

Проверяемое требование: Ограничение доступа по IP-адресу
- Настройка / механизм: allow; deny
- Действия испытателя: Настроить доступ к ресурсу только с разрешённого IP. Выполнить запрос с разрешённого и запрещённого адреса.
- Ожидаемый результат: С разрешённого адреса доступ предоставлен, с запрещённого адреса доступ запрещён.
- Признак выполнения: Разные HTTP-ответы для разрешённого и запрещённого IP.
- Проверка:
  - Статус: Пригодно с оговорками
  - Ревью мероприятия: Действия, ожидаемый результат и признак выполнения корректны. Для проверки «запрещённого IP» необходим второй хост в другой подсети или изменение IP испытательной машины; подмена IP через заголовок X-Forwarded-For не влияет на $remote_addr без модуля realip.
  - Источник: https://nginx.org/en/docs/http/ngx_http_access_module.html
  - Пример конфигурации:
```
location /admin/ {
    allow 192.168.1.100;
    deny all;
}
```
  - Примеры команд испытания:
```
# С разрешённого хоста (192.168.1.100)
curl -s -o /dev/null -w "%{http_code}" http://nginx-test/admin/

# С запрещённого хоста (другой IP)
curl -s -o /dev/null -w "%{http_code}" http://nginx-test/admin/
```
  - Проверка признака выполнения: С разрешённого IP — код 200 (или иной успешный); с запрещённого — 403 Forbidden.
  - Примечание: Зафиксировать в протоколе IP-адреса испытательных хостов.
Проверяемое требование: Аутентификация по имени пользователя и паролю
- Настройка / механизм: auth_basic; auth_basic_user_file
- Действия испытателя: Настроить защищённый location. Выполнить запрос без учётных данных, с неверными и с корректными учётными данными.
- Ожидаемый результат: Без учётных данных и с неверными данными доступ запрещён, с корректными данными доступ разрешён.
- Признак выполнения: HTTP 401 для отказа и успешный ответ при корректной аутентификации.
- Проверка:
  - Статус: Пригодно для ПМИ
  - Ревью мероприятия: Мероприятие полностью воспроизводимо. Три сценария (без credentials, неверные, верные) покрывают требование. Признак выполнения однозначен.
  - Источник: https://nginx.org/en/docs/http/ngx_http_auth_basic_module.html
  - Пример конфигурации:
```
location /secure/ {
    auth_basic           "Restricted";
    auth_basic_user_file /etc/nginx/htpasswd;
}
```
  - Примеры команд испытания:
```
curl -s -o /dev/null -w "%{http_code}" http://nginx-test/secure/
curl -s -o /dev/null -w "%{http_code}" -u wrong:wrong http://nginx-test/secure/
curl -s -o /dev/null -w "%{http_code}" -u user:password http://nginx-test/secure/
```
  - Проверка признака выполнения: Первые два запроса — 401; третий — 200 (или иной успешный код).
Проверяемое требование: Проверка клиентского TLS-сертификата
- Настройка / механизм: ssl_verify_client; ssl_client_certificate
- Действия испытателя: Настроить проверку клиентского сертификата. Выполнить подключение без сертификата, с недоверенным и с доверенным сертификатом.
- Ожидаемый результат: Доступ разрешён только при предъявлении доверенного клиентского сертификата.
- Признак выполнения: Успешное TLS-подключение только с доверенным сертификатом.
- Проверка:
  - Статус: Пригодно с оговорками
  - Ревью мероприятия: Действия и ожидаемый результат корректны. Требуется подготовка тестовых сертификатов (CA, доверенный клиентский, недоверенный). При ssl_verify_client on подключение без сертификата завершается ошибкой на этапе handshake.
  - Источник: https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_verify_client
  - Пример конфигурации:
```
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;
}
```
  - Примеры команд испытания:
```
# Без клиентского сертификата — ошибка handshake
openssl s_client -connect nginx-test:443 -servername nginx-test </dev/null

# С доверенным сертификатом
openssl s_client -connect nginx-test:443 -cert client.crt -key client.key </dev/null

# С недоверенным (самоподписанным) сертификатом
openssl s_client -connect nginx-test:443 -cert untrusted.crt -key untrusted.key </dev/null
```
  - Проверка признака выполнения: Успешный handshake и HTTP-ответ только при доверенном сертификате; без сертификата или с недоверенным — ошибка TLS (verify return code != 0).
Проверяемое требование: Авторизация через внешний сервис
- Настройка / механизм: auth_request
- Действия испытателя: Настроить внешний сервис авторизации. Проверить доступ при ответах 2xx, 401 и 403 от сервиса авторизации.
- Ожидаемый результат: При 2xx доступ разрешён, при 401/403 доступ запрещён.
- Признак выполнения: Поведение nginx соответствует ответу сервиса авторизации.
- Проверка:
  - Статус: Пригодно с оговорками
  - Ревью мероприятия: Мероприятие корректно. Требуется mock-сервер авторизации с переключаемыми ответами. Необходимо подтвердить наличие модуля auth_request в поставке nginx (nginx -V).
  - Источник: https://nginx.org/en/docs/http/ngx_http_auth_request_module.html
  - Пример конфигурации:
```
location = /auth {
    internal;
    proxy_pass              http://127.0.0.1:9999/validate;
    proxy_pass_request_body off;
    proxy_set_header        Content-Length "";
}

location / {
    auth_request /auth;
    proxy_pass http://backend;
}
```
  - Примеры команд испытания:
```
# Mock возвращает 200 — доступ разрешён
curl -s -o /dev/null -w "%{http_code}" http://nginx-test/

# Переключить mock на 401/403 — повторить запрос
curl -s -o /dev/null -w "%{http_code}" http://nginx-test/
```
  - Проверка признака выполнения: При ответе auth-сервиса 2xx — успешный код от nginx; при 401 — 401; при 403 — 403.
Проверяемое требование: Комбинирование проверок доступа
- Настройка / механизм: satisfy
- Действия испытателя: Настроить совместное применение IP-ограничения и Basic Authentication. Проверить сценарии прохождения одной или нескольких проверок.
- Ожидаемый результат: Доступ предоставляется в соответствии с выбранным режимом satisfy all/any.
- Признак выполнения: Фактический доступ соответствует заданной политике.
- Проверка:
  - Статус: Пригодно для ПМИ
  - Ревью мероприятия: Мероприятие корректно. Рекомендуется в протоколе явно фиксировать значение satisfy (all/any) и матрицу сценариев: IP+пароль, только IP, только пароль, ни то ни другое.
  - Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html#satisfy
  - Пример конфигурации:
```
location /admin/ {
    satisfy all;
    allow 10.0.0.0/8;
    deny all;
    auth_basic           "Admin";
    auth_basic_user_file /etc/nginx/htpasswd;
}
```
  - Примеры команд испытания:
```
# IP из allow + верный пароль
curl -u user:password http://nginx-test/admin/

# IP из allow + без пароля
curl http://nginx-test/admin/

# IP вне allow + верный пароль (при satisfy all — отказ)
curl -u user:password http://nginx-test/admin/
```
  - Проверка признака выполнения: Сверить фактические коды ответов с матрицей для выбранного satisfy all или satisfy any.
Проверяемое требование: Разграничение доступа по URL
- Настройка / механизм: server; location
- Действия испытателя: Настроить разные правила доступа для публичного и защищённого location. Выполнить запросы к обоим разделам.
- Ожидаемый результат: Публичный раздел доступен, защищённый раздел доступен только при выполнении условий доступа.
- Признак выполнения: Разные правила доступа применяются к разным URL.
- Проверка:
  - Статус: Пригодно для ПМИ
  - Ревью мероприятия: Мероприятие корректно и воспроизводимо. Достаточно двух location с разными правилами.
  - Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html#location
  - Пример конфигурации:
```
location /public/ {
    root /var/www/html;
}

location /admin/ {
    allow 10.0.0.0/8;
    deny all;
    root /var/www/html;
}
```
  - Примеры команд испытания:
```
curl -s -o /dev/null -w "%{http_code}" http://nginx-test/public/index.html
curl -s -o /dev/null -w "%{http_code}" http://nginx-test/admin/
```
  - Проверка признака выполнения: /public/ — 200; /admin/ — 403 с неразрешённого IP или 200 с разрешённого.
Проверяемое требование: Ограничение HTTP-методов
- Настройка / механизм: limit_except
- Действия испытателя: Настроить ограничение методов. Выполнить запросы методами GET, POST, PUT, DELETE.
- Ожидаемый результат: Разрешённые методы обрабатываются, запрещённые методы блокируются.
- Признак выполнения: Запрещённые методы возвращают отказ.
- Проверка:
  - Статус: Пригодно для ПМИ
  - Ревью мероприятия: Мероприятие корректно. В протоколе указать, какие методы разрешены в limit_except.
  - Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html#limit_except
  - Пример конфигурации:
```
location /api/ {
    limit_except GET POST {
        deny all;
    }
    proxy_pass http://backend;
}
```
  - Примеры команд испытания:
```
curl -s -o /dev/null -w "%{http_code}" -X GET  http://nginx-test/api/
curl -s -o /dev/null -w "%{http_code}" -X POST http://nginx-test/api/
curl -s -o /dev/null -w "%{http_code}" -X PUT  http://nginx-test/api/
curl -s -o /dev/null -w "%{http_code}" -X DELETE http://nginx-test/api/
```
  - Проверка признака выполнения: GET и POST — успешные коды; PUT и DELETE — 403.
Проверяемое требование: Запрет прямого доступа к внутренним ресурсам
- Настройка / механизм: internal
- Действия испытателя: Настроить internal location. Выполнить прямой запрос к нему и внутреннее перенаправление.
- Ожидаемый результат: Прямой запрос запрещён, внутреннее перенаправление работает.
- Признак выполнения: Прямой доступ получает отказ, внутренний сценарий успешен.
- Проверка:
  - Статус: Пригодно для ПМИ
  - Ревью мероприятия: Мероприятие корректно. Прямой запрос к internal location возвращает 404 (не 403) — это штатное поведение nginx; признак выполнения следует трактовать как «отказ в доступе» (404).
  - Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html#internal
  - Пример конфигурации:
```
location /protected/ {
    internal;
    alias /var/data/files/;
}

location /download {
    rewrite ^ /protected/document.pdf last;
}
```
  - Примеры команд испытания:
```
# Прямой запрос — отказ
curl -s -o /dev/null -w "%{http_code}" http://nginx-test/protected/document.pdf

# Внутреннее перенаправление — успех
curl -s -o /dev/null -w "%{http_code}" http://nginx-test/download
```
  - Проверка признака выполнения: Прямой запрос — 404; через /download — 200 и содержимое файла.
Проверяемое требование: Защита соединения TLS
- Настройка / механизм: listen 443 ssl; ssl_certificate; ssl_certificate_key
- Действия испытателя: Настроить HTTPS-сервер. Выполнить подключение по HTTPS.
- Ожидаемый результат: Соединение устанавливается по TLS.
- Признак выполнения: Клиент видит действующее TLS-соединение.
- Проверка:
  - Статус: Пригодно с оговорками
  - Ревью мероприятия: Мероприятие корректно. Требуются тестовые сертификаты. Для самоподписанных сертификатов в командах нужен флаг -k/--insecure.
  - Источник: https://nginx.org/en/docs/http/ngx_http_ssl_module.html
  - Пример конфигурации:
```
server {
    listen 443 ssl;
    server_name nginx-test;
    ssl_certificate     /etc/nginx/ssl/server.crt;
    ssl_certificate_key /etc/nginx/ssl/server.key;
}
```
  - Примеры команд испытания:
```
curl -vk https://nginx-test/
openssl s_client -connect nginx-test:443 -servername nginx-test </dev/null
```
  - Проверка признака выполнения: В выводе openssl s_client — строка Verify return code: 0 (или успешный handshake); curl завершается без ошибки SSL.
Проверяемое требование: Ограничение версий TLS и шифров
- Настройка / механизм: ssl_protocols; ssl_ciphers
- Действия испытателя: Настроить допустимые версии TLS и шифры. Выполнить подключение с разрешёнными и запрещёнными версиями/шифрами.
- Ожидаемый результат: Разрешённые параметры работают, запрещённые отклоняются.
- Признак выполнения: Результат подключения соответствует политике TLS.
- Проверка:
  - Статус: Пригодно для ПМИ
  - Ревью мероприятия: Мероприятие корректно. Рекомендуется зафиксировать в ТУ/ПМИ конкретную политику (например, только TLSv1.2 и TLSv1.3).
  - Источник: https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols
  - Пример конфигурации:
```
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
```
  - Примеры команд испытания:
```
# Разрешённая версия
openssl s_client -connect nginx-test:443 -tls1_2 </dev/null

# Запрещённая версия (если в политике только TLSv1.2+)
openssl s_client -connect nginx-test:443 -tls1_1 </dev/null
```
  - Проверка признака выполнения: TLSv1.2 — успешный handshake; TLSv1.1 — ошибка handshake (alert protocol version).
Проверяемое требование: Принудительное использование HTTPS
- Настройка / механизм: return 301/308; Strict-Transport-Security
- Действия испытателя: Выполнить HTTP-запрос к ресурсу. Проверить перенаправление и наличие HSTS-заголовка, если он настроен.
- Ожидаемый результат: HTTP-запрос перенаправляется на HTTPS.
- Признак выполнения: В ответе присутствует redirect на HTTPS и/или HSTS.
- Проверка:
  - Статус: Пригодно для ПМИ
  - Ревью мероприятия: Мероприятие корректно. HSTS проверяется только на HTTPS-ответе, не на HTTP-редиректе.
  - Источник: https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#return
  - Пример конфигурации:
```
server {
    listen 80;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    add_header Strict-Transport-Security "max-age=31536000" always;
}
```
  - Примеры команд испытания:
```
curl -I http://nginx-test/
curl -I https://nginx-test/
```
  - Проверка признака выполнения: HTTP — 301 и заголовок Location: https://...; HTTPS — заголовок Strict-Transport-Security.
Проверяемое требование: Журналирование HTTP-запросов
- Настройка / механизм: access_log; log_format
- Действия испытателя: Выполнить несколько HTTP-запросов. Проверить появление записей в access log.
- Ожидаемый результат: Запросы зарегистрированы в журнале.
- Признак выполнения: В журнале присутствуют записи с требуемыми полями.
- Проверка:
  - Статус: Пригодно для ПМИ
  - Ревью мероприятия: Мероприятие корректно. В ПМИ зафиксировать перечень обязательных полей журнала (IP, время, метод, URI, статус).
  - Источник: https://nginx.org/en/docs/http/ngx_http_log_module.html
  - Пример конфигурации:
```
log_format pmi '$remote_addr - [$time_local] "$request" $status';
access_log /var/log/nginx/access.log pmi;
```
  - Примеры команд испытания:
```
curl http://nginx-test/test-page
curl http://nginx-test/another-page
tail -n 5 /var/log/nginx/access.log
```
  - Проверка признака выполнения: В журнале две новые записи с IP клиента, URI /test-page и /another-page, кодами ответа.
Проверяемое требование: Журналирование ошибок
- Настройка / механизм: error_log
- Действия испытателя: Сформировать ошибочную ситуацию, которая гарантированно фиксируется в error log: ошибка доступа к файлу, ошибка взаимодействия с backend, некорректный upstream или иная ошибка обработки. Проверить наличие записи в error log.
- Ожидаемый результат: Ошибка зарегистрирована в журнале ошибок.
- Признак выполнения: В error log появилась запись о событии.
- Проверка:
  - Статус: Пригодно для ПМИ
  - Ревью мероприятия: Мероприятие корректно. Простейший воспроизводимый сценарий — proxy_pass на недоступный upstream (connection refused).
  - Источник: https://nginx.org/en/docs/ngx_core_module.html#error_log
  - Пример конфигурации:
```
error_log /var/log/nginx/error.log warn;

location /broken/ {
    proxy_pass http://127.0.0.1:59999;
}
```
  - Примеры команд испытания:
```
curl http://nginx-test/broken/
tail -n 10 /var/log/nginx/error.log
```
  - Проверка признака выполнения: В error log — запись об ошибке подключения к upstream (connect() failed).
Проверяемое требование: Передача журналов в syslog
- Настройка / механизм: access_log syslog:...; error_log syslog:...
- Действия испытателя: Настроить вывод журналов в syslog. Выполнить запросы и проверить внешнюю систему журналирования.
- Ожидаемый результат: События передаются во внешнюю систему журналирования.
- Признак выполнения: Записи обнаружены в syslog/централизованном журнале.
- Проверка:
  - Статус: Требует внешних средств
  - Ревью мероприятия: Мероприятие корректно, но зависит от rsyslog/journald или централизованного SIEM. nginx только отправляет в syslog; приёмник — внешний компонент стенда.
  - Источник: https://nginx.org/en/docs/syslog.html
  - Пример конфигурации:
```
error_log syslog:server=127.0.0.1:514,facility=local7,tag=nginx,severity=error;
access_log syslog:server=127.0.0.1:514,facility=local7,tag=nginx,severity=info combined;
```
  - Примеры команд испытания:
```
curl http://nginx-test/
# На приёмнике syslog (Linux)
journalctl -t nginx --since "1 min ago"
# или
tail -f /var/log/syslog | grep nginx
```
  - Проверка признака выполнения: Запись с тегом nginx и данными HTTP-запроса в syslog/journal.
  - Примечание: Статус отражает внешнюю меру. См. Контроль целостности хранимого кода и конфигурации — проверка.md п. 13; Минимально необходимые полномочия nginx — проверка.md п. 5; функции 4.4 в функции безопасности — проверка.md.
Проверяемое требование: Ограничение частоты запросов
- Настройка / механизм: limit_req_zone; limit_req
- Действия испытателя: Настроить лимит запросов. Выполнить серию запросов с превышением лимита.
- Ожидаемый результат: Избыточные запросы ограничиваются или отклоняются.
- Признак выполнения: При превышении лимита сервер возвращает отказ/задержку согласно настройке.
- Проверка:
  - Статус: Пригодно для ПМИ
  - Ревью мероприятия: Мероприятие корректно. По умолчанию nginx возвращает 503 при превышении limit_req (без limit_req_status).
  - Источник: https://nginx.org/en/docs/http/ngx_http_limit_req_module.html
  - Пример конфигурации:
```
limit_req_zone $binary_remote_addr zone=one:10m rate=2r/s;

location / {
    limit_req zone=one burst=5 nodelay;
}
```
  - Примеры команд испытания:
```
for i in $(seq 1 20); do
  curl -s -o /dev/null -w "%{http_code}\n" http://nginx-test/
done
```
  - Проверка признака выполнения: Первые запросы — 200; при превышении лимита — 503 (или задержка при отсутствии nodelay).
Проверяемое требование: Ограничение количества соединений
- Настройка / механизм: limit_conn_zone; limit_conn
- Действия испытателя: Настроить лимит соединений. Открыть число соединений выше допустимого.
- Ожидаемый результат: Лишние соединения отклоняются.
- Признак выполнения: При превышении лимита сервер возвращает отказ.
- Проверка:
  - Статус: Пригодно для ПМИ
  - Ревью мероприятия: Мероприятие корректно. Для воспроизведения удобен ab или параллельные curl с длительным запросом (sleep на backend).
  - Источник: https://nginx.org/en/docs/http/ngx_http_limit_conn_module.html
  - Пример конфигурации:
```
limit_conn_zone $binary_remote_addr zone=addr:10m;

location / {
    limit_conn addr 2;
}
```
  - Примеры команд испытания:
```
for i in $(seq 1 5); do
  curl -s http://nginx-test/slow &
done
wait
```
  - Проверка признака выполнения: Часть запросов получает 503 (limit_conn_status по умолчанию).
Проверяемое требование: Ограничение размера запроса
- Настройка / механизм: client_max_body_size
- Действия испытателя: Настроить максимальный размер тела запроса. Отправить запрос меньше и больше лимита.
- Ожидаемый результат: Запрос меньше лимита принимается, больше лимита отклоняется.
- Признак выполнения: Большой запрос получает ошибку ограничения размера.
- Проверка:
  - Статус: Пригодно для ПМИ
  - Ревью мероприятия: Мероприятие корректно и полностью воспроизводимо.
  - Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size
  - Пример конфигурации:
```
client_max_body_size 1m;
```
  - Примеры команд испытания:
```
# Меньше лимита
dd if=/dev/zero bs=1024 count=100 2>/dev/null | curl -s -o /dev/null -w "%{http_code}" -X POST -d @- http://nginx-test/upload

# Больше лимита
dd if=/dev/zero bs=1M count=2 2>/dev/null | curl -s -o /dev/null -w "%{http_code}" -X POST -d @- http://nginx-test/upload
```
  - Проверка признака выполнения: Малый запрос — 200/204; большой — 413 Request Entity Too Large.
Проверяемое требование: Настройка таймаутов
- Настройка / механизм: client_header_timeout; client_body_timeout; send_timeout; keepalive_timeout
- Действия испытателя: Настроить таймауты. Смоделировать медленную отправку заголовков/тела запроса.
- Ожидаемый результат: Медленные соединения закрываются по таймауту.
- Признак выполнения: Соединение разрывается после заданного времени.
- Проверка:
  - Статус: Пригодно с оговорками
  - Ревью мероприятия: Мероприятие корректно по смыслу, но воспроизведение медленной отправки заголовков требует специальных инструментов (nc, скрипт на Python) или модулей; curl --limit-rate подходит для тела запроса (client_body_timeout).
  - Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_timeout
  - Пример конфигурации:
```
client_header_timeout 5s;
client_body_timeout   5s;
```
  - Примеры команд испытания:
```
# Медленная отправка тела (превышение client_body_timeout)
dd if=/dev/zero bs=1K count=1000 2>/dev/null | curl --limit-rate 1K -m 30 -X POST -d @- http://nginx-test/upload
```
  - Проверка признака выполнения: curl завершается с ошибкой (timeout/connection reset) примерно через заданный client_body_timeout.
Проверяемое требование: Сокрытие версии nginx
- Настройка / механизм: server_tokens off
- Действия испытателя: Выполнить запрос и проверить заголовки/страницы ошибок.
- Ожидаемый результат: Версия nginx не раскрывается в ответах.
- Признак выполнения: В ответе отсутствует номер версии nginx.
- Проверка:
  - Статус: Пригодно для ПМИ
  - Ревью мероприятия: Мероприятие корректно. server_tokens off убирает версию, но заголовок Server: nginx остаётся — это соответствует документации.
  - Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html#server_tokens
  - Пример конфигурации:
```
http {
    server_tokens off;
}
```
  - Примеры команд испытания:
```
curl -I http://nginx-test/
curl http://nginx-test/nonexistent-page
```
  - Проверка признака выполнения: Заголовок Server: nginx без номера версии (не nginx/1.24.0); в теле ошибки 404 нет номера версии.
Проверяемое требование: Управление страницами ошибок
- Настройка / механизм: error_page
- Действия испытателя: Настроить пользовательскую страницу ошибки. Вызвать ошибку 404/403/500.
- Ожидаемый результат: Отображается настроенная страница ошибки без раскрытия лишних деталей.
- Признак выполнения: Пользователь видит заданную страницу ошибки.
- Проверка:
  - Статус: Пригодно для ПМИ
  - Ревью мероприятия: Мероприятие корректно и воспроизводимо.
  - Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html#error_page
  - Пример конфигурации:
```
error_page 404 /custom_404.html;

location = /custom_404.html {
    root /var/www/errors;
    internal;
}
```
  - Примеры команд испытания:
```
curl http://nginx-test/nonexistent-page
```
  - Проверка признака выполнения: Тело ответа содержит текст/разметку из /var/www/errors/custom_404.html, а не стандартную страницу nginx.
Проверяемое требование: Отключение листинга директорий
- Настройка / механизм: autoindex off
- Действия испытателя: Обратиться к директории без индексного файла.
- Ожидаемый результат: Листинг директории не отображается.
- Признак выполнения: Сервер возвращает отказ или штатную ошибку, но не список файлов.
- Проверка:
  - Статус: Пригодно для ПМИ
  - Ревью мероприятия: Мероприятие корректно. autoindex off — значение по умолчанию; при отсутствии index.html ожидается 403.
  - Источник: https://nginx.org/en/docs/http/ngx_http_autoindex_module.html
  - Пример конфигурации:
```
location /files/ {
    autoindex off;
    root /var/www/html;
}
```
  - Примеры команд испытания:
```
curl http://nginx-test/files/
```
  - Проверка признака выполнения: Ответ 403 Forbidden (или 404), в теле нет HTML-листинга с перечнем файлов.
Проверяемое требование: Обратное проксирование backend
- Настройка / механизм: proxy_pass
- Действия испытателя: Настроить proxy_pass на backend. Если архитектурой предусмотрена изоляция backend-сервиса, проверить, что пользовательский доступ к backend выполняется через nginx, а прямой доступ к backend ограничен сетевыми правилами/настройками инфраструктуры.
- Ожидаемый результат: Запрос проходит через nginx; прямой доступ к backend ограничен, если это предусмотрено архитектурой.
- Признак выполнения: Backend обслуживается через nginx согласно настройке.
- Проверка:
  - Статус: Пригодно с оговорками
  - Ревью мероприятия: Проверка proxy_pass через nginx — корректна. Проверка сетевой изоляции backend — отдельное инфраструктурное мероприятие (firewall, bind только на 127.0.0.1); в протоколе разделить результаты.
  - Источник: https://nginx.org/en/docs/http/ngx_http_proxy_module.html
  - Пример конфигурации:
```
location /api/ {
    proxy_pass http://127.0.0.1:8080/;
}
```
  - Примеры команд испытания:
```
# Через nginx — успех
curl http://nginx-test/api/status

# Прямой доступ к backend (с испытательной машины, если backend на 127.0.0.1 — недоступен)
curl http://127.0.0.1:8080/status
```
  - Проверка признака выполнения: Запрос через nginx возвращает ответ backend; прямой доступ с внешней сети к порту 8080 — отказ (если изоляция настроена).
Проверяемое требование: Ограничение директорий веб-контента
- Настройка / механизм: root; alias; location; try_files
- Действия испытателя: Настроить разрешённую директорию веб-контента. Выполнить запрос к файлу внутри и вне разрешённой директории.
- Ожидаемый результат: Файлы внутри разрешённой директории доступны, вне директории не обслуживаются.
- Признак выполнения: Доступ к произвольным каталогам ОС отсутствует.
- Проверка:
  - Статус: Пригодно для ПМИ
  - Ревью мероприятия: Мероприятие корректно. Для «вне директории» использовать path traversal (/../etc/passwd) или запрос к URI вне root.
  - Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html#root
  - Пример конфигурации:
```
server {
    root /var/www/app/public;

    location / {
        try_files $uri =404;
    }
}
```
  - Примеры команд испытания:
```
# Файл внутри root
curl -s -o /dev/null -w "%{http_code}" http://nginx-test/index.html

# Попытка path traversal
curl -s -o /dev/null -w "%{http_code}" http://nginx-test/../../../etc/passwd
```
  - Проверка признака выполнения: Легитимный файл — 200; traversal — 404 (содержимое /etc/passwd не отдаётся).
Проверяемое требование: Контроль целостности
- Настройка / механизм: afick или иной механизм
- Действия испытателя: Настроить контроль целостности для конфигурации, web-root и модулей. Изменить контролируемый файл.
- Ожидаемый результат: Изменение обнаруживается механизмом контроля целостности.
- Признак выполнения: Средство контроля фиксирует нарушение целостности.
- Проверка:
  - Статус: Требует внешних средств
  - Ревью мероприятия: Мероприятие корректно. nginx не выполняет FIM; испытание относится к внешнему средству (afick, AIDE). В протоколе указать версию и конфигурацию FIM.
  - Источник: https://nginx.org/en/docs/ (функция FIM в nginx не описана)
  - Пример конфигурации внешнего средства (afick):
```
# /etc/afick.conf (фрагмент)
/etc/nginx/               R
/var/www/                 R
/usr/lib/nginx/modules/   R
```
  - Примеры команд испытания:
```
# Базовая проверка (без изменений)
afick -c /etc/afick.conf --check

# Изменить контролируемый файл
echo "# test change" >> /etc/nginx/nginx.conf

# Повторная проверка
afick -c /etc/afick.conf --check
```
  - Проверка признака выполнения: Отчёт afick содержит запись об изменении /etc/nginx/nginx.conf. После испытания восстановить файл из эталона.
  - Примечание: Не относится к функциям nginx; включается в ПМИ как проектное/инфраструктурное мероприятие. Статус отражает внешнюю меру. См. Контроль целостности хранимого кода и конфигурации — проверка.md (весь документ); функции 9.3 в функции безопасности — проверка.md; Контроль выполнения кода — проверка.md п. 15–16.

49 KiB Raw Permalink Blame History Unescape Escape

Проверочные мероприятия для ПМИ — результаты проверки

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

49 KiB

Raw Permalink Blame History