# Контроль выполнения кода 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 | --- 1. **Механизм:** 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 - **Пример реализации контроля:** ```nginx 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; } } ``` - **Проверка эффективности контроля:** ```bash 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`. 2. **Механизм:** uWSGI - **Риск:** Передача запроса в приложение, выполняющее код вне контроля nginx. - **Требование:** Разрешить маршрутизацию только к утверждённым uWSGI-приложениям. - **Что контролировать:** uwsgi_pass; upstream; конфигурация backend. - Проверка: - **Статус:** Реализуемо - **Ревью меры контроля:** Требование корректно: nginx не исполняет код, но направляет запросы. Контроль — фиксированный `upstream` с явным списком сокетов/адресов, без произвольных `uwsgi_pass` на внешние хосты. - **Источник:** https://nginx.org/en/docs/http/ngx_http_uwsgi_module.html - **Пример реализации контроля:** ```nginx upstream approved_uwsgi { server unix:/run/uwsgi/app.sock; } location / { uwsgi_pass approved_uwsgi; include uwsgi_params; } ``` - **Проверка эффективности контроля:** ```bash nginx -T 2>/dev/null | grep -E 'uwsgi_pass|upstream' # Все uwsgi_pass ссылаются на утверждённый upstream # Нет uwsgi_pass на произвольные IP/порты вне списка ``` - **Примечание:** См. классификацию п. 3 в `Выполнение кода — проверка.md`. 3. **Механизм:** SCGI - **Риск:** Передача запроса во внешний обработчик, выполняющий код приложения. - **Требование:** Разрешить маршрутизацию только к утверждённым SCGI-приложениям. - **Что контролировать:** scgi_pass; upstream; конфигурация backend. - Проверка: - **Статус:** Реализуемо - **Ревью меры контроля:** Аналогично uWSGI. Мера достаточна при фиксированном upstream и документированном перечне SCGI-приложений. - **Источник:** https://nginx.org/en/docs/http/ngx_http_scgi_module.html - **Пример реализации контроля:** ```nginx upstream approved_scgi { server 127.0.0.1:4000; } location / { scgi_pass approved_scgi; include scgi_params; } ``` - **Проверка эффективности контроля:** ```bash nginx -T 2>/dev/null | grep -E 'scgi_pass|upstream' ``` - **Примечание:** См. классификацию п. 4 в `Выполнение кода — проверка.md`. 4. **Механизм:** 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 - **Пример реализации контроля:** ```nginx upstream approved_backend { server 127.0.0.1:8080; keepalive 32; } location /api/ { proxy_pass http://approved_backend; proxy_set_header Host $host; } ``` - **Проверка эффективности контроля:** ```bash nginx -T 2>/dev/null | grep -E 'proxy_pass|upstream' # Нет proxy_pass с переменными или на неутверждённые адреса ``` - **Примечание:** См. классификацию п. 5 в `Выполнение кода — проверка.md`. 5. **Механизм:** 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 - **Пример реализации контроля:** ```nginx upstream approved_grpc { server 127.0.0.1:50051; } location /grpc.service/ { grpc_pass grpc://approved_grpc; } ``` - **Проверка эффективности контроля:** ```bash nginx -T 2>/dev/null | grep -E 'grpc_pass|upstream' ``` - **Примечание:** См. классификацию п. 6 в `Выполнение кода — проверка.md`. 6. **Механизм:** njs - **Риск:** Выполнение JavaScript-логики внутри процесса nginx. - **Требование:** Разрешить использование njs только из утверждённых файлов/модулей, если njs применяется. - **Что контролировать:** js_import; js_content; js_set; файлы JavaScript. - Проверка: - **Статус:** Реализуемо с оговорками - **Ревью меры контроля:** Требование адекватно. Рекомендуется по умолчанию не использовать njs; при необходимости — белый список JS-файлов и FIM на `/etc/nginx/njs/`. Перечень контролируемых объектов полный. - **Источник:** https://nginx.org/en/docs/njs/ - **Пример реализации контроля:** ```nginx # Только утверждённые модули и файлы 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; } } ``` - **Проверка эффективности контроля:** ```bash 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`. 7. **Механизм:** 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 - **Пример реализации контроля:** ```nginx # Рекомендация: не включать Perl-модуль в сборку/конфигурацию # Если необходим — только утверждённые файлы: # perl_modules /etc/nginx/perl; # perl_require approved.pm; ``` - **Проверка эффективности контроля:** ```bash 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`. 8. **Механизм:** SSI - **Риск:** Обработка SSI-команд в ответах может изменить формируемый контент. - **Требование:** Разрешить SSI только для утверждённых ресурсов или отключить, если не требуется. - **Что контролировать:** ssi; SSI-файлы; location, где включён SSI. - Проверка: - **Статус:** Реализуемо - **Ревью меры контроля:** Требование адекватно. Дополнительно: запретить `` в SSI-файлах (выполнение shell-команд). По умолчанию `ssi off`. - **Источник:** https://nginx.org/en/docs/http/ngx_http_ssi_module.html - **Пример реализации контроля:** ```nginx http { ssi off; # по умолчанию отключено } location /ssi-approved/ { ssi on; root /var/www/html; } ``` - **Проверка эффективности контроля:** ```bash 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`. 9. **Механизм:** XSLT - **Риск:** Выполнение логики преобразования XML с использованием XSLT-стилей. - **Требование:** Разрешить XSLT-преобразования только с утверждёнными XSLT-файлами, если функция используется. - **Что контролировать:** xslt_stylesheet; XSLT-файлы. - Проверка: - **Статус:** Реализуемо с оговорками - **Ревью меры контроля:** Требование корректно. XSLT-файлы — объекты FIM. Рекомендуется не использовать модуль, если не требуется. - **Источник:** https://nginx.org/en/docs/http/ngx_http_xslt_module.html - **Пример реализации контроля:** ```nginx location /api/xml { proxy_pass http://backend; xslt_stylesheet /etc/nginx/xslt/approved-transform.xslt; } ``` - **Проверка эффективности контроля:** ```bash nginx -T 2>/dev/null | grep xslt_stylesheet ls -la /etc/nginx/xslt/ # Все XSLT-файлы в утверждённом перечне ``` - **Примечание:** См. условное отключение в `Минимизация поверхности атаки nginx — проверка.md` п. 8 (XSLT). См. классификацию п. 10 в `Выполнение кода — проверка.md`. 10. **Механизм:** Динамические модули nginx - **Риск:** Загрузка неразрешённого .so-модуля, выполняемого в процессе nginx. - **Требование:** Разрешить загрузку только модулей из утверждённого перечня. - **Что контролировать:** load_module; директории модулей; .so-файлы. - Проверка: - **Статус:** Реализуемо - **Ревью меры контроля:** Требование полностью адекватно риску. Организационный белый список `load_module` + FIM на каталог модулей. - **Источник:** https://nginx.org/en/docs/ngx_core_module.html#load_module - **Пример реализации контроля:** ```nginx # В nginx.conf — только утверждённые модули load_module modules/ngx_http_geoip_module.so; # load_module /path/to/unapproved.so; # запрещено ``` - **Проверка эффективности контроля:** ```bash 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`. 11. **Механизм:** Сторонние динамические модули - **Риск:** Подключение стороннего кода без контроля поставки и целостности. - **Требование:** Запретить сторонние модули либо допускать только после включения в утверждённый список. - **Что контролировать:** load_module; пакет модуля; путь к .so. - Проверка: - **Статус:** Реализуемо с оговорками - **Ревью меры контроля:** Требование корректно. Сочетание организационного запрета, процедуры включения в белый список, контроля пакета (подпись, репозиторий) и FIM на `.so`. - **Источник:** https://nginx.org/en/docs/ngx_core_module.html#load_module - **Пример реализации контроля:** ```nginx # Политика: только модули из дистрибутивного пакета nginx # load_module modules/ngx_http_js_module.so; # только после утверждения ``` - **Проверка эффективности контроля:** ```bash 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`. 12. **Механизм:** WebDAV - **Риск:** Загрузка файла, который затем может быть обработан как код внешним обработчиком. - **Требование:** Запретить WebDAV в базовой конфигурации либо ограничить загрузку в директории, не передаваемые обработчикам кода. - **Что контролировать:** dav_methods; права на директории; location WebDAV. - Проверка: - **Статус:** Реализуемо - **Ревью меры контроля:** Требование адекватно косвенному риску. WebDAV не должен пересекаться с каталогами, обрабатываемыми FastCGI/uWSGI. Upload-директория — только статика, без `.php`/скриптов. - **Источник:** https://nginx.org/en/docs/http/ngx_http_dav_module.html - **Пример реализации контроля:** ```nginx # WebDAV не включён в базовой конфигурации # При необходимости — изолированный location: location /uploads/ { root /var/www/static-only; dav_methods PUT; # Нет fastcgi_pass / uwsgi_pass в этом location } ``` - **Проверка эффективности контроля:** ```bash nginx -T 2>/dev/null | grep -E 'dav_methods|dav_access' # dav_methods отсутствует вне утверждённых location # upload-директория не содержит исполняемых расширений ``` - **Примечание:** См. условное отключение в `Минимизация поверхности атаки nginx — проверка.md` п. 5 (WebDAV). См. классификацию п. 13 в `Выполнение кода — проверка.md`. 13. **Механизм:** Внутренние перенаправления - **Риск:** Перенаправление запроса к обработчику кода в обход ожидаемой логики доступа. - **Требование:** Контролировать внутренние маршруты и исключить передачу в обработку файлов из неразрешённых директорий. - **Что контролировать:** 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 - **Пример реализации контроля:** ```nginx 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; } ``` - **Проверка эффективности контроля:** ```bash nginx -T 2>/dev/null | grep -E 'try_files|error_page|rewrite|internal' # Все try_files перед FastCGI содержат =404 # internal location не ведут за пределы root ``` - **Примечание:** См. классификацию п. 14 в `Выполнение кода — проверка.md`. 14. **Механизм:** 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 - **Пример реализации контроля:** ```nginx server { root /var/www/app/public; location / { try_files $uri =404; } location ~ /\. { deny all; } } ``` - **Проверка эффективности контроля:** ```bash 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`. 15. **Механизм:** Конфигурация 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/ ``` - **Проверка эффективности контроля:** ```bash 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`. 16. **Механизм:** Файлы веб-приложений - **Риск:** Изменение файлов приложения может привести к выполнению неразрешённого кода. - **Требование:** Поставить разрешённые директории веб-приложений на контроль целостности. - **Что контролировать:** web-root; директории приложений; исполняемые скрипты. - Проверка: - **Статус:** Требует внешних/организационных мер - **Ревью меры контроля:** Требование адекватно. Контроль целостности web-root и скриптов (.php, .py и др.) — внешнее средство (afick). nginx не отслеживает изменения файлов приложения. - **Источник:** Внешняя мера (FIM) - **Пример реализации контроля:** ``` # /etc/afick.conf (фрагмент) /var/www/ R ``` - **Проверка эффективности контроля:** ```bash 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`.