Astra/nginx-analize
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
master
nginx-analize/docs/Минимально_необходимые_полномочия_nginx_—_проверка.md
Redsandyg fcc9139361 init
2026-06-15 06:31:35 +03:00

25 KiB
Raw Permalink Blame History

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

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

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

№ Объект полномочий Статус Уровень
1 Worker-процессы nginx Реализуемо процесс
2 Конфигурация nginx Реализуемо ФС
3 Директории веб-контента Реализуемо ФС
4 Директории загрузки файлов Условно (если используется) ФС
5 Журналы nginx Комбинированная мера ФС / syslog
6 TLS-сертификаты Реализуемо ФС
7 TLS-ключи Реализуемо ФС
8 Файл пользователей Basic Auth Условно (если используется) ФС
9 Unix-сокеты backend Реализуемо ФС / процесс
10 Динамические модули nginx Комбинированная мера ФС + FIM
11 Временные директории nginx Реализуемо ФС
12 Сетевые соединения к backend Комбинированная мера сеть / конфигурация

  1. Worker-процессы nginx

    • Необходимые полномочия: выполнение от непривилегированного пользователя, заданного в конфигурации; повышенные права master-процесса допускаются только для запуска службы и системных операций.
    • Запрещено: работа worker-процессов с избыточными правами root.
    • Комментарий: master-процесс может стартовать с повышенными правами для привязки к портам, worker-процессы должны работать с минимальными правами.
    • Проверка:
      • Статус: Реализуемо
      • Ревью полномочий: Модель полномочий корректна и соответствует архитектуре nginx. Master (root) выполняет bind к портам <1024, чтение TLS-ключей при reload, fork worker-процессов. Worker работает от пользователя из директивы user с минимальными правами. Запрет worker от root — обязательное требование; worker_processes на привилегии не влияет.
      • Источник: https://nginx.org/en/docs/ngx_core_module.html#user
      • Пример реализации: 
        # /etc/nginx/nginx.conf
user nginx nginx;
# или: user www-data www-data;
worker_processes auto;
      • Проверка эффективности: 
        nginx -T 2>/dev/null | grep '^user '
ps aux | grep 'nginx:'
# Master — root; worker — UID пользователя из user (не 0)
id nginx 2>/dev/null || id www-data
      • Примечание: См. п. 15 в Минимизация поверхности атаки nginx — проверка.md.

  2. Конфигурация nginx

    • Необходимые полномочия: чтение конфигурации nginx.
    • Запрещено: запись в конфигурацию от имени пользователя nginx.
    • Комментарий: изменение конфигурации должно быть доступно только администратору.
    • Проверка:
      • Статус: Реализуемо
      • Ревью полномочий: Требования адекватны. Master читает конфигурацию при старте/reload (от root); worker не должен иметь прав на запись в /etc/nginx/. Владелец — root, права на файлы — 644, на каталоги — 755. Изменения — только администратором; контроль целостности — FIM.
      • Источник: https://nginx.org/en/docs/ngx_core_module.html#include
      • Пример реализации: 
        chown -R root:root /etc/nginx/
find /etc/nginx -type f -exec chmod 644 {} \;
find /etc/nginx -type d -exec chmod 755 {} \;
      • Проверка эффективности: 
        ls -la /etc/nginx/
namei -l /etc/nginx/nginx.conf
# Пользователь nginx не имеет write на /etc/nginx/
sudo -u nginx test -w /etc/nginx/nginx.conf && echo FAIL || echo OK
      • Примечание: См. п. 1–2 в Контроль целостности хранимого кода и конфигурации — проверка.md.

  3. Директории веб-контента

    • Необходимые полномочия: чтение файлов, которые должны обслуживаться пользователям.
    • Запрещено: запись в web-root, если nginx не должен изменять контент.
    • Комментарий: для статического сайта nginx обычно нужны только права чтения.
    • Проверка:
      • Статус: Реализуемо
      • Ревью полномочий: Требования корректны. Worker нужен только read/execute (traverse) на каталоги и read на файлы. Запись в web-root для статического сайта запрещена — снижает риск подмены контента при компрометации worker. Каталоги — 755, файлы — 644; без world-writable (777, 666).
      • Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html#root
      • Пример реализации: 
        chown -R root:www-data /var/www/html/
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;
# nginx (www-data) — только чтение, без write
      • Проверка эффективности: 
        nginx -T 2>/dev/null | grep -E '^\s*root\s|^\s*alias\s'
namei -l /var/www/html/index.html
ls -la /var/www/html/
sudo -u nginx test -w /var/www/html/index.html && echo FAIL || echo OK
find /var/www -perm -0002 -type f 2>/dev/null
# Не должно быть world-writable файлов
      • Примечание: См. п. 3–4 в Контроль целостности хранимого кода и конфигурации — проверка.md; п. 14 в Минимизация поверхности атаки nginx — проверка.md.

  4. Директории загрузки файлов

    • Необходимые полномочия: запись только в специально выделенные директории (если функция загрузки нужна).
    • Запрещено: запись в директории, передаваемые обработчикам кода, если это не предусмотрено.
    • Комментарий: нужно исключить загрузку исполняемого кода в директории обработки.
    • Проверка:
      • Статус: Условно (если используется)
      • Ревью полномочий: Требования адекватны при использовании WebDAV или иной загрузки. Write — только в выделенный каталог (/var/www/uploads/), изолированный от FastCGI root. Запрет исполняемых расширений (.php, .py) в upload-директории. Без WebDAV — запись worker в web-root не нужна.
      • Источник: https://nginx.org/en/docs/http/ngx_http_dav_module.html
      • Пример реализации: 
        mkdir -p /var/www/uploads
chown nginx:nginx /var/www/uploads
chmod 750 /var/www/uploads
# Нет fastcgi_pass в location /uploads/

        location /uploads/ {
    root /var/www/static-only;
    dav_methods PUT;
}
      • Проверка эффективности: 
        nginx -T 2>/dev/null | grep dav_methods
ls -la /var/www/uploads/ 2>/dev/null
# Upload-каталог не пересекается с root для .php
find /var/www/uploads -name '*.php' -o -name '*.py' 2>/dev/null
      • Примечание: См. п. 10 в Контроль целостности хранимого кода и конфигурации — проверка.md; п. 5 в Минимизация поверхности атаки nginx — проверка.md.

  5. Журналы nginx

    • Необходимые полномочия: права на запись текущих журналов или передачу событий в syslog.
    • Запрещено: изменение, удаление и подмена архивных журналов (ограничить правами ОС и/или централизованным журналированием).
    • Комментарий: для аудита важна защита журналов от подмены и удаления.
    • Проверка:
      • Статус: Комбинированная мера
      • Ревью полномочий: Модель корректна. Активные журналы — write для пользователя nginx (или группа adm); архивы после logrotate — read-only для nginx (chmod 440, владелец root:adm). Централизованное журналирование через syslog снимает зависимость от локальных файлов. Worker не должен удалять/перезаписывать архивы.
      • Источник: https://nginx.org/en/docs/ngx_core_module.html#error_log , https://nginx.org/en/docs/syslog.html
      • Пример реализации: 
        chown root:adm /var/log/nginx/
chmod 750 /var/log/nginx/
chmod 640 /var/log/nginx/access.log /var/log/nginx/error.log

        # Альтернатива: централизованное журналирование
# access_log syslog:server=192.168.1.1:514,facility=local7,tag=nginx,severity=info combined;
# error_log syslog:server=192.168.1.1:514,facility=local7,tag=nginx;
      • Проверка эффективности: 
        ls -la /var/log/nginx/
stat -c '%a %U:%G' /var/log/nginx/*.log
sudo -u nginx rm /var/log/nginx/access.log.1 2>&1
# Ожидание: отказ в удалении архива
nginx -T 2>/dev/null | grep -E 'access_log|error_log'
      • Примечание: См. п. 13 в Контроль целостности хранимого кода и конфигурации — проверка.md; п. 14 в Проверочные мероприятия для ПМИ — проверка.md.

  6. TLS-сертификаты

    • Необходимые полномочия: минимальные права для чтения сертификатов на этапе запуска/перезагрузки конфигурации.
    • Запрещено: запись/изменение сертификатов от имени nginx.
    • Комментарий: сертификаты должны изменяться только администратором.
    • Проверка:
      • Статус: Реализуемо
      • Ревью полномочий: Требования корректны. Сертификаты (публичная часть) — 644, владелец root. Master читает при старте/reload; worker не нуждается в write. Обновление сертификатов — администратором, с последующим nginx -s reload.
      • Источник: https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate
      • Пример реализации: 
        chown root:root /etc/nginx/ssl/
chmod 644 /etc/nginx/ssl/*.crt
chmod 755 /etc/nginx/ssl/
      • Проверка эффективности: 
        ls -la /etc/nginx/ssl/
stat -c '%a %U:%G %n' /etc/nginx/ssl/*.crt
sudo -u nginx test -w /etc/nginx/ssl/server.crt && echo FAIL || echo OK
      • Примечание: См. п. 11 в Контроль целостности хранимого кода и конфигурации — проверка.md.

  7. TLS-ключи

    • Необходимые полномочия: минимальные права для чтения закрытых ключей на этапе запуска/перезагрузки конфигурации.
    • Запрещено: доступ к закрытым ключам для неуполномоченных пользователей/процессов.
    • Комментарий: доступ к закрытым ключам должен быть ограничен только необходимыми системными пользователями/процессами.
    • Проверка:
      • Статус: Реализуемо
      • Ревью полномочий: Требования полностью адекватны. Закрытые ключи читает master-процесс (root) при старте и nginx -s reload; worker обычно не обращается к ключам напрямую. Права — 600, владелец root:root. Пользователь nginx и прочие — без read. Запись nginx на ключи запрещена.
      • Источник: https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate_key
      • Пример реализации: 
        chmod 600 /etc/nginx/ssl/*.key
chown root:root /etc/nginx/ssl/*.key
      • Проверка эффективности: 
        stat -c '%a %U:%G %n' /etc/nginx/ssl/*.key
# Ожидание: 600 root root
sudo -u nginx cat /etc/nginx/ssl/server.key 2>&1
# Ожидание: Permission denied
getfacl /etc/nginx/ssl/server.key 2>/dev/null
      • Примечание: См. п. 11 в Контроль целостности хранимого кода и конфигурации — проверка.md.

  8. Файл пользователей Basic Auth

    • Необходимые полномочия: чтение файла для проверки паролей.
    • Запрещено: запись в файл пользователей от имени nginx.
    • Комментарий: изменение учётных данных должно выполняться администратором.
    • Проверка:
      • Статус: Условно (если используется)
      • Ревью полномочий: Требования корректны при использовании auth_basic. Worker нужен read; write — только root (администратор). Рекомендуемые права — 640, владелец root:root (или root:nginx при необходимости read для worker через группу).
      • Источник: https://nginx.org/en/docs/http/ngx_http_auth_basic_module.html#auth_basic_user_file
      • Пример реализации: 
        chown root:root /etc/nginx/htpasswd
chmod 640 /etc/nginx/htpasswd
# Обновление: htpasswd от root, затем nginx -s reload
      • Проверка эффективности: 
        nginx -T 2>/dev/null | grep auth_basic_user_file
ls -la /etc/nginx/htpasswd
sudo -u nginx test -w /etc/nginx/htpasswd && echo FAIL || echo OK
      • Примечание: См. п. 12 в Контроль целостности хранимого кода и конфигурации — проверка.md.

  9. Unix-сокеты backend

    • Необходимые полномочия: доступ только к сокетам тех backend, которые используются конфигурацией.
    • Запрещено: доступ к произвольным сокетам и сервисам ОС.
    • Комментарий: например, socket PHP-FPM/uWSGI должен быть доступен только при необходимости.
    • Проверка:
      • Статус: Реализуемо
      • Ревью полномочий: Требования адекватны. Доступ к Unix-сокету — через группу: пользователь nginx в группе www-data/php-fpm, сокет с правами 660 и группой www-data. Не использовать world-readable сокеты (777). Доступ только к сокетам из fastcgi_pass/uwsgi_pass в конфигурации.
      • Источник: https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_pass , https://nginx.org/en/docs/http/ngx_http_uwsgi_module.html#uwsgi_pass
      • Пример реализации: 
        # PHP-FPM pool: listen.owner = www-data, listen.group = www-data, listen.mode = 0660
usermod -aG www-data nginx

        location ~ \.php$ {
    fastcgi_pass unix:/run/php/php-fpm.sock;
}
      • Проверка эффективности: 
        nginx -T 2>/dev/null | grep -E 'fastcgi_pass|uwsgi_pass|scgi_pass'
namei -l /run/php/php-fpm.sock
ls -la /run/php/
groups nginx 2>/dev/null || groups www-data
# Сокет не world-writable; nginx в нужной группе
      • Примечание: См. п. 1–3 в Контроль выполнения кода — проверка.md.

  10. Динамические модули nginx

    • Необходимые полномочия: чтение разрешённых .so-модулей.
    • Запрещено: запись/подмена .so-модулей от имени nginx.
    • Комментарий: модули выполняются в процессе nginx, поэтому требуют контроля целостности.
    • Проверка:
      • Статус: Комбинированная мера
      • Ревью полномочий: Требования корректны. Master загружает .so при старте (read); каталог /usr/lib/nginx/modules/ — root:root, 755, файлы 644. Пользователь nginx не имеет write. Подмена модулей предотвращается FIM и организационным белым списком load_module.
      • Источник: https://nginx.org/en/docs/ngx_core_module.html#load_module
      • Пример реализации: 
        chown -R root:root /usr/lib/nginx/modules/
chmod 755 /usr/lib/nginx/modules/
chmod 644 /usr/lib/nginx/modules/*.so

        load_module modules/ngx_http_geoip_module.so;
      • Проверка эффективности: 
        ls -la /usr/lib/nginx/modules/
nginx -T 2>/dev/null | grep load_module
sudo -u nginx test -w /usr/lib/nginx/modules/ngx_http_geoip_module.so && echo FAIL || echo OK
afick -c /etc/afick.conf --check
      • Примечание: См. п. 5 в Контроль целостности хранимого кода и конфигурации — проверка.md; п. 3 в Минимизация поверхности атаки nginx — проверка.md.

  11. Временные директории nginx

    • Необходимые полномочия: запись во временные директории, необходимые для buffering/client body.
    • Запрещено: запись в произвольные системные директории.
    • Комментарий: временные директории должны быть ограничены и контролируемы правами.
    • Проверка:
      • Статус: Реализуемо
      • Ревью полномочий: Требования адекватны. По умолчанию nginx использует client_body_temp_path, proxy_temp_path, fastcgi_temp_path под /var/cache/nginx или compile-time пути. Явно задать пути в конфигурации; каталог — владелец nginx:nginx, 700 или 750. Не использовать world-writable /tmp.
      • Источник: https://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_temp_path , https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_temp_path
      • Пример реализации: 
        http {
    client_body_temp_path /var/cache/nginx/client_temp;
    proxy_temp_path       /var/cache/nginx/proxy_temp;
    fastcgi_temp_path     /var/cache/nginx/fastcgi_temp;
}

        mkdir -p /var/cache/nginx/{client_temp,proxy_temp,fastcgi_temp}
chown -R nginx:nginx /var/cache/nginx/
chmod 750 /var/cache/nginx/
      • Проверка эффективности: 
        nginx -T 2>/dev/null | grep -E 'client_body_temp_path|proxy_temp_path|fastcgi_temp_path'
ls -la /var/cache/nginx/
find /var/cache/nginx -perm -0002 2>/dev/null
# Нет world-writable каталогов
      • Примечание: При proxy_buffering off часть temp-файлов не создаётся; пути всё равно зафиксировать в ЭД.

  12. Сетевые соединения к backend

    • Необходимые полномочия: исходящие соединения только к утверждённым backend-сервисам (при проксировании).
    • Запрещено: произвольные исходящие соединения, если они не нужны.
    • Комментарий: ограничивается архитектурой, межсетевыми правилами и конфигурацией.
    • Проверка:
      • Статус: Комбинированная мера
      • Ревью полномочий: Требования корректны, но nginx не имеет встроенного egress-filter. Ограничение исходящих соединений — комбинация: (1) конфигурация с белым списком upstream/proxy_pass; (2) файрвол/nftables на хосте; (3) сегментация сети. Без проксирования исходящие соединения nginx минимальны (DNS при resolver, syslog при централизованном журналировании).
      • Источник: https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass , https://nginx.org/en/docs/http/ngx_http_upstream_module.html
      • Пример реализации: 
        upstream approved_backend {
    server 127.0.0.1:8080;
    server 10.0.0.5:8080;
}

location /api/ {
    proxy_pass http://approved_backend;
}

        # nftables (фрагмент): исходящие от nginx только к утверждённым адресам
# ip saddr @nginx_workers ip daddr { 10.0.0.5, 127.0.0.1 } tcp dport 8080 accept
      • Проверка эффективности: 
        nginx -T 2>/dev/null | grep -E 'proxy_pass|fastcgi_pass|uwsgi_pass|grpc_pass|resolver'
ss -tnp | grep nginx
# Сверить активные соединения с утверждённым перечнем backend
nft list ruleset 2>/dev/null | grep -i nginx
      • Примечание: См. п. 12–13 в Минимизация поверхности атаки nginx — проверка.md; п. 4 в Контроль выполнения кода — проверка.md.
Reference in New Issue View Git Blame Copy Permalink