Сегодня система подключаемых модулей аутентификации РАМ поставляется в комплекте практически с любым UNIX’om. Но немногие знают, что с ее помощью можно получить просто безграничный контроль над юзерами и способами входа в систему. К примеру, организовать аутентификацию по отпечаткам пальцев и USB-ключам, поместить пользователей в chroot-окружение и защитить хост от брутфорс-атак.

Мы уже рассматривали РАМ (Pluggable Authentication Modules) в одном из предыдущих выпусков журнала [речь идет о статье «Система безопасности РАМ изнутри», опубликованной в февральском номере JE за 2006 год, — Прим.ред.) Для тех, кто пропустил, объясню в двух словах. Система подключаемых модулей аутентификации представляет собой специальную модульную библиотеку, возможности которой может использовать любое приложение, осуществляющее аутентификацию и/или авторизацию пользователей. Хороший пример — системная утилита /bin/login, отвечающая за вход пользователя в ОС. До появления РАМ она должна была сама находить пользователя в базе /etc/passwd и сверять хеш введенного им пароля с хранящимся в базе хешем. Сегодня все эти действия осуществляет РАМ. а /bin/login только вызываетее из своего кода и проверяет возвращаемый статус. Но это пустяк, потому что настоящая мощь РАМ заключается в ее модульности, благодаря которой можно легко изменить используемый метод аутентификации (хочешь входить по отпечаткам пальцев — нет ничего проще!) и авторизации пользователь должен уйти в chroot после логина — легко!) путем редактирования всего лишь одного конфигурационного файла. РАМ использует закрепленные за приложениями конфиги для получения информации отом, какие модули следует использовать для аутентификации/авторизации пользователя. Все они располагаются в каталоге/etc/pam.d. Рассмотрим пример одного из них — файл /etc/pam.d/ login, закрепленный за утилитой/bin/login:

#vi/etc/pam.d/login
auth sufficient pam_self .so no_warn
auth include system
account  requisite pam_securetty. so
account  required   pam_nologin.so account  include system session  include system password include system

Формат конфигурационного файла РАМ был подробно описан в вышеназванной статье, поэтому сейчас я скажу только о том, что существует четыре стека РАМ-модулей, модули

• каждого из которых вызываются поочередно. Первый столбец как раз и указывает на используемый стек:
• auth — сюда помещаются модули, проводящие аутентификацию;
• account — модули, определяющие, можно ли пользователю зайти;
• session — выделение ресурсов для пользователей (например, монтирование домашнего катал о га);
• password — модули, обеспечивающие обновление учетной записи пользователя и его пароля (этот стек использует команда /и s г/ bin/passwd).

Второй столбец — это флаг, который определяет, что делать в случае (не)успешной отработки модуля. Третий столбец — имя модуля, четвертый — его аргументы (также модуль может иметь конфигурационный файл, располагающийся в каталоге/etc/security). Обрати внимание на особую директиву include, которая не вписывается в общий синтаксис и позволяет подключать другой конфиг (чтобы не дублировать содержимое). В нашем случае для каждого стека указан включаемый файл system (также расположенный в каталоге/etc/pam). Это специфика FreeBSD; Linux-дистрибутивы Debian и Ubuntu используют для тех же целей файлы common- (common-auth, common-session и т.д.), a Gentoo и Mandriva — system-. В одном из этих файлов ты обязательно найдешь строку с запуском РАМ-модуля, ответственного за поиск пользователя в базе/etc/passwd и сравнение хешей:

auth required pam_unix.so no_warn try_f irst_pass nullok

Уберем ее, и двери захлопнутся, больше в систему не войдешь. А теперь немного магии. Какя уже говорил, изменяя несколько строк в конфигурационных файлах, мы можем сделать с методом аутентификации и авторизации все, что угодно (в рамках возможностей доступных модулей, конечно). Возьмем, к примеру, файл /etc/pam.d/ su, стек модулей auth которого выглядит так:

#vi /etc/ра m. d/su
auth sufficient pam_rootok. so no_warn
auth sufficient pam_self .so no_ warn
auth requisite pam_group.
so no_warn group=wheel root_only
fail_safe
auth include system

Сначала вызывается модуль pam_rootok, который проверяет UID пользователя, запустившего приложение, и успешно завершается, если он равен нулю. Все остальные модули в этом случае пропускаются (флагsufficient). Если первый модуль завершился неудачно (пользователь не root), стартует модуль pam_self, который проверяет, совпадает ли UID вызывающего пользователя с UID'om пользователя, для которого осуществляется авторизация. Если это так, остальные модули не запускаются (поясню на примере: если пользователь vasya делает «suvasya», модуль возвращает «да», и su выполняется успешно, не спрашивая пароля). Далее с помощью модуля pam_group происходит проверка на членство вызывающего пользователя в группе wheel, и, если это не так, пользователя отфутболивают (флаг requisite). В конце выполняются модули, помещенные в стек auth в файле /etc/pam.d/system (вызов pam_unix, сверяющего пароль). Приведу несколько примеров. Хочешь сделать так, чтобы su не смог пользоваться никто? Тогда удали все эти строки и впиши на их место «auth sufficient pam_deny.so». Модуль pam_deny — это аналог команды false. Он всегда выполняется неудачно, поэтому su не сможет воспользоваться ни один пользователь, включая root. Антипод ему — модуль pam_permit, всегда исполняющийся удачно. Запиши в/etc/pam.d/su строку«auth sufficient pam_permit.so», и su смогут использовать все, кому не лень, не вводя пароль.
Но все это игрушки в сравнении стем, что нас ждет дальше.

Стандартная комплектация Linux-PAM и ОрепРАМ уже включает в себя несколько модулей аутентификации, которые следует помещать в стек auth. Это, например, модуль pam_guest, который позволяет использовать для аутентификации специальные гостевые аккаунты, pam_ftpusers, впускающий пользователя только если его имя присутствует вфайле/etc/ftpusers, или pam_securetty, разрешающий суперпользователю логиниться лишь с терминалов, которые помечены как secure в файле/etc/ttys (или просто перечислены в файле/etc/securetty в Linux). Все они задействованы в системах аутентификации различных приложений, но для нас особого интереса не представляют. В большинстве систем среди штатных модулей есть такие, которые позволяют производить аутентификацию с помощью USB-ключей, смарт-карт и даже отпечатков пальцев. Возьмем, к примеру модуль pam_usb. Он считывает ключ с USB-брелка и на его основе делает вывод о правомочности пользователя войти в систему Вставил брелок — вошел, вынул — система заблокирована. Интересно? Тогда вперед.

В портах FreeBSD pam_usb нет, поэтому все описанное ниже пригодится только пользователям Linux (примеры даны для Debian/ Ubuntu). Установим pam_usb и нужные для его настройки утилиты:
# apt-get install libpam-usb pamusb-tools
Подключим USB-брелок и запустим pamusb-conf, чтобы добавить флешку в конфигурационный файл:
# pamusb-conf --add-device любое__имя
Утилита попросит выбрать нужное устройство, раздел, используемый для хранения ключа, и спросит о том, следует ли заносить устройство в конфигурационный файл. Следует ответить «да», то есть «у». Добавим пользователей, которые смогут войти в систему с помощью этого USB-брелка:
# pamusb-conf --add-user root
Выбираем уже добавленный в конфиг брелок, нажимаем «у» и проверяем правильность произведенных настроек:
# pamusb-check root
На этом настройка pam_usb завершена. Осталось добавить pam_usb в стек auth необходимых приложений и насладиться результатом.
Не будем утомлять себя редактированием всех конфигурационных файлов РАМ, закрепленных за каждым приложением, и внесем изменения во включаемый файл/etc/pam.d/common-auth. Для этого откроем его в редакторе и перед строкой, содержащей имя pam_unix.so, добавим строку «auth sufficient pam_usb.so». Теперь любое приложение, конфигурационный файл РАМ которого включает в себя common-auth, будет пытаться аутентифицировать пользователя с помощью ключа, записанного на USB-брелок, и только в случае неудачи запросит пароль. С отпечатками пальцев дело обстоит еще проще. Уже год как существует замечательный проект fprint Iwww.reactivated. net/fprint/wiki/Main Page), смысл которого в разработке унифицированной библиотеки для работы с различными сканерами отпечатков (подключаемых к USB-порту) и набора утилит для работы с ней. Кроме прочего, в комплект утилит входит и нужный нам модуль pam_fprint. Связка libfprint и pam_fprint уже включена по умолчанию в новые релизы Ubuntu и Fedora и доступна через систему портов FreeBSD (/usr/ports/security/pam_fprint). Поэтому вручную устанавливать ничего не потребуется, а для настройки необходимо выполнить всего два шага. Первый — создать слепок пальца с помощью следующей команды:
$ pam_fprint_enroll --enroll-finger 6
Цифра 6 означает большой палец правой руки. Система fprint нумерует пальцы обеих рук слева направо, от одного до десяти, так что 1 — это мизинец левой руки, а 8 — средний палец правой.
Второй шаг. Добавить pam_fprint в стек auth необходимых приложений. Для этого открываем уже знакомый нам /etc/ pam.d/common-auth (или /etc/pam.d/system во FreeBSD) и вставляем в начало строку «auth sufficient pam_fprint. so». При необходимости указываем флаг required вместо sufficient, чтобы без отпечатка вообще нельзя было войти (но не рекомендую этого делать; современные потребительские системы распознавания отпечатков пальцев далеки от совершенства).
ЧЕРНЫЕ СПИСКИ, БЕСПАРОЛЬНЫЕ ПОЛЬЗОВАТЕЛИ И АЛЬТЕРНАТИВНЫЕ БАЗЫ ПАРОЛЕЙ
Процесс помещения пользователей в черные и белые списки до появления РАМ обычно превращался в какое-то шаманство, сопровождаемое многочисленными экспериментами, а конечная цель достигалась за счет использования костылей. Сегодня пользователям и системным администраторам живется намного легче: существует несколько РАМ-модулей, позволяющих реализовать блэклистинг и автоматизацию входа пользователя в систему. Возьмем, к примеру, модуль pam_listfile (доступный только в пакете Linux-PAM). С его помощью легко настроитьсис-тему беспарольного входа пользователей. Просто добавь следующую строку в конфигурационный РАМ-файл нужного приложения и запиши беспарольных пользователей в файл /etc/users.allow:
auth sufficient pam_listfile. so item=user sense=allow file=/etc/users.allow onerr=fail
Немного изменив строку, можно добиться запрещения входа пользователей:
auth sufficient pam_listfile.so item=user sense=deny file=/etc/users.deny onerr=fail
Причем, в качествезначения опции item можно использовать также tty, user, rhost, ruser, group, shell. Это дает возможность запрещать/позволять вход не только на основе имен пользователей, но и имени терминала, с которого происходит вход, имени удаленного хоста/пользователя, группы и т.д.
Другой похожий модуль называется pam_access. Он использует более гибкий и сложный формат конфигурационного файла и предназначен для помещения в стекассс-unt (проверка, может ли пользователь войти, осуществляется уже после того, как он представился, то есть ввел правильные логин и пароль). Модуль удобно использовать в связке с ssh для выставления за дверь неугодных. Для этого надо поместить модуль в стек account: «account required pam_access.so» и создать файл /etc/security/access.conf примерно с таким содержимым:
- : ALL : ALL w ДСП'
Это означает, что получить доступ через ssh могут все из подсети 192.168.1.0 и парень с логином good_guy. Остальные идут лесом. На просторах всемирной паутины можно найти и более простой модуль pam_lockout (ostaticcom/pam-lockout]. Он позволяет перечислить имена неугодных пользователей прямо в конфигурационном файле РАМ: «auth requisite pam_lockout.so user=bad_guy». Для организации беспарольной системы входа пользователей с консоли удобно использовать модуль pam_alredyloggedin (ilya-evseev. narod.ru/posix/pam alreadyloggedin). Он запрашивает пароль только в случае, если пользователь еще не залогинился в другой консоли (идеальное решение, когда используешь сразу несколько консолей, переключаясь между ними с помощью <Alt+Fx>). Для настройки просто помещаем следующие две строки на самый верх стека auth (в начало файла):
auth required    /lib/security/pam_securetty.so
auth sufficient /lib/security/pam_alreadyloggedin.so
no root
Возвращаясь к спискам пользователей, нельзя не упомянуть о довольно интересном модуле pam_pwdfile (cpbotha.net/software/pam pwdfilel. Его задача — предоставить приложениям альтернативную базу пользователей и паролей, которую они смогут использовать вместо системного файла /etc/passwd. Это своего рода плагин для тех приложений и демонов, которые не способны вести подобную базу самостоятельно. Яркий пример: минималистичный FTP-cepBepvsftpd. Запусти его от непривилегированного пользователя, и клиенты не смогут получить доступ к серверу Выход: использовать pam_pwdfile, который будет вести отдельный файл логинов и паролей специально для vsftpd. Для использования достаточно добавить следующие две строки в начало/etc/pam.d/vsftpd:
auth required pam_pwdfile.so pwdfile /usr/local/etc/ vsftpd/vsftpd.users
account required pam_pwdfile.so pwdfile /usr/local/ etc/vsftpd/vsftpd.users
И добавить пользователей в базу с помощью утилиты chpwdfile [eclipse.che.uct.ас.za/chpwdfile) — либо руками заполнив его строками вида: «логин:М05-хеш-пароля».
На закуску я оставил вкуснейший модуль pam_abl [hexten.net/ pam). самостоятельно ведущий и обновляющий черные списки пользователей-брутфорсеров. Это отличная портабельная между UNIX'aMH альтернатива блэклистингу на основе правил брандмауэра. Модуль вычисляеттех, кто слишком настойчиво пытается пройти аутентификацию, и блокирует аккаунт или вызывающий хост на определенное время. Для настройки открываем/etc/pam.d/sshd и добавляем в начало строку «auth required pam_abl.so config=/etc/ security/pam_abl.conf». По умолчанию модуль настроен на блокировку аккаунта. Это правильно, если твой хост подвергся распределенному брутфорсу, но вызовет проблемы для легальных пользователей, которые попытаются войти в систему сразу после проведения безуспешной попытки «взлома». В обычной ситуации для борьбы со скрипт-кидди лучше настроить блокировку на основе имени вызывающего хоста. Поэтому открываем файл /etc/security/pam.conf и пишем в него:
# vi /etc/secur ity/pam_abl.conf
// Черный список host_db=/var/lib/abl/hosts -db // Блокировка сроком на два дня host_purge=2d
// Блокировка любого хоста после 10 неудачных попыток за 1 час
host_rule=*:10/lh пространства имен, автомонтирование, chr00t
Как было сказано выше, стек РАМ-модулей session предназначен для модулей, подготавливающих окружение для только что вошедшего пользователя. Это можетбыть любое действие, связанное с выделением или ограничением доступных пользователям ресурсов. Наиболее показательный пример — модуль pam_limits из пакета Linux-РАМ (но не Open РАМ). Он ограничивает ресурсы приложений вошедшего пользователя на основе конфигурационного файла /etc/ security/Limits, conf.
Если говорить о сторонних разработках, то в первую очередь сле-дуетупомянуть полезнейший модуль pam_chroot (sourceforge.net/ projects/pam-chroot], единственная задача которого — помещать вошедших пользователей в песочницу. Модуль незаменим, когда требуется организация shell-, ftp- или какого-либо другого хостинга и любых конфигураций, предусматривающих вход в систему сомнительных лиц. Модуль очень прост в использовании. Для настройки достаточно выполнить две команды:
# echo ’session required pam_chroot. so ‘ >> /etc/pam.d/ ssh
# echo ‘vasya /usr/chroot’ >> /etc/security/chroot. conf
Все, теперь vasya, вошедший с помощью ssh-клиента, будет помещен в каталог/usr/chroot и не сможет из него выбраться. На втором месте в рейтинге — модуль pam_mkhomedir из пакета Linux-PAM, просто создающий домашний каталог для прошедшего аутентификацию пользователя.
Поначалу полезность модуля может показаться сомнительной, но администраторы гетерогенных сетей, состоящих вперемешку из машин Windows/UNIX, ценят его дороже своих потертых джинсов. Дело втом, что в таких сетях принято использовать Active Directory для хранения учетных данных пользователей, коих может быть не одна сотня. Вместо того чтобы создавать многочисленные каталоги для каждого пользователя, зарегистрированного в AD, они просто выполняют приведенную ниже команду на всех UNIX-машинах и удаляются в серверную порезаться в «контру»:
# echo ’session required pam_mkhomedir. so skel = /etc/ skel/ umask=027′ >> /etc/pam.d/common-session
Модуль обычно используется в связке с модулем pam_winbind, осуществляющим аутентификацию в AD, или с pam_ldap, аутентифи-цирующим пользователей, используя сервер LDAP. Почетное третье место занимает завязанный на возможностях Linux-ядра модуль pam_namespace. Его задача — незаметное создание изолированной копии общедоступного каталога l/tmp, например) для каждого пользователя. Другими словами, вошедший пользователь получает доступ только к своей версии каталога Amp и не видит файлов других пользователей. Нужно это для борьбы с методами взлома, основанными на использовании состояний гонок (race condition), символических ссылок и просто для ограждения возможного нарушителя от любых файлов легальных пользователей. Модуль использует простой конфигурационный файл/etc/security/ namespace.conf для принятия решения отом, какие каталоги должны быть подменены.