Directum RX на Astra Linux и РЕД ОС: что подготовить до установки и на чём спотыкаются

Коротко. На Astra Linux заранее проверьте МКЦ (astra-mic-control status, pdp-id): sudo не поднимает уровень целостности, работать надо из сессии администратора с уровнем 63. Ещё до установки найдите secdel на разделах с данными и учтите метки MAC в дампах PostgreSQL из состава Astra. На РЕД ОС разберитесь с SELinux (restorecon после переноса файлов) и firewalld. На обеих системах нужно зеркало репозиториев, Docker из репозитория ОС нужной версии и проверка условий на семейство ОС в автоматизации.

Инструкция по установке Directum RX на Linux одинакова для всех дистрибутивов: поставить Docker, развернуть Directum Launcher, пройти шаги. На Ubuntu и Debian так и получается. На Astra Linux и РЕД ОС в ту же инструкцию вмешиваются механизмы защиты, свои репозитории и сборки пакетов, и установка, рассчитанная на день, растягивается на неделю переписки с безопасниками. Ниже то, на чём спотыкаются чаще всего, и что проверить до начала работ. Большую часть этого списка мы собрали сами, разворачивая сервисы и агенты мониторинга на обеих системах.

Симптом

• Команда от root через sudo получает отказ в доступе к системному файлу.
• Служба, которая на Debian запускалась, на РЕД ОС падает с кодом 203/EXEC, хотя файл на месте и права верные.
• Пакета, привычного по Debian, в репозитории нет, а интернета на сервере нет вовсе.
• Сценарий Ansible, проверенный на Debian, на Astra отрабатывает «зелёным», но половину шагов пропускает.
• Реплика PostgreSQL на одном сервере отстаёт, хотя железо такое же, как у соседнего.
• Дамп базы с Astra не восстанавливается на обычный PostgreSQL.

Почему так

Astra Linux и РЕД ОС построены на знакомых основах: Astra на Debian, РЕД ОС на семействе RHEL. Отличия появляются там, ради чего их выбирают: сертификация и встроенные механизмы защиты. Эти механизмы включены по умолчанию или включаются требованием безопасности заказчика, и инструкции, написанные для Ubuntu, о них ничего не знают.

Docker и репозитории

Directum RX на Linux работает в контейнерах, поэтому первым делом нужен Docker. По справке вендора:

Версию Docker сверяйте с документом «Типовые требования к аппаратному и программному обеспечению» из комплекта поставки вашей версии RX. Ставить Docker со сторонних сайтов на сертифицированную ОС, как правило, не позволит безопасность заказчика, да и смысл сертифицированной сборки при этом теряется.

Если на РЕД ОС или Альт Сервер будут работать сервисы Directum Ario, вендор требует "live-restore": false в /etc/docker/daemon.json.

Репозитории в закрытом контуре. Серверы RX обычно без интернета, поэтому нужно локальное зеркало репозиториев ОС: основного, расширенного и обновлений безопасности. Доступ к репозиториям Astra привязан к лицензии, и часть из них без неё закрыта. Заранее пройдитесь по списку пакетов, которые понадобятся вокруг RX: агенты мониторинга, клиенты резервного копирования, утилиты. Часть привычного по Debian может отсутствовать: например, autossh нет ни в основном, ни в расширенном репозитории Astra 1.8.

Astra Linux

Мандатный контроль целостности: sudo не помогает

В режимах «Воронеж» и «Смоленск» есть мандатный контроль целостности (МКЦ), и обычно он включён. У каждого процесса есть уровень целостности, и системные файлы может менять только процесс с высоким уровнем. Уровень берётся от сессии, в которой вошёл пользователь, и sudo его не повышает. Отсюда классическая картина: администратор вошёл обычной учётной записью, выполняет sudo и получает отказ там, где на Debian всё работало.

Проверить до начала работ:

astra-mic-control status   # ACTIVE, если МКЦ включён
pdp-id                     # уровень текущей сессии: ILevel=0 низкий, 63 высокий

Установку и обслуживание ведут из сессии администратора (группа astra-admin), вошедшего с высоким уровнем целостности. Если подрядчик работает удалённо, это надо согласовать заранее: учётная запись с высоким уровнем обычно выдаётся по отдельной заявке. Сценарии установки, которые сами себя проверяют, стоит научить смотреть pdp-id и останавливаться с понятным сообщением, а не падать на середине.

Замкнутая программная среда

Если безопасность включила замкнутую программную среду (ЗПС), система запускает только исполняемые файлы с доверенной цифровой подписью. Всё, что ставится не из репозитория Astra, попадает под это ограничение: агенты мониторинга, утилиты резервного копирования, сторонние бинарники. Список такого ПО согласуйте до установки: в день запуска договариваться поздно.

secdel на разделах с данными

В Astra есть параметр монтирования secdel: при удалении и усечении файла освобождаемые блоки затираются. Для пользовательских каталогов это разумная мера. На разделе с данными PostgreSQL каждое удаление сегмента журнала превращается в синхронную запись, и реплика начинает отставать без видимой причины. Подробно сценарий разобран в статье про рост pg_wal. Проверка:

findmnt -no TARGET,OPTIONS | grep secdel

Параметры монтирования должны совпадать на всех узлах кластера. Расхождение между узлами и даёт картину «одна реплика отстаёт, а другая нет».

PostgreSQL из состава Astra: метки в дампах

В Astra есть своя сборка PostgreSQL с поддержкой мандатных меток. Дамп из неё содержит команды, которых обычный PostgreSQL не знает: MAC LABEL ON ..., MAC CCR ON ... и параметр таблиц WITH (MACS=FALSE). Ключ pg_dump --no-security-labels их не убирает. Восстановление такого дампа на обычный PostgreSQL, например при переезде на другую СУБД или при разборе копии у себя, падает на первой же команде.

Проверить, есть ли такие таблицы, можно до выгрузки:

SELECT count(*) FROM pg_class WHERE reloptions::text ILIKE '%macs%';

Если метки не нужны на новом месте, их вычищают из текстового дампа: удаляют строки MAC LABEL ON и MAC CCR ON и параметр MACS в WITH. Делать это надо только в описании объектов и не трогать блоки данных COPY, иначе можно повредить строки, где эти слова встречаются в данных. Проверять результат стоит восстановлением на тестовый сервер и сравнением числа строк в таблицах.

Автоматизация: Ansible не считает Astra Debian'ом

Astra Linux определяется в Ansible как отдельный дистрибутив (ID=astra в /etc/os-release). В версиях, с которыми мы работали, ansible_os_family для неё не равен Debian. Любое условие when: ansible_os_family == 'Debian' на Astra молча пропускает задачу: сценарий завершается без ошибок, а нужные шаги не выполнены. Мы ловили так пропущенную генерацию локалей (дальше initdb падал с No suitable locale found) и пропущенную установку Python-зависимостей. Перед первым запуском на Astra стоит найти в своих ролях все условия на семейство ОС и явно добавить в них Astra.

Ещё одна мелочь для тестовых стендов. systemd в Astra без модуля мандатного контроля завершается при старте с сообщением parsec module missing, terminating to prevent data leakage. Поэтому образ Astra в контейнере для проверки ролей не загрузится так же просто, как образ Debian.

РЕД ОС

SELinux: файл на месте, служба не запускается

В РЕД ОС работает SELinux, и обычно в режиме enforcing. У каждого файла есть метка контекста, и systemd откажется запускать программу с неподходящей меткой. Типичный путь к ошибке: архив распаковали в /tmp или домашний каталог, а потом перенесли в /opt командой mv. При переносе файл сохраняет старую метку, служба падает с 203/EXEC, а права и путь при этом верные.

getenforce                                  # Enforcing, Permissive или Disabled
ls -Z /opt/app/bin/                         # метки файлов
ausearch -m avc -ts recent                  # что SELinux запретил за последние минуты

Исправление:

restorecon -Rv /opt/app                     # вернуть метки по правилам системы
# если программе нужна метка исполняемого файла, закрепить правило и применить его:
semanage fcontext -a -t bin_t '/opt/app/bin(/.*)?'
restorecon -Rv /opt/app/bin

chcon меняет метку сразу, но до первого restorecon. Правило через semanage переживает переразметку файловой системы. Сама команда semanage входит в пакет policycoreutils-python-utils, на минимальной установке его может не быть.

Каталоги, которые монтируются в контейнеры, тоже должны иметь подходящую метку. В Podman, а в Docker при включённой поддержке SELinux, для этого к тому дописывают :Z (каталог одного контейнера) или :z (общий для нескольких).

firewalld

На серверных установках РЕД ОС часто включён firewalld, и порты, которые на Debian были доступны сразу, здесь закрыты.

firewall-cmd --state
firewall-cmd --list-all
firewall-cmd --permanent --add-port=9100/tcp && firewall-cmd --reload

Обратная ловушка: порты, которые публикует Docker, открываются его собственными правилами, и обычным правилом firewalld такой порт не закрыть. Ограничивать доступ к ним нужно в цепочке DOCKER-USER или не публиковать порт наружу вовсе. Доступность проверяйте с другой машины, а не по списку правил.

Podman вместо Docker

RX по документации ставится на Docker. Но в компаниях, которые уходят на Podman, рядом с RX оказываются сервисы на Podman: мониторинг, прокси, вспомогательные утилиты. Отличия, которые всплывают первыми: podman compose и podman-compose понимают не все возможности Docker Compose, а контейнер без прав root не может слушать порты ниже 1024. Ещё в наших проверках Podman выдавал пересозданному контейнеру новый адрес, и nginx, запомнивший старый адрес при старте, начинал отвечать ошибкой 502, пока его не перезапустили.

Общее для обеих систем

• Время. Синхронизация с внутренним NTP настраивается до установки. При расхождении часов ломается вход по Kerberos (Clock skew too great), а журналы разных серверов не сходятся по времени.
• Отдельные диски. Данные PostgreSQL, хранилище файлов, журналы и данные Docker лучше держать на разных разделах. Переполнение журналов тогда не останавливает базу.
• Требования к версиям. Docker, PostgreSQL и Elasticsearch сверяются с «Типовыми требованиями» именно вашей версии RX. Сертифицированные ОС часто отстают по версиям пакетов от Ubuntu.

Чек-лист до начала работ

Чего не делать

• Не отключать МКЦ или SELinux, «чтобы заработало». Для заказчика с требованием сертифицированной ОС это нарушение условий эксплуатации, и при проверке ИБ его найдут. Ошибку надо понять и исправить меткой или правилом.
• Не ставить Docker и пакеты из интернета в обход репозиториев ОС. Сертифицированная система с несертифицированными компонентами вызовет вопросы у безопасности.
• Не переносить приложения командой mv из временных каталогов на РЕД ОС. Копируйте или распаковывайте сразу на место, а после переноса делайте restorecon.
• Не верить «зелёному» прогону Ansible на новой ОС. Проверьте, сколько задач было пропущено и почему.