Контроль выполнения кода nginx — результаты проверки

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

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

№	Механизм	Статус	Тип контроля
1	FastCGI / PHP-FPM	Реализуемо	Конфигурация nginx
2	uWSGI	Реализуемо	Конфигурация nginx
3	SCGI	Реализуемо	Конфигурация nginx
4	HTTP reverse proxy	Реализуемо	Конфигурация nginx
5	gRPC backend	Реализуемо с оговорками	Конфигурация nginx
6	njs	Реализуемо с оговорками	Конфигурация + FIM
7	Perl module	Реализуемо с оговорками	Организационный запрет / FIM
8	SSI	Реализуемо	Конфигурация nginx
9	XSLT	Реализуемо с оговорками	Конфигурация + FIM
10	Динамические модули nginx	Реализуемо	Конфигурация + FIM
11	Сторонние динамические модули	Реализуемо с оговорками	Организационный белый список + FIM
12	WebDAV	Реализуемо	Конфигурация nginx
13	Внутренние перенаправления	Реализуемо	Конфигурация nginx
14	root / alias	Реализуемо	Конфигурация + права ФС
15	Конфигурация nginx	Требует внешних/организационных мер	FIM + права доступа
16	Файлы веб-приложений	Требует внешних/организационных мер	FIM

Механизм: FastCGI / PHP-FPM
- Риск: Передача в обработку файла из неразрешённого каталога ОС.
- Требование / решение: Разрешить передачу файлов во внешний обработчик только из утверждённых директорий веб-приложений.
- Что контролировать: location; root; alias; try_files; fastcgi_param SCRIPT_FILENAME.
- Проверка:
  - Статус: Реализуемо
  - Ревью меры контроля: Требование адекватно риску path traversal и произвольного SCRIPT_FILENAME. Перечень «Что контролировать» полный. Ключевой контроль — привязка location ~ \.php$ к фиксированному root и безопасное значение SCRIPT_FILENAME.
  - Источник: https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html
  - Пример реализации контроля:
```
server {
    root /var/www/app/public;

    location / {
        try_files $uri =404;
    }

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_pass   unix:/run/php/php-fpm.sock;
        include        fastcgi_params;
        fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}
```
  - Проверка эффективности контроля:
```
nginx -T 2>/dev/null | grep -E 'SCRIPT_FILENAME|fastcgi_pass|root|alias'
# Убедиться: SCRIPT_FILENAME = $document_root$fastcgi_script_name
# Нет fastcgi_param SCRIPT_FILENAME с пользовательскими переменными
# root указывает только на утверждённый каталог
```
  - Примечание: Зафиксировать перечень разрешённых директорий в эксплуатационной документации. См. классификацию п. 2 в Выполнение кода — проверка.md.
Механизм: uWSGI
- Риск: Передача запроса в приложение, выполняющее код вне контроля nginx.
- Требование: Разрешить маршрутизацию только к утверждённым uWSGI-приложениям.
- Что контролировать: uwsgi_pass; upstream; конфигурация backend.
- Проверка:
  - Статус: Реализуемо
  - Ревью меры контроля: Требование корректно: nginx не исполняет код, но направляет запросы. Контроль — фиксированный upstream с явным списком сокетов/адресов, без произвольных uwsgi_pass на внешние хосты.
  - Источник: https://nginx.org/en/docs/http/ngx_http_uwsgi_module.html
  - Пример реализации контроля:
```
upstream approved_uwsgi {
    server unix:/run/uwsgi/app.sock;
}

location / {
    uwsgi_pass approved_uwsgi;
    include    uwsgi_params;
}
```
  - Проверка эффективности контроля:
```
nginx -T 2>/dev/null | grep -E 'uwsgi_pass|upstream'
# Все uwsgi_pass ссылаются на утверждённый upstream
# Нет uwsgi_pass на произвольные IP/порты вне списка
```
  - Примечание: См. классификацию п. 3 в Выполнение кода — проверка.md.
Механизм: SCGI
- Риск: Передача запроса во внешний обработчик, выполняющий код приложения.
- Требование: Разрешить маршрутизацию только к утверждённым SCGI-приложениям.
- Что контролировать: scgi_pass; upstream; конфигурация backend.
- Проверка:
  - Статус: Реализуемо
  - Ревью меры контроля: Аналогично uWSGI. Мера достаточна при фиксированном upstream и документированном перечне SCGI-приложений.
  - Источник: https://nginx.org/en/docs/http/ngx_http_scgi_module.html
  - Пример реализации контроля:
```
upstream approved_scgi {
    server 127.0.0.1:4000;
}

location / {
    scgi_pass approved_scgi;
    include   scgi_params;
}
```
  - Проверка эффективности контроля:
```
nginx -T 2>/dev/null | grep -E 'scgi_pass|upstream'
```
  - Примечание: См. классификацию п. 4 в Выполнение кода — проверка.md.
Механизм: HTTP reverse proxy
- Риск: Передача запроса во внешний backend, где выполняется код приложения.
- Требование: Разрешить proxy_pass только к утверждённым backend-сервисам.
- Что контролировать: proxy_pass; upstream; proxy_set_header.
- Проверка:
  - Статус: Реализуемо
  - Ревью меры контроля: Требование адекватно. Контроль через именованный upstream с фиксированными backend; запрет proxy_pass http://$variable (динамический backend). Сетевая изоляция backend — дополнительная мера на уровне firewall.
  - Источник: https://nginx.org/en/docs/http/ngx_http_proxy_module.html
  - Пример реализации контроля:
```
upstream approved_backend {
    server 127.0.0.1:8080;
    keepalive 32;
}

location /api/ {
    proxy_pass http://approved_backend;
    proxy_set_header Host $host;
}
```
  - Проверка эффективности контроля:
```
nginx -T 2>/dev/null | grep -E 'proxy_pass|upstream'
# Нет proxy_pass с переменными или на неутверждённые адреса
```
  - Примечание: См. классификацию п. 5 в Выполнение кода — проверка.md.
Механизм: gRPC backend
- Риск: Передача запроса во внешний gRPC-сервис, где выполняется код.
- Требование: Разрешить grpc_pass только к утверждённым gRPC-сервисам.
- Что контролировать: grpc_pass; upstream; TLS-настройки при необходимости.
- Проверка:
  - Статус: Реализуемо с оговорками
  - Ревью меры контроля: Требование корректно. Дополнительно контролировать TLS для gRPC (HTTP/2). Перечень «Что контролировать» полный.
  - Источник: https://nginx.org/en/docs/http/ngx_http_grpc_module.html
  - Пример реализации контроля:
```
upstream approved_grpc {
    server 127.0.0.1:50051;
}

location /grpc.service/ {
    grpc_pass grpc://approved_grpc;
}
```
  - Проверка эффективности контроля:
```
nginx -T 2>/dev/null | grep -E 'grpc_pass|upstream'
```
  - Примечание: См. классификацию п. 6 в Выполнение кода — проверка.md.
Механизм: njs
- Риск: Выполнение JavaScript-логики внутри процесса nginx.
- Требование: Разрешить использование njs только из утверждённых файлов/модулей, если njs применяется.
- Что контролировать: js_import; js_content; js_set; файлы JavaScript.
- Проверка:
  - Статус: Реализуемо с оговорками
  - Ревью меры контроля: Требование адекватно. Рекомендуется по умолчанию не использовать njs; при необходимости — белый список JS-файлов и FIM на /etc/nginx/njs/. Перечень контролируемых объектов полный.
  - Источник: https://nginx.org/en/docs/njs/
  - Пример реализации контроля:
```
# Только утверждённые модули и файлы
load_module modules/ngx_http_js_module.so;

http {
    js_import main from /etc/nginx/njs/main.js;

    location /njs-handler {
        js_content main.handler;
    }
}
```
  - Проверка эффективности контроля:
```
nginx -T 2>/dev/null | grep -E 'js_import|js_content|js_set|load_module.*js'
ls -la /etc/nginx/njs/
# Сверить перечень JS-файлов с утверждённым списком
```
  - Примечание: JS-файлы включить в контроль целостности (afick). См. условное отключение в Минимизация поверхности атаки nginx — проверка.md п. 6 (njs). См. классификацию п. 7 в Выполнение кода — проверка.md.
Механизм: Perl module
- Риск: Выполнение Perl-логики внутри процесса nginx.
- Требование: Разрешить использование Perl-модуля только при наличии обоснованной необходимости.
- Что контролировать: perl; perl_set; perl_require; Perl-файлы.
- Проверка:
  - Статус: Реализуемо с оговорками
  - Ревью меры контроля: Требование корректно — предпочтительно не включать Perl-модуль. Если включён — обоснование в документации, FIM на Perl-файлы, аудит директив perl/perl_require.
  - Источник: https://nginx.org/en/docs/http/ngx_http_perl_module.html
  - Пример реализации контроля:
```
# Рекомендация: не включать Perl-модуль в сборку/конфигурацию
# Если необходим — только утверждённые файлы:
# perl_modules /etc/nginx/perl;
# perl_require approved.pm;
```
  - Проверка эффективности контроля:
```
nginx -V 2>&1 | grep -i perl
nginx -T 2>/dev/null | grep -E 'perl|perl_require|perl_set'
# Ожидание для безопасной конфигурации: отсутствие директив perl
```
  - Примечание: См. условное отключение в Минимизация поверхности атаки nginx — проверка.md п. 7 (Perl). См. классификацию п. 8 в Выполнение кода — проверка.md.
Механизм: SSI
- Риск: Обработка SSI-команд в ответах может изменить формируемый контент.
- Требование: Разрешить SSI только для утверждённых ресурсов или отключить, если не требуется.
- Что контролировать: ssi; SSI-файлы; location, где включён SSI.
- Проверка:
  - Статус: Реализуемо
  - Ревью меры контроля: Требование адекватно. Дополнительно: запретить  в SSI-файлах (выполнение shell-команд). По умолчанию ssi off.
  - Источник: https://nginx.org/en/docs/http/ngx_http_ssi_module.html
  - Пример реализации контроля:
```
http {
    ssi off;  # по умолчанию отключено
}

location /ssi-approved/ {
    ssi on;
    root /var/www/html;
}
```
  - Проверка эффективности контроля:
```
nginx -T 2>/dev/null | grep -i ssi
grep -r '#exec' /var/www/html/ 2>/dev/null
# ssi on только в утверждённых location; нет exec в SSI-файлах
```
  - Примечание: См. условное отключение в Минимизация поверхности атаки nginx — проверка.md п. 9 (SSI). См. классификацию п. 9 в Выполнение кода — проверка.md.
Механизм: XSLT
- Риск: Выполнение логики преобразования XML с использованием XSLT-стилей.
- Требование: Разрешить XSLT-преобразования только с утверждёнными XSLT-файлами, если функция используется.
- Что контролировать: xslt_stylesheet; XSLT-файлы.
- Проверка:
  - Статус: Реализуемо с оговорками
  - Ревью меры контроля: Требование корректно. XSLT-файлы — объекты FIM. Рекомендуется не использовать модуль, если не требуется.
  - Источник: https://nginx.org/en/docs/http/ngx_http_xslt_module.html
  - Пример реализации контроля:
```
location /api/xml {
    proxy_pass http://backend;
    xslt_stylesheet /etc/nginx/xslt/approved-transform.xslt;
}
```
  - Проверка эффективности контроля:
```
nginx -T 2>/dev/null | grep xslt_stylesheet
ls -la /etc/nginx/xslt/
# Все XSLT-файлы в утверждённом перечне
```
  - Примечание: См. условное отключение в Минимизация поверхности атаки nginx — проверка.md п. 8 (XSLT). См. классификацию п. 10 в Выполнение кода — проверка.md.
Механизм: Динамические модули nginx
- Риск: Загрузка неразрешённого .so-модуля, выполняемого в процессе nginx.
- Требование: Разрешить загрузку только модулей из утверждённого перечня.
- Что контролировать: load_module; директории модулей; .so-файлы.
- Проверка:
  - Статус: Реализуемо
  - Ревью меры контроля: Требование полностью адекватно риску. Организационный белый список load_module + FIM на каталог модулей.
  - Источник: https://nginx.org/en/docs/ngx_core_module.html#load_module
  - Пример реализации контроля:
```
# В nginx.conf — только утверждённые модули
load_module modules/ngx_http_geoip_module.so;
# load_module /path/to/unapproved.so;  # запрещено
```
  - Проверка эффективности контроля:
```
nginx -T 2>/dev/null | grep load_module
ls -la /usr/lib/nginx/modules/
# Сверить с утверждённым перечнем в эксплуатационной документации
afick -c /etc/afick.conf --check
```
- Примечание: См. условное отключение в Минимизация поверхности атаки nginx — проверка.md п. 3 (динамические модули). См. классификацию п. 11 в Выполнение кода — проверка.md.
Механизм: Сторонние динамические модули
- Риск: Подключение стороннего кода без контроля поставки и целостности.
- Требование: Запретить сторонние модули либо допускать только после включения в утверждённый список.
- Что контролировать: load_module; пакет модуля; путь к .so.
- Проверка:
  - Статус: Реализуемо с оговорками
  - Ревью меры контроля: Требование корректно. Сочетание организационного запрета, процедуры включения в белый список, контроля пакета (подпись, репозиторий) и FIM на .so.
  - Источник: https://nginx.org/en/docs/ngx_core_module.html#load_module
  - Пример реализации контроля:
```
# Политика: только модули из дистрибутивного пакета nginx
# load_module modules/ngx_http_js_module.so;  # только после утверждения
```
  - Проверка эффективности контроля:
```
nginx -T 2>/dev/null | grep load_module
rpm -V nginx 2>/dev/null || dpkg -V nginx 2>/dev/null
# Проверка целостности пакета и отсутствия посторонних .so
find /usr/lib/nginx/modules/ -name '*.so' -newer /etc/nginx/nginx.conf
```
  - Примечание: Процедура утверждения сторонних модулей — организационная мера. См. условное отключение в Минимизация поверхности атаки nginx — проверка.md п. 7 (Perl). См. условное отключение в Минимизация поверхности атаки nginx — проверка.md п. 9 (SSI). См. условное отключение в Минимизация поверхности атаки nginx — проверка.md п. 8 (XSLT). См. условное отключение в Минимизация поверхности атаки nginx — проверка.md п. 3 (динамические модули). См. условное отключение в Минимизация поверхности атаки nginx — проверка.md п. 3 (сторонние модули). См. классификацию п. 8 в Выполнение кода — проверка.md. См. классификацию п. 9 в Выполнение кода — проверка.md. См. классификацию п. 10 в Выполнение кода — проверка.md. См. классификацию п. 11 в Выполнение кода — проверка.md. См. классификацию п. 12 в Выполнение кода — проверка.md.
- Примечание: Процедура утверждения сторонних модулей — организационная мера. См. условное отключение в Минимизация поверхности атаки nginx — проверка.md п. 3 (сторонние модули). См. классификацию п. 12 в Выполнение кода — проверка.md.
Механизм: WebDAV
- Риск: Загрузка файла, который затем может быть обработан как код внешним обработчиком.
- Требование: Запретить WebDAV в базовой конфигурации либо ограничить загрузку в директории, не передаваемые обработчикам кода.
- Что контролировать: dav_methods; права на директории; location WebDAV.
- Проверка:
  - Статус: Реализуемо
  - Ревью меры контроля: Требование адекватно косвенному риску. WebDAV не должен пересекаться с каталогами, обрабатываемыми FastCGI/uWSGI. Upload-директория — только статика, без .php/скриптов.
  - Источник: https://nginx.org/en/docs/http/ngx_http_dav_module.html
  - Пример реализации контроля:
```
# WebDAV не включён в базовой конфигурации
# При необходимости — изолированный location:
location /uploads/ {
    root /var/www/static-only;
    dav_methods PUT;
    # Нет fastcgi_pass / uwsgi_pass в этом location
}
```
  - Проверка эффективности контроля:
```
nginx -T 2>/dev/null | grep -E 'dav_methods|dav_access'
# dav_methods отсутствует вне утверждённых location
# upload-директория не содержит исполняемых расширений
```
- Примечание: См. условное отключение в Минимизация поверхности атаки nginx — проверка.md п. 5 (WebDAV). См. классификацию п. 13 в Выполнение кода — проверка.md.
Механизм: Внутренние перенаправления
- Риск: Перенаправление запроса к обработчику кода в обход ожидаемой логики доступа.
- Требование: Контролировать внутренние маршруты и исключить передачу в обработку файлов из неразрешённых директорий.
- Что контролировать: try_files; error_page; internal; named location.
- Проверка:
  - Статус: Реализуемо
  - Ревью меры контроля: Требование корректно. Аудит цепочек try_files → FastCGI, error_page → internal location, rewrite на обход root.
  - Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html#try_files , https://nginx.org/en/docs/http/ngx_http_core_module.html#internal
  - Пример реализации контроля:
```
location / {
    root /var/www/app/public;
    try_files $uri $uri/ =404;
}

location ~ \.php$ {
    try_files $uri =404;
    fastcgi_pass unix:/run/php/php-fpm.sock;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
```
  - Проверка эффективности контроля:
```
nginx -T 2>/dev/null | grep -E 'try_files|error_page|rewrite|internal'
# Все try_files перед FastCGI содержат =404
# internal location не ведут за пределы root
```
- Примечание: См. классификацию п. 14 в Выполнение кода — проверка.md.
Механизм: root / alias
- Риск: Ошибка настройки может открыть произвольный каталог ОС или передать файл во внешний обработчик.
- Требование: Разрешить обслуживание и обработку файлов только из утверждённых директорий.
- Что контролировать: root; alias; location; права ФС.
- Проверка:
  - Статус: Реализуемо
  - Ревью меры контроля: Требование полностью адекватно. Контроль конфигурации + права ФС (nginx не должен читать /etc, /root и т.д.). Осторожность с alias и regex location.
  - Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html#root , https://nginx.org/en/docs/http/ngx_http_core_module.html#alias
  - Пример реализации контроля:
```
server {
    root /var/www/app/public;

    location / {
        try_files $uri =404;
    }

    location ~ /\. {
        deny all;
    }
}
```
  - Проверка эффективности контроля:
```
nginx -T 2>/dev/null | grep -E '^\s*(root|alias)\s'
namei -l /var/www/app/public
# root/alias только на утверждённые пути
# права: каталоги 755, файлы 644, владелец не root для web-контента
```
- Примечание: См. классификацию п. 15 в Выполнение кода — проверка.md.
Механизм: Конфигурация nginx
- Риск: Изменение конфигурации может разрешить выполнение/передачу неразрешённого кода.
- Требование: Поставить конфигурацию nginx на контроль целостности и ограничить права изменения.
- Что контролировать: /etc/nginx/nginx.conf; подключаемые конфигурации.
- Проверка:
  - Статус: Требует внешних/организационных мер
  - Ревью меры контроля: Требование корректно. nginx не обеспечивает FIM самостоятельно. Необходимы: afick/AIDE, ограничение прав записи (chmod 644, владелец root), разделение ролей (изменение конфигурации — только администратор).
  - Источник: Внешняя мера (FIM); https://nginx.org/en/docs/
  - Пример реализации контроля:
```
# /etc/afick.conf (фрагмент)
/etc/nginx/               R

# Права доступа
# chmod 644 /etc/nginx/nginx.conf
# chmod 644 /etc/nginx/conf.d/*.conf
# chown root:root /etc/nginx/
```
  - Проверка эффективности контроля:
```
afick -c /etc/afick.conf --check
ls -la /etc/nginx/nginx.conf /etc/nginx/conf.d/
# Только root может изменять конфигурацию
stat -c '%a %U' /etc/nginx/nginx.conf
```
  - Примечание: Изменение конфигурации — через процедуру Change Management с повторным nginx -t. Статус отражает внешнюю меру. См. Контроль целостности хранимого кода и конфигурации — проверка.md п. 1–2; функции 9.3 в функции безопасности — проверка.md. См. условное отключение в Минимизация поверхности атаки nginx — проверка.md п. 5 (WebDAV). См. классификацию п. 13 в Выполнение кода — проверка.md. См. классификацию п. 14 в Выполнение кода — проверка.md. См. классификацию п. 15 в Выполнение кода — проверка.md.
- Примечание: Статус отражает внешнюю меру. См. Контроль целостности хранимого кода и конфигурации — проверка.md п. 1–2; функции 9.3 в функции безопасности — проверка.md.
Механизм: Файлы веб-приложений
- Риск: Изменение файлов приложения может привести к выполнению неразрешённого кода.
- Требование: Поставить разрешённые директории веб-приложений на контроль целостности.
- Что контролировать: web-root; директории приложений; исполняемые скрипты.
- Проверка:
  - Статус: Требует внешних/организационных мер
  - Ревью меры контроля: Требование адекватно. Контроль целостности web-root и скриптов (.php, .py и др.) — внешнее средство (afick). nginx не отслеживает изменения файлов приложения.
  - Источник: Внешняя мера (FIM)
  - Пример реализации контроля:
```
# /etc/afick.conf (фрагмент)
/var/www/                 R
```
  - Проверка эффективности контроля:
```
afick -c /etc/afick.conf --check
find /var/www -name '*.php' -o -name '*.py' | head -20
# Сверить перечень скриптов с утверждённым
# После тестового изменения файла — afick должен зафиксировать нарушение
```
  - Примечание: Дополняет конфигурационный контроль (п. 1, 14); не заменяет его. Статус отражает внешнюю меру. См. Контроль целостности хранимого кода и конфигурации — проверка.md п. 3–4; функции 9.3 в функции безопасности — проверка.md.
- Примечание: Статус отражает внешнюю меру. См. Контроль целостности хранимого кода и конфигурации — проверка.md п. 3–4; функции 9.3 в функции безопасности — проверка.md.

34 KiB Raw Permalink Blame History Unescape Escape

Контроль выполнения кода nginx — результаты проверки

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

34 KiB

Raw Permalink Blame History