По умолчанию, любой пользователь домена имеет право входить на любой компьютер домена, включая сервера. Это опасная ситуация может создать благоприятные условия для проведения различных атак. Чтобы предотвратить подобного рода атаки можно ограничить доступ к серверам по определенным протоколам из пользовательского сегмента сети, но лучше полностью запретить обычным пользователям интерактивный вход на сервера.
Политика локального входа Windows
В домене Active Directory управлять правами локального входа в систему можно с помощью двух параметров групповых политик, которые находятся в разделе «Computer Configuration > Policies > Security Settings > Local Policies > User Rights Assignment» (Конфигурация пользователя > Политики > Параметры безопасности > Локальные политики > Назначение прав пользователя): - Allow log on locally (Локальный вход в систему) — определяет список пользователей и групп, которым разрешен локальный вход в систему. - Deny log on locally (Запретить локальный вход) — определяет список пользователей и групп, которым запрещен локальный вход в систему. Если пользователь попадает под действие двух параметров сразу, то запрещающий параметр имеет больше приоритет, поэтому доступ будет заблокирован доступ.
На контроллеры домена AD интерактивно могут заходить только пользователи шести административных групп, что определено параметрами объекта групповой политики Default Domain Controllers Policy.
Политики доступа к узлу FreeIPA
Для ограничения доступа к компьютерам в домене FreeIPA есть мощные правила управления доступом к хостам (host-based access control, HBAC), которые значительно превосходят по функциональности политики локального входа Windows. Они создают дополнительный слой авторизации, позволяя разрешить определенным пользователям использовать указанные службы на конкретных хостах. Что такое «пользователи» и «хосты» обычно вопросов не вызывает, но понятие «служб» требует дополнительных пояснений. В контексте правил HBAC службами являются любые приложения, которые используют PAM-стек, и при этом не важно, являются ли эти приложения просто исполняемыми файлами или работают как демоны в фоновом режиме. Как мы уже знаем, библиотека подключаемых модулей аутентификации (Pluggable Authentication Modules, PAM) обеспечивает унифицированный программный интерфейс для абстрагирования приложений (таких как login, sshd или sudo) от выполнения стандартных задач аутентификации. Перечень необходимых модулей аутентификации для каждого приложения задается индивидуально с помощью конфигурационных файлов из директории /etc/pam.d, поэтому настройки могут быть изменены в любой момент, что не потребует повторной компиляции приложения. За обработку правил HBAC, например, отвечает модуль pam_sss.so, который является одной из клиентских библиотек службы sssd, обеспечивающей работу хоста в домене.
При подключении пользователя по ssh служба sshd обращается к библиотеке PAM, чтобы создать контекст безопасности для выполнения команд от имени этого пользователя. При вызове функции "pam_start" служба передает библиотеке свой идентификатор (PAM service name), который представляет из себя простую строку, например, «sshd». Идентификатор службы обычно совпадает с именем исполняемого файла, но это не является обязательным условием, а некоторые приложения могут использовать даже несколько идентификаторов, например, утилита sudo может применять дополнительный идентификатор «sudo-i». Идентификатор службы определяет имя файла из каталога pam.d, откуда библиотека PAM будет брать настройки стека модулей (например, для службы sshd настройки будут из файла /etc/pam.d/sshd).
Для вступления в силу изменений в настройках HBAC-правил вы можете воспользоваться на целевой машине командами sss_cache -E или sssctl cache-remove, чтобы очистить локальный кэш службы sssd. Так же, стоит заметить, что в разных дистрибутивах Linux приложения могут использовать разные идентификаторы, например, ssh и sshd, поэтому список служб нужно будет расширять в соответствии с тем, какие операционные системы с каким программным обеспечением используются в инфраструктуре вашего предприятия.
Еще один важный момент. В силу особенностей FreeIPA в правилах HBAC не получится использовать следующие группы:
- группу пользователей ipausers, т.к. у нее нет POSIX идентификатора и поэтому на целевых хостах служба SSSD не отображает участие пользователей в этой группе. Группа ipausers является не POSIX группой, потому что это повышает производительность SSSD на клиенте. По умолчанию SSSD выгружает всю информацию о группах пользователя, включая список участников, поэтому при наличии в домене группы, в состав участников которой входят тысячи пользователей, службе SSSD придется записать много данных в кеш, а это довольно медленная операция;
- группу хостов ipaservers, т.к. у нее нет класса mepmanagedentry и соответствующих зависимостей.
Самый простой способ обойти указанные проблемы – это создать вспомогательные группы posix-ipausers/posix-ipaservers и сделать группы ipausers/ipaservers их участниками. В этом случае можно использовать вспомогательные группы в политиках без ограничений.
Настройка политик доступа к узлу
Как ограничить доступ к серверам
Правила HBAC являются «разрешающими», т. е. «по умолчанию» доступ к службам на доменных компьютерах запрещен, и его нужно открывать с помощью правил. Однако, при развертывании домена автоматически создается правило allow_all, которое разрешает доступ «всех ко всему», поэтому для управления авторизацией на уровне HBAC нам нужно сначала ограничить область применения этого правила, например, только группой администраторов.
Внести указанные настройки можно через веб-портал управления на странице «Групповые политики > Политики доступа к узлу > allow_all > Пользователи»:
То же самое можно сделать в командной строке:
kinit admin
ipa hbacrule-show allow_all
ipa hbacrule-mod allow_all --usercat=''
ipa hbacrule-add-user allow_all --group admins
ipa hbacrule-mod allow_all --desc='Разрешает администраторам доступ к любому хосту в домене'
Где:
- hbacrule-mod - команда, с помощью которой можно модифицировать настройки существующей группы; - allow_all - имя правила, которые мы хотим модифицировать; - usercat ( user category) - ключ, который позволяет изменить категорию для области применения в части пользователей. Может принимать значение 'all' или пустую строку '';
- hbacrule-add-user - команда, с помощью которой можно расширить область применения правила в части пользователей; - allow_all - имя правила, которое мы хотим модифицировать; - group - ключ, который позволяет добавить группу пользователей в область применения HBAC-правила; - admins - имя группы, которая будет добавлена в область применения правила;
- hbacrule-show - команда, с помощью которой можно получить информацию о существующем HBAC-правиле; - allow_all - имя правила, по которому мы хотим получить информацию;
ВАЖНО! Если из-за неправильной настройки HBAC-правил доступ к хостам будет заблокирован, то вы сможете подключиться к порталу управления с любого другого компьютера, который не находится в домене, чтобы исправить ошибку. Доступ к порталу управления не регулируется через механизм HBAC-правил.
Если ограничить область действия правила allow_all группой администраторов, то для остальных сотрудников компании нужно будет создать правило allow_computers, которое предоставит им право входа на обычные компьютеры в домене.
1. Создадим группу компьютеров:
ipa hostgroup-add computers
2. Сделаем описание только что созданной группы:
ipa hostgroup-mod computers --desc='Группа, в которой будут все обычные компьютеры домена'
3. Включим в группу computers компьютер с именем host1:
ipa hostgroup-add-member computers --hosts host1
4. Создадим HBAC - правило:
ipa hbacrule-add allow_computers
5. Сделаем описание только что созданному правилу:
ipa hbacrule-mod allow_computers --desc='Разрешает всем пользователям доступ к обычным компьютерам в домене'
6. Установим область применения - на всех пользователей:
ipa hbacrule-mod allow_computers --usercat=all
7. Установим область применения - на все службы:
ipa hbacrule-mod allow_computers --servicecat=all
8. Назначаем HBAC - правило на группу хостов computers:
ipa hbacrule-add-host allow_computers --hostgroup computers
Где:
- hbacrule-add - команда для создания HBAC-правила;
- hbacrule-mod - команда для модификации правила,
ключ --desc позволяет задать описание;
- команда hbacrule-add-host позволяет определить область применения правила;
- ключ hostgroups - позволяет указать группу хостов.
Проверим работу правила и попробуем войти доменным пользователем на контроллер домена (он не входит в группу разрешенных ко входу хостов):
sudo grep -i ald-user1 /var/log/auth.log | tail
Из журнала видно, что учётная запись пользователя ald-user1 не прошла проверку в модуле pam_sss подсистемы аутентификации pam. Более того, по журналу мы видим, что доступ требовался службе с идентификатором fly-dm.
Гранулированный доступ к службам
Для тонкой настройки HBAC-правил необходимо тщательно анализировать типовые сценарии работы пользователей в части используемых служб. Например, для подключения по RDP потребуются fly-wm и xrdp-sesman.
Чтобы понять, к какой службе требуется предоставить доступ, проще всего выполнить необходимое действие на целевой системе и посмотреть, какие сообщения об ошибках появятся в журнале auth.log.
После развертывания домена в системе уже есть список наиболее распространенных служб, но какие-то службы вам все равно потребуется добавить вручную. Давайте создадим «fly-dm», «flywm» и «xrdp-sessman». Сделать это можно через веб-интерфейс на странице «Групповые политики > Политики доступа к узлу > Службы HBAC», или в командной строке:
kinit admin
ipa hbacsvc-add 'fly-dm' --desc='Локальный вход в режиме рабочего стола'
ipa hbacsvc-add 'fly-wm' --desc='Доступ к оконному менеджеру ALSE'
ipa hbacsvc-add 'xrdp-sesman' --desc='Доступ по RDP'
Допустим, нам нужно предоставить возможность разработчикам из группы dev-users удаленно подключаться к своим компьютерам из группы dev-computers через SSH/RDP и выполнять отдельные команды из-под sudo. Для этого откройте страницу «Групповые политики > Политики доступа к узлу > Правила HBAC» и нажмите кнопку «Новое правило». Введите имя правила «allow_developers» и нажмите кнопку «Сохранить». Настройте область применения правила: группа пользователей «dev-users», группа хостов «dev-computers», службы fly-dm, fly-wm, xrdpsesman, sshd и sudo. Тоже самое можно сделать из командной строки:
kinit admin ipa hbacrule-add allow_developers --desc='Доступ для разработчиков' ipa hbacrule-add-user allow_developers --groups dev-users ipa hbacrule-add-host allow_developers --hostgroups dev-computers ipa hbacrule-add-service allow_developers --hbacsvcs fly-dm
ipa hbacrule-add-service allow_developers --hbacsvcs fly-wm ipa hbacrule-add-service allow_developers --hbacsvcs xrdp-sesman ipa hbacrule-add-service allow_developers --hbacsvcs sshd ipa hbacrule-add-service allow_developers --hbacsvcs sudo
Проверка HBAC-правил
Когда у вас в домене два-три правила, их довольно легко проверить напрямую, подключаясь к целевым хостам под тестовыми учетными записями, но в реальной инфраструктуре потребуется управлять десятками правил, и упростить их отладку поможет команда ipa hbactest, которая работает как RSOP в Windows, моделируя применение правил по тому же алгоритму, который будет использовать служба SSSD.
Вы можете выполнить команду на любом контроллере домена и для любого сочетания пользователь-хост-сервис, чтобы получить ответ о том, есть ли в домене правило, которое соответствует этим критериям. Например, давайте проверим, что пользователь ald-user1 имеет доступ к службе sudo на хосте host1 и dc1:
ipa hbactest --user=ald-user1 --host=host1 --service=sudo
ipa hbactest --user=ald-user1 --host=dc1 --service=sudo
Мы видим, что доступ к службе sudo у пользователя ald-user1 есть только на компьютере host1.
Выполним проверку конкретного правила allow_computers с помощью ключа --rules, сможет ли пользователь ald-user1 выполнить вход на компьютер host1 и dc1, для чего ему нужна служба fly-dm:
ipa hbactest --user=ald-user1 --host=host1 --service=fly-dm --rules allow_computers
ipa hbactest --user=ald-user1 --host=dc1 --service=fly-dm --rules allow_computers
Так же наглядной может быть демонстрация, что пользователь admin не может получить доступ к службе fly-dm на хосте dc-1 через правило allow_computers, хотя такое право у него есть через allow_all:
ipa hbactest --user=admin --host=dc1 --service=fly-dm --rules allow_computers
