init
This commit is contained in:
Redsandyg
451
docs/Контроль_выполнения_кода_—_проверка.md
Normal file
451
docs/Контроль_выполнения_кода_—_проверка.md
Normal file
@@ -0,0 +1,451 @@
|
||||
# Контроль выполнения кода 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.
|
||||
- Проверка:
|
||||
- **Статус:** Реализуемо
|
||||
- **Ревью меры контроля:** Требование адекватно. Дополнительно: запретить `<!--#exec cmd="..."-->` в 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`.
|
||||
@@ -0,0 +1,356 @@
|
||||
# Контроль целостности хранимого кода и конфигурации — результаты проверки
|
||||
|
||||
**Дата проверки:** 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
|
||||
```
|
||||
- **Проверка эффективности контроля:**
|
||||
```bash
|
||||
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
|
||||
```
|
||||
- **Проверка эффективности контроля:**
|
||||
```bash
|
||||
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
|
||||
```
|
||||
- **Проверка эффективности контроля:**
|
||||
```bash
|
||||
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
|
||||
```
|
||||
- **Проверка эффективности контроля:**
|
||||
```bash
|
||||
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
|
||||
```
|
||||
- **Проверка эффективности контроля:**
|
||||
```bash
|
||||
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
|
||||
```
|
||||
- **Проверка эффективности контроля:**
|
||||
```bash
|
||||
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
|
||||
```
|
||||
- **Проверка эффективности контроля:**
|
||||
```bash
|
||||
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
|
||||
```
|
||||
- **Проверка эффективности контроля:**
|
||||
```bash
|
||||
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
|
||||
```
|
||||
- **Проверка эффективности контроля:**
|
||||
```bash
|
||||
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
|
||||
```
|
||||
- **Проверка эффективности контроля:**
|
||||
```bash
|
||||
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/
|
||||
```
|
||||
- **Проверка эффективности контроля:**
|
||||
```bash
|
||||
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
|
||||
```
|
||||
- **Проверка эффективности контроля:**
|
||||
```bash
|
||||
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
|
||||
```
|
||||
- **Проверка эффективности контроля:**
|
||||
```bash
|
||||
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`.
|
||||
339
docs/Минимально_необходимые_полномочия_nginx_—_проверка.md
Normal file
339
docs/Минимально_необходимые_полномочия_nginx_—_проверка.md
Normal file
@@ -0,0 +1,339 @@
|
||||
# Минимально необходимые полномочия 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
|
||||
- **Пример реализации:**
|
||||
```nginx
|
||||
# /etc/nginx/nginx.conf
|
||||
user nginx nginx;
|
||||
# или: user www-data www-data;
|
||||
worker_processes auto;
|
||||
```
|
||||
- **Проверка эффективности:**
|
||||
```bash
|
||||
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 {} \;
|
||||
```
|
||||
- **Проверка эффективности:**
|
||||
```bash
|
||||
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
|
||||
```
|
||||
- **Проверка эффективности:**
|
||||
```bash
|
||||
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/
|
||||
```
|
||||
```nginx
|
||||
location /uploads/ {
|
||||
root /var/www/static-only;
|
||||
dav_methods PUT;
|
||||
}
|
||||
```
|
||||
- **Проверка эффективности:**
|
||||
```bash
|
||||
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
|
||||
```
|
||||
```nginx
|
||||
# Альтернатива: централизованное журналирование
|
||||
# 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;
|
||||
```
|
||||
- **Проверка эффективности:**
|
||||
```bash
|
||||
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/
|
||||
```
|
||||
- **Проверка эффективности:**
|
||||
```bash
|
||||
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
|
||||
```
|
||||
- **Проверка эффективности:**
|
||||
```bash
|
||||
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
|
||||
```
|
||||
- **Проверка эффективности:**
|
||||
```bash
|
||||
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
|
||||
```
|
||||
```nginx
|
||||
location ~ \.php$ {
|
||||
fastcgi_pass unix:/run/php/php-fpm.sock;
|
||||
}
|
||||
```
|
||||
- **Проверка эффективности:**
|
||||
```bash
|
||||
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
|
||||
```
|
||||
```nginx
|
||||
load_module modules/ngx_http_geoip_module.so;
|
||||
```
|
||||
- **Проверка эффективности:**
|
||||
```bash
|
||||
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
|
||||
- **Пример реализации:**
|
||||
```nginx
|
||||
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/
|
||||
```
|
||||
- **Проверка эффективности:**
|
||||
```bash
|
||||
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
|
||||
- **Пример реализации:**
|
||||
```nginx
|
||||
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
|
||||
```
|
||||
- **Проверка эффективности:**
|
||||
```bash
|
||||
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`.
|
||||
408
docs/Минимизация_поверхности_атаки_nginx_—_проверка.md
Normal file
408
docs/Минимизация_поверхности_атаки_nginx_—_проверка.md
Normal file
@@ -0,0 +1,408 @@
|
||||
# Минимизация поверхности атаки nginx — результаты проверки
|
||||
|
||||
**Дата проверки:** 10.06.2026
|
||||
**Объект проверки:** upstream nginx + меры минимизации поверхности атаки
|
||||
**Метод:** ревью мер минимизации, подтверждение по документации nginx, примеры реализации и команды аудита (без практической настройки на стенде)
|
||||
|
||||
## Сводная таблица
|
||||
|
||||
| № | Объект минимизации | Статус | Уровень |
|
||||
|---|-------------------|--------|---------|
|
||||
| 1 | Состав обязательных модулей | Организационная мера | сборка / поставка |
|
||||
| 2 | Состав необязательных модулей | Организационная мера | сборка / поставка |
|
||||
| 3 | Динамические модули | Комбинированная мера | конфигурация + FIM |
|
||||
| 4 | Auth Request | Условно (если используется) | конфигурация |
|
||||
| 5 | WebDAV | Условно (если используется) | конфигурация |
|
||||
| 6 | njs | Условно (если используется) | сборка / конфигурация |
|
||||
| 7 | Perl module | Условно (если используется) | сборка / конфигурация |
|
||||
| 8 | XSLT | Условно (если используется) | конфигурация |
|
||||
| 9 | SSI | Условно (если используется) | конфигурация |
|
||||
| 10 | Autoindex | Реализуемо | конфигурация |
|
||||
| 11 | Лишние HTTP-методы | Реализуемо | конфигурация |
|
||||
| 12 | Reverse proxy / upstream | Реализуемо | конфигурация |
|
||||
| 13 | FastCGI/uWSGI/SCGI/gRPC | Реализуемо | конфигурация |
|
||||
| 14 | Права файловой системы | Комбинированная мера | ОС |
|
||||
| 15 | Пользователь и группа nginx | Реализуемо | конфигурация / процесс |
|
||||
|
||||
---
|
||||
|
||||
1. **Состав обязательных модулей**
|
||||
- Что необходимо определить: Какие модули нужны для базовой работы nginx как веб-сервера.
|
||||
- Возможное решение: Оставить обязательные модули в базовой поставке.
|
||||
- Риск / комментарий: Нужно не нарушить штатные сценарии эксплуатации.
|
||||
- Проверка:
|
||||
- **Статус:** Организационная мера
|
||||
- **Ревью меры минимизации:** Задача и решение корректны. nginx не предоставляет runtime-API для отключения встроенных модулей — минимизация выполняется на этапе сборки (`./configure`) или выбора пакета поставки. Базовый набор: `http`, `core`, `events`, `ngx_http_core_module`, `ngx_http_static_module`, `ngx_http_log_module`, `ngx_http_access_module`. Риск «нарушить штатные сценарии» учтён: перечень обязательных модулей фиксируется в ТУ/эксплуатационной документации.
|
||||
- **Источник:** https://nginx.org/en/docs/configure.html , https://nginx.org/en/docs/
|
||||
- **Пример реализации:**
|
||||
```
|
||||
# Сборка с минимальным набором HTTP-модулей
|
||||
./configure \
|
||||
--with-http_ssl_module \
|
||||
--with-http_realip_module \
|
||||
--with-http_gzip_static_module \
|
||||
--with-http_stub_status_module
|
||||
|
||||
# В ТУ/ЭД: перечень обязательных модулей из вывода nginx -V
|
||||
```
|
||||
- **Проверка эффективности:**
|
||||
```bash
|
||||
nginx -V 2>&1
|
||||
# Сверить --with-* / --add-module с утверждённым перечнем в ТУ
|
||||
rpm -qi nginx 2>/dev/null || dpkg -s nginx 2>/dev/null
|
||||
```
|
||||
- **Примечание:** См. п. 24 в `Требования безопасности для включения в ТУ — проверка.md`.
|
||||
|
||||
2. **Состав необязательных модулей**
|
||||
- Что необходимо определить: Какие модули не нужны для базовой роли веб-сервера.
|
||||
- Возможное решение: Вынести в отдельные пакеты или не загружать по умолчанию.
|
||||
- Риск / комментарий: Возможны риски совместимости с существующими конфигурациями.
|
||||
- Проверка:
|
||||
- **Статус:** Организационная мера
|
||||
- **Ревью меры минимизации:** Решение адекватно. Необязательные модули (Perl, njs, XSLT, WebDAV, auth_request, stream и др.) исключаются при сборке (`--without-http_perl_module`, `--without-http_dav_module`) или поставляются отдельными пакетами (`nginx-module-perl`, `nginx-module-njs`). Риск совместимости снимается документированием: при обновлении поставки проверять `nginx -t` и наличие директив в конфигурации.
|
||||
- **Источник:** https://nginx.org/en/docs/configure.html
|
||||
- **Пример реализации:**
|
||||
```
|
||||
# Исключение при сборке
|
||||
./configure \
|
||||
--without-http_perl_module \
|
||||
--without-http_dav_module \
|
||||
--without-http_xslt_module \
|
||||
--without-http_auth_request_module
|
||||
|
||||
# Или: базовый пакет nginx без модулей-расширений;
|
||||
# опциональные модули — отдельные RPM/DEB, не устанавливаются по умолчанию
|
||||
```
|
||||
- **Проверка эффективности:**
|
||||
```bash
|
||||
nginx -V 2>&1 | grep -E 'perl|dav|xslt|auth_request|njs'
|
||||
# Ожидание: отсутствие неутверждённых модулей в выводе
|
||||
dpkg -l 'nginx-module-*' 2>/dev/null || rpm -qa 'nginx-module-*' 2>/dev/null
|
||||
```
|
||||
- **Примечание:** См. п. 24 в `Требования безопасности для включения в ТУ — проверка.md`.
|
||||
|
||||
3. **Динамические модули**
|
||||
- Что необходимо определить: Какие .so-модули разрешены к загрузке.
|
||||
- Возможное решение: Разрешить только утверждённый перечень модулей.
|
||||
- Риск / комментарий: Неразрешённый модуль может выполнять код в процессе nginx.
|
||||
- Проверка:
|
||||
- **Статус:** Комбинированная мера
|
||||
- **Ревью меры минимизации:** Решение полностью адекватно риску. Белый список `load_module` в конфигурации + FIM на каталог `.so` + организационный запрет сторонних модулей без процедуры утверждения.
|
||||
- **Источник:** https://nginx.org/en/docs/ngx_core_module.html#load_module
|
||||
- **Пример реализации:**
|
||||
```nginx
|
||||
# /etc/nginx/nginx.conf — только утверждённые модули
|
||||
load_module modules/ngx_http_geoip_module.so;
|
||||
# load_module /path/to/unapproved.so; # запрещено
|
||||
```
|
||||
```
|
||||
# /etc/afick.conf (фрагмент)
|
||||
/usr/lib/nginx/modules/ R
|
||||
```
|
||||
- **Проверка эффективности:**
|
||||
```bash
|
||||
nginx -T 2>/dev/null | grep load_module
|
||||
ls -la /usr/lib/nginx/modules/
|
||||
# Сверить с утверждённым перечнем в эксплуатационной документации
|
||||
afick -c /etc/afick.conf --check
|
||||
```
|
||||
- **Примечание:** См. п. 5 в `Контроль целостности хранимого кода и конфигурации — проверка.md`; п. 10–11 в `Контроль выполнения кода — проверка.md`.
|
||||
|
||||
4. **Auth Request**
|
||||
- Что необходимо определить: Требуется ли авторизация через внешний сервис в базовой поставке.
|
||||
- Возможное решение: Оставить только при наличии обоснованных сценариев.
|
||||
- Риск / комментарий: Модуль не является обязательным для простого веб-сервера.
|
||||
- Проверка:
|
||||
- **Статус:** Условно (если используется)
|
||||
- **Ревью меры минимизации:** Решение корректно. `ngx_http_auth_request_module` не нужен для статического веб-сервера с `auth_basic`. Включается только при сценарии делегированной авторизации (OAuth-шлюз, внешний IdP). Риск минимален при отсутствии модуля в сборке и директив в конфигурации.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_auth_request_module.html
|
||||
- **Пример реализации:**
|
||||
```nginx
|
||||
# Базовая конфигурация — auth_request не используется
|
||||
# При необходимости (после утверждения сценария):
|
||||
# location /protected/ {
|
||||
# auth_request /auth;
|
||||
# proxy_pass http://backend;
|
||||
# }
|
||||
```
|
||||
- **Проверка эффективности:**
|
||||
```bash
|
||||
nginx -V 2>&1 | grep auth_request
|
||||
nginx -T 2>/dev/null | grep -E 'auth_request|auth_request_set'
|
||||
# Ожидание для минимальной поставки: отсутствие директив
|
||||
```
|
||||
- **Примечание:** См. п. 4 в `Требования безопасности для включения в ТУ — проверка.md`.
|
||||
|
||||
5. **WebDAV**
|
||||
- Что необходимо определить: Требуется ли возможность записи/изменения файлов через HTTP.
|
||||
- Возможное решение: Отключить или не включать в базовую конфигурацию, если не требуется.
|
||||
- Риск / комментарий: Может позволить загрузку файлов, которые затем попадут в обработку.
|
||||
- Проверка:
|
||||
- **Статус:** Условно (если используется)
|
||||
- **Ревью меры минимизации:** Решение адекватно. WebDAV не включается в базовую конфигурацию. При необходимости — изолированный `location` без пересечения с FastCGI/uWSGI и без исполняемых расширений в upload-каталоге.
|
||||
- **Источник:** 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
|
||||
# }
|
||||
```
|
||||
- **Проверка эффективности:**
|
||||
```bash
|
||||
nginx -T 2>/dev/null | grep -E 'dav_methods|dav_access|create_full_put_path'
|
||||
# Ожидание: dav_methods отсутствует вне утверждённых location
|
||||
```
|
||||
- **Примечание:** См. п. 10 в `Контроль целостности хранимого кода и конфигурации — проверка.md`; п. 12 в `Контроль выполнения кода — проверка.md`.
|
||||
|
||||
6. **njs**
|
||||
- Что необходимо определить: Требуется ли серверная JavaScript-логика внутри nginx.
|
||||
- Возможное решение: Не включать или не загружать без обоснованной необходимости.
|
||||
- Риск / комментарий: Выполняет логику внутри процесса nginx.
|
||||
- Проверка:
|
||||
- **Статус:** Условно (если используется)
|
||||
- **Ревью меры минимизации:** Решение корректно. njs выполняет JavaScript в процессе worker — для базового веб-сервера не требуется. Не загружать `ngx_http_js_module.so`, не использовать `js_import`/`js_content` без утверждённого сценария.
|
||||
- **Источник:** https://nginx.org/en/docs/njs/
|
||||
- **Пример реализации:**
|
||||
```nginx
|
||||
# Базовая конфигурация — njs не используется
|
||||
# load_module modules/ngx_http_js_module.so; # только после утверждения
|
||||
```
|
||||
- **Проверка эффективности:**
|
||||
```bash
|
||||
nginx -V 2>&1 | grep -i njs
|
||||
nginx -T 2>/dev/null | grep -E 'js_import|js_content|js_set|load_module.*js'
|
||||
# Ожидание: отсутствие njs в минимальной поставке
|
||||
```
|
||||
- **Примечание:** См. п. 6 в `Контроль целостности хранимого кода и конфигурации — проверка.md`; п. 6 в `Контроль выполнения кода — проверка.md`.
|
||||
|
||||
7. **Perl module**
|
||||
- Что необходимо определить: Требуется ли Perl-логика внутри nginx.
|
||||
- Возможное решение: Не включать или не загружать без обоснованной необходимости.
|
||||
- Риск / комментарий: Выполняет логику внутри процесса nginx.
|
||||
- Проверка:
|
||||
- **Статус:** Условно (если используется)
|
||||
- **Ревью меры минимизации:** Решение полностью адекватно. Perl-модуль — наиболее рискованный встроенный интерпретатор. Рекомендация: не собирать (`--without-http_perl_module`), не устанавливать пакет `nginx-module-perl`.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_perl_module.html
|
||||
- **Пример реализации:**
|
||||
```
|
||||
# Сборка без Perl
|
||||
./configure --without-http_perl_module
|
||||
|
||||
# Конфигурация — директивы perl/perl_require отсутствуют
|
||||
```
|
||||
- **Проверка эффективности:**
|
||||
```bash
|
||||
nginx -V 2>&1 | grep -i perl
|
||||
nginx -T 2>/dev/null | grep -E 'perl|perl_require|perl_modules'
|
||||
# Ожидание: Perl отсутствует
|
||||
```
|
||||
- **Примечание:** См. п. 7 в `Контроль целостности хранимого кода и конфигурации — проверка.md`; п. 7 в `Контроль выполнения кода — проверка.md`.
|
||||
|
||||
8. **XSLT**
|
||||
- Что необходимо определить: Требуется ли преобразование XML через XSLT.
|
||||
- Возможное решение: Оставить только при наличии сценариев эксплуатации.
|
||||
- Риск / комментарий: Добавляет дополнительную поверхность обработки данных.
|
||||
- Проверка:
|
||||
- **Статус:** Условно (если используется)
|
||||
- **Ревью меры минимизации:** Решение корректно. XSLT-модуль не нужен для типового веб-сервера. При использовании — только утверждённые `.xslt` в FIM-области.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_xslt_module.html
|
||||
- **Пример реализации:**
|
||||
```nginx
|
||||
# Базовая конфигурация — XSLT не используется
|
||||
# xslt_stylesheet отсутствует
|
||||
```
|
||||
- **Проверка эффективности:**
|
||||
```bash
|
||||
nginx -V 2>&1 | grep xslt
|
||||
nginx -T 2>/dev/null | grep xslt_stylesheet
|
||||
# Ожидание: xslt_stylesheet отсутствует
|
||||
```
|
||||
- **Примечание:** См. п. 8 в `Контроль целостности хранимого кода и конфигурации — проверка.md`.
|
||||
|
||||
9. **SSI**
|
||||
- Что необходимо определить: Требуется ли обработка SSI-команд.
|
||||
- Возможное решение: Отключить в конфигурации, если не требуется.
|
||||
- Риск / комментарий: Может влиять на формирование ответа.
|
||||
- Проверка:
|
||||
- **Статус:** Условно (если используется)
|
||||
- **Ревью меры минимизации:** Решение адекватно. По умолчанию `ssi off`. При включении — запрет `<!--#exec-->`, контроль SSI-файлов через FIM (web-root).
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_ssi_module.html
|
||||
- **Пример реализации:**
|
||||
```nginx
|
||||
http {
|
||||
ssi off; # явно в базовой конфигурации
|
||||
}
|
||||
```
|
||||
- **Проверка эффективности:**
|
||||
```bash
|
||||
nginx -T 2>/dev/null | grep -i 'ssi on'
|
||||
# Ожидание: ssi on отсутствует вне утверждённых location
|
||||
grep -r '#exec' /var/www/ 2>/dev/null
|
||||
```
|
||||
- **Примечание:** См. п. 9 в `Контроль целостности хранимого кода и конфигурации — проверка.md`; п. 8 в `Контроль выполнения кода — проверка.md`.
|
||||
|
||||
10. **Autoindex**
|
||||
- Что необходимо определить: Требуется ли листинг директорий.
|
||||
- Возможное решение: Отключить по умолчанию.
|
||||
- Риск / комментарий: Раскрывает структуру директорий и файлов.
|
||||
- Проверка:
|
||||
- **Статус:** Реализуемо
|
||||
- **Ревью меры минимизации:** Решение полностью адекватно. `autoindex off` — значение по умолчанию; явное указание в `http {}` обеспечивает однозначность аудита. При отсутствии `index` — 403, не листинг.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_autoindex_module.html
|
||||
- **Пример реализации:**
|
||||
```nginx
|
||||
http {
|
||||
autoindex off;
|
||||
}
|
||||
```
|
||||
- **Проверка эффективности:**
|
||||
```bash
|
||||
nginx -T 2>/dev/null | grep autoindex
|
||||
# Ожидание: autoindex off или директива отсутствует (default off)
|
||||
curl -s -o /dev/null -w '%{http_code}' http://localhost/no-index-dir/
|
||||
# Ожидание: 403
|
||||
```
|
||||
- **Примечание:** См. п. 21 в `Проверочные мероприятия для ПМИ — проверка.md`; п. 21 в `Требования безопасности для включения в ТУ — проверка.md`.
|
||||
|
||||
11. **Лишние HTTP-методы**
|
||||
- Что необходимо определить: Какие методы реально нужны приложениям.
|
||||
- Возможное решение: Ограничить PUT, DELETE и другие методы, если они не требуются.
|
||||
- Риск / комментарий: Ненужные методы расширяют поверхность атаки.
|
||||
- Проверка:
|
||||
- **Статус:** Реализуемо
|
||||
- **Ревью меры минимизации:** Решение корректно. Для статического веб-сервера достаточно GET, HEAD, POST (если есть формы). PUT, DELETE, PATCH, OPTIONS — блокировать, если не требуются API/WebDAV.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_limit_except_module.html
|
||||
- **Пример реализации:**
|
||||
```nginx
|
||||
location / {
|
||||
limit_except GET HEAD POST {
|
||||
deny all;
|
||||
}
|
||||
root /var/www/html;
|
||||
}
|
||||
|
||||
# Альтернатива для глобального ограничения:
|
||||
# if ($request_method !~ ^(GET|HEAD|POST)$) {
|
||||
# return 405;
|
||||
# }
|
||||
```
|
||||
- **Проверка эффективности:**
|
||||
```bash
|
||||
nginx -T 2>/dev/null | grep -E 'limit_except|request_method'
|
||||
curl -s -o /dev/null -w '%{http_code}' -X DELETE http://localhost/
|
||||
# Ожидание: 403 или 405
|
||||
```
|
||||
- **Примечание:** См. п. 7 в `Требования безопасности для включения в ТУ — проверка.md`.
|
||||
|
||||
12. **Reverse proxy / upstream**
|
||||
- Что необходимо определить: Какие backend-направления разрешены.
|
||||
- Возможное решение: Разрешить только утверждённые backend-сервисы.
|
||||
- Риск / комментарий: Неверная настройка может открыть доступ к внутренним сервисам.
|
||||
- Проверка:
|
||||
- **Статус:** Реализуемо
|
||||
- **Ревью меры минимизации:** Решение адекватно риску SSRF и доступа к внутренним сервисам. Белый список `upstream` с фиксированными адресами; запрет произвольных `proxy_pass http://$variable` без валидации.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_proxy_module.html , https://nginx.org/en/docs/http/ngx_http_upstream_module.html
|
||||
- **Пример реализации:**
|
||||
```nginx
|
||||
upstream approved_backend {
|
||||
server 127.0.0.1:8080;
|
||||
server 10.0.0.5:8080;
|
||||
}
|
||||
|
||||
location /api/ {
|
||||
proxy_pass http://approved_backend;
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
}
|
||||
```
|
||||
- **Проверка эффективности:**
|
||||
```bash
|
||||
nginx -T 2>/dev/null | grep -E 'proxy_pass|upstream'
|
||||
# Сверить все proxy_pass с утверждённым перечнем backend
|
||||
# Нет proxy_pass на 127.0.0.1:22, 169.254.169.254 и т.п.
|
||||
```
|
||||
- **Примечание:** См. п. 4 в `Контроль выполнения кода — проверка.md`.
|
||||
|
||||
13. **FastCGI/uWSGI/SCGI/gRPC**
|
||||
- Что необходимо определить: Какие внешние обработчики допустимы.
|
||||
- Возможное решение: Разрешить только утверждённые обработчики и маршруты.
|
||||
- Риск / комментарий: Ошибка маршрутизации может привести к обработке неразрешённого кода.
|
||||
- Проверка:
|
||||
- **Статус:** Реализуемо
|
||||
- **Ревью меры минимизации:** Решение полностью адекватно. Включать только необходимые протоколы; фиксированные `*_pass` на утверждённые сокеты/адреса; `try_files $uri =404` перед FastCGI; безопасный `SCRIPT_FILENAME`.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html , https://nginx.org/en/docs/http/ngx_http_uwsgi_module.html , https://nginx.org/en/docs/http/ngx_http_scgi_module.html , https://nginx.org/en/docs/http/ngx_http_grpc_module.html
|
||||
- **Пример реализации:**
|
||||
```nginx
|
||||
# Только FastCGI — утверждённый PHP-FPM
|
||||
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;
|
||||
}
|
||||
# uwsgi_pass, scgi_pass, grpc_pass — только при утверждённом сценарии
|
||||
```
|
||||
- **Проверка эффективности:**
|
||||
```bash
|
||||
nginx -T 2>/dev/null | grep -E 'fastcgi_pass|uwsgi_pass|scgi_pass|grpc_pass'
|
||||
nginx -T 2>/dev/null | grep SCRIPT_FILENAME
|
||||
# Все *_pass — из утверждённого перечня
|
||||
# SCRIPT_FILENAME = $document_root$fastcgi_script_name
|
||||
```
|
||||
- **Примечание:** См. п. 1–5 в `Контроль выполнения кода — проверка.md`.
|
||||
|
||||
14. **Права файловой системы**
|
||||
- Что необходимо определить: Какие права нужны nginx для чтения/записи.
|
||||
- Возможное решение: Выдать минимально необходимые права.
|
||||
- Риск / комментарий: Избыточные права повышают риск компрометации.
|
||||
- Проверка:
|
||||
- **Статус:** Комбинированная мера
|
||||
- **Ревью меры минимизации:** Решение корректно. Worker-процесс должен иметь доступ только на чтение к web-root и конфигурации; запись — только в журналы, кэш, upload (если WebDAV). Ключи TLS — `600`, конфигурация — `644 root:root`, web-root — `755`/`644`, без world-writable.
|
||||
- **Источник:** https://nginx.org/en/docs/ngx_core_module.html#user
|
||||
- **Пример реализации:**
|
||||
```
|
||||
# Минимальные права
|
||||
chown -R root:root /etc/nginx/
|
||||
chmod 644 /etc/nginx/nginx.conf
|
||||
chown -R root:www-data /var/www/html/
|
||||
chmod -R 755 /var/www/html/
|
||||
find /var/www/html -type f -exec chmod 644 {} \;
|
||||
chmod 600 /etc/nginx/ssl/*.key
|
||||
chown root:adm /var/log/nginx/
|
||||
chmod 750 /var/log/nginx/
|
||||
```
|
||||
- **Проверка эффективности:**
|
||||
```bash
|
||||
namei -l /var/www/html/index.html
|
||||
ls -la /etc/nginx/ /var/www/ /var/log/nginx/
|
||||
stat -c '%a %U:%G %n' /etc/nginx/ssl/*
|
||||
# Нет каталогов с mode 777; ключи — 600
|
||||
```
|
||||
- **Примечание:** Детальный FIM — в `Контроль целостности хранимого кода и конфигурации — проверка.md` п. 3–4, 11. Здесь акцент на минимальных правах для worker.
|
||||
|
||||
15. **Пользователь и группа nginx**
|
||||
- Что необходимо определить: От чьего имени выполняются worker-процессы.
|
||||
- Возможное решение: Запускать worker-процессы от непривилегированного пользователя.
|
||||
- Риск / комментарий: Избыточные полномочия процесса повышают ущерб при компрометации.
|
||||
- Проверка:
|
||||
- **Статус:** Реализуемо
|
||||
- **Ревью меры минимизации:** Решение полностью адекватно. Master — root (для привязки к портам <1024), worker — непривилегированный пользователь (`nginx`, `www-data`). Директива `user` в конфигурации обязательна для однозначности.
|
||||
- **Источник:** https://nginx.org/en/docs/ngx_core_module.html#user
|
||||
- **Пример реализации:**
|
||||
```nginx
|
||||
# /etc/nginx/nginx.conf
|
||||
user nginx nginx;
|
||||
# или: user www-data www-data;
|
||||
```
|
||||
- **Проверка эффективности:**
|
||||
```bash
|
||||
nginx -T 2>/dev/null | grep '^user '
|
||||
ps aux | grep 'nginx: worker'
|
||||
# Worker-процессы — не root (UID != 0)
|
||||
id nginx 2>/dev/null || id www-data
|
||||
```
|
||||
- **Примечание:** Master-процесс остаётся root — это штатное поведение nginx для bind к 80/443.
|
||||
664
docs/Проверочные_мероприятия_для_ПМИ_—_проверка.md
Normal file
664
docs/Проверочные_мероприятия_для_ПМИ_—_проверка.md
Normal file
@@ -0,0 +1,664 @@
|
||||
# Проверочные мероприятия для ПМИ — результаты проверки
|
||||
|
||||
**Дата проверки:** 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 или иной механизм |
|
||||
|
||||
---
|
||||
|
||||
1. **Проверяемое требование:** Ограничение доступа по 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
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
location /admin/ {
|
||||
allow 192.168.1.100;
|
||||
deny all;
|
||||
}
|
||||
```
|
||||
- **Примеры команд испытания:**
|
||||
```bash
|
||||
# С разрешённого хоста (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-адреса испытательных хостов.
|
||||
|
||||
2. **Проверяемое требование:** Аутентификация по имени пользователя и паролю
|
||||
- **Настройка / механизм:** auth_basic; auth_basic_user_file
|
||||
- **Действия испытателя:** Настроить защищённый location. Выполнить запрос без учётных данных, с неверными и с корректными учётными данными.
|
||||
- **Ожидаемый результат:** Без учётных данных и с неверными данными доступ запрещён, с корректными данными доступ разрешён.
|
||||
- **Признак выполнения:** HTTP 401 для отказа и успешный ответ при корректной аутентификации.
|
||||
- Проверка:
|
||||
- **Статус:** Пригодно для ПМИ
|
||||
- **Ревью мероприятия:** Мероприятие полностью воспроизводимо. Три сценария (без credentials, неверные, верные) покрывают требование. Признак выполнения однозначен.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_auth_basic_module.html
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
location /secure/ {
|
||||
auth_basic "Restricted";
|
||||
auth_basic_user_file /etc/nginx/htpasswd;
|
||||
}
|
||||
```
|
||||
- **Примеры команд испытания:**
|
||||
```bash
|
||||
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 (или иной успешный код).
|
||||
|
||||
3. **Проверяемое требование:** Проверка клиентского 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
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
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;
|
||||
}
|
||||
```
|
||||
- **Примеры команд испытания:**
|
||||
```bash
|
||||
# Без клиентского сертификата — ошибка 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).
|
||||
|
||||
4. **Проверяемое требование:** Авторизация через внешний сервис
|
||||
- **Настройка / механизм:** 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
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
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;
|
||||
}
|
||||
```
|
||||
- **Примеры команд испытания:**
|
||||
```bash
|
||||
# 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.
|
||||
|
||||
5. **Проверяемое требование:** Комбинирование проверок доступа
|
||||
- **Настройка / механизм:** satisfy
|
||||
- **Действия испытателя:** Настроить совместное применение IP-ограничения и Basic Authentication. Проверить сценарии прохождения одной или нескольких проверок.
|
||||
- **Ожидаемый результат:** Доступ предоставляется в соответствии с выбранным режимом satisfy all/any.
|
||||
- **Признак выполнения:** Фактический доступ соответствует заданной политике.
|
||||
- Проверка:
|
||||
- **Статус:** Пригодно для ПМИ
|
||||
- **Ревью мероприятия:** Мероприятие корректно. Рекомендуется в протоколе явно фиксировать значение `satisfy` (all/any) и матрицу сценариев: IP+пароль, только IP, только пароль, ни то ни другое.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html#satisfy
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
location /admin/ {
|
||||
satisfy all;
|
||||
allow 10.0.0.0/8;
|
||||
deny all;
|
||||
auth_basic "Admin";
|
||||
auth_basic_user_file /etc/nginx/htpasswd;
|
||||
}
|
||||
```
|
||||
- **Примеры команд испытания:**
|
||||
```bash
|
||||
# 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`.
|
||||
|
||||
6. **Проверяемое требование:** Разграничение доступа по URL
|
||||
- **Настройка / механизм:** server; location
|
||||
- **Действия испытателя:** Настроить разные правила доступа для публичного и защищённого location. Выполнить запросы к обоим разделам.
|
||||
- **Ожидаемый результат:** Публичный раздел доступен, защищённый раздел доступен только при выполнении условий доступа.
|
||||
- **Признак выполнения:** Разные правила доступа применяются к разным URL.
|
||||
- Проверка:
|
||||
- **Статус:** Пригодно для ПМИ
|
||||
- **Ревью мероприятия:** Мероприятие корректно и воспроизводимо. Достаточно двух location с разными правилами.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html#location
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
location /public/ {
|
||||
root /var/www/html;
|
||||
}
|
||||
|
||||
location /admin/ {
|
||||
allow 10.0.0.0/8;
|
||||
deny all;
|
||||
root /var/www/html;
|
||||
}
|
||||
```
|
||||
- **Примеры команд испытания:**
|
||||
```bash
|
||||
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 с разрешённого.
|
||||
|
||||
7. **Проверяемое требование:** Ограничение HTTP-методов
|
||||
- **Настройка / механизм:** limit_except
|
||||
- **Действия испытателя:** Настроить ограничение методов. Выполнить запросы методами GET, POST, PUT, DELETE.
|
||||
- **Ожидаемый результат:** Разрешённые методы обрабатываются, запрещённые методы блокируются.
|
||||
- **Признак выполнения:** Запрещённые методы возвращают отказ.
|
||||
- Проверка:
|
||||
- **Статус:** Пригодно для ПМИ
|
||||
- **Ревью мероприятия:** Мероприятие корректно. В протоколе указать, какие методы разрешены в `limit_except`.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html#limit_except
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
location /api/ {
|
||||
limit_except GET POST {
|
||||
deny all;
|
||||
}
|
||||
proxy_pass http://backend;
|
||||
}
|
||||
```
|
||||
- **Примеры команд испытания:**
|
||||
```bash
|
||||
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.
|
||||
|
||||
8. **Проверяемое требование:** Запрет прямого доступа к внутренним ресурсам
|
||||
- **Настройка / механизм:** internal
|
||||
- **Действия испытателя:** Настроить internal location. Выполнить прямой запрос к нему и внутреннее перенаправление.
|
||||
- **Ожидаемый результат:** Прямой запрос запрещён, внутреннее перенаправление работает.
|
||||
- **Признак выполнения:** Прямой доступ получает отказ, внутренний сценарий успешен.
|
||||
- Проверка:
|
||||
- **Статус:** Пригодно для ПМИ
|
||||
- **Ревью мероприятия:** Мероприятие корректно. Прямой запрос к internal location возвращает 404 (не 403) — это штатное поведение nginx; признак выполнения следует трактовать как «отказ в доступе» (404).
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html#internal
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
location /protected/ {
|
||||
internal;
|
||||
alias /var/data/files/;
|
||||
}
|
||||
|
||||
location /download {
|
||||
rewrite ^ /protected/document.pdf last;
|
||||
}
|
||||
```
|
||||
- **Примеры команд испытания:**
|
||||
```bash
|
||||
# Прямой запрос — отказ
|
||||
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 и содержимое файла.
|
||||
|
||||
9. **Проверяемое требование:** Защита соединения 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
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
server {
|
||||
listen 443 ssl;
|
||||
server_name nginx-test;
|
||||
ssl_certificate /etc/nginx/ssl/server.crt;
|
||||
ssl_certificate_key /etc/nginx/ssl/server.key;
|
||||
}
|
||||
```
|
||||
- **Примеры команд испытания:**
|
||||
```bash
|
||||
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.
|
||||
|
||||
10. **Проверяемое требование:** Ограничение версий TLS и шифров
|
||||
- **Настройка / механизм:** ssl_protocols; ssl_ciphers
|
||||
- **Действия испытателя:** Настроить допустимые версии TLS и шифры. Выполнить подключение с разрешёнными и запрещёнными версиями/шифрами.
|
||||
- **Ожидаемый результат:** Разрешённые параметры работают, запрещённые отклоняются.
|
||||
- **Признак выполнения:** Результат подключения соответствует политике TLS.
|
||||
- Проверка:
|
||||
- **Статус:** Пригодно для ПМИ
|
||||
- **Ревью мероприятия:** Мероприятие корректно. Рекомендуется зафиксировать в ТУ/ПМИ конкретную политику (например, только TLSv1.2 и TLSv1.3).
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
ssl_protocols TLSv1.2 TLSv1.3;
|
||||
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
|
||||
```
|
||||
- **Примеры команд испытания:**
|
||||
```bash
|
||||
# Разрешённая версия
|
||||
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).
|
||||
|
||||
11. **Проверяемое требование:** Принудительное использование 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
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
server {
|
||||
listen 80;
|
||||
return 301 https://$host$request_uri;
|
||||
}
|
||||
|
||||
server {
|
||||
listen 443 ssl;
|
||||
add_header Strict-Transport-Security "max-age=31536000" always;
|
||||
}
|
||||
```
|
||||
- **Примеры команд испытания:**
|
||||
```bash
|
||||
curl -I http://nginx-test/
|
||||
curl -I https://nginx-test/
|
||||
```
|
||||
- **Проверка признака выполнения:** HTTP — `301` и заголовок `Location: https://...`; HTTPS — заголовок `Strict-Transport-Security`.
|
||||
|
||||
12. **Проверяемое требование:** Журналирование HTTP-запросов
|
||||
- **Настройка / механизм:** access_log; log_format
|
||||
- **Действия испытателя:** Выполнить несколько HTTP-запросов. Проверить появление записей в access log.
|
||||
- **Ожидаемый результат:** Запросы зарегистрированы в журнале.
|
||||
- **Признак выполнения:** В журнале присутствуют записи с требуемыми полями.
|
||||
- Проверка:
|
||||
- **Статус:** Пригодно для ПМИ
|
||||
- **Ревью мероприятия:** Мероприятие корректно. В ПМИ зафиксировать перечень обязательных полей журнала (IP, время, метод, URI, статус).
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_log_module.html
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
log_format pmi '$remote_addr - [$time_local] "$request" $status';
|
||||
access_log /var/log/nginx/access.log pmi;
|
||||
```
|
||||
- **Примеры команд испытания:**
|
||||
```bash
|
||||
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`, кодами ответа.
|
||||
|
||||
13. **Проверяемое требование:** Журналирование ошибок
|
||||
- **Настройка / механизм:** 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
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
error_log /var/log/nginx/error.log warn;
|
||||
|
||||
location /broken/ {
|
||||
proxy_pass http://127.0.0.1:59999;
|
||||
}
|
||||
```
|
||||
- **Примеры команд испытания:**
|
||||
```bash
|
||||
curl http://nginx-test/broken/
|
||||
tail -n 10 /var/log/nginx/error.log
|
||||
```
|
||||
- **Проверка признака выполнения:** В error log — запись об ошибке подключения к upstream (`connect() failed`).
|
||||
|
||||
14. **Проверяемое требование:** Передача журналов в syslog
|
||||
- **Настройка / механизм:** access_log syslog:...; error_log syslog:...
|
||||
- **Действия испытателя:** Настроить вывод журналов в syslog. Выполнить запросы и проверить внешнюю систему журналирования.
|
||||
- **Ожидаемый результат:** События передаются во внешнюю систему журналирования.
|
||||
- **Признак выполнения:** Записи обнаружены в syslog/централизованном журнале.
|
||||
- Проверка:
|
||||
- **Статус:** Требует внешних средств
|
||||
- **Ревью мероприятия:** Мероприятие корректно, но зависит от rsyslog/journald или централизованного SIEM. nginx только отправляет в syslog; приёмник — внешний компонент стенда.
|
||||
- **Источник:** https://nginx.org/en/docs/syslog.html
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
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;
|
||||
```
|
||||
- **Примеры команд испытания:**
|
||||
```bash
|
||||
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`.
|
||||
|
||||
15. **Проверяемое требование:** Ограничение частоты запросов
|
||||
- **Настройка / механизм:** limit_req_zone; limit_req
|
||||
- **Действия испытателя:** Настроить лимит запросов. Выполнить серию запросов с превышением лимита.
|
||||
- **Ожидаемый результат:** Избыточные запросы ограничиваются или отклоняются.
|
||||
- **Признак выполнения:** При превышении лимита сервер возвращает отказ/задержку согласно настройке.
|
||||
- Проверка:
|
||||
- **Статус:** Пригодно для ПМИ
|
||||
- **Ревью мероприятия:** Мероприятие корректно. По умолчанию nginx возвращает 503 при превышении `limit_req` (без `limit_req_status`).
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_limit_req_module.html
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
limit_req_zone $binary_remote_addr zone=one:10m rate=2r/s;
|
||||
|
||||
location / {
|
||||
limit_req zone=one burst=5 nodelay;
|
||||
}
|
||||
```
|
||||
- **Примеры команд испытания:**
|
||||
```bash
|
||||
for i in $(seq 1 20); do
|
||||
curl -s -o /dev/null -w "%{http_code}\n" http://nginx-test/
|
||||
done
|
||||
```
|
||||
- **Проверка признака выполнения:** Первые запросы — 200; при превышении лимита — 503 (или задержка при отсутствии `nodelay`).
|
||||
|
||||
16. **Проверяемое требование:** Ограничение количества соединений
|
||||
- **Настройка / механизм:** limit_conn_zone; limit_conn
|
||||
- **Действия испытателя:** Настроить лимит соединений. Открыть число соединений выше допустимого.
|
||||
- **Ожидаемый результат:** Лишние соединения отклоняются.
|
||||
- **Признак выполнения:** При превышении лимита сервер возвращает отказ.
|
||||
- Проверка:
|
||||
- **Статус:** Пригодно для ПМИ
|
||||
- **Ревью мероприятия:** Мероприятие корректно. Для воспроизведения удобен `ab` или параллельные `curl` с длительным запросом (sleep на backend).
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_limit_conn_module.html
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
limit_conn_zone $binary_remote_addr zone=addr:10m;
|
||||
|
||||
location / {
|
||||
limit_conn addr 2;
|
||||
}
|
||||
```
|
||||
- **Примеры команд испытания:**
|
||||
```bash
|
||||
for i in $(seq 1 5); do
|
||||
curl -s http://nginx-test/slow &
|
||||
done
|
||||
wait
|
||||
```
|
||||
- **Проверка признака выполнения:** Часть запросов получает 503 (`limit_conn_status` по умолчанию).
|
||||
|
||||
17. **Проверяемое требование:** Ограничение размера запроса
|
||||
- **Настройка / механизм:** client_max_body_size
|
||||
- **Действия испытателя:** Настроить максимальный размер тела запроса. Отправить запрос меньше и больше лимита.
|
||||
- **Ожидаемый результат:** Запрос меньше лимита принимается, больше лимита отклоняется.
|
||||
- **Признак выполнения:** Большой запрос получает ошибку ограничения размера.
|
||||
- Проверка:
|
||||
- **Статус:** Пригодно для ПМИ
|
||||
- **Ревью мероприятия:** Мероприятие корректно и полностью воспроизводимо.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
client_max_body_size 1m;
|
||||
```
|
||||
- **Примеры команд испытания:**
|
||||
```bash
|
||||
# Меньше лимита
|
||||
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.
|
||||
|
||||
18. **Проверяемое требование:** Настройка таймаутов
|
||||
- **Настройка / механизм:** 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
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
client_header_timeout 5s;
|
||||
client_body_timeout 5s;
|
||||
```
|
||||
- **Примеры команд испытания:**
|
||||
```bash
|
||||
# Медленная отправка тела (превышение 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`.
|
||||
|
||||
19. **Проверяемое требование:** Сокрытие версии nginx
|
||||
- **Настройка / механизм:** server_tokens off
|
||||
- **Действия испытателя:** Выполнить запрос и проверить заголовки/страницы ошибок.
|
||||
- **Ожидаемый результат:** Версия nginx не раскрывается в ответах.
|
||||
- **Признак выполнения:** В ответе отсутствует номер версии nginx.
|
||||
- Проверка:
|
||||
- **Статус:** Пригодно для ПМИ
|
||||
- **Ревью мероприятия:** Мероприятие корректно. `server_tokens off` убирает версию, но заголовок `Server: nginx` остаётся — это соответствует документации.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html#server_tokens
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
http {
|
||||
server_tokens off;
|
||||
}
|
||||
```
|
||||
- **Примеры команд испытания:**
|
||||
```bash
|
||||
curl -I http://nginx-test/
|
||||
curl http://nginx-test/nonexistent-page
|
||||
```
|
||||
- **Проверка признака выполнения:** Заголовок `Server: nginx` без номера версии (не `nginx/1.24.0`); в теле ошибки 404 нет номера версии.
|
||||
|
||||
20. **Проверяемое требование:** Управление страницами ошибок
|
||||
- **Настройка / механизм:** error_page
|
||||
- **Действия испытателя:** Настроить пользовательскую страницу ошибки. Вызвать ошибку 404/403/500.
|
||||
- **Ожидаемый результат:** Отображается настроенная страница ошибки без раскрытия лишних деталей.
|
||||
- **Признак выполнения:** Пользователь видит заданную страницу ошибки.
|
||||
- Проверка:
|
||||
- **Статус:** Пригодно для ПМИ
|
||||
- **Ревью мероприятия:** Мероприятие корректно и воспроизводимо.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html#error_page
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
error_page 404 /custom_404.html;
|
||||
|
||||
location = /custom_404.html {
|
||||
root /var/www/errors;
|
||||
internal;
|
||||
}
|
||||
```
|
||||
- **Примеры команд испытания:**
|
||||
```bash
|
||||
curl http://nginx-test/nonexistent-page
|
||||
```
|
||||
- **Проверка признака выполнения:** Тело ответа содержит текст/разметку из `/var/www/errors/custom_404.html`, а не стандартную страницу nginx.
|
||||
|
||||
21. **Проверяемое требование:** Отключение листинга директорий
|
||||
- **Настройка / механизм:** autoindex off
|
||||
- **Действия испытателя:** Обратиться к директории без индексного файла.
|
||||
- **Ожидаемый результат:** Листинг директории не отображается.
|
||||
- **Признак выполнения:** Сервер возвращает отказ или штатную ошибку, но не список файлов.
|
||||
- Проверка:
|
||||
- **Статус:** Пригодно для ПМИ
|
||||
- **Ревью мероприятия:** Мероприятие корректно. `autoindex off` — значение по умолчанию; при отсутствии index.html ожидается 403.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_autoindex_module.html
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
location /files/ {
|
||||
autoindex off;
|
||||
root /var/www/html;
|
||||
}
|
||||
```
|
||||
- **Примеры команд испытания:**
|
||||
```bash
|
||||
curl http://nginx-test/files/
|
||||
```
|
||||
- **Проверка признака выполнения:** Ответ 403 Forbidden (или 404), в теле нет HTML-листинга с перечнем файлов.
|
||||
|
||||
22. **Проверяемое требование:** Обратное проксирование 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
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
location /api/ {
|
||||
proxy_pass http://127.0.0.1:8080/;
|
||||
}
|
||||
```
|
||||
- **Примеры команд испытания:**
|
||||
```bash
|
||||
# Через nginx — успех
|
||||
curl http://nginx-test/api/status
|
||||
|
||||
# Прямой доступ к backend (с испытательной машины, если backend на 127.0.0.1 — недоступен)
|
||||
curl http://127.0.0.1:8080/status
|
||||
```
|
||||
- **Проверка признака выполнения:** Запрос через nginx возвращает ответ backend; прямой доступ с внешней сети к порту 8080 — отказ (если изоляция настроена).
|
||||
|
||||
23. **Проверяемое требование:** Ограничение директорий веб-контента
|
||||
- **Настройка / механизм:** root; alias; location; try_files
|
||||
- **Действия испытателя:** Настроить разрешённую директорию веб-контента. Выполнить запрос к файлу внутри и вне разрешённой директории.
|
||||
- **Ожидаемый результат:** Файлы внутри разрешённой директории доступны, вне директории не обслуживаются.
|
||||
- **Признак выполнения:** Доступ к произвольным каталогам ОС отсутствует.
|
||||
- Проверка:
|
||||
- **Статус:** Пригодно для ПМИ
|
||||
- **Ревью мероприятия:** Мероприятие корректно. Для «вне директории» использовать path traversal (`/../etc/passwd`) или запрос к URI вне `root`.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html#root
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
server {
|
||||
root /var/www/app/public;
|
||||
|
||||
location / {
|
||||
try_files $uri =404;
|
||||
}
|
||||
}
|
||||
```
|
||||
- **Примеры команд испытания:**
|
||||
```bash
|
||||
# Файл внутри 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` не отдаётся).
|
||||
|
||||
24. **Проверяемое требование:** Контроль целостности
|
||||
- **Настройка / механизм:** 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
|
||||
```
|
||||
- **Примеры команд испытания:**
|
||||
```bash
|
||||
# Базовая проверка (без изменений)
|
||||
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.
|
||||
547
docs/Требования_безопасности_для_включения_в_ТУ_—_проверка.md
Normal file
547
docs/Требования_безопасности_для_включения_в_ТУ_—_проверка.md
Normal file
@@ -0,0 +1,547 @@
|
||||
# Требования безопасности для включения в ТУ — результаты проверки
|
||||
|
||||
**Дата проверки:** 10.06.2026
|
||||
**Объект проверки:** upstream nginx (официальная документация nginx.org)
|
||||
**Метод:** анализ официальной документации, примеры конфигурации и вывод о пригодности требований для включения в ТУ (без практических тестов на работающем экземпляре)
|
||||
|
||||
## Сводная таблица
|
||||
|
||||
| № | Требование | Статус | Механизм nginx |
|
||||
|---|------------|--------|----------------|
|
||||
| 1 | Ограничение доступа по IP-адресу | Подтверждено | ngx_http_access_module; allow; deny |
|
||||
| 2 | Аутентификация по имени пользователя и паролю | Подтверждено | ngx_http_auth_basic_module |
|
||||
| 3 | Аутентификация по клиентскому TLS-сертификату | Подтверждено с оговорками | ngx_http_ssl_module |
|
||||
| 4 | Авторизация через внешний сервис | Подтверждено с оговорками | ngx_http_auth_request_module |
|
||||
| 5 | Комбинирование механизмов доступа | Подтверждено | satisfy |
|
||||
| 6 | Разграничение доступа по URL и виртуальным серверам | Подтверждено | server; location |
|
||||
| 7 | Ограничение HTTP-методов | Подтверждено | limit_except |
|
||||
| 8 | Запрет прямого доступа к внутренним ресурсам | Подтверждено | internal |
|
||||
| 9 | Защита соединения с использованием TLS | Подтверждено с оговорками | ngx_http_ssl_module |
|
||||
| 10 | Ограничение версий TLS и наборов шифров | Подтверждено | ssl_protocols; ssl_ciphers |
|
||||
| 11 | Принудительное использование HTTPS | Подтверждено | return; add_header (HSTS) |
|
||||
| 12 | Журналирование HTTP-запросов | Подтверждено | access_log; log_format |
|
||||
| 13 | Журналирование ошибок | Подтверждено | error_log |
|
||||
| 14 | Передача журналов во внешнюю систему | Подтверждено | syslog |
|
||||
| 15 | Ограничение частоты запросов | Подтверждено | ngx_http_limit_req_module |
|
||||
| 16 | Ограничение количества соединений | Подтверждено | ngx_http_limit_conn_module |
|
||||
| 17 | Ограничение размера клиентского запроса | Подтверждено | client_max_body_size |
|
||||
| 18 | Настройка таймаутов соединений | Подтверждено | client_*_timeout; send_timeout; keepalive_timeout |
|
||||
| 19 | Сокрытие версии веб-сервера | Подтверждено | server_tokens off |
|
||||
| 20 | Управление страницами ошибок | Подтверждено | error_page |
|
||||
| 21 | Управление листингом директорий | Подтверждено | autoindex off |
|
||||
| 22 | Обратное проксирование backend-сервисов | Подтверждено | proxy_pass; proxy_set_header |
|
||||
| 23 | Управление директориями веб-контента | Подтверждено | root; alias; location; try_files |
|
||||
| 24 | Минимизация поверхности атаки | Подтверждено с оговорками | configure; load_module; конфигурация |
|
||||
|
||||
---
|
||||
|
||||
1. **Ограничение доступа по IP-адресу**
|
||||
- Требование для ТУ: Веб-сервер должен обеспечивать возможность ограничения доступа к защищаемым ресурсам по IP-адресу клиента.
|
||||
- Механизм nginx: ngx_http_access_module; allow; deny
|
||||
- Комментарий: Проверяется через настройку разрешённых и запрещённых IP-адресов.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью требования:** Формулировка требования согласуется с возможностями nginx.
|
||||
- **Вывод для ТУ:** Требование может быть включено в ТУ — nginx обеспечивает ограничение доступа по IP-адресу клиента.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_access_module.html
|
||||
- **Результат:** Модуль `ngx_http_access_module` входит в стандартную сборку nginx. Директивы `allow` и `deny` позволяют задавать правила доступа по IP-адресу, сети CIDR или `all`, что полностью соответствует формулировке требования.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
location /admin/ {
|
||||
allow 192.168.1.0/24;
|
||||
allow 10.0.0.1;
|
||||
deny all;
|
||||
}
|
||||
```
|
||||
|
||||
2. **Аутентификация по имени пользователя и паролю**
|
||||
- Требование для ТУ: Веб-сервер должен обеспечивать возможность аутентификации пользователей по имени пользователя и паролю при доступе к защищаемым ресурсам.
|
||||
- Механизм nginx: ngx_http_auth_basic_module; auth_basic; auth_basic_user_file
|
||||
- Комментарий: Реализуется через HTTP Basic Authentication.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью требования:** Формулировка требования согласуется с возможностями nginx.
|
||||
- **Вывод для ТУ:** Требование может быть включено в ТУ — nginx поддерживает аутентификацию по имени пользователя и паролю.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_auth_basic_module.html
|
||||
- **Результат:** Модуль `ngx_http_auth_basic_module` реализует HTTP Basic Authentication. Директивы `auth_basic` и `auth_basic_user_file` обеспечивают проверку учётных данных пользователя при доступе к защищаемым ресурсам.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
location /secure/ {
|
||||
auth_basic "Restricted Area";
|
||||
auth_basic_user_file /etc/nginx/htpasswd;
|
||||
}
|
||||
```
|
||||
|
||||
3. **Аутентификация по клиентскому TLS-сертификату**
|
||||
- Требование для ТУ: Веб-сервер должен обеспечивать возможность проверки клиентского TLS-сертификата при доступе к защищаемым ресурсам.
|
||||
- Механизм nginx: ngx_http_ssl_module; ssl_client_certificate; ssl_verify_client
|
||||
- Комментарий: Применяется при использовании HTTPS и доверенного центра сертификации.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено с оговорками
|
||||
- **Ревью требования:** Описание и механизм в целом адекватны; учтены оговорки сборки, конфигурации или эксплуатации.
|
||||
- **Вывод для ТУ:** Требование может быть включено в ТУ — nginx обеспечивает проверку клиентского TLS-сертификата при использовании HTTPS.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_verify_client
|
||||
- **Результат:** Модуль `ngx_http_ssl_module` поддерживает проверку клиентских сертификатов через `ssl_verify_client` и `ssl_client_certificate`. Требуется сборка с SSL-модулем и настроенный HTTPS.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
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;
|
||||
}
|
||||
```
|
||||
- **Примечание:** В ТУ следует указать требование наличия SSL-модуля и доверенного CA.
|
||||
|
||||
4. **Авторизация через внешний сервис**
|
||||
- Требование для ТУ: Веб-сервер должен обеспечивать возможность принятия решения о доступе на основании ответа внешнего сервиса авторизации.
|
||||
- Механизм nginx: ngx_http_auth_request_module; auth_request
|
||||
- Комментарий: Наличие модуля зависит от состава сборки nginx.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено с оговорками
|
||||
- **Ревью требования:** Описание и механизм в целом адекватны; учтены оговорки сборки, конфигурации или эксплуатации.
|
||||
- **Вывод для ТУ:** Требование может быть включено в ТУ при условии наличия модуля `auth_request` в поставке nginx.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_auth_request_module.html
|
||||
- **Результат:** Модуль `ngx_http_auth_request_module` выполняет подзапрос к внешнему сервису авторизации и разрешает или запрещает доступ по коду ответа (2xx — разрешено, 401/403 — запрещено). Состав сборки nginx должен быть зафиксирован в ТУ.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
location = /auth {
|
||||
internal;
|
||||
proxy_pass http://auth-service:8080/validate;
|
||||
proxy_pass_request_body off;
|
||||
proxy_set_header Content-Length "";
|
||||
}
|
||||
|
||||
location / {
|
||||
auth_request /auth;
|
||||
}
|
||||
```
|
||||
- **Примечание:** В ТУ указать требование включения `--with-http_auth_request_module` или подтверждение наличия модуля в дистрибутивном пакете.
|
||||
|
||||
5. **Комбинирование механизмов доступа**
|
||||
- Требование для ТУ: Веб-сервер должен обеспечивать возможность совместного применения нескольких механизмов контроля доступа.
|
||||
- Механизм nginx: satisfy; allow; deny; auth_basic; auth_request
|
||||
- Комментарий: Например, доступ по IP или по паролю.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью требования:** Формулировка требования согласуется с возможностями nginx.
|
||||
- **Вывод для ТУ:** Требование может быть включено в ТУ — nginx позволяет комбинировать механизмы контроля доступа.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html#satisfy
|
||||
- **Результат:** Директива `satisfy` управляет логикой совместного применения `allow`/`deny`, `auth_basic` и `auth_request`. Значение `any` позволяет доступ при успехе любой проверки; `all` — при успехе всех.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
location /admin/ {
|
||||
satisfy any;
|
||||
allow 10.0.0.0/8;
|
||||
deny all;
|
||||
auth_basic "Admin";
|
||||
auth_basic_user_file /etc/nginx/htpasswd;
|
||||
}
|
||||
```
|
||||
|
||||
6. **Разграничение доступа по URL и виртуальным серверам**
|
||||
- Требование для ТУ: Веб-сервер должен обеспечивать возможность задания разных правил доступа для разных виртуальных серверов и разделов сайта.
|
||||
- Механизм nginx: server; location
|
||||
- Комментарий: Используется для разделения публичных, служебных и закрытых ресурсов.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью требования:** Формулировка требования согласуется с возможностями nginx.
|
||||
- **Вывод для ТУ:** Требование может быть включено в ТУ — nginx поддерживает разграничение по виртуальным серверам и URL.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html#server , https://nginx.org/en/docs/http/ngx_http_core_module.html#location
|
||||
- **Результат:** Блоки `server` определяют виртуальные хосты, блоки `location` — правила для URI-путей. Это базовый механизм nginx для задания разных правил доступа на разных серверах и разделах сайта.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
server {
|
||||
listen 80;
|
||||
server_name public.example.com;
|
||||
location / { root /var/www/public; }
|
||||
}
|
||||
|
||||
server {
|
||||
listen 80;
|
||||
server_name admin.example.com;
|
||||
location / {
|
||||
allow 10.0.0.0/8;
|
||||
deny all;
|
||||
root /var/www/admin;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
7. **Ограничение HTTP-методов**
|
||||
- Требование для ТУ: Веб-сервер должен обеспечивать возможность ограничения использования HTTP-методов для защищаемых ресурсов.
|
||||
- Механизм nginx: limit_except
|
||||
- Комментарий: Позволяет ограничивать методы PUT, DELETE и другие методы, если они не требуются.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью требования:** Формулировка требования согласуется с возможностями nginx.
|
||||
- **Вывод для ТУ:** Требование может быть включено в ТУ — nginx позволяет ограничивать HTTP-методы.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html#limit_except
|
||||
- **Результат:** Директива `limit_except` задаёт методы, для которых применяются вложенные правила доступа. Методы, не перечисленные в блоке, обрабатываются без дополнительных ограничений.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
location /uploads/ {
|
||||
limit_except GET HEAD {
|
||||
deny all;
|
||||
}
|
||||
}
|
||||
```
|
||||
- **Минимальный аудит конфигурации:**
|
||||
```bash
|
||||
nginx -T 2>/dev/null | grep -E 'limit_except|request_method'
|
||||
```
|
||||
- **Примечание:** См. `Минимизация поверхности атаки nginx — проверка.md` п. 11; `Проверочные мероприятия для ПМИ — проверка.md` п. 7.
|
||||
|
||||
8. **Запрет прямого доступа к внутренним ресурсам**
|
||||
- Требование для ТУ: Веб-сервер должен обеспечивать возможность запрета прямого доступа пользователя к внутренним ресурсам.
|
||||
- Механизм nginx: internal
|
||||
- Комментарий: Внутренние location-блоки доступны только для внутренних перенаправлений.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью требования:** Формулировка требования согласуется с возможностями nginx.
|
||||
- **Вывод для ТУ:** Требование может быть включено в ТУ — nginx обеспечивает запрет прямого доступа к внутренним ресурсам.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html#internal
|
||||
- **Результат:** Директива `internal` ограничивает доступ к location только для внутренних запросов (error_page, rewrite, X-Accel-Redirect и др.). Прямые клиентские запросы возвращают 404.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
location /protected/ {
|
||||
internal;
|
||||
alias /var/data/files/;
|
||||
}
|
||||
```
|
||||
|
||||
9. **Защита соединения с использованием TLS**
|
||||
- Требование для ТУ: Веб-сервер должен обеспечивать возможность защиты сетевого соединения с использованием TLS.
|
||||
- Механизм nginx: ngx_http_ssl_module; ssl_certificate; ssl_certificate_key
|
||||
- Комментарий: Используется для HTTPS-соединений.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено с оговорками
|
||||
- **Ревью требования:** Описание и механизм в целом адекватны; учтены оговорки сборки, конфигурации или эксплуатации. Модуль `ngx_http_ssl_module` обеспечивает HTTPS через `ssl_certificate` и `ssl_certificate_key`.
|
||||
- **Вывод для ТУ:** Требование может быть включено в ТУ — nginx обеспечивает защиту соединения с использованием TLS.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_ssl_module.html
|
||||
- **Результат:** Модуль `ngx_http_ssl_module` обеспечивает HTTPS через `ssl_certificate` и `ssl_certificate_key`. Требуется сборка с `--with-http_ssl_module` и библиотека OpenSSL.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
server {
|
||||
listen 443 ssl;
|
||||
server_name example.com;
|
||||
ssl_certificate /etc/nginx/ssl/example.com.crt;
|
||||
ssl_certificate_key /etc/nginx/ssl/example.com.key;
|
||||
}
|
||||
```
|
||||
|
||||
10. **Ограничение версий TLS и наборов шифров**
|
||||
- Требование для ТУ: Веб-сервер должен обеспечивать возможность задания допустимых версий TLS и наборов шифров.
|
||||
- Механизм nginx: ssl_protocols; ssl_ciphers
|
||||
- Комментарий: Конкретные допустимые значения должны определяться политикой безопасности.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью требования:** Формулировка требования согласуется с возможностями nginx. Директивы `ssl_protocols` и `ssl_ciphers` позволяют ограничить версии протокола и наборы шифров.
|
||||
- **Вывод для ТУ:** Требование может быть включено в ТУ — nginx позволяет задавать допустимые версии TLS и шифры; конкретные значения фиксируются в политике безопасности ТУ.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols , https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_ciphers
|
||||
- **Результат:** Директивы `ssl_protocols` и `ssl_ciphers` позволяют ограничить версии протокола и наборы шифров. Формулировка требования ТУ корректна: nginx обеспечивает возможность задания, а конкретные значения определяются политикой.
|
||||
- **Минимальный аудит конфигурации:**
|
||||
```bash
|
||||
nginx -T 2>/dev/null | grep -E 'limit_except|request_method'
|
||||
```
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
ssl_protocols TLSv1.2 TLSv1.3;
|
||||
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
|
||||
ssl_prefer_server_ciphers on;
|
||||
```
|
||||
- **Примечание:** В ТУ отдельно зафиксировать допустимую криптографическую политику (версии TLS, список шифров). См. `Минимизация поверхности атаки nginx — проверка.md` п. 11; `Проверочные мероприятия для ПМИ — проверка.md` п. 7.
|
||||
|
||||
11. **Принудительное использование HTTPS**
|
||||
- Требование для ТУ: Веб-сервер должен обеспечивать возможность перенаправления HTTP-запросов на HTTPS.
|
||||
- Механизм nginx: return 301/308; Strict-Transport-Security
|
||||
- Комментарий: HSTS реализуется через HTTP-заголовок.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью требования:** Формулировка требования согласуется с возможностями nginx. Редирект HTTP→HTTPS реализуется директивой `return 301` или `308`.
|
||||
- **Вывод для ТУ:** Требование может быть включено в ТУ — nginx обеспечивает перенаправление HTTP на HTTPS и заголовок HSTS.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#return , https://nginx.org/en/docs/http/ngx_http_headers_module.html#add_header
|
||||
- **Результат:** Редирект HTTP→HTTPS реализуется директивой `return 301` или `308`. Заголовок `Strict-Transport-Security` добавляется через `add_header` в HTTPS-блоке.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
server {
|
||||
listen 80;
|
||||
server_name example.com;
|
||||
return 301 https://$host$request_uri;
|
||||
}
|
||||
|
||||
server {
|
||||
listen 443 ssl;
|
||||
server_name example.com;
|
||||
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
|
||||
}
|
||||
```
|
||||
|
||||
12. **Журналирование HTTP-запросов**
|
||||
- Требование для ТУ: Веб-сервер должен обеспечивать регистрацию HTTP-запросов пользователей.
|
||||
- Механизм nginx: access_log; log_format
|
||||
- Комментарий: В журнале должны фиксироваться параметры, необходимые для анализа событий.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью требования:** Формулировка требования согласуется с возможностями nginx. Модуль `ngx_http_log_module` записывает access log.
|
||||
- **Вывод для ТУ:** Требование может быть включено в ТУ — nginx обеспечивает регистрацию HTTP-запросов в настраиваемом формате.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_log_module.html
|
||||
- **Результат:** Модуль `ngx_http_log_module` записывает access log. Директива `log_format` позволяет задать поля, необходимые для анализа событий безопасности (IP, время, запрос, статус, user-agent и др.).
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
log_format security '$remote_addr - $remote_user [$time_local] '
|
||||
'"$request" $status $body_bytes_sent '
|
||||
'"$http_referer" "$http_user_agent"';
|
||||
|
||||
access_log /var/log/nginx/access.log security;
|
||||
```
|
||||
|
||||
13. **Журналирование ошибок**
|
||||
- Требование для ТУ: Веб-сервер должен обеспечивать регистрацию ошибок обработки запросов и ошибок конфигурации.
|
||||
- Механизм nginx: error_log
|
||||
- Комментарий: Используется для диагностики и анализа событий безопасности.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью требования:** Формулировка требования согласуется с возможностями nginx. Директива `error_log` задаёт файл журнала и уровень детализации (`warn`, `error`, `crit` и др.
|
||||
- **Вывод для ТУ:** Требование может быть включено в ТУ — nginx обеспечивает регистрацию ошибок.
|
||||
- **Источник:** https://nginx.org/en/docs/ngx_core_module.html#error_log
|
||||
- **Результат:** Директива `error_log` задаёт файл журнала и уровень детализации (`warn`, `error`, `crit` и др.). Ошибки обработки запросов, конфигурации и взаимодействия с backend фиксируются в error log.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
error_log /var/log/nginx/error.log warn;
|
||||
```
|
||||
|
||||
14. **Передача журналов во внешнюю систему**
|
||||
- Требование для ТУ: Веб-сервер должен обеспечивать возможность передачи журналов во внешнюю систему журналирования.
|
||||
- Механизм nginx: syslog в access_log/error_log
|
||||
- Комментарий: Используется для централизованного сбора событий.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью требования:** Формулировка требования согласуется с возможностями nginx. nginx поддерживает запись `access_log` и `error_log` в syslog с параметрами `server`, `facility`, `tag`, `severity`, что обеспечивает централизованный сбор событий во внешней системе журналирования.
|
||||
- **Вывод для ТУ:** Требование может быть включено в ТУ — nginx поддерживает передачу журналов в syslog.
|
||||
- **Источник:** https://nginx.org/en/docs/syslog.html
|
||||
- **Результат:** nginx поддерживает запись `access_log` и `error_log` в syslog с параметрами `server`, `facility`, `tag`, `severity`, что обеспечивает централизованный сбор событий во внешней системе журналирования.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
error_log syslog:server=192.168.1.1:514,facility=local7,tag=nginx,severity=error;
|
||||
access_log syslog:server=192.168.1.1:514,facility=local7,tag=nginx,severity=info security;
|
||||
```
|
||||
|
||||
15. **Ограничение частоты запросов**
|
||||
- Требование для ТУ: Веб-сервер должен обеспечивать возможность ограничения частоты запросов от клиента.
|
||||
- Механизм nginx: limit_req_zone; limit_req
|
||||
- Комментарий: Снижает риск избыточной нагрузки и злоупотреблений.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью требования:** Формулировка требования согласуется с возможностями nginx. Модуль `ngx_http_limit_req_module` реализует ограничение частоты запросов по ключу (например, IP-адрес клиента) с использованием алгоритма leaky bucket.
|
||||
- **Вывод для ТУ:** Требование может быть включено в ТУ — nginx обеспечивает ограничение частоты запросов.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_limit_req_module.html
|
||||
- **Результат:** Модуль `ngx_http_limit_req_module` реализует ограничение частоты запросов по ключу (например, IP-адрес клиента) с использованием алгоритма leaky bucket.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
http {
|
||||
limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;
|
||||
|
||||
server {
|
||||
location / {
|
||||
limit_req zone=one burst=20 nodelay;
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
16. **Ограничение количества соединений**
|
||||
- Требование для ТУ: Веб-сервер должен обеспечивать возможность ограничения количества одновременных соединений.
|
||||
- Механизм nginx: limit_conn_zone; limit_conn
|
||||
- Комментарий: Снижает риск исчерпания ресурсов.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью требования:** Формулировка требования согласуется с возможностями nginx. Модуль `ngx_http_limit_conn_module` ограничивает число одновременных соединений по заданному ключу, что соответствует требованию ТУ.
|
||||
- **Вывод для ТУ:** Требование может быть включено в ТУ — nginx обеспечивает ограничение количества соединений.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_limit_conn_module.html
|
||||
- **Результат:** Модуль `ngx_http_limit_conn_module` ограничивает число одновременных соединений по заданному ключу, что соответствует требованию ТУ.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
http {
|
||||
limit_conn_zone $binary_remote_addr zone=addr:10m;
|
||||
|
||||
server {
|
||||
location / {
|
||||
limit_conn addr 10;
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
17. **Ограничение размера клиентского запроса**
|
||||
- Требование для ТУ: Веб-сервер должен обеспечивать возможность ограничения размера тела клиентского запроса.
|
||||
- Механизм nginx: client_max_body_size
|
||||
- Комментарий: Используется для защиты от чрезмерно больших запросов и нежелательных загрузок.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью требования:** Формулировка требования согласуется с возможностями nginx. Директива `client_max_body_size` задаёт максимальный размер тела запроса.
|
||||
- **Вывод для ТУ:** Требование может быть включено в ТУ — nginx обеспечивает ограничение размера тела запроса.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size
|
||||
- **Результат:** Директива `client_max_body_size` задаёт максимальный размер тела запроса. При превышении nginx возвращает 413 (Request Entity Too Large).
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
server {
|
||||
client_max_body_size 10m;
|
||||
}
|
||||
```
|
||||
|
||||
18. **Настройка таймаутов соединений**
|
||||
- Требование для ТУ: Веб-сервер должен обеспечивать возможность настройки таймаутов обработки клиентских соединений.
|
||||
- Механизм nginx: client_header_timeout; client_body_timeout; send_timeout; keepalive_timeout
|
||||
- Комментарий: Снижает риск удержания ресурсов медленными соединениями.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью требования:** Формулировка требования согласуется с возможностями nginx. Директивы `client_header_timeout`, `client_body_timeout`, `send_timeout` и `keepalive_timeout` позволяют задавать таймауты на разных этапах обработки клиентского соединения.
|
||||
- **Вывод для ТУ:** Требование может быть включено в ТУ — nginx обеспечивает настройку таймаутов соединений.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html
|
||||
- **Результат:** Директивы `client_header_timeout`, `client_body_timeout`, `send_timeout` и `keepalive_timeout` позволяют задавать таймауты на разных этапах обработки клиентского соединения.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
http {
|
||||
client_header_timeout 10s;
|
||||
client_body_timeout 10s;
|
||||
send_timeout 10s;
|
||||
keepalive_timeout 30s;
|
||||
}
|
||||
```
|
||||
|
||||
19. **Сокрытие версии веб-сервера**
|
||||
- Требование для ТУ: Веб-сервер должен обеспечивать возможность отключения раскрытия версии nginx в ответах сервера.
|
||||
- Механизм nginx: server_tokens off
|
||||
- Комментарий: Снижает объём информации, доступной внешнему пользователю.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью требования:** Формулировка требования согласуется с возможностями nginx. Директива `server_tokens off` убирает номер версии из заголовка `Server` и со страниц ошибок nginx.
|
||||
- **Вывод для ТУ:** Требование может быть включено в ТУ — nginx позволяет отключить раскрытие версии.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html#server_tokens
|
||||
- **Результат:** Директива `server_tokens off` убирает номер версии из заголовка `Server` и со страниц ошибок nginx.
|
||||
- **Минимальный аудит конфигурации:**
|
||||
```bash
|
||||
nginx -T 2>/dev/null | grep server_tokens
|
||||
```
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
http {
|
||||
server_tokens off;
|
||||
}
|
||||
```
|
||||
|
||||
20. **Управление страницами ошибок**
|
||||
- Требование для ТУ: Веб-сервер должен обеспечивать возможность настройки пользовательских страниц ошибок.
|
||||
- Механизм nginx: error_page
|
||||
- Комментарий: Позволяет не раскрывать технические детали пользователю.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью требования:** Формулировка требования согласуется с возможностями nginx. Директива `error_page` перенаправляет обработку указанных кодов ошибок на пользовательские страницы, скрывая технические детали nginx.
|
||||
- **Вывод для ТУ:** Требование может быть включено в ТУ — nginx обеспечивает настройку пользовательских страниц ошибок.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html#error_page
|
||||
- **Результат:** Директива `error_page` перенаправляет обработку указанных кодов ошибок на пользовательские страницы, скрывая технические детали nginx.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
error_page 404 /custom_404.html;
|
||||
error_page 500 502 503 504 /custom_50x.html;
|
||||
|
||||
location = /custom_404.html {
|
||||
root /var/www/errors;
|
||||
internal;
|
||||
}
|
||||
```
|
||||
|
||||
21. **Управление листингом директорий**
|
||||
- Требование для ТУ: Веб-сервер должен обеспечивать возможность отключения листинга директорий.
|
||||
- Механизм nginx: autoindex off
|
||||
- Комментарий: В безопасной конфигурации листинг директорий должен быть отключён, если не требуется.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью требования:** Формулировка требования согласуется с возможностями nginx. По умолчанию `autoindex off`. Директива `autoindex off` явно отключает формирование листинга каталога, что соответствует требованию безопасной конфигурации.
|
||||
- **Вывод для ТУ:** Требование может быть включено в ТУ — nginx позволяет отключить листинг директорий.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_autoindex_module.html
|
||||
- **Результат:** По умолчанию `autoindex off`. Директива `autoindex off` явно отключает формирование листинга каталога, что соответствует требованию безопасной конфигурации.
|
||||
- **Минимальный аудит конфигурации:**
|
||||
```bash
|
||||
nginx -T 2>/dev/null | grep autoindex
|
||||
```
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
server {
|
||||
autoindex off;
|
||||
root /var/www/html;
|
||||
}
|
||||
```
|
||||
- **Примечание:** См. `Минимизация поверхности атаки nginx — проверка.md` п. 10; `Проверочные мероприятия для ПМИ — проверка.md` п. 21.
|
||||
|
||||
22. **Обратное проксирование backend-сервисов**
|
||||
- Требование для ТУ: Веб-сервер должен обеспечивать возможность изоляции backend-сервисов через обратное проксирование.
|
||||
- Механизм nginx: proxy_pass; proxy_set_header
|
||||
- Комментарий: Backend-сервисы не должны быть доступны напрямую, если это предусмотрено архитектурой.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью требования:** Формулировка требования согласуется с возможностями nginx. Модуль `ngx_http_proxy_module` передаёт запросы на внутренние backend-сервисы.
|
||||
- **Вывод для ТУ:** Требование может быть включено в ТУ — nginx обеспечивает изоляцию backend через обратное проксирование.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_proxy_module.html
|
||||
- **Результат:** Модуль `ngx_http_proxy_module` передаёт запросы на внутренние backend-сервисы. `proxy_set_header` позволяет корректно передавать адрес клиента. Backend может быть недоступен напрямую извне при правильной сетевой архитектуре.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
location /api/ {
|
||||
proxy_pass http://127.0.0.1:8080;
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
proxy_set_header X-Forwarded-Proto $scheme;
|
||||
}
|
||||
```
|
||||
|
||||
23. **Управление директориями веб-контента**
|
||||
- Требование для ТУ: Веб-сервер должен обеспечивать возможность задания разрешённых директорий веб-контента.
|
||||
- Механизм nginx: root; alias; location; try_files
|
||||
- Комментарий: Требует безопасной настройки, чтобы исключить доступ к произвольным каталогам ОС.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью требования:** Формулировка требования согласуется с возможностями nginx. Директивы `root`, `alias`, `location` и `try_files` позволяют ограничить область обслуживаемого контента.
|
||||
- **Вывод для ТУ:** Требование может быть включено в ТУ — nginx позволяет задавать разрешённые директории веб-контента через конфигурацию.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html#root , https://nginx.org/en/docs/http/ngx_http_core_module.html#alias
|
||||
- **Результат:** Директивы `root`, `alias`, `location` и `try_files` позволяют ограничить область обслуживаемого контента. Встроенного allowlist нет — перечень разрешённых директорий фиксируется в ТУ и реализуется конфигурацией.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
server {
|
||||
root /var/www/app/public;
|
||||
|
||||
location / {
|
||||
try_files $uri =404;
|
||||
}
|
||||
|
||||
location ~ /\. {
|
||||
deny all;
|
||||
}
|
||||
}
|
||||
```
|
||||
- **Примечание:** В ТУ зафиксировать перечень разрешённых директорий веб-контента. См. `Минимизация поверхности атаки nginx — проверка.md` п. 10; `Проверочные мероприятия для ПМИ — проверка.md` п. 21.
|
||||
|
||||
24. **Минимизация поверхности атаки**
|
||||
- Требование для ТУ: Поставка и конфигурация веб-сервера должны обеспечивать возможность минимизации поверхности атаки за счёт исключения, отделения или незагрузки неиспользуемых модулей и функциональных возможностей.
|
||||
- Механизм nginx: параметры сборки; dynamic modules; load_module; конфигурация nginx
|
||||
- Комментарий: Конкретные меры определяются по составу поставки и целевой конфигурации.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено с оговорками
|
||||
- **Ревью требования:** Описание и механизм в целом адекватны; учтены оговорки сборки, конфигурации или эксплуатации. nginx позволяет исключать модули при сборке (`.
|
||||
- **Вывод для ТУ:** Требование может быть включено в ТУ как проектно-эксплуатационное — nginx предоставляет механизмы минимизации поверхности атаки; конкретные меры фиксируются в ТУ по составу поставки.
|
||||
- **Источник:** https://nginx.org/en/docs/configure.html , https://nginx.org/en/docs/ngx_core_module.html#load_module
|
||||
- **Результат:** nginx позволяет исключать модули при сборке (`./configure --without-...`), не загружать неиспользуемые динамические модули (`load_module`) и отключать возможности конфигурацией (`autoindex off`, удаление лишних `location`). Конкретный перечень мер определяется целевой конфигурацией и должен быть зафиксирован в ТУ.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
# Загрузка только утверждённых динамических модулей
|
||||
# load_module modules/ngx_http_geoip_module.so;
|
||||
|
||||
http {
|
||||
autoindex off;
|
||||
server_tokens off;
|
||||
# Неиспользуемые proxy/fastcgi-направления не включаются
|
||||
}
|
||||
```
|
||||
- **Примечание:** В ТУ указать: состав модулей поставки, запрет загрузки неутверждённых `.so`, перечень отключённых возможностей конфигурации. См. `Минимизация поверхности атаки nginx — проверка.md` п. 1–15.
|
||||
743
docs/функции безопасности — проверка.md
Normal file
743
docs/функции безопасности — проверка.md
Normal file
@@ -0,0 +1,743 @@
|
||||
# Функции безопасности nginx — результаты проверки
|
||||
|
||||
**Дата проверки:** 10.06.2026
|
||||
**Объект проверки:** upstream nginx (официальная документация nginx.org)
|
||||
**Метод:** анализ официальной документации и составление примеров конфигурации (без практических тестов на работающем экземпляре)
|
||||
|
||||
## Сводная таблица
|
||||
|
||||
| № | Функция безопасности | Статус | Модуль / механизм |
|
||||
|---|---------------------|--------|-------------------|
|
||||
| 1.1 | Ограничение доступа по IP-адресу | Подтверждено | ngx_http_access_module; allow; deny |
|
||||
| 1.2 | Аутентификация по имени пользователя и паролю | Подтверждено | ngx_http_auth_basic_module; auth_basic; auth_basic_user_file |
|
||||
| 1.3 | Аутентификация по клиентскому TLS-сертификату | Подтверждено с оговорками | ngx_http_ssl_module; ssl_verify_client |
|
||||
| 1.4 | Авторизация через внешний сервис | Подтверждено с оговорками | ngx_http_auth_request_module; auth_request |
|
||||
| 1.5 | Комбинирование нескольких проверок доступа | Подтверждено | satisfy; access; auth_basic; auth_request |
|
||||
| 2.1 | Разделение правил по виртуальным серверам и путям | Подтверждено | ngx_http_core_module; server; location |
|
||||
| 2.2 | Ограничение HTTP-методов | Подтверждено | ngx_http_core_module; limit_except |
|
||||
| 2.3 | Запрет доступа к служебным и скрытым файлам | Подтверждено | location; deny all |
|
||||
| 2.4 | Запрет прямого доступа к внутренним ресурсам | Подтверждено | ngx_http_core_module; internal |
|
||||
| 3.1 | Поддержка HTTPS/TLS | Подтверждено с оговорками | ngx_http_ssl_module; ssl_certificate |
|
||||
| 3.2 | Ограничение версий TLS и шифров | Подтверждено | ngx_http_ssl_module; ssl_protocols; ssl_ciphers |
|
||||
| 3.3 | Проверка клиентского сертификата | Подтверждено | ssl_client_certificate; ssl_verify_client |
|
||||
| 3.4 | Принудительное использование HTTPS | Подтверждено | return 301/308; Strict-Transport-Security |
|
||||
| 4.1 | Журналирование HTTP-запросов | Подтверждено | ngx_http_log_module; access_log |
|
||||
| 4.2 | Журналирование ошибок | Подтверждено | error_log |
|
||||
| 4.3 | Настройка формата журналов | Подтверждено | log_format |
|
||||
| 4.4 | Передача журналов в syslog | Подтверждено | access_log syslog; error_log syslog |
|
||||
| 5.1 | Ограничение частоты запросов | Подтверждено | ngx_http_limit_req_module; limit_req |
|
||||
| 5.2 | Ограничение количества соединений | Подтверждено | ngx_http_limit_conn_module; limit_conn |
|
||||
| 5.3 | Ограничение размера клиентского запроса | Подтверждено | ngx_http_core_module; client_max_body_size |
|
||||
| 5.4 | Ограничение скорости отдачи данных | Подтверждено | ngx_http_core_module; limit_rate |
|
||||
| 5.5 | Настройка таймаутов соединений | Подтверждено | client_*_timeout; send_timeout; keepalive_timeout |
|
||||
| 6.1 | Сокрытие версии nginx | Подтверждено | server_tokens off |
|
||||
| 6.2 | Управление страницами ошибок | Подтверждено | error_page |
|
||||
| 6.3 | Управление листингом директорий | Подтверждено | ngx_http_autoindex_module; autoindex |
|
||||
| 7.1 | Обратное проксирование HTTP/HTTPS | Подтверждено | ngx_http_proxy_module; proxy_pass |
|
||||
| 7.2 | Балансировка и группы upstream | Подтверждено | ngx_http_upstream_module; upstream |
|
||||
| 7.3 | Управление заголовками при проксировании | Подтверждено | proxy_set_header |
|
||||
| 8.1 | Задание корневой директории сайта | Подтверждено | ngx_http_core_module; root |
|
||||
| 8.2 | Задание альтернативного пути для location | Подтверждено | ngx_http_core_module; alias |
|
||||
| 8.3 | Проверка существования файлов и маршрутизация | Подтверждено | ngx_http_core_module; try_files |
|
||||
| 8.4 | Ограничение доступа к произвольным каталогам ОС | Подтверждено | root; alias; location; права ФС |
|
||||
| 9.1 | Исключение неиспользуемых модулей | Подтверждено | configure; load_module |
|
||||
| 9.2 | Отключение неиспользуемых возможностей конфигурацией | Подтверждено | конфигурация nginx |
|
||||
| 9.3 | Контроль целостности конфигурации и разрешённых директорий | Не применимо к nginx напрямую (внешняя мера) | afick или иной FIM |
|
||||
|
||||
---
|
||||
|
||||
- **1. Идентификация и аутентификация**
|
||||
- **1.1 Ограничение доступа по IP-адресу**
|
||||
- Описание реализации: nginx позволяет ограничивать доступ к ресурсам по IP-адресам клиентов. Для этого используются правила разрешения и запрета доступа.
|
||||
- Модуль / механизм: ngx_http_access_module; директивы allow, deny
|
||||
- Комментарий: Подтверждено официальной документацией nginx: модуль предназначен для ограничения доступа по адресам клиентов.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. Модуль `ngx_http_access_module` входит в стандартную сборку nginx.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_access_module.html
|
||||
- **Результат:** Модуль `ngx_http_access_module` входит в стандартную сборку nginx. Директивы `allow` и `deny` задают правила доступа по IP-адресу, сети CIDR, `all` или `unix:`. Правила обрабатываются последовательно; первое совпавшее правило определяет результат.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
location /admin/ {
|
||||
allow 192.168.1.0/24;
|
||||
allow 10.0.0.1;
|
||||
deny all;
|
||||
}
|
||||
```
|
||||
- **1.2 Аутентификация по имени пользователя и паролю**
|
||||
- Описание реализации: nginx поддерживает HTTP Basic Authentication: пользователь вводит имя и пароль, nginx проверяет их по файлу пользователей.
|
||||
- Модуль / механизм: ngx_http_auth_basic_module; директивы auth_basic, auth_basic_user_file
|
||||
- Комментарий: Подтверждено официальной документацией nginx: модуль валидирует имя пользователя и пароль по протоколу HTTP Basic Authentication.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. Модуль `ngx_http_auth_basic_module` реализует HTTP Basic Authentication.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_auth_basic_module.html
|
||||
- **Результат:** Модуль `ngx_http_auth_basic_module` реализует HTTP Basic Authentication. Директива `auth_basic` включает аутентификацию и задаёт текстовое сообщение для диалога; `auth_basic_user_file` указывает файл с парами «пользователь:хеш_пароля» (формат htpasswd).
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
location /secure/ {
|
||||
auth_basic "Restricted Area";
|
||||
auth_basic_user_file /etc/nginx/htpasswd;
|
||||
}
|
||||
```
|
||||
- **Примечание:** Файл паролей создаётся утилитой `htpasswd` (пакет apache2-utils или httpd-tools).
|
||||
- **1.3 Аутентификация по клиентскому TLS-сертификату**
|
||||
- Описание реализации: nginx может запрашивать и проверять клиентский сертификат при HTTPS-соединении.
|
||||
- Модуль / механизм: ngx_http_ssl_module; директивы ssl_client_certificate, ssl_verify_client, ssl_verify_depth
|
||||
- Комментарий: Реализуется через SSL/TLS-модуль nginx. Сам SSL-модуль требует включения при сборке и использует OpenSSL.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено с оговорками
|
||||
- **Ревью функции:** Описание и механизм в целом адекватны; учтены оговорки сборки, конфигурации или эксплуатации. Модуль `ngx_http_ssl_module` поддерживает проверку клиентских сертификатов.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_verify_client
|
||||
- **Результат:** Модуль `ngx_http_ssl_module` поддерживает проверку клиентских сертификатов. Директива `ssl_verify_client on` требует обязательного предъявления и проверки сертификата; `ssl_client_certificate` задаёт файл доверенного CA; `ssl_verify_depth` ограничивает глубину цепочки. Модуль требует сборки с `--with-http_ssl_module` и библиотекой OpenSSL.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
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;
|
||||
ssl_verify_depth 2;
|
||||
}
|
||||
```
|
||||
- **Примечание:** Акцент на идентификации клиента; для контекста защиты канала см. также п. 3.3.
|
||||
- **1.4 Авторизация через внешний сервис**
|
||||
- Описание реализации: nginx может выполнять подзапрос во внешний сервис авторизации и разрешать или запрещать доступ по результату ответа.
|
||||
- Модуль / механизм: ngx_http_auth_request_module; директивы auth_request, auth_request_set
|
||||
- Комментарий: Модуль официально поддерживается, но в upstream nginx не собирается по умолчанию и должен включаться параметром сборки --with-http_auth_request_module.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено с оговорками
|
||||
- **Ревью функции:** Описание и механизм в целом адекватны; учтены оговорки сборки, конфигурации или эксплуатации. Модуль `ngx_http_auth_request_module` выполняет подзапрос к указанному URI;
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_auth_request_module.html
|
||||
- **Результат:** Модуль `ngx_http_auth_request_module` выполняет подзапрос к указанному URI; доступ разрешается при ответе 2xx, запрещается при 401/403. Директива `auth_request_set` позволяет передать значения из заголовков ответа авторизационного сервиса в переменные nginx. В официальной сборке модуль включается флагом `--with-http_auth_request_module`; в большинстве дистрибутивных пакетов он уже присутствует.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
location = /auth {
|
||||
internal;
|
||||
proxy_pass http://auth-service:8080/validate;
|
||||
proxy_pass_request_body off;
|
||||
proxy_set_header Content-Length "";
|
||||
proxy_set_header X-Original-URI $request_uri;
|
||||
}
|
||||
|
||||
location / {
|
||||
auth_request /auth;
|
||||
proxy_pass http://backend;
|
||||
}
|
||||
```
|
||||
- **Примечание:** См. `Требования безопасности для включения в ТУ — проверка.md` п. 4; `Минимизация поверхности атаки nginx — проверка.md` п. 4.
|
||||
- **1.5 Комбинирование нескольких проверок доступа**
|
||||
- Описание реализации: nginx позволяет комбинировать несколько механизмов проверки доступа, например ограничение по IP и Basic Authentication.
|
||||
- Модуль / механизм: satisfy; совместно с access, auth_basic, auth_request
|
||||
- Комментарий: В документации nginx указано, что одновременное ограничение доступа по адресу, паролю и подзапросу управляется директивой satisfy.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. Директива `satisfy` управляет логикой комбинирования проверок `allow`/`deny`, `auth_basic` и `auth_request`.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html#satisfy
|
||||
- **Результат:** Директива `satisfy` управляет логикой комбинирования проверок `allow`/`deny`, `auth_basic` и `auth_request`. Значение `all` (по умолчанию) требует прохождения всех проверок; значение `any` — достаточно одной успешной.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
location /admin/ {
|
||||
satisfy all;
|
||||
allow 192.168.1.0/24;
|
||||
deny all;
|
||||
auth_basic "Admin Area";
|
||||
auth_basic_user_file /etc/nginx/htpasswd;
|
||||
}
|
||||
```
|
||||
- **Примечание:** См. `Требования безопасности для включения в ТУ — проверка.md` п. 4; `Минимизация поверхности атаки nginx — проверка.md` п. 4.
|
||||
|
||||
- **2. Разграничение доступа к ресурсам**
|
||||
- **2.1 Разделение правил по виртуальным серверам и путям**
|
||||
- Описание реализации: nginx позволяет задавать разные правила обработки и доступа для разных виртуальных серверов и URL-путей.
|
||||
- Модуль / механизм: ngx_http_core_module; блоки server, location
|
||||
- Комментарий: Это базовый механизм конфигурации nginx. Используется для разделения публичных, служебных и закрытых разделов сайта.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. Блоки `server` определяют виртуальные хосты (по `listen`, `server_name`), блоки `location` — правила для URI-префиксов, регулярных выражений и точных совпадений.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html#server , https://nginx.org/en/docs/http/ngx_http_core_module.html#location
|
||||
- **Результат:** Блоки `server` определяют виртуальные хосты (по `listen`, `server_name`), блоки `location` — правила для URI-префиксов, регулярных выражений и точных совпадений. Это базовый механизм разграничения доступа и обработки запросов.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
server {
|
||||
listen 80;
|
||||
server_name public.example.com;
|
||||
location / {
|
||||
root /var/www/public;
|
||||
}
|
||||
}
|
||||
|
||||
server {
|
||||
listen 80;
|
||||
server_name admin.example.com;
|
||||
location / {
|
||||
allow 10.0.0.0/8;
|
||||
deny all;
|
||||
root /var/www/admin;
|
||||
}
|
||||
}
|
||||
```
|
||||
- **2.2 Ограничение HTTP-методов**
|
||||
- Описание реализации: nginx позволяет задавать отдельные правила доступа для методов, отличных от явно разрешённых.
|
||||
- Модуль / механизм: ngx_http_core_module; директива limit_except
|
||||
- Комментарий: Используется для ограничения методов вроде PUT, DELETE, если они не требуются приложению.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. Директива `limit_except` задаёт методы, для которых применяются вложенные директивы доступа.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html#limit_except
|
||||
- **Результат:** Директива `limit_except` задаёт методы, для которых применяются вложенные директивы доступа. Методы, не перечисленные в `limit_except`, обрабатываются без дополнительных ограничений внутри данного блока.
|
||||
- **Минимальный аудит конфигурации:**
|
||||
```bash
|
||||
nginx -T 2>/dev/null | grep -E 'limit_except|request_method'
|
||||
```
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
location /uploads/ {
|
||||
limit_except GET HEAD {
|
||||
deny all;
|
||||
}
|
||||
}
|
||||
```
|
||||
- **2.3 Запрет доступа к служебным и скрытым файлам**
|
||||
- Описание реализации: nginx позволяет запрещать доступ к отдельным путям и шаблонам URI через правила location и deny all.
|
||||
- Модуль / механизм: location, регулярные выражения, deny all
|
||||
- Комментарий: Это не отдельный модуль безопасности, а конфигурационный механизм безопасной настройки.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. Комбинация `location` с регулярными выражениями и `deny all` позволяет блокировать доступ к скрытым файлам (`.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_access_module.html , https://nginx.org/en/docs/http/ngx_http_core_module.html#location
|
||||
- **Результат:** Комбинация `location` с регулярными выражениями и `deny all` позволяет блокировать доступ к скрытым файлам (`.git`, `.env`, `.htaccess` и т.п.). Это стандартный конфигурационный паттерн безопасности.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
location ~ /\. {
|
||||
deny all;
|
||||
access_log off;
|
||||
log_not_found off;
|
||||
}
|
||||
|
||||
location ~* \.(bak|sql|log|conf)$ {
|
||||
deny all;
|
||||
}
|
||||
```
|
||||
- **2.4 Запрет прямого доступа к внутренним ресурсам**
|
||||
- Описание реализации: nginx поддерживает внутренние location-блоки, которые недоступны напрямую клиенту и могут использоваться только для внутренних перенаправлений.
|
||||
- Модуль / механизм: ngx_http_core_module; директива internal
|
||||
- Комментарий: Применяется для скрытия служебных маршрутов и файлов от прямого обращения пользователя.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. Директива `internal` ограничивает доступ к location только для внутренних запросов (error_page, rewrite, auth_request, X-Accel-Redirect и др.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html#internal
|
||||
- **Результат:** Директива `internal` ограничивает доступ к location только для внутренних запросов (error_page, rewrite, auth_request, X-Accel-Redirect и др.). Прямые клиентские запросы к такому location возвращают 404.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
location /protected-files/ {
|
||||
internal;
|
||||
alias /var/data/files/;
|
||||
}
|
||||
|
||||
location /download {
|
||||
# Клиент обращается сюда; nginx внутренне отдаёт файл
|
||||
rewrite ^ /protected-files/document.pdf last;
|
||||
}
|
||||
```
|
||||
|
||||
- **3. Защита соединения и передаваемых данных**
|
||||
- **3.1 Поддержка HTTPS/TLS**
|
||||
- Описание реализации: nginx поддерживает HTTPS при наличии SSL-модуля. Можно задавать сертификаты, ключи, версии TLS и наборы шифров.
|
||||
- Модуль / механизм: ngx_http_ssl_module; ssl_certificate, ssl_certificate_key, ssl_protocols, ssl_ciphers
|
||||
- Комментарий: SSL-модуль nginx предоставляет поддержку HTTPS, требует OpenSSL и должен быть включён при сборке.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено с оговорками
|
||||
- **Ревью функции:** Описание и механизм в целом адекватны; учтены оговорки сборки, конфигурации или эксплуатации. Модуль `ngx_http_ssl_module` обеспечивает HTTPS.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_ssl_module.html
|
||||
- **Результат:** Модуль `ngx_http_ssl_module` обеспечивает HTTPS. Директивы `ssl_certificate` и `ssl_certificate_key` задают серверный сертификат и ключ; `ssl_protocols` и `ssl_ciphers` — параметры TLS. Модуль требует OpenSSL и включения при сборке (`--with-http_ssl_module`).
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
server {
|
||||
listen 443 ssl;
|
||||
server_name example.com;
|
||||
ssl_certificate /etc/nginx/ssl/example.com.crt;
|
||||
ssl_certificate_key /etc/nginx/ssl/example.com.key;
|
||||
ssl_protocols TLSv1.2 TLSv1.3;
|
||||
ssl_ciphers HIGH:!aNULL:!MD5;
|
||||
}
|
||||
```
|
||||
- **3.2 Ограничение версий TLS и шифров**
|
||||
- Описание реализации: nginx позволяет задавать допустимые версии TLS и наборы шифров.
|
||||
- Модуль / механизм: ngx_http_ssl_module; ssl_protocols, ssl_ciphers
|
||||
- Комментарий: Для ТУ/ПМИ нужно отдельно фиксировать допустимую криптографическую политику.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. Директива `ssl_protocols` задаёт разрешённые версии протокола (TLSv1.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols , https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_ciphers
|
||||
- **Результат:** Директива `ssl_protocols` задаёт разрешённые версии протокола (TLSv1.2, TLSv1.3 и др.); `ssl_ciphers` — список шифронаборов в формате OpenSSL. Дополнительно доступны `ssl_prefer_server_ciphers` и параметры для TLS 1.3 (`ssl_conf_command` в новых версиях).
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
ssl_protocols TLSv1.2 TLSv1.3;
|
||||
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
|
||||
ssl_prefer_server_ciphers on;
|
||||
```
|
||||
- **Примечание:** Конкретная криптографическая политика должна быть зафиксирована в ТУ/ПМИ отдельно.
|
||||
- **3.3 Проверка клиентского сертификата**
|
||||
- Описание реализации: nginx может проверять клиентские TLS-сертификаты по доверенному центру сертификации.
|
||||
- Модуль / механизм: ssl_client_certificate, ssl_verify_client
|
||||
- Комментарий: Может использоваться как механизм строгой аутентификации клиента.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. Директива `ssl_verify_client` поддерживает значения `on`, `off`, `optional`, `optional_no_ca`.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_verify_client
|
||||
- **Результат:** Директива `ssl_verify_client` поддерживает значения `on`, `off`, `optional`, `optional_no_ca`. При `on` клиент обязан предъявить сертификат, подписанный доверенным CA из `ssl_client_certificate`. Режим `optional` запрашивает сертификат, но не прерывает соединение при его отсутствии.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
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/client-ca.crt;
|
||||
ssl_verify_client optional;
|
||||
ssl_verify_depth 3;
|
||||
}
|
||||
```
|
||||
- **Примечание:** В отличие от п. 1.3, здесь акцент на защите канала и политике доверия к клиентским сертификатам.
|
||||
- **3.4 Принудительное использование HTTPS**
|
||||
- Описание реализации: nginx может перенаправлять HTTP-запросы на HTTPS и добавлять заголовки безопасности.
|
||||
- Модуль / механизм: return 301/308; add_header Strict-Transport-Security
|
||||
- Комментарий: HSTS реализуется через HTTP-заголовок, а не отдельным модулем безопасности.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. Редирект HTTP→HTTPS реализуется директивой `return` (301 или 308).
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#return , https://nginx.org/en/docs/http/ngx_http_headers_module.html#add_header
|
||||
- **Результат:** Редирект HTTP→HTTPS реализуется директивой `return` (301 или 308). Заголовок HSTS (`Strict-Transport-Security`) добавляется через `add_header` в HTTPS-блоке. Отдельного модуля HSTS в nginx нет.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
server {
|
||||
listen 80;
|
||||
server_name example.com;
|
||||
return 301 https://$host$request_uri;
|
||||
}
|
||||
|
||||
server {
|
||||
listen 443 ssl;
|
||||
server_name example.com;
|
||||
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
|
||||
}
|
||||
```
|
||||
|
||||
- **4. Регистрация событий и аудит**
|
||||
- **4.1 Журналирование HTTP-запросов**
|
||||
- Описание реализации: nginx ведёт журнал HTTP-запросов в настраиваемом формате.
|
||||
- Модуль / механизм: ngx_http_log_module; access_log, log_format
|
||||
- Комментарий: Официальный модуль nginx записывает request logs в заданном формате.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. Модуль `ngx_http_log_module` записывает access log.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_log_module.html
|
||||
- **Результат:** Модуль `ngx_http_log_module` записывает access log. Директива `access_log` задаёт путь (или syslog) и формат; по умолчанию используется формат `combined`. Журналирование можно отключить (`access_log off`) на уровне server/location.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
http {
|
||||
access_log /var/log/nginx/access.log combined;
|
||||
}
|
||||
```
|
||||
- **4.2 Журналирование ошибок**
|
||||
- Описание реализации: nginx ведёт журнал ошибок, где фиксируются проблемы обработки запросов, конфигурации и взаимодействия с backend.
|
||||
- Модуль / механизм: error_log
|
||||
- Комментарий: Официальная документация указывает, что nginx пишет error log и позволяет задавать место и уровень журналирования.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. Директива `error_log` задаёт файл (или syslog) и уровень детализации: `debug`, `info`, `notice`, `warn`, `error`, `crit`, `alert`, `emerg`.
|
||||
- **Источник:** https://nginx.org/en/docs/ngx_core_module.html#error_log
|
||||
- **Результат:** Директива `error_log` задаёт файл (или syslog) и уровень детализации: `debug`, `info`, `notice`, `warn`, `error`, `crit`, `alert`, `emerg`. Уровень по умолчанию — `error`.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
error_log /var/log/nginx/error.log warn;
|
||||
```
|
||||
- **4.3 Настройка формата журналов**
|
||||
- Описание реализации: nginx позволяет задавать собственный формат access log с нужными полями.
|
||||
- Модуль / механизм: log_format
|
||||
- Комментарий: Для ПМИ можно проверять наличие обязательных полей в журнале.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. Директива `log_format` определяет именованный формат с произвольным набором переменных (`$remote_addr`, `$request`, `$status`, `$body_bytes_sent`, `$http_user_agent` и др.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_log_module.html#log_format
|
||||
- **Результат:** Директива `log_format` определяет именованный формат с произвольным набором переменных (`$remote_addr`, `$request`, `$status`, `$body_bytes_sent`, `$http_user_agent` и др.). Формат применяется в `access_log`.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
log_format audit '$remote_addr - $remote_user [$time_local] '
|
||||
'"$request" $status $body_bytes_sent '
|
||||
'"$http_referer" "$http_user_agent" '
|
||||
'$request_time $upstream_response_time';
|
||||
|
||||
access_log /var/log/nginx/audit.log audit;
|
||||
```
|
||||
- **4.4 Передача журналов в syslog**
|
||||
- Описание реализации: nginx поддерживает запись access_log и error_log в syslog.
|
||||
- Модуль / механизм: access_log syslog:...; error_log syslog:...
|
||||
- Комментарий: Подтверждено официальной документацией nginx по syslog.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. nginx поддерживает запись `access_log` и `error_log` в syslog с параметрами `server`, `facility`, `tag`, `severity`.
|
||||
- **Источник:** https://nginx.org/en/docs/syslog.html
|
||||
- **Результат:** nginx поддерживает запись `access_log` и `error_log` в syslog с параметрами `server`, `facility`, `tag`, `severity`. Формат: `syslog:server=address[,parameter=value]`.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
error_log syslog:server=192.168.1.1:514,facility=local7,tag=nginx,severity=error;
|
||||
|
||||
access_log syslog:server=192.168.1.1:514,facility=local7,tag=nginx,severity=info combined;
|
||||
```
|
||||
- **Примечание:** См. ПМИ п. 14 в `Проверочные мероприятия для ПМИ — проверка.md`; `Контроль целостности хранимого кода и конфигурации — проверка.md` п. 13; `Минимально необходимые полномочия nginx — проверка.md` п. 5.
|
||||
|
||||
- **5. Ограничение нагрузки и защита от избыточных запросов**
|
||||
- **5.1 Ограничение частоты запросов**
|
||||
- Описание реализации: nginx может ограничивать частоту обработки запросов по заданному ключу, например по IP-адресу клиента.
|
||||
- Модуль / механизм: ngx_http_limit_req_module; limit_req_zone, limit_req
|
||||
- Комментарий: Модуль использует метод leaky bucket и официально предназначен для ограничения request rate.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. Модуль `ngx_http_limit_req_module` реализует алгоритм leaky bucket.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_limit_req_module.html
|
||||
- **Результат:** Модуль `ngx_http_limit_req_module` реализует алгоритм leaky bucket. `limit_req_zone` определяет зону и ключ (например, `$binary_remote_addr`); `limit_req` применяет ограничение с параметрами `rate` и `burst`.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
http {
|
||||
limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;
|
||||
|
||||
server {
|
||||
location / {
|
||||
limit_req zone=one burst=20 nodelay;
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
- **Примечание:** См. `Требования безопасности для включения в ТУ — проверка.md` п. 15; `Проверочные мероприятия для ПМИ — проверка.md` п. 15.
|
||||
- **5.2 Ограничение количества соединений**
|
||||
- Описание реализации: nginx может ограничивать количество соединений по заданному ключу, например по IP-адресу клиента.
|
||||
- Модуль / механизм: ngx_http_limit_conn_module; limit_conn_zone, limit_conn
|
||||
- Комментарий: Официальный модуль ограничивает количество соединений per defined key.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. Модуль `ngx_http_limit_conn_module` ограничивает число одновременных соединений по ключу.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_limit_conn_module.html
|
||||
- **Результат:** Модуль `ngx_http_limit_conn_module` ограничивает число одновременных соединений по ключу. `limit_conn_zone` задаёт зону; `limit_conn` применяет лимит.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
http {
|
||||
limit_conn_zone $binary_remote_addr zone=addr:10m;
|
||||
|
||||
server {
|
||||
location / {
|
||||
limit_conn addr 10;
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
- **Примечание:** См. `Требования безопасности для включения в ТУ — проверка.md` п. 16; `Проверочные мероприятия для ПМИ — проверка.md` п. 16.
|
||||
- **5.3 Ограничение размера клиентского запроса**
|
||||
- Описание реализации: nginx позволяет ограничивать максимальный размер тела клиентского запроса.
|
||||
- Модуль / механизм: ngx_http_core_module; client_max_body_size
|
||||
- Комментарий: Используется для защиты от чрезмерно больших запросов и нежелательных загрузок.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. Директива `client_max_body_size` задаёт максимальный размер тела запроса.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size
|
||||
- **Результат:** Директива `client_max_body_size` задаёт максимальный размер тела запроса. Значение по умолчанию — 1m. При превышении nginx возвращает 413 (Request Entity Too Large).
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
server {
|
||||
client_max_body_size 10m;
|
||||
}
|
||||
```
|
||||
- **Примечание:** См. `Требования безопасности для включения в ТУ — проверка.md` п. 15; `Проверочные мероприятия для ПМИ — проверка.md` п. 15.
|
||||
- **5.4 Ограничение скорости отдачи данных**
|
||||
- Описание реализации: nginx позволяет ограничивать скорость передачи ответа клиенту.
|
||||
- Модуль / механизм: ngx_http_core_module; limit_rate
|
||||
- Комментарий: Используется для управления нагрузкой и потреблением ресурсов.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. Директива `limit_rate` ограничивает скорость отдачи ответа клиенту (байт/с).
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html#limit_rate
|
||||
- **Результат:** Директива `limit_rate` ограничивает скорость отдачи ответа клиенту (байт/с). Дополнительно `limit_rate_after` позволяет отдавать начальный объём без ограничения.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
location /downloads/ {
|
||||
limit_rate 500k;
|
||||
}
|
||||
```
|
||||
- **Примечание:** См. `Требования безопасности для включения в ТУ — проверка.md` п. 16; `Проверочные мероприятия для ПМИ — проверка.md` п. 16.
|
||||
- **5.5 Настройка таймаутов соединений**
|
||||
- Описание реализации: nginx позволяет задавать таймауты чтения заголовков, тела запроса, отправки ответа и keepalive.
|
||||
- Модуль / механизм: client_header_timeout, client_body_timeout, send_timeout, keepalive_timeout
|
||||
- Комментарий: Снижает риск удержания ресурсов медленными или зависшими соединениями.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. Директивы `client_header_timeout`, `client_body_timeout`, `send_timeout` и `keepalive_timeout` задают таймауты на разных этапах обработки соединения.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html
|
||||
- **Результат:** Директивы `client_header_timeout`, `client_body_timeout`, `send_timeout` и `keepalive_timeout` задают таймауты на разных этапах обработки соединения. Значения по умолчанию: 60s для header/body/send, 75s для keepalive.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
http {
|
||||
client_header_timeout 10s;
|
||||
client_body_timeout 10s;
|
||||
send_timeout 10s;
|
||||
keepalive_timeout 30s;
|
||||
}
|
||||
```
|
||||
|
||||
- **6. Управление раскрытием информации**
|
||||
- **6.1 Сокрытие версии nginx**
|
||||
- Описание реализации: nginx позволяет отключить отображение версии сервера в стандартных ответах.
|
||||
- Модуль / механизм: server_tokens off
|
||||
- Комментарий: Важно: server_tokens off скрывает версию, но не всегда полностью скрывает сам факт использования nginx.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. Директива `server_tokens off` убирает номер версии из заголовка `Server` и со страниц ошибок nginx.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html#server_tokens
|
||||
- **Результат:** Директива `server_tokens off` убирает номер версии из заголовка `Server` и со страниц ошибок nginx. Заголовок `Server` по-прежнему содержит слово «nginx».
|
||||
- **Минимальный аудит конфигурации:**
|
||||
```bash
|
||||
nginx -T 2>/dev/null | grep server_tokens
|
||||
```
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
http {
|
||||
server_tokens off;
|
||||
}
|
||||
```
|
||||
- **Примечание:** Для полного сокрытия идентификатора сервера требуются дополнительные меры (например, заголовки через `more_clear_headers` в сторонних модулях).
|
||||
- **6.2 Управление страницами ошибок**
|
||||
- Описание реализации: nginx позволяет задавать собственные страницы ошибок и внутренние перенаправления.
|
||||
- Модуль / механизм: error_page
|
||||
- Комментарий: Позволяет не раскрывать технические детали пользователю.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. Директива `error_page` перенаправляет обработку указанных кодов ошибок на URI, именованный location или внешний адрес.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html#error_page
|
||||
- **Результат:** Директива `error_page` перенаправляет обработку указанных кодов ошибок на URI, именованный location или внешний адрес. Позволяет показывать пользовательские страницы вместо стандартных сообщений nginx.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
error_page 404 /custom_404.html;
|
||||
error_page 500 502 503 504 /custom_50x.html;
|
||||
|
||||
location = /custom_404.html {
|
||||
root /var/www/errors;
|
||||
internal;
|
||||
}
|
||||
```
|
||||
- **6.3 Управление листингом директорий**
|
||||
- Описание реализации: nginx может формировать листинг директорий через autoindex, если режим включён.
|
||||
- Модуль / механизм: ngx_http_autoindex_module; autoindex
|
||||
- Комментарий: Модуль официально формирует directory listing для запросов, оканчивающихся /, когда не найден индексный файл. Для безопасной конфигурации должен быть отключён, если не требуется.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. Модуль `ngx_http_autoindex_module` включается директивой `autoindex on` и формирует HTML-листинг каталога при отсутствии индексного файла.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_autoindex_module.html
|
||||
- **Результат:** Модуль `ngx_http_autoindex_module` включается директивой `autoindex on` и формирует HTML-листинг каталога при отсутствии индексного файла. По умолчанию `autoindex off`. Для безопасной конфигурации рекомендуется явно отключать или не включать.
|
||||
- **Минимальный аудит конфигурации:**
|
||||
```bash
|
||||
nginx -T 2>/dev/null | grep autoindex
|
||||
```
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
location /public-files/ {
|
||||
autoindex off;
|
||||
root /var/www/files;
|
||||
}
|
||||
```
|
||||
|
||||
- **7. Обратное проксирование и изоляция backend-сервисов**
|
||||
- **7.1 Обратное проксирование HTTP/HTTPS**
|
||||
- Описание реализации: nginx может принимать клиентские запросы и передавать их внутренним backend-сервисам.
|
||||
- Модуль / механизм: ngx_http_proxy_module; proxy_pass
|
||||
- Комментарий: Официальный модуль proxy передаёт запросы другому серверу.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. Модуль `ngx_http_proxy_module` передаёт HTTP-запросы на backend через `proxy_pass`.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_proxy_module.html
|
||||
- **Результат:** Модуль `ngx_http_proxy_module` передаёт HTTP-запросы на backend через `proxy_pass`. Поддерживается проксирование на HTTP и HTTPS upstream.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
location /api/ {
|
||||
proxy_pass http://127.0.0.1:8080;
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
}
|
||||
```
|
||||
- **7.2 Балансировка и группы upstream**
|
||||
- Описание реализации: nginx позволяет определять группы backend-серверов и использовать их для proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass, grpc_pass.
|
||||
- Модуль / механизм: ngx_http_upstream_module; upstream
|
||||
- Комментарий: Документация nginx описывает upstream как механизм групп серверов для разных pass-директив.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. Блок `upstream` определяет группу backend-серверов с методами балансировки (round-robin по умолчанию, `least_conn`, `ip_hash`, `hash`).
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_upstream_module.html
|
||||
- **Результат:** Блок `upstream` определяет группу backend-серверов с методами балансировки (round-robin по умолчанию, `least_conn`, `ip_hash`, `hash`). Используется с `proxy_pass`, `fastcgi_pass`, `uwsgi_pass`, `scgi_pass`, `grpc_pass`.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
upstream backend {
|
||||
server 192.168.1.10:8080;
|
||||
server 192.168.1.11:8080;
|
||||
keepalive 32;
|
||||
}
|
||||
|
||||
server {
|
||||
location / {
|
||||
proxy_pass http://backend;
|
||||
}
|
||||
}
|
||||
```
|
||||
- **7.3 Управление заголовками при проксировании**
|
||||
- Описание реализации: nginx позволяет явно задавать заголовки, передаваемые backend-сервису.
|
||||
- Модуль / механизм: proxy_set_header
|
||||
- Комментарий: Важно для корректной передачи адреса клиента и исключения нежелательных/подменённых заголовков.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. Директива `proxy_set_header` задаёт или переопределяет заголовки запроса к backend.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_set_header
|
||||
- **Результат:** Директива `proxy_set_header` задаёт или переопределяет заголовки запроса к backend. По умолчанию nginx передаёт ряд заголовков, но `Host` и `Connection` могут требовать явной настройки. `proxy_pass_request_headers` управляет передачей клиентских заголовков.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
location / {
|
||||
proxy_pass http://backend;
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
proxy_set_header X-Forwarded-Proto $scheme;
|
||||
}
|
||||
```
|
||||
|
||||
- **8. Управление статическим содержимым и директориями веб-приложений**
|
||||
- **8.1 Задание корневой директории сайта**
|
||||
- Описание реализации: nginx обслуживает файлы из директории, заданной директивой root.
|
||||
- Модуль / механизм: ngx_http_core_module; root
|
||||
- Комментарий: Используется для определения разрешённой области веб-контента.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. Директива `root` задаёт корневую директорию для запросов в данном server/location.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html#root
|
||||
- **Результат:** Директива `root` задаёт корневую директорию для запросов в данном server/location. Путь к файлу формируется как `root` + URI.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
server {
|
||||
root /var/www/example.com;
|
||||
location / {
|
||||
index index.html;
|
||||
}
|
||||
}
|
||||
```
|
||||
- **8.2 Задание альтернативного пути для location**
|
||||
- Описание реализации: nginx позволяет сопоставлять URI с другой директорией файловой системы через alias.
|
||||
- Модуль / механизм: ngx_http_core_module; alias
|
||||
- Комментарий: Требует осторожной настройки, чтобы не открыть произвольные каталоги ОС.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. Директива `alias` заменяет часть URI на указанный путь файловой системы.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html#alias
|
||||
- **Результат:** Директива `alias` заменяет часть URI на указанный путь файловой системы. При некорректной настройке (особенно с регулярными выражениями) возможен path traversal.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
location /images/ {
|
||||
alias /var/www/static/images/;
|
||||
}
|
||||
```
|
||||
- **Примечание:** Для location с регулярным выражением `alias` должен содержать захватывающие группы; завершающий слэш обязателен.
|
||||
- **8.3 Проверка существования файлов и маршрутизация**
|
||||
- Описание реализации: nginx позволяет проверять наличие файлов и выполнять внутреннюю маршрутизацию через try_files.
|
||||
- Модуль / механизм: ngx_http_core_module; try_files
|
||||
- Комментарий: Используется для контроля, какой файл или маршрут будет обработан.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. Директива `try_files` проверяет существование файлов/каталогов в указанном порядке и выполняет внутреннее перенаправление на последний параметр при отсутствии совпадений.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html#try_files
|
||||
- **Результат:** Директива `try_files` проверяет существование файлов/каталогов в указанном порядке и выполняет внутреннее перенаправление на последний параметр при отсутствии совпадений.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
location / {
|
||||
root /var/www/html;
|
||||
try_files $uri $uri/ /index.html;
|
||||
}
|
||||
```
|
||||
- **8.4 Ограничение доступа к произвольным каталогам ОС**
|
||||
- Описание реализации: nginx должен быть настроен так, чтобы обслуживать файлы только из разрешённых директорий.
|
||||
- Модуль / механизм: root, alias, location, deny all, права ФС
|
||||
- Комментарий: Это не отдельный модуль nginx, а требование безопасной конфигурации.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. nginx обслуживает только те пути, которые явно заданы через `root`/`alias` в `location`.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_core_module.html#root , https://nginx.org/en/docs/http/ngx_http_access_module.html
|
||||
- **Результат:** nginx обслуживает только те пути, которые явно заданы через `root`/`alias` в `location`. Безопасная конфигурация ограничивает `location /`, запрещает доступ к системным путям и сочетается с правами файловой системы (процесс nginx не должен иметь доступ к чувствительным каталогам).
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
server {
|
||||
root /var/www/site;
|
||||
location / {
|
||||
try_files $uri =404;
|
||||
}
|
||||
location ~ ^/(\.\.|etc|proc|sys) {
|
||||
deny all;
|
||||
}
|
||||
}
|
||||
```
|
||||
- **Примечание:** Дополнительно на уровне ОС следует ограничить права пользователя, от которого работает nginx. См. `Минимально необходимые полномочия nginx — проверка.md` п. 3; `Контроль выполнения кода — проверка.md` п. 14.
|
||||
|
||||
- **9. Минимизация поверхности атаки**
|
||||
- **9.1 Исключение неиспользуемых модулей**
|
||||
- Описание реализации: nginx может собираться с разным составом модулей; неиспользуемые модули могут быть исключены из сборки или не загружаться.
|
||||
- Модуль / механизм: Параметры сборки; dynamic modules; load_module
|
||||
- Комментарий: Это проектная мера снижения поверхности атаки.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. При сборке nginx параметры `./configure` позволяют включать/отключать модули (`--without-http_autoindex_module`, `--with-http_ssl_module` и др.
|
||||
- **Источник:** https://nginx.org/en/docs/configure.html , https://nginx.org/en/docs/ngx_core_module.html#load_module
|
||||
- **Результат:** При сборке nginx параметры `./configure` позволяют включать/отключать модули (`--without-http_autoindex_module`, `--with-http_ssl_module` и др.). Динамические модули подключаются через `load_module` в конфигурации; неиспользуемые модули можно не загружать.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
# Загрузка только необходимых динамических модулей
|
||||
load_module modules/ngx_http_geoip_module.so;
|
||||
|
||||
# Статические модули определяются при сборке:
|
||||
# ./configure --without-http_autoindex_module --with-http_ssl_module
|
||||
```
|
||||
- **Примечание:** См. `Минимизация поверхности атаки nginx — проверка.md` п. 1–2.
|
||||
- **9.2 Отключение неиспользуемых возможностей конфигурацией**
|
||||
- Описание реализации: Неиспользуемые возможности должны быть отключены в конфигурации: autoindex, лишние методы, лишние proxy/FastCGI-направления.
|
||||
- Модуль / механизм: Конфигурация nginx
|
||||
- Комментарий: Это не отдельная функция nginx, а требование безопасной эксплуатации.
|
||||
- Проверка:
|
||||
- **Статус:** Подтверждено
|
||||
- **Ревью функции:** Описание реализации и заявленный механизм соответствуют документации nginx. Неиспользуемые возможности отключаются конфигурацией: `autoindex off`, ограничение методов через `limit_except`, удаление неиспользуемых `location` с `proxy_pass`/`fastcgi_pass`.
|
||||
- **Источник:** https://nginx.org/en/docs/http/ngx_http_autoindex_module.html , https://nginx.org/en/docs/http/ngx_http_core_module.html#limit_except
|
||||
- **Результат:** Неиспользуемые возможности отключаются конфигурацией: `autoindex off`, ограничение методов через `limit_except`, удаление неиспользуемых `location` с `proxy_pass`/`fastcgi_pass`. Это требование безопасной эксплуатации, а не отдельный модуль.
|
||||
- **Пример конфигурации:**
|
||||
```nginx
|
||||
server {
|
||||
autoindex off;
|
||||
|
||||
location / {
|
||||
limit_except GET HEAD POST {
|
||||
deny all;
|
||||
}
|
||||
}
|
||||
|
||||
# Неиспользуемые направления не включаются в конфигурацию
|
||||
# location /legacy-api/ { proxy_pass http://old-backend; }
|
||||
}
|
||||
```
|
||||
- **Примечание:** См. `Минимизация поверхности атаки nginx — проверка.md` п. 4–10.
|
||||
- **9.3 Контроль целостности конфигурации и разрешённых директорий**
|
||||
- Описание реализации: Конфигурация nginx и разрешённые директории веб-контента должны контролироваться внешним механизмом целостности.
|
||||
- Модуль / механизм: afick или иной утверждённый механизм
|
||||
- Комментарий: nginx не выполняет контроль целостности сам. Это внешняя мера, требуемая для сертификационной логики.
|
||||
- Проверка:
|
||||
- **Статус:** Не применимо к nginx напрямую (внешняя мера)
|
||||
- **Ревью функции:** Корректно отнесено к внешней мере: nginx не реализует функцию напрямую. nginx не реализует контроль целостности файлов (FIM).
|
||||
- **Источник:** https://nginx.org/en/docs/ (функция FIM в nginx не описана)
|
||||
- **Результат:** nginx не реализует контроль целостности файлов (FIM). Данное требование выполняется внешними средствами: afick, AIDE, OSSEC или иным утверждённым механизмом. Контролируемые объекты: `/etc/nginx/` (конфигурация), директории `root`/`alias` веб-контента.
|
||||
- **Пример реализации:**
|
||||
```
|
||||
# /etc/afick.conf (фрагмент)
|
||||
/etc/nginx/ R
|
||||
/var/www/ R
|
||||
```
|
||||
- **Примечание:** См. `Минимизация поверхности атаки nginx — проверка.md` п. 4–10.
|
||||
- **Примечание:** Для ПМИ проверяется наличие и работоспособность внешнего средства, а не конфигурация nginx. Статус отражает внешнюю меру (см. `Контроль целостности хранимого кода и конфигурации — проверка.md`; ПМИ п. 24; `Контроль выполнения кода — проверка.md` п. 15–16).
|
||||
Reference in New Issue
Block a user