Существует много способов повышения безопасности ИТ-инфраструктуры, и внедрение доменных служб, таких как ALD Pro или Active Directory, является одним из них, т.к. помогает достижению цели уже только за счет централизованного управления учетными записями и конфигурациями рабочих станций. Но доменные решения не являются серебряной пулей, поэтому одного только развертывания домена будет недостаточно, и требуется должным образом настроить систему, для чего нужно разобраться в нюансах работы программных продуктов. В данной статье мы объясним, как работают основные механизмы обеспечения безопасности в домене ALD Pro. Материал будет полезен даже в том случае, если в вашей инфраструктуре пока еще используется ванильная система FreeIPA.

• 1. Ограничиваем доступ к хостам через правила HBAC

  • 1.1. Запрещаем доступ к хостам серверной группировки

  • 1.2. Управляем гранулированным доступом к службам

  • 1.3. Ограничиваем использование локальных учетных записей

• 2. Предоставляем права на повышение привилегий через правила SUDO

  • 2.1. Предоставляем права на управление службами через systemctl

  • 2.2. Ограничиваем действие локальных правил

  • 2.3. Ограничиваем область действия символов подстановки

  • 2.4. Исключаем запуск редактора vi с повышенными привилегиями

1. Ограничиваем доступ к хостам через правила HBAC

Только представьте себе: новому безопаснику выдают кружку, блокнот, ноутбук и доменную учетную запись, а он вместо того, чтобы пойти за кофе, начинает сразу ломиться на контроллер домена через ssh. Если системный администратор не подумает об этом сценарии заранее, то сотрудник зайдет на сервер и далее останется уповать только на правильные настройки доступа к объектам файловой системы. Чтобы предотвратить подобные атаки можно ограничить доступ по SSH из пользовательского сегмента сети, но в службе каталога есть и более удобный инструмент - так называемые правила управления доступом к хостам (host-based access control, HBAC). Они создают дополнительный слой авторизации, позволяя разрешить определенным пользователям использовать указанные службы на конкретных хостах.

Что такое «пользователи» и «хосты» обычно вопросов не вызывает, но понятие «служб» требует дополнительных пояснений. В контексте правил HBAC службами являются любые приложения, которые используют PAM-стек, и при этом не важно, являются ли эти приложения просто исполняемыми файлами или работают как демоны в фоновом режиме. Библиотека подключаемых модулей аутентификации (Pluggable Authentication Modules, PAM) обеспечивает унифицированный программный интерфейс для абстрагирования приложений (таких как login, sshd или sudo) от выполнения стандартных задач аутентификации. Перечень необходимых модулей аутентификации для каждого приложения задается индивидуально с помощью конфигурационных файлов из директории /etc/pam.d, поэтому настройки могут быть изменены в любой момент, что не потребует повторной компиляции приложения. За обработку правил HBAC, например, отвечает модуль pam_sss.so, который является одной из клиентских библиотек службы sssd, обеспечивающей работу хоста в домене. Механизм работы правил HBAC отражен на рисунке 1

При подключении пользователя по ssh служба sshd обращается к библиотеке PAM, чтобы создать контекст безопасности для выполнения команд от имени этого пользователя. При вызове функции "pam_start" служба передает библиотеке свой идентификатор (PAM service name), который представляет из себя простую строку, например, «sshd». Идентификатор службы обычно совпадает с именем исполняемого файла, но это не является обязательным условием, а некоторые приложения могут использовать даже несколько идентификаторов, например, утилита sudo может применять дополнительный идентификатор «sudo-i». Идентификатор службы определяет имя файла из каталога pam.d, откуда библиотека PAM будет брать настройки стека модулей (например, для службы sshd настройки будут из файла /etc/pam.d/sshd).

Наверно, стоит заметить, что в разных дистрибутивах Linux приложения могут использовать разные идентификаторы, например, ssh и sshd, поэтому список служб нужно будет расширять в соответствии с тем, какие операционные системы с каким программным обеспечением используются в инфраструктуре вашего предприятия.

1.1. Запрещаем доступ к хостам серверной группировки

Давайте воспользуемся правилами HBAC, чтобы ограничить возможность обычным пользователям запускать приложения на хостах серверной группировки. По умолчанию механизм HBAC запрещает доступ ко всем службам на доменных компьютерах, но при развертывании домена автоматически создается правило allow_all, которое разрешает доступ «всех ко всему», поэтому для управления авторизацией на уровне HBAC нам нужно сначала ограничить область применения этого правила, например, только группой администраторов. Внести указанные настройки можно через веб-портал управления на странице «Групповые политики > Политики доступа к узлу > allow_all > Пользователи» или через командную строку:

Если ограничить область действия правила allow_all группой администраторов, то для остальных сотрудников компании нужно будет создать отдельное правило allow_computers, которое предоставит им право входа на обычные рабочие станции в домене.

Сначала создайте группу хостов computers, для этого откройте страницу «Пользователи и компьютеры > Группы компьютеров», нажмите кнопку «Новая группа», введите имя группы, ее описание и нажмите кнопку «Сохранить». На вкладке «Компьютеры» внесите рабочие станции в состав участников группы. Затем создайте правило HBAC, для этого откройте страницу «Групповые политики > Политики доступа к узлу > Правила HBAC», нажмите кнопку «Новое правило», введите имя правила allow_computers, сохраните его, после чего определите следующую область действия: любой пользователь, группа computers, любая служба. Все тоже самое можно сделать из командной строки:

Рис. 3 Настройка правила HBAC для работы обычных пользователей

1.2. Управляем гранулированным доступом к службам

Для тонкой настройки HBAC нам потребуется тщательно анализировать типовые сценарии работы пользователей в части используемых служб. Например, для подключения по RDP потребуются fly-wm и xrdp-sesman, см. таблицу 1

Таблица 1 Службы, необходимые для типовых сценариев работы

Чтобы понять, к какой службе требуется предоставить доступ, проще всего выполнить необходимое действие на целевой системе и посмотреть, какие сообщения об ошибках появятся в журнале auth.log. На приведенном ниже примере видно, что пользователю не хватает прав на запуск sshd:

После развертывания домена в системе уже есть список наиболее распространенных служб, но какие-то службы нам все равно потребуется добавить вручную. Давайте создадим «fly-dm», «fly-wm» и «xrdp-sessman». Сделать это можно через веб-интерфейс на странице «Групповые политики > Политики доступа к узлу > Службы HBAC» или из командной строки:

Допустим, нам нужно предоставить возможность разработчикам из группы dev-users удаленно подключаться к своим компьютерам из группы dev-computers через SSH/RDP и выполнять отдельные команды из-под sudo. Для этого откройте страницу «Групповые политики > Политики доступа к узлу > Правила HBAC» и нажмите кнопку «Новое правило». Введите имя правила «allow_developers» и нажмите кнопку «Сохранить». Настройте область применения правила: группа пользователей «dev-users», группа хостов «dev-computers», службы fly-dm, fly-wm, xrdp-sesman, sshd и sudo. Тоже самое можно сделать из командной строки:

Рис. 5 Пример настройки правила HBAC для предоставления удаленного доступа через SSH/RDP

1.3. Ограничиваем использование локальных учетных записей

При установке операционной системы создается как минимум одна учетная запись локального администратора, с помощью которой на этом хосте можно получить права суперпользователя, поэтому жизненный цикл локальных учетных записей на компьютерах в домене требует повышенного внимания со стороны системных администраторов.

Есть разные подходы к решению этой задачи, например, вы можете организовать управление паролями локальных пользователей через скрипты групповых политик, внедрить IDM или использовать сторонние приложения, как LAPS (Local Admin Password Solution) в Active Directory. Но самый простой способ — это, конечно, заблокировать локальные учетные записи, например, с помощью команды passwd:

Чтобы не блокировать учетные записи по одной, в продукте ALD Pro для управления операционными системами Astra Linux есть специальная групповая политика, которую можно найти в «Параметры компьютеров > Безопасность > Политика безопасности > Политика локального входа». Если добавить этот параметр в соответствующий объект групповой политики и выставить значение «no», то вход локальными учетными записями будет заблокирован через штатную систему PARSEC.

2. Предоставляем права на повышение привилегий через правила SUDO

Хорошо известно, что безопасники плохого не посоветуют, но и хорошего не разрешат, однако, для установки программного обеспечения и выполнения других задач администрирования сотрудникам все же необходимы привилегии суперпользователя. Для этих целей можно, конечно, использовать учетную запись root, но из соображений безопасности рекомендуют все же работать из-под обычной учетной записи и повышать привилегии только при выполнении отдельных команд. Еще более востребован указанный подход, когда часть административных прав нужно делегировать обычным пользователям, например, чтобы разрешить им перезапуск служб.

В ОС Windows повышение привилегий реализуется с помощью команды «Запуск от имени администратора», которая вызывает утилиту runas.exe с требуемыми параметрами. На компьютерах под управлением Linux аналогичного результата можно добиться с помощью утилиты sudo (Substitute User and Do, подменить пользователя и выполнить), которая имеет богатые настройки и позволяет журналировать неудачные аутентификации. Например, вызовом следующей команды обычный пользователь может установить приложение htop, если ему разрешено запускать утилиту apt через sudo:

Правила SUDO, подобно правилам HBAC, создают дополнительный слой авторизации, позволяя определенным пользователям на конкретных хостах выполнять отдельные команды с повышенными привилегиями. Отличие между этими видами правил заключается в том, что правила HBAC проверяются на уровне PAM-стека, а правила SUDO непосредственно внутри кода утилиты sudo, поэтому для возможности использования утилиты sudo пользователю в первую очередь нужны права на обращение к этому приложению на уровне HBAC, иначе до проверки правил SUDO даже не дойдет.

Локальные настройки утилиты sudo находятся в файле /etc/sudoers, который назван так потому, что пользователей, которым разрешено повышать привилегии с помощью утилиты sudo, называют sudo enabled users или кратко sudoers. Файл можно править в любом редакторе, однако, учитывая, что любая очепятка может привести к отказу в работе системы, администраторам настоятельно рекомендуется использовать visudo. Но, как известно, инструктаж по технике безопасности ученики слушают намного внимательнее, если у трудовика не хватает указательного пальца.

В файле могут быть строки трех типов: параметры по умолчанию, псевдонимы (алиасы, именованные списки или проще переменные) и сами правила, синтаксис которых представлен на рисунке 7

Правила могут быть как разрешающими, так и запрещающими, но по умолчанию считается, что прав на выполнение команд через sudo ни у кого нет. Приведем несколько примеров правил:

Прокомментируем каждый из компонентов:

1) Пользователи и группы пользователей, которым разрешен запуск команд в рамках данного правила, например, ALL, localuser или %localgroup. Символ процента перед именем указывает на то, что это имя группы.

2) Хосты, на которых разрешен запуск команд, например, ALL, имя компьютера pc1 или его IP адрес 192.168.45.12. Параметр полезен, если один и тот же файл копируется на несколько хостов.

3) Пользователи, от имени которых разрешен запуск команд. При выполнении команды через sudo по умолчанию предполагается, что команда запускается от имени root, но можно указать имя пользователя в явном виде с помощью ключа -u. Вместо ALL можно указать имена конкретных пользователей, чтобы ограничить перечень допустимых значений.

4) Первичные группы, в контексте которых разрешен запуск команд. По умолчанию используется первичная группа пользователя, от имени которого выполняется команда, но группу можно указать явно с помощью ключа -g. Данное значение проявляет себя, когда выполняются команды, которые создают новые файлы и папки, например, touch или mkdir. Вместо ALL можно указать имена конкретных групп, чтобы ограничить перечень допустимых значений. Этот компонент правила не является обязательным.

5) Параметры, с которыми будет выполнена команда, позволяют изменить поведение утилиты sudo, например, можно отключить запрос пароля с помощью NOPASSWD (назначение параметров можно посмотреть в справке man sudoers, а полный список допустимых значений включает EXEC, NOEXEC, FOLLOW, NOFOLLOW, LOG_INPUT, NOLOG_INPUT, LOG_OUTPUT, NOLOG_OUTPUT, MAIL, NOMAIL, PASSWD, NOPASSWD, SETENV и NOSETENV). Этот компонент правила не является обязательным.

6) Команды, которые разрешено запускать в рамках этого правила. Это должен быть полный путь к исполняемому файлу, который можно узнать с помощью команды which на целевом хосте. В строке команды можно указать параметры, с которыми разрешается запуск утилиты.

Мы рассмотрели, как работают правила SUDO из локального файла sudoers. Но правила можно хранить не только в локальных файлах, но и централизованно. Любой сервер каталогов можно сделать поставщиком правил SUDO, если расширить схему должным образом и назначить каталог источником правил. Утилита sudo получает список источников правил через библиотеку службы имен (Name Service Switch, NSS), настройки которой находятся в файле /etc/nsswitch.conf. В операционных системах Linux через этот механизм настраиваются источники для получения информации о пользователях, группах, DNS и многом другом. После установки freeipa-client в файле /etc/nsswitch можно увидеть, что для базы данных sudoers правила сначала берутся из локального файла, а затем - через модуль службы SSSD, которая отвечает за взаимодействие с LDAP-каталогом.

Когда вы начнете погружаться в работу с правилами SUDO, вас могут озадачить несколько моментов:

• Изменения правил SUDO вступают в силу с большой задержкой из-за кеширования SSSD, поэтому для немедленного применения правил на клиентской машине необходимо выполнить команду sss_cache -E.

• Правила SUDO не получится применять напрямую для групп ipausers/ipaservers, но указанные группы можно сделать участниками обычных групп, тогда эти вспомогательные группы можно будет использовать в правилах SUDO без ограничений.

• В LDAP-каталоге правила SUDO находятся сразу в двух контейнерах «cn=sudorules,cn=sudo» и «ou=sudoers», что сделано для совместимости с UNIX-системами, nss-плагины которых не поддерживают более функциональную схему данных FreeIPA. За обеспечение совместимости отвечает плагин Compat.

2.1. Предоставляем права на управление службами через systemctl

Давайте предоставим пользователям право на остановку и перезапуск служб на компьютерах, где они смогут выполнить интерактивный вход в систему. Начнем с создания команды. Это можно сделать в меню «Групповые политики > Политики повышения привилегий». Далее создадим правило SUDO, разрешающее использование данной команды любому пользователю на любом компьютере. Тоже самое можно сделать из командной строки:

Рис. 8 Настройка правила SUDO для предоставления возможности перезапуска служб

2.2. Ограничиваем действие локальных правил

Предполагается, что в файле sudoers должны быть заданы правила для локальных пользователей, а в LDAP-каталоге, соответственно, для управления привилегиями доменных пользователей, но использование двух источников одновременно может привести к очень неприятной коллизии.

Администратор с ограниченными правами, которому были делегированы полномочия только на управление объектами отдельного структурного подразделения, может создать в этом подразделении группу с именем sudo или astra-admin, включить себя в состав одной из этих групп и получить привилегии суперпользователя на всех компьютерах в домене, включая сервера, так как в файле /etc/sudoers на этих машинах по умолчанию содержатся соответствующие локальные правила.

Чтобы избежать указанной проблемы, вы можете воспользоваться одним из следующих способов:

1. Удалите источник files для базы sudoers из файла /etc/nsswitch . В этом случае при вызове утилиты sudo настройки из локального файла учитываться не будут, и пользователи групп sudo и astra-admin потеряют возможность повышать свои привилегии.

2. Заранее создайте в домене группы с именами, которые используются в локальных файлах sudoers, чтобы администраторы с ограниченными правами не смогли создать такие группы в вверенных им подразделениях. В ALD Pro с версии 2.0.0 имена групп sudo и astra-admin уже запрещены на портале управления, поэтому для создания групп с такими именами вам нужно будет воспользоваться инструментами командной строки ipa.

2.3. Ограничиваем область действия символов подстановки

Команды допускают применение не только конкретных значений, но и шаблонов подстановки (wildcards), или как их еще называют метасимволов: знак вопроса «?» соответствует одному любому символу, а знак звездочки «*» соответствует любому количеству любых символов. Но с шаблонами подстановки нужно быть предельно осторожными, так как команда «/usr/bin/cat /var/log/messages*» неожиданно позволит прочитать не только журнал messages, но и любой другой файл на диске. Дело все в том, что утилита cat - это не просто вывод содержимого файла на экран, она позволяет объединять в поток содержимое сразу нескольких файлов (и даже называется так от слова concatenate, сцеплять), поэтому никто не помешает пользователю добавить к журналу messages содержимое другого файла, например, shadow:

Для предотвращения нежелательного поведения утилиты sudo в шаблон следует добавить еще одну команду, которая будет запрещать вызов команды cat с пробелами в параметре:

2.4. Исключаем запуск редактора vi с повышенными привилегиями

Работая в приложении vi, пользователь может не только редактировать текст, но и запускать команды оболочки, что дает значительные преимущества. Например, если в процессе редактирования файла конфигурации потребуется ввести точный путь к какому-то сертификату, пользователь сможет выполнить команду :shell, чтобы провалиться в оболочку и стандартными командами cd и ls уточнить необходимую информацию, а затем командой exit вернуться к редактированию файла.

Вместе с тем, такая реализация утилиты делает крайне опасным использование этого редактора вместе с правилами SUDO. Допустим, администратору нужно было предоставить сотруднику право на редактирование файла ldap.conf, и он создал следующее правило:

На первый взгляд все правильно, и пользователь сможет получить право редактировать файл от имени суперпользователя. Но при этом ему ничто не помешает запустить :shell из редактора и прочитать содержимое любого файла, в том числе /etc/shadow. Можно, конечно, попытаться заблокировать эту функцию опцией NOEXEC, но потом окажется, что в приложении есть еще команда :Texplore, поэтому лучше все же не давать прав на запуск этого редактора с повышенными привилегиями.

На этом мы завершаем первую часть статьи и рекомендуем дождаться следующего выпуска, в котором мы расскажем о том, как работают политики паролей, как менять пароли рабочих станций и как делегировать права на ввод хостов в домен рядовым сотрудникам ИТ-службы. Команда ALD Pro прикладывает значительные усилия для выработки лучших практик использования продуктов технологического стека, и мы будем рады, если наши наработки помогут вам в реализации программы импортозамещения на вашем предприятии.