Astra/nginx-analize
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
master
nginx-analize/docs/Контроль_целостности_хранимого_кода_и_конфигурации_—_проверка.md
Redsandyg fcc9139361 init
2026-06-15 06:31:35 +03:00

27 KiB
Raw Permalink Blame History

Контроль целостности хранимого кода и конфигурации — результаты проверки

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

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

№ Объект контроля Статус Механизм
1 Основной конфигурационный файл nginx Обязательно afick
2 Подключаемые конфигурационные файлы nginx Обязательно afick
3 Разрешённые директории веб-приложений Обязательно afick
4 Директории статического веб-контента Обязательно afick
5 Динамические .so-модули nginx Обязательно afick
6 Файлы njs Условно (если используется njs) afick
7 Perl-файлы Условно (если используется Perl) afick
8 XSLT-файлы Условно (если используется XSLT) afick
9 SSI-файлы Условно (если включён SSI) afick
10 Файлы WebDAV upload Условно (если включён WebDAV) afick
11 Сертификаты и ключи TLS Обязательно afick + права ФС
12 Файлы паролей Basic Authentication Условно (если используется auth_basic) afick + права ФС
13 Файлы журналов nginx Комбинированная мера права ФС + syslog

  1. Основной конфигурационный файл nginx

    • Причина контроля: Конфигурация определяет правила доступа, маршрутизацию, передачу запросов обработчикам и загрузку модулей.
    • Механизм контроля: afick или иной утверждённый механизм контроля целостности.
    • Ожидаемый результат: Несанкционированное изменение конфигурации выявляется.
    • Проверка:
      • Статус: Обязательно
      • Ревью меры контроля: Причина и механизм полностью адекватны. Изменение nginx.conf может включить load_module, proxy_pass на произвольный backend или ослабить allow/deny. FIM — единственный корректный способ контроля; nginx сам целостность не проверяет.
      • Источник: Внешнее средство FIM; https://nginx.org/en/docs/ (встроенный FIM не описан)
      • Связь с nginx: главный файл конфигурации, директива include подключает остальные файлы
      • Контролируемые пути (пример): /etc/nginx/nginx.conf
      • Пример реализации: 
        # /etc/afick.conf (фрагмент)
/etc/nginx/nginx.conf     R

# Права доступа
# chown root:root /etc/nginx/nginx.conf
# chmod 644 /etc/nginx/nginx.conf
      • Проверка эффективности контроля: 
        afick -c /etc/afick.conf --check
ls -la /etc/nginx/nginx.conf
# Тест: echo "# test" >> /etc/nginx/nginx.conf
afick -c /etc/afick.conf --check
# Ожидание: отчёт о нарушении; затем восстановить файл
      • Примечание: См. также функции 9.3 в функции безопасности — проверка.md; Контроль выполнения кода — проверка.md п. 15; Минимально необходимые полномочия nginx — проверка.md п. 2.

  2. Подключаемые конфигурационные файлы nginx

    • Причина: Через подключаемые файлы могут быть добавлены новые location, proxy_pass, fastcgi_pass или load_module.
    • Механизм: afick или иной утверждённый механизм контроля целостности.
    • Результат: Изменение подключаемой конфигурации выявляется.
    • Проверка:
      • Статус: Обязательно
      • Ревью меры контроля: Причина корректна: атака часто идёт через новый файл в conf.d/ или sites-enabled/, а не через правку основного nginx.conf. Механизм достаточен.
      • Источник: Внешнее средство FIM
      • Связь с nginx: include /etc/nginx/conf.d/*.conf;, include /etc/nginx/sites-enabled/*;
      • Контролируемые пути (пример): /etc/nginx/conf.d/, /etc/nginx/sites-enabled/
      • Пример реализации: 
        # /etc/afick.conf (фрагмент)
/etc/nginx/conf.d/        R
/etc/nginx/sites-enabled/ R
      • Проверка эффективности контроля: 
        afick -c /etc/afick.conf --check
ls -la /etc/nginx/conf.d/
# Тест: создать /etc/nginx/conf.d/evil.conf с proxy_pass
afick -c /etc/afick.conf --check
      • Примечание: См. права и полномочия в Минимально необходимые полномочия nginx — проверка.md п. 2.

  3. Разрешённые директории веб-приложений

    • Причина: В этих директориях хранится код или контент, который может быть передан внешнему обработчику.
    • Механизм: afick или иной утверждённый механизм контроля целостности.
    • Результат: Изменение файлов веб-приложений выявляется.
    • Проверка:
      • Статус: Обязательно
      • Ревью меры контроля: Причина и механизм адекватны. Изменение .php, .py и других скриптов — прямой риск выполнения кода через FastCGI/uWSGI. Пути должны соответствовать root/alias в конфигурации nginx.
      • Источник: Внешнее средство FIM
      • Связь с nginx: директивы root, alias, fastcgi_param SCRIPT_FILENAME
      • Контролируемые пути (пример): /var/www/app/, /var/www/app/public/
      • Пример реализации: 
        # /etc/afick.conf (фрагмент)
/var/www/app/             R
      • Проверка эффективности контроля: 
        nginx -T 2>/dev/null | grep -E '^\s*root\s|^\s*alias\s'
afick -c /etc/afick.conf --check
find /var/www/app -name '*.php' -o -name '*.py' | head -10
# Сверить пути с утверждённым перечнем в эксплуатационной документации
      • Примечание: См. права и полномочия в Минимально необходимые полномочия nginx — проверка.md п. 3.

  4. Директории статического веб-контента

    • Причина: Статические файлы могут быть изменены для подмены содержимого сайта.
    • Механизм: afick или иной утверждённый механизм контроля целостности.
    • Результат: Изменение статического контента выявляется, если он включён в область контроля.
    • Проверка:
      • Статус: Обязательно
      • Ревью меры контроля: Причина корректна (подмена HTML, JS, вредоносные вложения). Может быть объединена с п. 3 одной записью /var/www/ R, если статика и приложение в одном дереве каталогов.
      • Источник: Внешнее средство FIM
      • Связь с nginx: root для статических location
      • Контролируемые пути (пример): /var/www/html/
      • Пример реализации: 
        # Вариант 1: отдельная запись
/var/www/html/            R

# Вариант 2: объединение с п. 3
/var/www/                 R
      • Проверка эффективности контроля: 
        afick -c /etc/afick.conf --check
# Тест: изменить index.html в web-root
afick -c /etc/afick.conf --check
      • Примечание: См. права и полномочия в Минимально необходимые полномочия nginx — проверка.md п. 3. См. Минимизация поверхности атаки nginx — проверка.md п. 3–4.

  5. Динамические .so-модули nginx

    • Причина: Динамические модули выполняются в процессе nginx и расширяют функциональность сервера.
    • Механизм: afick или иной утверждённый механизм контроля целостности.
    • Результат: Подмена или изменение модуля выявляется.
    • Проверка:
      • Статус: Обязательно
      • Ревью меры контроля: Причина и механизм полностью адекватны. Подмена .so — выполнение произвольного нативного кода в процессе nginx. FIM обязателен в сочетании с белым списком в load_module.
      • Источник: Внешнее средство FIM; https://nginx.org/en/docs/ngx_core_module.html#load_module
      • Связь с nginx: load_module modules/...so;
      • Контролируемые пути (пример): /usr/lib/nginx/modules/
      • Пример реализации: 
        # /etc/afick.conf (фрагмент)
/usr/lib/nginx/modules/   R
      • Проверка эффективности контроля: 
        nginx -T 2>/dev/null | grep load_module
ls -la /usr/lib/nginx/modules/
afick -c /etc/afick.conf --check
rpm -V nginx 2>/dev/null || dpkg -V nginx 2>/dev/null
      • Примечание: См. права и полномочия в Минимально необходимые полномочия nginx — проверка.md п. 10.

  6. Файлы njs

    • Причина: При использовании njs JavaScript-файлы могут выполняться внутри nginx.
    • Механизм: afick или иной утверждённый механизм контроля целостности.
    • Результат: Изменение njs-кода выявляется.
    • Проверка:
      • Статус: Условно (если используется njs)
      • Ревью меры контроля: Причина корректна при наличии njs. Если js_import не используется — объект не включается в область контроля. Механизм достаточен.
      • Источник: Внешнее средство FIM; https://nginx.org/en/docs/njs/
      • Связь с nginx: js_import, js_content, js_set
      • Контролируемые пути (пример): /etc/nginx/njs/
      • Пример реализации: 
        # /etc/afick.conf (фрагмент) — только при использовании njs
/etc/nginx/njs/           R
      • Проверка эффективности контроля: 
        nginx -T 2>/dev/null | grep -E 'js_import|load_module.*js'
# Если njs не используется — записи в afick и директивы js_* отсутствуют
afick -c /etc/afick.conf --check
      • Примечание: См. права и полномочия в Минимально необходимые полномочия nginx — проверка.md п. 6.

  7. Perl-файлы

    • Причина: При использовании Perl-модуля Perl-код может выполняться внутри nginx.
    • Механизм: afick или иной утверждённый механизм контроля целостности.
    • Результат: Изменение Perl-кода выявляется.
    • Проверка:
      • Статус: Условно (если используется Perl)
      • Ревью меры контроля: Причина корректна. Рекомендация: не использовать Perl-модуль; при наличии — обязательный FIM на Perl-файлы.
      • Источник: Внешнее средство FIM; https://nginx.org/en/docs/http/ngx_http_perl_module.html
      • Связь с nginx: perl_modules, perl_require, perl
      • Контролируемые пути (пример): /etc/nginx/perl/
      • Пример реализации: 
        # /etc/afick.conf (фрагмент) — только при использовании Perl
/etc/nginx/perl/          R
      • Проверка эффективности контроля: 
        nginx -V 2>&1 | grep -i perl
nginx -T 2>/dev/null | grep -E 'perl|perl_require'
# Ожидание для безопасной конфигурации: отсутствие Perl
      • Примечание: См. права и полномочия в Минимально необходимые полномочия nginx — проверка.md п. 7.

  8. XSLT-файлы

    • Причина: XSLT-файлы управляют логикой преобразования XML-ответов.
    • Механизм: afick или иной утверждённый механизм контроля целостности.
    • Результат: Изменение XSLT-файлов выявляется.
    • Проверка:
      • Статус: Условно (если используется XSLT)
      • Ревью меры контроля: Причина и механизм адекватны при использовании xslt_stylesheet. Иначе объект исключается из области контроля.
      • Источник: Внешнее средство FIM; https://nginx.org/en/docs/http/ngx_http_xslt_module.html
      • Связь с nginx: xslt_stylesheet
      • Контролируемые пути (пример): /etc/nginx/xslt/
      • Пример реализации: 
        # /etc/afick.conf (фрагмент) — только при использовании XSLT
/etc/nginx/xslt/          R
      • Проверка эффективности контроля: 
        nginx -T 2>/dev/null | grep xslt_stylesheet
afick -c /etc/afick.conf --check
      • Примечание: См. права и полномочия в Минимально необходимые полномочия nginx — проверка.md п. 8.

  9. SSI-файлы

    • Причина: SSI-команды могут влиять на формирование ответа.
    • Механизм: afick или иной утверждённый механизм контроля целостности.
    • Результат: Изменение SSI-файлов выявляется.
    • Проверка:
      • Статус: Условно (если включён SSI)
      • Ревью меры контроля: Причина корректна. SSI-файлы обычно находятся в web-root (п. 3–4); отдельная запись нужна, если SSI включён в выделенном location. Дополнительно контролировать отсутствие <!--#exec--> в файлах.
      • Источник: Внешнее средство FIM; https://nginx.org/en/docs/http/ngx_http_ssi_module.html
      • Связь с nginx: ssi on в location
      • Контролируемые пути (пример): каталоги с ssi on внутри web-root, например /var/www/html/ssi/
      • Пример реализации: 
        # Покрывается записью web-root (п. 3–4), либо явно:
/var/www/html/ssi/       R
      • Проверка эффективности контроля: 
        nginx -T 2>/dev/null | grep -i 'ssi on'
grep -r '#exec' /var/www/html/ 2>/dev/null
# exec в SSI не должен присутствовать
      • Примечание: См. права и полномочия в Минимально необходимые полномочия nginx — проверка.md п. 3.

  10. Файлы, доступные для загрузки через WebDAV

    • Причина: Загруженные файлы могут стать источником риска при попадании в обработку внешним интерпретатором.
    • Механизм: afick или иной утверждённый механизм контроля целостности.
    • Результат: Несанкционированные изменения или появление файлов выявляются, если директория включена в контроль.
    • Проверка:
      • Статус: Условно (если включён WebDAV)
      • Ревью меры контроля: Причина корректна. FIM на upload-директорию выявляет появление новых файлов (в т.ч. .php). Рекомендация: upload-директория не должна пересекаться с FastCGI root.
      • Источник: Внешнее средство FIM; https://nginx.org/en/docs/http/ngx_http_dav_module.html
      • Связь с nginx: dav_methods, location с WebDAV
      • Контролируемые пути (пример): /var/www/uploads/
      • Пример реализации: 
        # /etc/afick.conf (фрагмент) — только при использовании WebDAV
/var/www/uploads/         R
      • Проверка эффективности контроля: 
        nginx -T 2>/dev/null | grep dav_methods
# Тест: загрузить файл через WebDAV, затем afick --check
afick -c /etc/afick.conf --check
    • Примечание: См. права и полномочия в Минимально необходимые полномочия nginx — проверка.md п. 4.

  11. Сертификаты и ключи TLS

    • Причина: Подмена сертификатов или ключей может нарушить доверие к защищённому соединению.
    • Механизм: afick или иной утверждённый механизм контроля целостности + ограничение прав доступа.
    • Результат: Изменение сертификатов/ключей выявляется.
    • Проверка:
      • Статус: Обязательно
      • Ревью меры контроля: Причина и комбинированный механизм (FIM + права) полностью адекватны. Приватные ключи — chmod 600, владелец root; сертификаты — 644.
      • Источник: Внешнее средство FIM; https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate
      • Связь с nginx: ssl_certificate, ssl_certificate_key, ssl_client_certificate
      • Контролируемые пути (пример): /etc/nginx/ssl/, /etc/ssl/nginx/
      • Пример реализации: 
        # /etc/afick.conf (фрагмент)
/etc/nginx/ssl/           R

# Права доступа
# chmod 600 /etc/nginx/ssl/*.key
# chmod 644 /etc/nginx/ssl/*.crt
# chown root:root /etc/nginx/ssl/
      • Проверка эффективности контроля: 
        afick -c /etc/afick.conf --check
ls -la /etc/nginx/ssl/
stat -c '%a %U %n' /etc/nginx/ssl/*
# Ключи: 600, сертификаты: 644, владелец root
    • Примечание: См. права и полномочия в Минимально необходимые полномочия nginx — проверка.md п. 6–7.

  12. Файлы паролей Basic Authentication

    • Причина: Изменение файла пользователей может привести к несанкционированному доступу.
    • Механизм: afick или иной утверждённый механизм контроля целостности + ограничение прав доступа.
    • Результат: Изменение файла пользователей выявляется.
    • Проверка:
      • Статус: Условно (если используется auth_basic)
      • Ревью меры контроля: Причина и механизм корректны. FIM + chmod 640, владелец root, группа nginx (или без доступа для others).
      • Источник: Внешнее средство FIM; https://nginx.org/en/docs/http/ngx_http_auth_basic_module.html#auth_basic_user_file
      • Связь с nginx: auth_basic_user_file
      • Контролируемые пути (пример): /etc/nginx/htpasswd, /etc/nginx/htpasswd.d/
      • Пример реализации: 
        # /etc/afick.conf (фрагмент) — при использовании auth_basic
/etc/nginx/htpasswd       R

# chmod 640 /etc/nginx/htpasswd
# chown root:root /etc/nginx/htpasswd
      • Проверка эффективности контроля: 
        nginx -T 2>/dev/null | grep auth_basic_user_file
ls -la /etc/nginx/htpasswd
afick -c /etc/afick.conf --check
    • Примечание: См. права и полномочия в Минимально необходимые полномочия nginx — проверка.md п. 8.

  13. Файлы журналов nginx

    • Причина: Журналы содержат события доступа и ошибок, важные для анализа безопасности.
    • Механизм: Контроль прав доступа; защита от несанкционированного изменения; централизованное журналирование.
    • Результат: Несанкционированное изменение или удаление журналов затруднено/выявляется.
    • Проверка:
      • Статус: Комбинированная мера
      • Ревью меры контроля: Причина корректна. Классический FIM на активно пишущиеся log-файлы неприменим (ложные срабатывания при каждой записи). Корректный подход: строгие права (adm/root), передача в syslog (см. ПМИ п. 14), ротация logrotate, опционально chattr +a (append-only). Механизм в исходнике описан верно.
      • Источник: Внешняя мера; https://nginx.org/en/docs/ngx_core_module.html#error_log , https://nginx.org/en/docs/syslog.html
      • Связь с nginx: access_log, error_log
      • Контролируемые пути (пример): /var/log/nginx/access.log, /var/log/nginx/error.log
      • Пример реализации: 
        # Права доступа (не afick на сами log-файлы)
# chown root:adm /var/log/nginx/
# chmod 750 /var/log/nginx/
# chmod 640 /var/log/nginx/*.log

# Централизованное журналирование в nginx.conf:
# access_log syslog:server=192.168.1.1:514,... combined;
# error_log syslog:server=192.168.1.1:514,...;

# Опционально append-only (осторожно с ротацией):
# chattr +a /var/log/nginx/access.log
      • Проверка эффективности контроля: 
        ls -la /var/log/nginx/
stat -c '%a %U:%G' /var/log/nginx/access.log
# Попытка удаления от непривилегированного пользователя должна завершиться отказом
nginx -T 2>/dev/null | grep -E 'access_log|error_log'
# При syslog — проверить наличие записей на приёмнике (journalctl -t nginx)
    • Примечание: Статус — комбинированная мера. См. Минимально необходимые полномочия nginx — проверка.md п. 5; ПМИ п. 14 в Проверочные мероприятия для ПМИ — проверка.md; функции 4.4 и 9.3 в функции безопасности — проверка.md.
Reference in New Issue View Git Blame Copy Permalink