LXF83:Hardcore Linux - История изменений

Yaleks: категория

2009-01-07T09:14:22Z

категория

Heeppy в 09:38, 22 апреля 2008

2008-04-22T09:38:16Z

Heeppy в 17:50, 16 апреля 2008

2008-04-16T17:50:25Z

Внесённые изменения

Bellycat77: /* Предостережение */

2008-03-10T11:29:55Z

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

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

2008-03-10T11:06:45Z

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

Bellycat77: /* Сидеть! Место! */

2008-03-10T11:00:27Z

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

Bellycat77: /* Укрепляем USB */

2008-03-10T10:58:31Z

‎Укрепляем USB

Bellycat77: /* Двойная защита */

2008-03-10T10:57:28Z

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

Bellycat77: /* PAM Аутентификация на заказ */

2008-03-10T10:50:33Z

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

Внесённые изменения

Bellycat77: Новая: == PAM Аутентификация на заказ == ''Аутентификация пользователей – это не для новичков, но при грамотном ...

2008-03-10T10:39:59Z

Новая: == PAM Аутентификация на заказ == ''Аутентификация пользователей – это не для новичков, но при грамотном ...

Новая страница

== 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

← Предыдущая		Версия 09:14, 7 января 2009
Строка 206:		Строка 206:

	[[Категория:Учебники]]		[[Категория:Учебники]]
		+	[[Категория:Hardcore Linux]]
		+	[[Категория:Грэм Моррисон]]

@@ Строка 67: / Строка 67: @@
   Интерфейс модуля    Флаг управления    Путь к модулю    Опции
   auth                include            common-auth      null
-|Ширина=400px
+|Ширина=450px
 }}
@@ Строка 78: / Строка 78: @@
 К тому же, настоятельно рекомендуется, чтобы устройства монтировали себя сами (используя hotplug); в противном случае вы завязнете, если не сможете войти на машину и разобраться с хулиганящим USB-оборудованием. Я обнаружил, что и SUSE 10.1, и Ubuntu 6.06 работают без каких-либо дополнительных ухищрений. Современные дистрибутивы монтируют эти устройства согласно их идентификаторам, назначенным изготовителем и определяемым скриптом hotplug при опросе USB (вы можете сделать это сами, набрав '''lsusb'''). Когда вы сможете достоверно находить ваше устройство USB в файловой системе, вам потребуется передать эту информацию в usbadm; она автоматически создаст ключи, необходимые для шифрования, чтобы защитить вашу информацию, и скопирует все файлы конфигурации на их законные места в файловой системе и на USB-брелок.
 Отданная вами команда должна выглядеть следующим образом – только измените имя пользователя и размещение вашего USB-устройства:
@@ Строка 116: / Строка 118: @@
   session    required      /lib/security/pam_limits.so
-|Ширина=350px
+|Ширина=450px
 }}
 Теперь вникнем в детали добавления нового метода 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, не сможет выполнить аутентификацию и блокирует вашу систему.

@@ Строка 6: / Строка 6: @@
 === Предостережение ===
-Коль скоро вы соблюдаете обычную меру предосторожности, резерви-
+Коль скоро вы соблюдаете обычную меру предосторожности, резервируя все редактируемые файлы, при испытании этого USB-проекта беспокоиться особо не о чем. Но всё будет немного иначе, если вы планируете использовать USB-аутентификацию в реальном окружении, как первую линию обороны от пользователей, пытающихся обольстить вашу систему с целью получения неавторизованного доступа. В этом случае единственное требование – убедитесь, что PAM настроен как надо. Нужно также ограничить физический доступ к машине и заблокировать все не в меру вольные сервисы, запущенные на вашей системе. Даже когда пользователи аутентифицируются исключительно при помощи USB-брелка, злоумышленник сможет получить административный доступ к вашей системе, просто нажав кнопку «Reset» и перегрузив ваш дистрибутив в безопасный режим (failsafe mode).
-руя все редактируемые файлы, при испытании этого USB-проекта беспо-
-коиться особо не о чем. Но всё будет немного иначе, если вы планируете
+Если вы планируете использовать PAM, чтобы защитить свою систему таким способом, важно также иметь стратегию ограничения физического доступа к вашему компьютеру. Простое решение – запереть компьютер в защищённом помещении и подключить к USB-хабу, запертому в вашем столе. Так могут делать люди, желающие обезопасить свои драгоценные «USB-замки» для программной аутентификации, и вы можете это использовать для PAM-аутентификации. В любом случае, безопасность определяется самым слабым звеном в цепи.
 использовать USB-аутентификацию в реальном окружении, как первую
-линию обороны от пользователей, пытающихся обольстить вашу систе-
+Прежде чем зарываться в настройку PAM, стоит рассмотреть это приложение как таковое. Программа была разработана в Sun Microsystems в 1996 году, с целью навести порядок в широком спектре механизмов аутентификации, использовавшихся в начале 90-х.
-му с целью получения неавторизованного доступа. В этом случае единс-
-твенное требование – убедитесь, что PAM настроен как надо. Нужно
+Проблема тогда заключалась в том, что не существовало единого унифицированного интерфейса, используемого при аутентификации пользователей. Тем, кто разрабатывал инструменты, требующие входа (login), приходилось вручную связывать свое приложение с необходимым методом (или методами) аутентификации. Хороший пример – Linux-команда login, генерирующая приглашение ввести имя пользователя на виртуальных терминалах. До PAM login нужно было связывать с каждым механизмом аутентификации, угодным автору, а это могли быть столь несходные методы, как шифрованные пароли, биометрия и всевозможные смарт-карты. Разработчикам было нелегко заниматься сопровождением в этой ситуации. Если администратор решал изменить механизм аутентификации, нужно было перенастраивать все приложения, которые его использовали.
 также ограничить физический доступ к машине и заблокировать все не
-в меру вольные сервисы, запущенные на вашей системе. Даже когда
+Вот почему появился PAM. PAM размещается между тем, что называется сервисами (в основном, login и другие программы «системного входа»), нуждающимися в механизме аутентификации, и самим механизмом. В сервис нужно только встроить поддержку PAM – и употреблять любой метод аутентификации, предусмотренный в PAM. Пока login использует PAM, разработчику больше ни о чем думать не нужно: это забота PAM, и если вам нужно изменить механизм аутентификации для login, ftp или su, 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 – единственное место, где это нужно делать.
 === И аутентификация всей страны! ===

@@ Строка 54: / Строка 54: @@
 === И аутентификация всей страны! ===
-Как правило, файлы конфигурации PAM находятся в каталоге
+Как правило, файлы конфигурации PAM находятся в каталоге /etc/pam.d вашей файловой системы. Этот каталог содержит файлы конфигурации всех приложений с аутентификацией через PAM, обычно включающие записи для стандартных сервисов, например, gdm, xdm, cups и даже screensaver – почти всех, в которых требуется пароль.
 /etc/pam.d вашей файловой системы. Этот каталог содержит файлы
-конфигурации всех приложений с аутентификацией через PAM, обычно
+Взглянув на любой конфигурационный файл PAM, вы увидите нечто подобное (взято из gdm в SUSE 10.1):
-включающие записи для стандартных сервисов, например, gdm, xdm,
+{|style="background-color:#c0c0ff;" cellpadding="3"
-cups и даже screensaver – почти всех, в которых требуется пароль.
+|auth
-Взглянув на любой конфигурационный файл PAM, вы увидите нечто
+|include
-подобное (взято из gdm в SUSE 10.1):
+|common-auth
-auth include common-auth
+|-
-account include common-account
+|account
-password include common-password
+|include
-session include common-session
+|common-account
-Каждый столбец этого конфигурационного файла представляет
+|-
-одну из четырёх директив. Это тип интерфейса модуля (первый стол-
+|password
-бец), флаг управления (второй столбец), путь к модулю (третий столбец)
+|include
-и любые аргументы модуля (в примере gdm их нет, поэтому столбец
+|common-password
-пустой). Интерфейс модуля и сам имеет четыре варианта, каждый
+|-
-из которых показан в нашем примере – auth, account, password и
+|session
-session. Модули auth будут аутентифицировать пользователей, что
+|include
-обычно означает проверку соответствия имени пользователя и пароля.
+|common-session
-Затем идут модули account, проверяющие правильность учётной запи-
+|}
-си. Password, естественно, проверяет пароль, а 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):
-аутентификации, когда вставлен USB-брелок. В нашем куске кода из
+ auth required pam_env.so
-конфигурационного файла gdm все четыре поля установлены в include.
+ auth required pam_unix2.so
 Это особый случай, поскольку ключевое слово include на самом деле
-указывает PAM направление к другому конфигурационному файлу в
+Когда пользователь входит в систему, модуль аутентификации передаёт сигнал к флагу управления практически тем же способом, как возвращают сигналы процессы и функции. Этот сигнал сообщает о том, что происходило, пока процес или функция исполнялась. Есть сигналы для «успеха» и «неудачи», а есть и сигналы для ошибок сервиса или оповещения, что учётная запись устарела. С новыми версиями PAM вы можете создавать собственные правила для любого из этих условий, это облегчает обработку исключений.
 третьем поле (common-auth). Этот файл содержит общие правила,
-пригодные для различных сервисов. Содержимое файла login указы-
+Приведённый выше фрагмент включает более типичный флаг управления – required. Он говорит PAM, что модуль auth обязан завершиться успешно. Менее строгий флаг управления – sufficient, означающий, что если аутентификация для этого модуля успешна, системе PAM не нужно продолжать аутентификацию какими-нибудь другими модулями, чтобы предоставить доступ. Другой общий флаг управления – optional, который, как подсказывает название, не критичен для предоставления доступа. Причина, почему существуют меняющиеся степени «успешности», заключается в том, что вы можете объединить модули вместе и проектировать аутентификацию на основе «успешности» отдельного модуля или стека из нескольких – именно то, как мы будем настраивать нашу аутентификацию по USB.
-вает туда же.
-Открыв файл /etc/pam.d/common-auth, вы увидите нечто вроде
+Модуль USB, который нам понадобится, разрабатывается отдельно от основного приложения PAM, и пока считается не завершенным, хотя на самом деле полностью функционален. Называется он Pam_usb, и его можно найти на нашем диске или на www.pamusb.org. Последняя версия выпущена в октябре 2005 года, но она работает с ядрами 2.6 и современными дистрибутивами.
 следующего (если вы используете старую версию PAM, эта информация
-будет в файле gdm):
+Первый шаг – скачать исходный код с сайта Pam_usb. Сборка и инсталляция модуля очень просты: наберите make, затем – make install с правами root , а конфигурационного скрипта здесь нет. Будет установлена пара скриптов hotplug и создан каталог /etc/pam_usb. Кроме того, в /usr/bin будет установлен инструмент администрирования usbadm. Скрипт hotplug разработан для блокировки сеанса, когда извлекается USB-устройство, используемое для аутентификации.
 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-устройство, используемое для аутентификации.
 === Сидеть! Место! ===

@@ Строка 127: / Строка 127: @@
 === Сидеть! Место! ===
-Очень важно, чтобы ваше устройство USB всегда обнаруживалось в
+Очень важно, чтобы ваше устройство USB всегда обнаруживалось в одном и том же месте. Горячее подключение USB-устройств печально известно в Linux как ненадёжное, но многие из последних дистрибутивов, похоже, наконец-то заставят его работать. Сложность заключается в том, что модулю Pam_usb необходимо находить устройство USB в одной и той же точке монтирования, когда бы вы ни подключили его к машине.
 одном и том же месте. Горячее подключение USB-устройств печально
-известно в Linux как ненадёжное, но многие из последних дистрибути-
+К тому же, настоятельно рекомендуется, чтобы устройства монтировали себя сами (используя hotplug); в противном случае вы завязнете, если не сможете войти на машину и разобраться с хулиганящим USB-оборудованием. Я обнаружил, что и SUSE 10.1, и Ubuntu 6.06 работают без каких-либо дополнительных ухищрений. Современные дистрибутивы монтируют эти устройства согласно их идентификаторам, назначенным изготовителем и определяемым скриптом hotplug при опросе USB (вы можете сделать это сами, набрав lsusb). Когда вы сможете достоверно находить ваше устройство USB в файловой системе, вам потребуется передать эту информацию в usbadm; она автоматически создаст ключи, необходимые для шифрования, чтобы защитить вашу информацию, и скопирует все файлы конфигурации на их законные места в файловой системе и на USB-брелок.
-вов, похоже, наконец-то заставят его работать. Сложность заключается
-в том, что модулю Pam_usb необходимо находить устройство USB в
+Отданная вами команда должна выглядеть следующим образом – только измените имя пользователя и размещение вашего USB-устройства:
-одной и той же точке монтирования, когда бы вы ни подключили его
+ usbadm keygen /media/KINGSTON graham 1024
 к машине.
-К тому же, настоятельно рекомендуется, чтобы устройства монтиро-
+В этом примере /media/KINGSTON – точка монтирования USB-брелка, graham – имя пользователя, а 1024 – размер DSA-ключа шифрования, который должен сгенерироваться. Фактически эта команда размещает открытый ключ в .auth в пользовательском каталоге, а закрытый ключ в .auth на 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 ===

@@ Строка 162: / Строка 162: @@
 === Укрепляем USB ===
-Конечно, вы наверняка уже обнаружили большую проблему. Запросто
+Конечно, вы наверняка уже обнаружили большую проблему. Запросто можно скопировать приватный ключ на другое устройство и использовать его для аутентификации. Это основное отличие между общим USB-устройством, используемым с модулем Pam_usb, и блокирующей проприетарной смарт-картой, которая запирает закрытый ключ на аппаратном уровне.
-можно скопировать приватный ключ на другое устройство и исполь-
-зовать его для аутентификации. Это основное отличие между общим
+Есть два решения этой проблемы. Первая – держать ваш закрытый ключ на USB-устройстве с определенным серийным номером. Модуль Pam_usb может затем проверять этот серийный номер и убеждаться, что приватный ключ не был скопирован.
 USB-устройством, используемым с модулем Pam_usb, и блокирующей
-проприетарной смарт-картой, которая запирает закрытый ключ на аппа-
+Если ваше USB-устройство снабжено встроенным серийным номером, вы можете запросить его и добавить его к модулю, набрав usbadm addserial, или добавить его вручную, введя usbadm addserial 12345. Серийный номер добавляется к /etc/pam_usb/serials.conf. Использовать серийные номера таким способом не совсем безопасно – отчасти потому, что программисту относительно легко раскрыть серийный номер, хранящийся в вашем устройстве, а отчасти потому, что так мало USB-брелков действительно снабжены серийный номер. Итак, подумаем над альтернативным решением.
-ратном уровне.
 Есть два решения этой проблемы. Первая – держать ваш закрытый
 ключ на USB-устройстве с определенным серийным номером. Модуль
 Pam_usb может затем проверять этот серийный номер и убеждаться,
 что приватный ключ не был скопирован.
-Если ваше USB-устройство снабжено встроенным серийным номе-
-ром, вы можете запросить его и добавить его к модулю, набрав usbadm
 addserial, или добавить его вручную, введя usbadm addserial
 . Серийный номер добавляется к /etc/pam_usb/serials.conf.
-Использовать серийные номера таким способом не совсем безопас-
-но – отчасти потому, что программисту относительно легко раскрыть
 серийный номер, хранящийся в вашем устройстве, а отчасти потому, что
 так мало USB-брелков действительно снабжены серийный номер. Итак,
 подумаем над альтернативным решением.
 === Двойная защита ===

@@ Строка 183: / Строка 183: @@
 === Двойная защита ===
-Каждый отдельный метод аутентификации называется токеном, и каж-
+Каждый отдельный метод аутентификации называется токеном, и каждый имеет сильные и слабые стороны. В случае с приватным ключом, размещённым на USB-брелке, слабостью, очевидно, является безопасность ключа и серьёзное неудобство в случае потери USB-брелка. Аналогично, основная слабость парольной аутентификации – атака подбором (brute force): взломщик может пройтись по тысячам хорошо известных комбинаций символов в надежде угадать ваш пароль.
-дый имеет сильные и слабые стороны. В случае с приватным ключом,
-размещённым на USB-брелке, слабостью, очевидно, является безо-
+Решение, оно же моя альтернатива использованию серийного номера – двухкаскадная аутентификация, задействующая два различных метода одновременно. Здесь безопасность USB-брелка должна играть важную роль. Комбинация приватного ключа, размещённого на USB-брелке, и обычной аутентификации по паролю предоставляет сильный уровень системной безопасности и защищает от наиболее общей атаки на безопасность: подбора пароля. При использовании двух методов аутентификации, даже если пароль будет угадан, потенциальному злоумышленнику всё-таки не обойтись без закрытого ключа с вашего USB-брелка. В PAM это означает стековую аутентификацию, и на следующей странице я покажу вам, как её настроить.
-пасность ключа и серьёзное неудобство в случае потери USB-брелка.
-Аналогично, основная слабость парольной аутентификации – атака
+Теперь вникнем в детали добавления нового метода PAM-аутентификации. Для начала, нам нужно выбрать сервис, который мы хотим запереть с помощью нашего USB-ключа. Вышеупомянутый login – хорошая стартовая точка, отчасти потому, что его легко использовать, а отчасти – потому что не будет большой беды, если вы что-то заблокируете (если, конечно, это не удалённая система, и login – не единственный способ подключиться к ней). Скрипт конфигурации PAM для login можно найти в /etc/pam.d/login; откройте его в своём любимом редакторе (или в нелюбимом, если вам нужно встряхнуться).
 подбором (brute force): взломщик может пройтись по тысячам хорошо
-известных комбинаций символов в надежде угадать ваш пароль.
+Нам нужно проверить, что Pam_usb работает, и простейший способ проверки – убедиться, что это единственный метод, требуемый для входа в систему, для чего мы закомментируем строку, включающую auth required pam_unix2.so. Если такой строки нет, вероятно, найдётся строка с директивой include, указывающей на файл с именем common-auth. Просмотрите содержимое этого файла, и найдете auth required pam_unix2.so – но здесь это закомментировать было бы глупо, потому что тогда любой другой сервис, включающий common-auth, не сможет выполнить аутентификацию и блокирует вашу систему.
-Решение, оно же моя альтернатива использованию серийного номе-
-ра – двухкаскадная аутентификация, задействующая два различных
 метода одновременно. Здесь безопасность 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; получится нечто вроде