Система Syslog

PAM

Подключаемые модули аутентификации (Pluggable Authentication Module – PAM) не защитят систему после того, как она была взломана, но они могут помочь предотвратить сам взлом. Повышение безопасности достигается за счет чрезвычайно гибкой системы аутентификации.

PAM – это центральный механизм аутентификации всех служб, в том числе команды login, утилит дистанционной регистрации (telnet, rlogin, rsh, ftp), протокола PPP и команды su. Модули PAM позволяют ограничить доступ к приложениям и время доступа к системе, реализовать альтернативные схемы аутентификации, осуществить расширенную регистрацию событий. Они могут использоваться с любыми Unix-приложениями.

Рис. 13.1. Схема функционирования модулей PAM

В основе лежит ядро PAM (библиотеки, находящиеся в каталоге /lib), которое отвечает за загрузку необходимых модулей на основании конфигурационных файлов. Общая последовательность действий такова:

1. Приложение, например login, делает первичное обращение к ядру PAM.

2. Ядро PAM находит соответствующий конфигурационный файл в каталоге /etc/pam.d (или обращается к файлу /etc/pam.conf) и загружает из него список модулей, необходимых для обслуживания запроса.

3. После этого ядро PAM загружает модули в том порядке, в котором они перечислены в конфигурационном файле.

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

Конфигурирование PAM

Есть два конфигурационных параметра компиляции модулей PAM. Первый из них заставляет модуль использовать либо файл /etc/pam.conf, либо группу файлов в каталоге /etc/pam.d. Второй подключает оба конфигурационных механизма, причем записи, найденные в каталоге /etc/pam.d, имеют приоритет над записями файла /etc/pam.conf.

Формат файла /etc/pam.conf и файлов каталога /etc/pam.d неодинаков. В первом случае имеется начальное поле, определяющее тип службы, т.е. приложение, к которому относится данная запись. Во втором случае в каталоге находятся файлы, имя каждого из которых соответствует названию приложения. Соответственно, поле типа службы в этих файлах отсутствует.

Формат записей конфигурационного файла:

тип_модуля управляющий_флаг путь_к_модулю аргументы

Типы модулей PAM:

· auth – модуль данного типа заставляет приложение запросить у пользователя идентификационные данные, например пароль. Модуль может назначать пользователю права доступа и предоставлять привилегии;

· account – модуль данного типа проверяет различные параметры учетной записи пользователя, связанные, в частности, с устареванием пароля, ограничивая доступ в систему определенными периодами времени или определенными адресами подключения. Можно также задать ограничения на использование системных ресурсов;

· session – модуль данного типа используется для выполнения определенных функций до и после организации сеанса. Сюда входят задание переменных среды, журнальная регистрация и т.д.;

· password – модуль данного типа обычно объединяется в стек с модулем типа auth. Он отвечает за обновление пользовательского маркера аутентификации (как правило, пароля).

Поле управляющий_флаг задает действие, выполняемое в зависимости от результатов работы модуля. Для одного и того же приложения может быть задано несколько модулей PAM (это называется стеком). Поле управляющий_флаг определяет также относительную важность модулей в стеке. Возможные значения данного поля:

· required – чтобы пользователь получил доступ к службе, работа модуля должна завершиться успешно. Если модуль включен в стек, остальные модули тоже выполняются. Приложению не сообщается о том, какой из модулей потерпел неудачу;

· requisite – аналогично предыдущему, но в случае неудачи остальные модули в стеке не выполняются и приложению немедленно возвращается код ошибки;

· optional – это необязательный модуль, но если он один в стеке, то в случае неудачи приложению возвращается код ошибки;

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

· [значение1=действие1

значение2=действие2] – использование данного синтаксиса позволяет более гибко управлять обработкой стека. Это называют флагом расширенного контроля.

Поле путь_к_модулю содержит полное имя модуля с указанием

пути доступа к нему.

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

· debug – заставляет модуль передавать дополнительную информацию в систему Syslog. Точные действия зависят от конкретного модуля;

· audit – заставляет модуль передавать расширенную информацию в систему Syslog;

· no_warn – запрещает передавать приложению предупреждающие сообщения;

· use_first_pass – заставляет модуль использовать пароль, полученный от предыдущего модуля. Если аутентификация прошла неудачно, попытки получить другой пароль не предпринимаются. Этот аргумент предназначен для использования только с модулями типа auth и password;

· try_first_pass – аналогично предыдущему, но в случае неуспешной аутентификации у пользователя будет запрещен другой пароль. Этот аргумент предназначен для использования только с модулями типа auth и password;

· likeauth – заставляет модуль возвращать одинаковое значение независимо от того, проверяется или задается пароль (либо другие идентификационные данные).

Каждый файл в каталоге /etc/pam.d связан с определенным приложением, по имени которого он назван. Этот файл содержит список записей, в каждой из которых задается тип модуля, управляющий флаг, путь к модулю и дополнительные аргументы. Модули одного типа считаются объединенными в стек и выполняются в указанном порядке, если только управляющие флаги не предписывают досрочно прекратить выполнение. Работой службы или приложения управляет весь стек, а не один конкретный модуль. Необязательные аргументы используются для контроля работы модуля.

Контрольные вопросы

1. Какая модель безопасности реализована в SELinux?

2. Возможно ли с помощью SELinux запретить то, что запрещено через установку прав пользователей/групп?

3. Какой тип политики SELinux основан на модели Белла-Ла Падула?

4. Сравните SElinux и RSBAC.

5. Какие недостатки Unix-систем устраняет RSBAC?

6. Каковы отличительные особенности GRsecurity по сравнению с SELinux и RSBAC?

7. Почему возникла необходимость в появлении PAM?

8. Опишите схему функционирования модулей PAM.

9. Какие действия, связанные с аутентификацией, невозможно реализовать в модуле PAM?

10. Каким образом можно контролировать работу модулей PAM?

Лекция 14.

МОНИТОРИНГ СОБЫТИЙ БЕЗОПАСНОСТИ
СРЕДСТВАМИ UNIX-СИСТЕМ

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

В Unix-системах существует множество журнальных файлов. Некоторые из них используются конкретными утилитами. Например, в файле /var/log/xferlog фиксируются записи об операциях по протоколу FTP. Журнальные файлы – важный источник информации о безопасности системы.

Система Syslog имеется во всех разновидностях Unix. В основе системы лежит демон syslogd, который принимает поступающие журнальные сообщения и обрабатывает их в соответствии с инструкциями, содержащимися в файле /etc/syslog.conf. Журнальные сообщения генерируются программами, демоном и ядром. Это относится к большинству внутренних системных утилит, в частности, к подсистемам электронной почты и печати, а также к внешним программам, таким как TCP_Wrappers и SSH.

Рис. 14.1. Механизм распространения журнальных сообщений

В терминологии системы Syslog программные компоненты, генерирующие сообщения, называются средствами. Каждое сообщение имеет определенный уровень важности. В файле /etc/syslog.conf указано, как обрабатывать сообщения в зависимости от типа средства и уровня важности: записывать в файл, направлять в другую систему, посылать пользователю или игнорировать.

Конфигурация Syslog

Записи файла /etc/syslog.conf имеют следующий синтаксис:

средство.уровень действие

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

Каждому демону, каждой программе и системной утилите соответствует определенное средство. Например, демоны inetd, telnetd и ftpd регистрируют свои сообщения от имени средства daemon. Средство по умолчанию – user. Разрешается задавать список средств, разделенных запятыми. Например, запись вида

daemon,lpr,mail.crit

соответствует всем сообщениям уровня crit (и выше) от средств daemon, lpr и mail.

Таблица 14.1.

Уровни важности Syslog

Уровень	Описание
emerg или panic	Работа системы парализована. Уровень panic считается устаревшим
alert	Ситуация, требующая немедленного реагирования
crit	Ошибка, которая препятствует нормальной работе определенной утилиты или подсистемы
err	Ошибка, которая препятствует нормальной работе компонента определенной утилиты или подсистемы
warning	Предупреждение
notice	Обычное событие, которое заслуживает внимания
info	Информационное сообщения
debug	Вспомогательное сообщение, не связанное с возникновением ошибки
none	Отсутствие уровня. Используется для задания исключения при наличии метасимвола *
*	Все уровни, кроме none

Допустимые уровни важности перечислены в Таблице 1 в порядке убывания.

Если в файле /etc/syslog.conf указан конкретный уровень, то подразумеваются сообщения этого и всех более высоких уровней. Например, селектору user.info соответствуют сообщения, регистрируемые от имени средства user на уровнях info, notice, warning, err, crit, alert и emerg. Для указания конкретных уровней предназначены специальные операторы! и =. В частности, выражению

user.=info

соответствуют только сообщения уровня info. Выражение

*.info;mail.!=info;user.none

означает, что регистрируются сообщения всех средств уровня info и выше, кроме средств mail и user. Для средства mail запрашиваются сообщения уровня notice и выше. Сообщения от средства user игнорируются.

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

Вызов демона syslogd

Демон syslogd запускается из сценария /etc/rc.d/init.d/syslog на уровне выполнения 2. По умолчанию не указывается никаких опций, но для правильной настройки системы Syslog могут понадобиться два флага: -r и –h.

Флаг –r используется при наличии сервера журнальной регистрации. По умолчанию демон syslogd не принимает сообщения от удаленных систем. Если указан флаг –r, демон будет ожидать поступления UDP-пактов через порт 514. Перед записью сообщения к нему добавляется имя удаленного компьютера. Если в файле /etc/syslog.conf не указано, как обрабатывать сообщение, оно игнорируется.

Если нужно, чтобы сервер журнальной регистрации сам пересылал сообщения, необходимо задать флаг –h. По умолчанию демон syslogd игнорирует записи файла /etc/syslog.conf, которые заставляют его пересылать сообщения из одной удаленной системы в другую.

После модификации файла /etc/syslog.conf необходимо сообщить демону syslogd об изменениях, послав ему сигнал HUP. Проще всего сделать это командой killall –HUP syslogd. Она заставит демон повторно прочитать свой конфигурационный файл. Если в файле /etc/syslog.conf указан новый журнальный файл, то после получения сигнала HUP этот файл будет создан.

Дата добавления: 2014-12-07