В первой части мы обсудили правила HBAC и SUDO для ограничения доступа к хостам и предоставления прав на повышение привилегий. Теперь поднимем не менее важные вопросы: мы поговорим о политиках паролей, необходимости обновления учетных данных хостов и способах делегирования прав на ввод хостов в домен рядовым сотрудникам ИТ-службы.
- 1. Устанавливаем политики паролей
- 2. Обновляем пароли рабочих станций
- 3. Делегируем права на ввод хостов в домен
1. Устанавливаем политики паролей
Пароли являются самым простым, но при этом не самым безопасным способом аутентификации, так как их можно подобрать или перехватить, а если не устанавливать дополнительных ограничений по длине и сложности, то каждый двадцатый сотрудник в организации окажется счастливчиком, который угадает комбинацию из Топ-100, типа, 123456, password или qwerty. Совокупность требований к паролям называют также политиками. Чем строже эти требования, тем сложнее злоумышленнику подобрать пароль и воспользоваться результатами успешной атаки, но вместе с тем сложнее и пользователям работать в таком домене. Для разных групп пользователей следует устанавливать разные требования, обеспечивающие компромисс между удобством и безопасностью. И в этом вопросе главное – достичь компромисса с ИБ, поскольку, как известно, если жена хочет на море, а муж – в горы, то все едут загорать, но мужчине разрешают взять с собой лыжи.
Механизм политик паролей в домене ALD Pro (FreeIPA) позволяет для каждой группы пользователей создать отдельный набор правил. Учитывая то, что пользователь может входить сразу в несколько групп, алгоритм проверки выглядит следующим образом:
- Из контейнера «cn=cosTemplates,cn=accounts» отбираются шаблоны, под действие которых попадает текущий пользователь в соответствии с его участием в группах. В этих записях содержится минимальное количество информации, а расширенные наборы параметров представлены в контейнере «cn=kerberos» и связаны с шаблонами ссылками через значение атрибута krbPwdPolicyReference.
- Если на пользователя не распространяется действие ни одной политики, ему будет назначена глобальная политика (global_policy) по умолчанию.
- Если пользователь попадает под действие сразу нескольких политик, то параметры политик не суммируются, а выбирается одна из них, приоритет которой будет иметь наименьшее значение (см. таблицу 1).
Таблица 1. Выбор политики в зависимости от приоритета
Параметр | Политика для группы А(приоритет 0) | Политика для группы В(приоритет 1) | Результат (используются параметрыдля группы А, приоритет 0) |
Максимальный срок действия | 60 дней | 90 дней | 60 дней |
Минимальная длина | 10 символов | 0 (без ограничений) | 10 символов |
Проверки паролей ограничены возможностями MIT Kerberos, поэтому они поддерживают тот же самый набор параметров (см. таблицу 2).
Таблица 2. Параметры политик паролей
Параметр политики | Значение глобальной политики по умолчанию |
Максимальный срок действия задает период в количестве дней, в течение которого система не будет требовать смены пароля | krbMaxPwdLife = 90Пароль активен 90 дней, после чего пользователю будет предложено сменить его. |
Минимальный срок действия задает период в часах, в течение которого система будет запрещать повторную смену пароля | krbMinPwdLife = 1После смены пароля пользователь должен подождать 1 час перед повторной сменой. |
Размер журнала определяет количество предыдущих паролей, которые нельзя использовать повторно | krbPwdHistoryLength = 0Запрет на повторное использование паролей не налагается. |
Классы символов – этот параметр, который определяет требование по сложности пароля, указывая сколько разных классов символов должно быть использовано в пароле:цифры;буквы нижнего регистра;буквы верхнего регистра;символы UTF-8;все остальные символы, не вошедшие ни в одну из предыдущих групп, например, ! ” # $ % и т.д.Занятно, что при использовании одного и того же символа более двух раз подряд сложность пароля будет занижена на один балл. Например, если сложность пароля «Secret1pwd» будет оценена в три балла (большие буквы + маленькие буквы + цифры), то для пароля «Secret111pwd» сложность снизится до двух баллов (минус штраф за повторы символа «1»). При этом последний символ в пароле не учитывается, поэтому если повторяющиеся символы будут идти в конце строки, то нужно, чтобы их было не меньше четырех «Secretpwd1111», иначе штраф налагаться не будет. | krbPwdMinDiffChars = 0Требований по сложности пароля по умолчанию нет. |
Минимальная длина задает минимально допустимое количество символов в пароле. | krbPwdMinLength = 8Пользователь не может использовать пароль короче 8 символов. |
Максимальное количество ошибок определяет, сколько раз пользователь может неправильно ввести пароль, прежде чем его аккаунт будет временно заблокирован. Блокировка выполняется только на текущем контроллере, на другие сервера эта информация не передается. | krbPwdMaxFailure = 6Пользователь будет временно заблокирован после 7 неверно введенных паролей подряд. Срок блокировки указан в параметре krbPwdLockoutDuration. |
Интервал сброса ошибок задает период в секундах, по истечении которого счетчик неудачных попыток входа будет сброшен. | krbPwdFailureCountInterval = 60Если пользователь выждет 1 минуту после 6 неудачных попыток введения пароля, то счетчик неудачных попыток обнулится. |
Длительность блокировки задает период в секундах, в течение которого пользователь не сможет выполнить аутентификацию в домене. Блокировка накладывается после превышения количества разрешенных неудачных попыток входа. Блокировка выполняется только на текущем контроллере, на другие сервера эта информация не передается. | krbPwdLockoutDuration = 600Временно заблокированный пользователь не сможет осуществить вход в систему в течение последующих 10 минут. |
Следствием интеграции с MIT Kerberos является возможность использования таких атрибутов, как krbPrincipalExpiration и krbLastSuccessfulAuth. Например, с помощью команды ipa user-mod вы можете установить срок действия учетной записи, после которого пользователю станет недоступна Kerberos аутентификация:
ipa user-mod alexander.kuznetsov --principal-expiration='20330725115110Z' |
где срок действия учетной записи задается в формате временной метки:
- 2033 – год;
- 07 – месяц;
- 25 – день месяца;
- 115110 – часы, минуты, секунды;
- Z – часовой пояс по нулевому (Zero) меридиану.
Стоит заметить, что логирование даты последнего входа по умолчанию отключено из соображений повышения производительности домена, но ее можно включить изменением конфигурации сервера. Для этого потребуется посмотреть текущие настройки и установить новое значение параметра ipaconfigstring, исключив из него значение «KDC:Disable Last Success»:
ipa config-show | grep паролей Возможности подключаемого модуля паролей: AllowNThash, KDC:Disable Last Success ipa config-mod --ipaconfigstring='AllowNThash' ipactl restart kinit admin ipa user-show admin --all --raw | grep krbLastSuccessful krbLastSuccessfulAuth: 20230608094515Z |
1.1. Повышаем требования к паролям администраторов
Требования глобальной политики довольно лояльны, поэтому для группы администраторов их целесообразно сделать строже. Для этого откройте страницу «Групповые политики > Политики паролей» и нажмите кнопку «+ Новая политика паролей». В поле «Наименование группы пользователей» выберите admins, установите наименьший «Приоритет», равный 0, и нажмите кнопку «Сохранить». Далее вам станет доступна страница управления политикой, где вы можете задать необходимые настройки, как на нижеприведенной иллюстрации. То же самое можно сделать из командной строки:
$ ipa pwpolicy-add admins --priority=0 --maxlife=45 --minlife=0 --history=12 \ --minclasses=5 --minlength=12 --maxfail=3 --failinterval=120 --lockouttime=1200 Группа: admins Максимальный срок действия (в днях): 45 Минимальный срок действия (в часах): 0 Размер журнала : 12 Классы символов: 5 Минимальная длина: 12 Приоритет: 0 Максимальное количество ошибок: 3 Интервал сброса ошибок: 120 Длительность блокировки: 1200 |
Обратите внимание, изменение максимального срока действия пароля сразу же ни на что не повлияет, т.к. проверка выполняется по значению пользовательского атрибута krbPasswordExpiration, которое устанавливается в момент смены пароля. Текущее значение этого атрибута можно уточнить командой user-show:
$ ipa user-show admin --raw --all | grep krbPasswordExpiration krbPasswordExpiration: 20230528010101Z |
Таким образом, чтобы изменения в части срока действия паролей вступили в силу, пользователь должен хотя бы один раз сменить свой пароль, но при необходимости вы можете установить значение krbPasswordExpiration вручную с помощью команды user-mod. Это удобно также в тех случаях, когда вам нужно сбросить пользователю пароль, но вы не хотите, чтобы система сразу же требовала смены пароля.
$ ipa user-mod admin --password-expiration 20230528010101Z ---------------------------- Изменён пользователь "admin" ---------------------------- Имя учётной записи пользователя: admin Фамилия: Administrator Домашний каталог: /home/admin Оболочка входа: /bin/bash Псевдоним учётной записи: admin@ALD.COMPANY.LAN, root@ALD.COMPANY.LAN Окончание действия пароля пользователя: 20230528010101Z UID: 959800000 ID группы: 959800000 Учётная запись отключена: False Link to department: ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=local Пароль: True Участник групп: trust admins, lpadmin, admins Роли: ALDPRO - Main Administrator Доступные ключи Kerberos: True |
2. Обновляем пароли рабочих станций
При вводе компьютера в домен создается учетная запись вида host/pc-1.ald.company.lan, пароль от которой сохраняется в файле /etc/krb5.keytab и используется для проверки Kerberos-билетов при аутентификации пользователей и для получения информации из LDAP-каталога (правила HBAC и SUDO, информация о пользователях и группах и др.). Содержимое keytab-файла можно посмотреть с помощью утилиты klist:
root@pc-1:~# klist -ek /etc/krb5.keytab Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 1 host/pc-1.ald.company.lan@ALD.COMPANY.LAN (aes256-cts-hmac-sha1-96) 1 host/pc-1.ald.company.lan@ALD.COMPANY.LAN (aes128-cts-hmac-sha1-96) |
В файле находятся AES-ключи, полученные в результате хеширования сложных паролей, но это не защищает от всех видов атак, поэтому их все равно необходимо время от времени менять. Сделать это можно с помощью утилиты ipa-getkeytab, выполнив аутентификацию из-под учетной записи самого компьютера:
# kinit -kt /etc/krb5.keytab # ipa-getkeytab -p host/pc-1.ald.company.lan -k /etc/krb5.keytab |
После смены пароля можно убедиться, что в keytab-файле появилась новая пара ключей следующей версии:
# klist -ek Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 1 host/pc-1.ald.company.lan@ALD.COMPANY.LAN (aes256-cts-hmac-sha1-96) 1 host/pc-1.ald.company.lan@ALD.COMPANY.LAN (aes128-cts-hmac-sha1-96) 2 host/pc-1.ald.company.lan@ALD.COMPANY.LAN (aes256-cts-hmac-sha1-96) 2 host/pc-1.ald.company.lan@ALD.COMPANY.LAN (aes128-cts-hmac-sha1-96) |
3. Делегируем права на ввод хостов в домен
Ввод компьютера в домен ALD Pro осуществляется с помощью утилиты aldpro-client-installer, которая по цепочке вызывает утилиту astra-freeipa-client и скрипт ipa-client-install. Фактически присоединение к домену выполняет именно скрипт ipa, а две других утилиты отвечают за настройку агентов ALD Pro и других служб в соответствии с особенностями операционной системы Astra Linux. Но какой бы скрипт или утилиту вы ни использовали, процедура ввода в домен требует повышенных привилегий, и если вы предоставите учетные данные обычного пользователя, то получите ошибку «Joining realm failed: No permission to join this host to the IPA domain».
В большинстве инструкций для ввода машины в домен предлагают использовать учетную запись администратора домена, что не подходит для крупных организаций с большим штатом ИТ-специалистов, где эту функцию делегируют сотрудникам, не имеющим отношения к администрированию серверной группировки. Правильнее будет выдать данным сотрудникам минимальные права, которых достаточно для выполнения конкретной задачи. Для решения указанной задачи нам потребуется немного погрузиться в механизм работы ролевой модели.
Права доступа в службе каталога FreeIPA назначаются с помощью трехуровневой модели безопасности, которая включает в себя Роли (Roles), Привилегии (Privileges) и Разрешения (Permissions). На низком уровне Разрешениям соответствуют инструкции управления доступом 389 Directory Server (Access Control Instructions, ACI), которые определяют права на добавление, удаление, чтение, запись и другие действия по отношению к конкретным записям и атрибутам каталога. Разрешения группируются в Привилегии, Привилегии объединяются в Роли, а Роли назначаются пользователям.
В системе уже есть Роль «Enrollment Administrator», которая включает Привилегию «Host Enrollment», объединяющую почти все необходимые Разрешения за исключением права на создание хостов «System: Add Hosts», поэтому самым простым способом решения задачи является расширение списка Разрешений указанной Привилегии и назначение роли «Enrollment Administrator» пользователю.
ipa privilege-add-permission 'Host Enrollment' --permissions='System: Add Hosts' ipa role-add-member 'Enrollment Administrator' --users=enrolladmin |
Если вы не хотите изменять объекты, созданные в системе по умолчанию, то можно создать новую Роль и новую Привилегию, в которую включить все необходимые Разрешения:
ipa privilege-add 'New Host Enrollment' --desc='Ввод новых хостов в домен' ipa privilege-add-permission 'New Host Enrollment' \ --permissions='System: Add Hosts' \ --permissions='System: Add krbPrincipalName to a Host' \ --permissions='System: Enroll a Host' \ --permissions='System: Manage Host Certificates' \ --permissions='System: Manage Host Enrollment Password' \ --permissions='System: Manage Host Keytab' \ --permissions='System: Manage Host Principals' ipa role-add 'New Host Enrollment Administrator' --desc='Участники роли имеют привилегии, необходимые для регистрации новых компьютеров в домене' ipa role-add-privilege 'New Host Enrollment Administrator' \ --privileges='New Host Enrollment' ipa role-add-member 'New Host Enrollment Administrator' --users=enrolladmin |
После создания Роли ее можно будет назначать пользователям через веб-интерфейс на странице «Управление доменом \ Роли и права доступа \ Роли в системе»
На этом, наверное, пока все. Будем рады вашим комментариям. Команда ALD Pro прикладывает значительные усилия для выработки лучших практик использования продуктов технологического стека, и мы будем рады, если наши наработки помогут вам в реализации программы импортозамещения на вашем предприятии.
Свежие комментарии