LXF83:Hardcore Linux
|
|
|
Содержание |
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-аутентификации. В любом случае, безопас- ность определяется самым слабым звеном в цепи. Прежде чем зарываться в настройку 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. Модуль 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-брелок. Отданная вами команда должна выглядеть следующим обра- зом – только измените имя пользователя и размещение вашего 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 это означает стековую аутентификацию, и на следующей странице я покажу вам, как её настроить. Теперь вникнем в детали добавления нового метода PAM-аутенти- фикации. Для начала, нам нужно выбрать сервис, который мы хотим запереть с помощью нашего USB-ключа. Вышеупомянутый login – хоро- шая стартовая точка, отчасти потому, что его легко использовать, а отчасти – потому что не будет большой беды, если вы что-то заблокиру- ете (если, конечно, это не удалённая система, и login – не единственный способ подключиться к ней). Скрипт конфигурации PAM для login можно найти в /etc/pam.d/login; откройте его в своём любимом редакторе (или в нелюбимом, если вам нужно встряхнуться). Нам нужно проверить, что 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 куда больше возможностей, чем добавление нескольких дополнительных механизмов аутентификации. Теперь, когда вы вооружены идеями насчёт того, как создать собственный стек аутентификации и добавить произвольные модули, почему бы не построить супер-механизм аутентификации на базе той старой шляпы из фольги? LXF
