Привет, Хабр, меня зовут Елена, я работаю в компании «РЕД СОФТ» и отвечаю за функционал централизованного управления конфигурациями РЕД АДМ Промышленная редакция. В прошлой статье я рассказала о механизме работы конфигураций — одного из разделов подсистемы управления РЕД АДМ. Однако сферические конфигурации в вакууме — это, конечно, замечательно, но вам, дорогие читатели, наверняка хотелось бы больше реальных боевых кейсов. Их есть у меня!
Сегодня расскажу вам, как реальные кейсы наших заказчиков ложатся в основу стандартных конфигураций в РЕД АДМ, где уже это применялось и с какими трудностями столкнулись заказчики и разработчики (а также пресейл, техподдержка и все сообщ….то есть причастные). Конечно же, явок и паролей называть не буду, но техническую составляющую распишу во всех деталях.
Задачка по математике для администраторов старшего и младшего возраста
Ну что ж, рассмотрим реальный кейс использования наших конфигураций.
Дано: крупный заказчик (более n рабочих мест) планирует мигрировать на решения российских вендоров. В процессе миграции довольно‑таки много различных этапов, но сегодня мы рассмотрим лишь один (следите за нашими статьями, про остальные этапы мы тоже обязательно расскажем).
Найти: решение того, как управлять рабочими станциями на базе РЕД ОС.
Решение: С хостами на базе ОС Windows все более‑менее понятно, есть такой инструмент как RSAT. С помощью него вполне можно работать с существующими групповыми политиками и создавать новые.
Поэтому обратимся к конфигурациям, которые есть в РЕД АДМ. Конечно же, они не повторяют полностью групповые политики из MS AD (как минимум потому, что они управляют разными ОС), однако наиболее популярные в РЕД АДМ присутствуют. Ну а само решение ниже расписано в деталях.
Гляжу в него как в зеркало, а там рабочий стол
Одна из самых популярных корпоративных конфигураций — это картинка рабочего стола. Данная конфигурация относится к пользовательским, то есть в области применения нужно указать именно пользователя, для которого она будет выполняться. И вот на этом этапе возникла бы первая сложность в том случае, если бы заказчик решил воспользоваться просто чистым Ansible. Дело в том, что плейбуки выполняются от имени пользователя root, а смена картинки рабочего стола происходит с помощью консольной утилиты Gsettings, которая должна выполняться от имени интересующего нас пользователя, а также необходимы переменные окружения этого пользователя.
Для решения этой задачи мы используем утилиту sudo, с помощью которой определяем права пользователя, а также вычисляем значения переменных окружения DISPLAY и DBUS_SESSION_BUS_ADDRESS с помощью вот таких конструкций:
DISPLAY=`who | grep {{user}} | grep -oE '[^ ]+$'`
`DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/`id -u {{user}}{{domain}} /bus
Эта (или немного модифицированная) конструкция используется во всех пользовательских конфигурациях.
Возможно, вы могли заметить, что Gsettings используется не во всех графических окружениях РЕД ОС. Для окружения KDE Plasma мы используем kwriteconfig5, однако запуск от имени пользователя происходит аналогично примеру выше.
У меня для вас посылка, но я вам её не отдам у вас сертификатов нет
«Добавление сертификата» — еще одна популярная конфигурация. Эта конфигурация добавляет корневые сертификаты в ОС и является множественной, с ее помощью можно добавить в систему не один сертификат, а сразу несколько. Множественная конфигурация работает таким образом, что для каждого значения, заданного пользователем, формируется отдельный плейбук, который будет выполнен на машине из области применения. Сама конфигурация под капотом выглядит достаточно просто — файл загружается в хранилище корневых сертификатов и выполняется команда обновления update‑ca‑trust extract.
Репозиториев много не бывает
Так как работа над кейсом, о котором мы сейчас говорим, началась еще в прошлом году, то некоторых конфигураций на тот момент еще не было, а вот запрос от заказчика — был. На этот случай у нас есть блок «Собственные сценарии», с помощью которого можно реализовать ЛЮБУЮ идею системного администратора (даже если она противоречит здравому смыслу).
Запрос от заказчика был таков — нужно было изменить пути к стандартным репозиториям, так как репозитории у заказчики были локальные. Периодически мы помогаем в написании плейбуков или скриптов заказчикам. А уж если кейс оказался интересный и про него многие спрашивают, то появляется новая конфигурация.
Логика работы этой конфигурации достаточно проста — первые таски делают неактивными существующие репозитории. Это делается с помощью модуля replace, который заменяет параметр enabled=1 на enabled=0 в файлах /etc/yum.repos.d/RedOS-* и далее уже создается файл /etc/yum.repos.d/standart‑local.repo в который попадает вот такое содержимое:
base-local]
name=RedAdm-Base
baseurl = {{ url_base }}
gpgcheck = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-RED-SOFT
[updates-local]
name = RedAdm-Updates
baseurl = {{ url_update }}
gpgcheck = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-RED-SOFT
kernels-local]
name = RedAdm-Kernels
baseurl = {{ url_kerneles }}
gpgcheck = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-RED-SOFT
kernels6-local]
name = RedAdm-Kernels
baseurl = {{ url_kerneles6 }}
gpgcheck = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-RED-SOFT
Данная конфигурация немного была изменена с выходом РЕД ОС 8, потому что у нее не было репозитория для обновления ядра и поэтому часть полей в интерфейсе решено было сделать необязательными.
Рекомендации от которых невозможно отказаться
Еще один актуальный блок конфигураций появился похожим образом, как кейс с репозиториями, описанный ранее. Заказчику потребовалось выполнить рекомендации ФСТЭК России (методический документ от 25 декабря 2022 г.) и он обратился в службу технической поддержки за помощью. Наши специалисты предложили облегчить жизнь админа созданием bash‑скрипта, который бы выполнял рекомендации ФСТЭК (не все, но многие), а также делал проверку — выполнены ли эти рекомендации на хосте.
Скрипт — это, конечно, хорошо, подумали мы, его можно выполнять в блоки «Собственные сценарии», но почему бы не создать блок конфигураций, который бы выполнял эти рекомендации? Поэтому скрипт был разбит на несколько частей и переработан в плейбуки.
Основная сложность заключалась в том, что часть рекомендаций ФСТЭК затрагивают редактирование загрузчика, что может по неосторожности превратить систему в кирпич. И другая сложность была в написание конфигураций‑отмен, что представляло собой возврат состояния машины в исходное (до применения конфигурации). Так как этот блок появился у нас относительно недавно, расскажу обо всех конфигурациях подробнее.
Хоть и простая конфигурация, но с нюансом
«Шаблонный sudoers». Довольно‑таки простая конфигурация, состоящая всего из 2 тасков. Первый — создает файл‑бекапа текущего файла /etc/sudoers, а второй — заменяет файл на «эталонный». Однако, и здесь есть нюанс!
Зачастую наши заказчики прописываю какие‑либо правила в файл /etc/sudoers, что в целом не запрещено системой, однако, при применении этой конфигурации такие правила превратятся в тыкву. Поэтому все правила для sudo мы рекомендуем прописывать в дополнительных файлах /etc/sudoers.d/ .
Не всем пользователям su одинакова полезна
«Ограничение доступа к команде su». Эта конфигурация выполнена непосредственно по рекомендациям ФСТЭК России. В файле /etc/pam.d/su дописывается строка auth required pam_wheel.so use_uid, которая говорит системе о том, что использовать команду su могут только члены группы wheel. Далее, так как конфигурация имеет отмену, мы делаем бекап пользователей, входящих в группу wheel:
- replace:
regexp: 'wheel'
dest: /etc/group
replace: '#wheel'
when: group_wheel.stdout == ""
Причем делаем этот бекап только в том случае, если его еще не было. И далее уже дописываем новую строку с актуальными пользователям в /etc/group:
- lineinfile:
dest: "/etc/group"
line: "wheel:x:10:root,{{user_list}}"
state: present
Нет пароля, нет и пользователя
«Блокировка пользователей с пустыми паролями». На самом деле это конфигурация «на всякий случай», так как в РЕД ОС по умолчанию нельзя создавать пользователей с пустыми паролями. Конфигурация также имеет отмену, поэтому первым делом — создаем бекап файла с хешами паролей /etc/shadows. Далее, с помощью конструкции awk -F":" '($2 == "") {print $1}' /etc/shadow ищем пользователей с пустыми паролями и блокируем их.
Ни root’а тебе, ни ssh
«Запретить доступ root по ssh». Как ни странно, это одна из самых опасных конфигураций. Опасность ее заключается в том, что зачастую наши заказчики распространяют ключ для пользователя root (чего мы категорически не рекомендуем!) и, соответственно, когда доступ root по ssh закрывается, конфигурации перестают приходить на клиентские хосты. То есть если ключ распространен для пользователя root и применяется эта конфигурация – больше ничего работать не будет и поэтому нужно распространить ключ для другого пользователя.
Не важен размер ядра Linux, а важно умение его защитить
«Уменьшение периметра атаки ядра Linux» и «Механизмы защиты ядра Linux». Две очень схожие конфигурации, в которых редактируется загрузчик ядра. Мы хотели сделать эти конфигурации с возможностью их отмены и применения независимо друг от друга, то естественно, проверяем наличие записей в файле /etc/default/grub:
- name: check_vars
shell: cat /etc/default/grub | grep "vsyscall=none debugfs=no-mount tsx=off"
register: grub_vars
failed_when: grub_vars.rc not in [0,1]
Данная конфигурация должна быть с отменой, поэтому делаем бекап строки, в которую будут записываться данные:
- name: backup grub
replace:
regexp: "^GRUB_CMDLINE"
dest: /etc/default/grub
replace: "#GRUB_CMDLINE"
when: grub_check.stdout == ""
Sysctl параметры записываются в отдельный файл, который при отмене конфигурации просто удаляется:
- name: create config sysctl.conf
copy:
dest: /etc/sysctl.d/01-sysctl.conf
content: |
kernel.perf_event_paranoid=3
kernel.kexec_load_disabled=1
user.max_user_namespaces=2
kernel.unprivileged_bpf_disabled=1
vm.unprivileged_userfaultfd=0
dev.tty.ldisc_autoload=0
vm.mmap_min_addr=4096
kernel.randomize_va_space=2
Посторонним в файл вход воспрещён
«Права на файлы настроек пользователя». Данная конфигурация аналогична «Блокировке пользователей с пустыми паролями». На самом деле, файлы настроек пользователей и так имеют права 644. Однако, конфигурацию «Права на файлы настроек пользователя» можно применять, чтобы обезопасить себя в том случае, если админ решил все‑таки изменить эти права. Эта конфигурация не имеет отмены, так как она и так приводит права на файлы к эталонному виду. Это самый популярный вариант того, как появляются наши новые конфигурации.
Заключение
Ну чтож, как я обещала, вам был представлен реальный кейс администрирования нашей системы. На конечных примерах были продемонстрированы возможности РЕД АДМ Промышленная редакция. Никаких сферических коней, (то есть конфигураций) в вакууме. Надеюсь было интересно Кстати, если у вас есть плейбуки\скрипты, которые вы хотели бы видеть в интерфейсе РЕД АДМ, присылайте их нам или пишите в комментарии. Также у нас наконец‑то состоялся релиз нашей системы, поэтому кому интересно почитать о нём, милости прошу!
