Журнал LinuxFormat - перейти на главную

LXF83:Hardcore Linux

Материал из Linuxformat
Перейти к: навигация, поиск
Подписка на печатную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подписка на электронную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подшивки старых номеров журнала (печатные версии)
Весь 2014 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)

Содержание

PAM Аутентификация на заказ

Аутентификация пользователей – это не для новичков, но при грамотном применении PAM-модулей можно настроить довольно хитроумные схемы входа в систему – даже используя скромный USB-брелок. Грэм Моррисон покажет – как.

Большинство из нас считает аутентификацию пользователя само собой разумеющейся: вводим имя пользователя и пароль, жмём Enter, и всё. Но всякий раз, когда вы входите в свою систему – хоть через обычную консоль, хоть с помощью графического менеджера вроде GDM, хоть удалённо, используя SSH – существует фоновая система, проверяющая ваши полномочия, и почти всегда этой системой является PAM, как сокращённо именуются подключаемые модули аутентификации (Pluggable Authentication Modules). Я сказал «почти», потому что Slackware по умолчанию не задействует PAM – насколько мне известно, он один такой среди крупных дистрибутивов. Пользователи же SUSE, Fedora, Ubuntu и Mandriva могут использовать PAM прямо сейчас. Конкретно мы займемся на данном уроке вот чем: добавим новый модуль аутентификации, который позволит вам входить в систему, не используя ничего, кроме USB-брелка. Такой пример – лучший способ разобраться, как работает PAM и почему это такой замечательный инструмент. Несмотря на сложность этой темы и на тот факт, что вы все-таки читаете учебник для профессионалов, вы обнаружите, что настроить собственный модуль аутентификации с помощью PAM относительно просто. Мы пометили этот учебник «для профессионалов», так как будем иметь дело с аутентификацией пользователей. С PAM может быть очень сложно работать, и если вы что-то сделаете неправильно, последствия могут быть катастрофическими.

Предостережение

Коль скоро вы соблюдаете обычную меру предосторожности, резервируя все редактируемые файлы, при испытании этого USB-проекта беспокоиться особо не о чем. Но всё будет немного иначе, если вы планируете использовать USB-аутентификацию в реальном окружении, как первую линию обороны от пользователей, пытающихся обольстить вашу систему с целью получения неавторизованного доступа. В этом случае единственное требование – убедитесь, что PAM настроен как надо. Нужно также ограничить физический доступ к машине и заблокировать все не в меру вольные сервисы, запущенные на вашей системе. Даже когда пользователи аутентифицируются исключительно при помощи USB-брелка, злоумышленник сможет получить административный доступ к вашей системе, просто нажав кнопку «Reset» и перегрузив ваш дистрибутив в безопасный режим (failsafe mode).

Если вы планируете использовать PAM, чтобы защитить свою систему таким способом, важно также иметь стратегию ограничения физического доступа к вашему компьютеру. Простое решение – запереть компьютер в защищённом помещении и подключить к USB-хабу, запертому в вашем столе. Так могут делать люди, желающие обезопасить свои драгоценные «USB-замки» для программной аутентификации, и вы можете это использовать для PAM-аутентификации. В любом случае, безопасность определяется самым слабым звеном в цепи.

Шаг 1 – Зачем нужен PAM

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

Проблема тогда заключалась в том, что не существовало единого унифицированного интерфейса, используемого при аутентификации пользователей. Тем, кто разрабатывал инструменты, требующие входа (login), приходилось вручную связывать свое приложение с необходимым методом (или методами) аутентификации. Хороший пример – Linux-команда login, генерирующая приглашение ввести имя пользователя на виртуальных терминалах. До PAM login нужно было связывать с каждым механизмом аутентификации, угодным автору, а это могли быть столь несходные методы, как шифрованные пароли, биометрия и всевозможные смарт-карты. Разработчикам было нелегко заниматься сопровождением в этой ситуации. Если администратор решал изменить механизм аутентификации, нужно было перенастраивать все приложения, которые его использовали.

Вот почему появился PAM. PAM размещается между тем, что называется сервисами (в основном, login и другие программы «системного входа»), нуждающимися в механизме аутентификации, и самим механизмом. В сервис нужно только встроить поддержку PAM – и употреблять любой метод аутентификации, предусмотренный в PAM. Пока login использует PAM, разработчику больше ни о чем думать не нужно: это забота PAM, и если вам нужно изменить механизм аутентификации для login, ftp или su, PAM – единственное место, где это нужно делать.

И аутентификация всей страны!

Как правило, файлы конфигурации PAM находятся в каталоге /etc/pam.d вашей файловой системы. Этот каталог содержит файлы конфигурации всех приложений с аутентификацией через PAM, обычно включающие записи для стандартных сервисов, например, gdm, xdm, cups и даже screensaver – почти всех, в которых требуется пароль.

Взглянув на любой конфигурационный файл PAM, вы увидите нечто подобное (взято из gdm в SUSE 10.1):

auth include common-auth account include common-account password include common-password session include common-session


Каждый столбец этого конфигурационного файла представляет одну из четырёх директив. Это тип интерфейса модуля (первый столбец), флаг управления (второй столбец), путь к модулю (третий столбец) и любые аргументы модуля (в примере gdm их нет, поэтому столбец пустой). Интерфейс модуля и сам имеет четыре варианта, каждый из которых показан в нашем примере – auth, account, password и session. Модули auth будут аутентифицировать пользователей, что обычно означает проверку соответствия имени пользователя и пароля. Затем идут модули account, проверяющие правильность учётной записи. Password, естественно, проверяет пароль, а session обеспечивает выполнение всего, что полагается сделать перед предоставлением сервиса пользователю, например, монтирование пользовательского домашнего или почтового каталога.

Наиболее важный столбец – второй, флаг управления; его-то мы и будем менять в нашем новом модуле, чтобы изменить требования аутентификации, когда вставлен USB-брелок. В нашем куске кода из конфигурационного файла gdm все четыре поля установлены в include. Это особый случай, поскольку ключевое слово include на самом деле указывает PAM направление к другому конфигурационному файлу в третьем поле (common-auth). Этот файл содержит общие правила, пригодные для различных сервисов. Содержимое файла login указывает туда же.

Открыв файл /etc/pam.d/common-auth, вы увидите нечто вроде следующего (если вы используете старую версию PAM, эта информация будет в файле gdm): 

auth    required    pam_env.so
auth    required    pam_unix2.so

Когда пользователь входит в систему, модуль аутентификации передаёт сигнал к флагу управления практически тем же способом, как возвращают сигналы процессы и функции. Этот сигнал сообщает о том, что происходило, пока процес или функция исполнялась. Есть сигналы для «успеха» и «неудачи», а есть и сигналы для ошибок сервиса или оповещения, что учётная запись устарела. С новыми версиями PAM вы можете создавать собственные правила для любого из этих условий, это облегчает обработку исключений.

Приведённый выше фрагмент включает более типичный флаг управления – required. Он говорит PAM, что модуль auth обязан завершиться успешно. Менее строгий флаг управления – sufficient, означающий, что если аутентификация для этого модуля успешна, системе PAM не нужно продолжать аутентификацию какими-нибудь другими модулями, чтобы предоставить доступ. Другой общий флаг управления – optional, который, как подсказывает название, не критичен для предоставления доступа. Причина, почему существуют меняющиеся степени «успешности», заключается в том, что вы можете объединить модули вместе и проектировать аутентификацию на основе «успешности» отдельного модуля или стека из нескольких – именно то, как мы будем настраивать нашу аутентификацию по USB.

Шаг 2 - Установка модуля USB

Модуль USB, который нам понадобится, разрабатывается отдельно от основного приложения PAM, и пока считается не завершенным, хотя на самом деле полностью функционален. Называется он Pam_usb, и его можно найти на нашем диске или на www.pamusb.org. Последняя версия выпущена в октябре 2005 года, но она работает с ядрами 2.6 и современными дистрибутивами.

Первый шаг – скачать исходный код с сайта Pam_usb. Сборка и инсталляция модуля очень просты: наберите make, затем – make install с правами root , а конфигурационного скрипта здесь нет. Будет установлена пара скриптов hotplug и создан каталог /etc/pam_usb. Кроме того, в /usr/bin будет установлен инструмент администрирования usbadm. Скрипт hotplug разработан для блокировки сеанса, когда извлекается USB-устройство, используемое для аутентификации.

Сидеть! Место!

Очень важно, чтобы ваше устройство USB всегда обнаруживалось в одном и том же месте. Горячее подключение USB-устройств печально известно в Linux как ненадёжное, но многие из последних дистрибутивов, похоже, наконец-то заставят его работать. Сложность заключается в том, что модулю Pam_usb необходимо находить устройство USB в одной и той же точке монтирования, когда бы вы ни подключили его к машине.

К тому же, настоятельно рекомендуется, чтобы устройства монтировали себя сами (используя hotplug); в противном случае вы завязнете, если не сможете войти на машину и разобраться с хулиганящим USB-оборудованием. Я обнаружил, что и SUSE 10.1, и Ubuntu 6.06 работают без каких-либо дополнительных ухищрений. Современные дистрибутивы монтируют эти устройства согласно их идентификаторам, назначенным изготовителем и определяемым скриптом hotplug при опросе USB (вы можете сделать это сами, набрав lsusb). Когда вы сможете достоверно находить ваше устройство USB в файловой системе, вам потребуется передать эту информацию в usbadm; она автоматически создаст ключи, необходимые для шифрования, чтобы защитить вашу информацию, и скопирует все файлы конфигурации на их законные места в файловой системе и на USB-брелок.

(thumbnail)
Создание ключа шифрования DSA с помощью usbadm очень похоже на генерацию ключа с помощью GnuPG – и не удивительно, поскольку оба используют один и тот же вид шифрования.

Отданная вами команда должна выглядеть следующим образом – только измените имя пользователя и размещение вашего USB-устройства: 

usbadm keygen /media/KINGSTON graham 1024

В этом примере /media/KINGSTON – точка монтирования USB-брелка, graham – имя пользователя, а 1024 – размер DSA-ключа шифрования, который должен сгенерироваться. Фактически эта команда размещает открытый ключ в .auth в пользовательском каталоге, а закрытый ключ в .auth на USB-устройстве. Тем, кто знаком с шифрованием парным ключом, известно, что неважно, кому доступен публичный ключ – но каждый владелец копии закрытого ключа сможет пройти аутентификацию и войти на вашу машину. Другими словами, любая личность, присвоившая ваше USB-устройство...

Укрепляем USB

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

Есть два решения этой проблемы. Первая – держать ваш закрытый ключ на USB-устройстве с определенным серийным номером. Модуль Pam_usb может затем проверять этот серийный номер и убеждаться, что приватный ключ не был скопирован.

Если ваше USB-устройство снабжено встроенным серийным номером, вы можете запросить его и добавить его к модулю, набрав usbadm addserial, или добавить его вручную, введя usbadm addserial 12345. Серийный номер добавляется к /etc/pam_usb/serials.conf. Использовать серийные номера таким способом не совсем безопасно – отчасти потому, что программисту относительно легко раскрыть серийный номер, хранящийся в вашем устройстве, а отчасти потому, что так мало USB-брелков действительно снабжены серийный номер. Итак, подумаем над альтернативным решением.

Двойная защита

Каждый отдельный метод аутентификации называется токеном, и каждый имеет сильные и слабые стороны. В случае с приватным ключом, размещённым на USB-брелке, слабостью, очевидно, является безопасность ключа и серьёзное неудобство в случае потери USB-брелка. Аналогично, основная слабость парольной аутентификации – атака подбором (brute force): взломщик может пройтись по тысячам хорошо известных комбинаций символов в надежде угадать ваш пароль.

Решение, оно же моя альтернатива использованию серийного номера – двухкаскадная аутентификация, задействующая два различных метода одновременно. Здесь безопасность USB-брелка должна играть важную роль. Комбинация приватного ключа, размещённого на USB-брелке, и обычной аутентификации по паролю предоставляет сильный уровень системной безопасности и защищает от наиболее общей атаки на безопасность: подбора пароля. При использовании двух методов аутентификации, даже если пароль будет угадан, потенциальному злоумышленнику всё-таки не обойтись без закрытого ключа с вашего USB-брелка. В PAM это означает стековую аутентификацию, и на следующей странице я покажу вам, как её настроить.

Шаг 3 - Ваша конфигурация PAM

Теперь вникнем в детали добавления нового метода PAM-аутентификации. Для начала, нам нужно выбрать сервис, который мы хотим запереть с помощью нашего USB-ключа. Вышеупомянутый login – хорошая стартовая точка, отчасти потому, что его легко использовать, а отчасти – потому что не будет большой беды, если вы что-то заблокируете (если, конечно, это не удалённая система, и login – не единственный способ подключиться к ней). Скрипт конфигурации PAM для login можно найти в /etc/pam.d/login; откройте его в своём любимом редакторе (или в нелюбимом, если вам нужно встряхнуться).

(thumbnail)
Это – рабочий файл конфигурации PAM из SUSE 10.1, модифицированный добавкой модуля Pam_usb.

Нам нужно проверить, что Pam_usb работает, и простейший способ проверки – убедиться, что это единственный метод, требуемый для входа в систему, для чего мы закомментируем строку, включающую auth required pam_unix2.so. Если такой строки нет, вероятно, найдётся строка с директивой include, указывающей на файл с именем common-auth. Просмотрите содержимое этого файла, и найдете auth required pam_unix2.so – но здесь это закомментировать было бы глупо, потому что тогда любой другой сервис, включающий common-auth, не сможет выполнить аутентификацию и блокирует вашу систему.

Вместо этого скопируйте содержимое из common-auth в login, и закомментируйте обе строки – include, указывающую на этот файл, и строку, заканчивающуюся на pam_unix2.so. Затем добавьте auth require pam_usb.so; получится нечто вроде 

auth     required    pam_usb.so
auth     required    pam_env.so
#auth    required    pam_unix2.so
#auth    include     common-auth


Переключитесь в виртуальный терминал, убедитесь, что ваше USB-устройство подключено, и попробуйте войти в систему, используя учётную запись пользователя, которую вы настраивали с помощью пары открытого/закрытого ключей. Если всё пойдёт по плану, пароль у вас не спросят: вместо этого вы окажетесь в системе под вашей учётной записью. Вы даже можете заметить огонёк на вашем USB, вспыхивающий, когда Pam_usb считывает публичный ключ. На экране вы должны увидеть следующее: 

Authentication request for user graham from local console (/dev/tty2)
Access granted

Это сообщение отображается всякий раз, когда модуль Pam_usb выполняет свою работу. Если вы извлечёте ваше USB-устройство, то обнаружите, что обратно вас не пускают, и отображается предупреждение. Попробуйте подключить ваш USB-брелок и попытаться ещё раз.

Ура! Вы только что сумели заставить работать USB-аутентификацию. Но что произойдёт, если вы потеряете свой USB-брелок? Вы не сможете войти в систему. Это катастрофа! Решение – добавить ещё одно правило в стек в конфигурационном файле PAM. Просто раскомментируйте строку с pam_unix2.so, и измените директиву для pam_usb на sufficient: 

auth    sufficient    pam_usb.so
auth    required      pam_unix2.so


Как мы видели ранее, это означает, что если PAM сможет аутентифицировать пользователя только по USB-модулю, то так оно и будет. В противном случае процедура перекинется на нормальную аутентификацию по паролю с использованием pam_unix2.so. Старые версии PAM будут использовать pam_unix.so. (Это, вероятно, самое мудрое решение для тех, кто боится потерять свой USB-брелок).

Пароль про запас

Данный способ использования Pam_usb, несомненно, предлагает приемлемый уровень безопасности для домашней машины, и удобен тем, что не требует пароля – но если вы действительно бережёте свою учётную запись, вам нужен иной уровень безопасности. Простейший способ сделать это – настроить требование как пароля, так и USB-аутентификации одновременно, пресекая подбор вашего пароля и копирование ключа с USB-брелка.

Для этого просто измените sufficient для pam_usb снова на required, чтобы конфигурационный файл выглядел следующим образом: 

auth    required    pam_usb.so
auth    required    pam_unix2.so


Поздравляем – у вас есть работающая система USB-аутентификации, использующая PAM. Просто подойдите к вашей машине и вставьте USB-брелок – правда, круто? Но зачем останавливаться на достигнутом? Для лучшей интеграции с вашим рабочим столом следующий шаг – взять ту же самую процедуру, которую мы использовали для login, и сделать такие же изменения с другими сервисами, которые ваша система использует для аутентификации пользователей – хотя бы с графическим менеджером входа в систему GDM. Запуск утилит с привилегиями администратора через sudo – тоже хорошее применение для ваших свежеобретённых навыков. Просто сделайте такие же изменения в /etc/pam.d/sudo, какие мы делали в /etc/pam.d/login, и пользователи вашей системы смогут использовать sudo, только если подключен USB-брелок.

У PAM куда больше возможностей, чем добавление нескольких дополнительных механизмов аутентификации. Теперь, когда вы вооружены идеями насчёт того, как создать собственный стек аутентификации и добавить произвольные модули, почему бы не построить супер-механизм аутентификации на базе той старой шляпы из фольги?

Источник — «http://wiki.linuxformat.ru/wiki/index.php?title=LXF83:Hardcore_Linux&oldid=6474»
Персональные инструменты
купить
подписаться
Яндекс.Метрика