Linux аутентификация по usb

Oh, MSBRO !

Сетевые заметки системного администратора

Авторизация по флешке в Linux

После прочтения поста Вход в систему по подключению определенной флешки стало интересно, а можно ли так сделать в Linux?

Оказывается, можно, и очень легко! Для этого надо:
1. Установить модуль для аутентификации по usb
2. Настроить модуль для аутентификации по usb
3. Настроить механизм аутентификации на использование необходимого нам модуля
Вся процедура настройки — от силы 15 минут.

Кратко о механизме аутентификации

Для начала нам следует знать, что за все, что относится к аутентификации отвечает PAM (pluggable authentication modules) — механизм, отслеживающий, способен ли пользователь получить доступ в существующих условиях.
Например, способен ли он получить права root через sudo по отпечатку пальца, если истек срок действия его пароля.

Для каждого типа аутентификации существует свой модуль. Вот некоторые из них:

pam_fprint	отпечаток пальца
pam_blue	устройство bluetooth
pam-face-authentication	лицо
pam_usb	usb накопитель

Как уже, вероятно, очевидно, для аутентификации по флешке нам необходим модуль pam_usb.
Возможно, он уже есть в репозитории вашего дистрибутива; если нет, скачать его можно на странице проекта pam_usb. Там же можно найти информацию на английском по использованию модуля.

Настройка pam_usb

Все настройки данного модуля, как то список usb накопителей, список ассоциированных с ними пользователей хранятся в файле /etc/pamusb.conf. Однако для более простого редактирования данного файла, вместе с модулем поставляется утилита pamusb-conf. Для редактирования файла pamusb.conf необходимы права root.

1. Добавление usb накопителя

Для добавления накопителя необходимо выполнить команду
# pamusb-conf —add-device name_of_device

name_of_device — любой удобный для вас идентификатор.
Здесь вам будет предложено выбрать устройство из списка присутствующих в вашей системе. Поскольку у меня была одна всего флешка, выбирать мне не пришлось 🙂

2. Добавление пользователя

# pamusb-conf —add-user username

Я, например, добавил пользователя root

Which device would you like to use for authentication?
* Using «rootflash» (only option)

User: root
Device: rootflash

3. Проверка настройки

* Authentication request for user «root» (pamusb-check)
* Device «rootflash» is connected (good).
* Performing one time pad verification…
* Regenerating new pads…
* Access granted.

Всё отлично, можно переходить к следующему этапу.

Настройка pam

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

Содрежимое /etc/pam.d/

Здесь содержится набор конфигурационных файлов, по одному на каждую программу, для которой вы хотите задать правила аутентификации. Можно, например, задать правила для xscreensaver, su, sudo, kscreensaver, gnome-screensaver… Тогда конфигурационные файлы должны иметь имена вида xkscreensaver, su, sudo, kscreensaver (без расширения).

Редактирование правил аутентификации

Для примера отредактируем правила для su.
Изначально, правила на моей системе имели следующий вид

#%PAM-1.0
auth sufficient pam_rootok.so
auth required pam_unix.so
account required pam_unix.so
session required pam_unix.so

Каждое правило авторизации начинается ключевым словом auth.
За ним следует либо sufficient, либо required. Использование одного из них определяет, является ли правило достаточным (sufficient) или же необходимым (required).
Затем следует имя модуля, используемого для аутентификации.
Например, в данном случае выполняется ряд проверок по порядку
1. если пользователь вызывающий su — уже root, то этого достаточно. Ничего больше спрашивать эта программа при выполнении не будет.
2. если же предыдущее правило не сработало, выполняется стандартная аутентификация с паролем.

В случае, если мы заменим в первом правиле sufficient на required, вызывать su не сможет ни один рядовой пользователь, т.к. для вызова будут необходимы права root.

Таким образом, для опциональной аутентификации по флешке (если присутствует — дать права, если отсутствует — спросить пароль), нам надо в файл /etc/pam.d/su вписать следующее:

#%PAM-1.0
auth sufficient pam_rootok.so
auth sufficient pam_usb.so
auth required pam_unix.so
account required pam_unix.so
session required pam_unix.so

После сказанного, думаю, анализ столь простого набора правил не составит труда.

Маленькие приятности

1. В качестве очень интересного варианта использования можно предложить аутентификацию по флешке с домашним разделом на ней же.
2. На появления флешки в системе можно реагировать выполнением скрипта. Также можно отреагировать и на исчезновение флешки. (см. man pamusb-agent)

Всем удачного флешко-логина 😉

UPD: Перенес в «Linux для всех». Спасибо.

Нет похожих постов.

Источник

Безопасная авторизация по usb флешке

Господа, всем доброго времени суток.

Подскажите параноику, как сделать БЕЗОПАСНУЮ авторизацию по флешке? Что бы в режиме запроса логина и пароля (GUI) можно было вставить флешку и ничего более не нажимая логинился юзер. А при вынимании происходило либо завершение сеанса, либо блокировка.

Про pam_usb знаю, мало того, что его в современных репах нет, так там IMHO беда с безопасностью /etc/pamusb.conf например:

Может есть защищённый метод? Сгенерированный ключ на флешку записать может, usb token купить или ещё как.

Заранее спасибо за ответы.

А разве pam_p11 не оно?

Никак. Ключ с флешки извлекаем.

Вариант в принципе, но ключи придётся покупать. Сначала хочется что-то без вложений, обычных флешек для этого пара горстей есть. Ну например аналог ssh авторизации по ключу, но только для GUI. Можно даже пользователя ввести.

а если это datashur usb- норм?

нет, нужен не экспортируемый ключ на токене

Надо аудиты публичне искать, Side Channel Attacks никто не отменял. Но от любопытного Васяна за соседним столом может помочь.

«Безопасную» никак, флешка это не токен.

В идеале токен — принято. А если проигнорировать безопасность «копируемости» и записать на флешку закрытый ключ?

Возьми алладиновский или yubikey токен. На крайняк, если уж ты совсем параноик, где-то видел опенсорсную реализацию под blue pill.

Безопасно с флешкой ты никак не сделаешь.

1) На флешке делаем шифрованный ключом №1 раздел, на этот раздел записываем ключ №2

2) На компе делаем шифрованный ключом №2 раздел, а ключ №1 закидываем в скрипт автоматики

В результате: при подключении флешки (скриптом) дешифруем в авторежиме флешку, а далее ключом с флешки открывается раздел тоже автоматом и логиним юзера.

При вынимании флешки размонтируем шифрованный раздел на харде и делогин юзера. В результате вроде как и флешка без компа бесполезна и комп без флешки. Мож прокатит? ))

нет защиты от копирования.

Это терпимо, шифрованную часть читай сколько хочешь ))

Подскажите параноику, как сделать БЕЗОПАСНУЮ авторизацию по флешке?

Никак. Тебе нужен токен.

Это терпимо, шифрованную часть читай сколько хочешь ))

А с переносом шифрованного раздела на другую флешку как быть?

Как я понимаю токен это такая разновидность ардуины, которой посылают зашифрованную случайную последовательность и смотрят как она её расшифровала.
При этом в отличии от ардуины содержимое токена прочитать нельзя.
(Изардуины можно вытащить sd карту и скопировать её на другую ардуину. Хотя что мешает ардуину залить эпоксидкой и подключать не по usb, а к com порту ПК через gpio ардуны.

А с переносом шифрованного раздела на другую флешку как быть?
содержимое токена прочитать нельзя

Скопировать раздел посекторно (вне зависимости что там внутри) это разве проблема?

Во, а как сделать резервную копию токена? Судя по всему никак: нагибается токен медным тазом и все данные им зашифрованные тоже тютю, а хранить резервные копии без шифрования ещё та дыра.

Где то под семью замками и в пяти сейфах лежит залитый в токен ключь.

Источник

Двухфакторная аутентификация на сайте с использованием USB-токена. Теперь и для Linux

В одной из наших предыдущих статей мы рассказывали про важность двухфакторной аутентификации на корпоративных порталах компаний. В прошлый раз мы продемонстрировали, как настроить безопасную аутентификацию в web-сервере IIS.

В комментариях нас просили написать инструкцию для самых распространенных web-серверов под Linux — nginx и Apache.

Вы просили — мы написали.

Что надо, чтобы начать?

Выписывание сертификатов

В предыдущих статьях мы опирались на то, что сертификаты сервера и клиентов будут выписываться с помощью Microsoft CA. Но раз уж мы настраиваем все в Linux, то заодно расскажем про альтернативный способ выписывания этих сертификатов — не покидая Linux.
В качестве CA будем использовать XCA (https://hohnstaedt.de/xca/), который доступен в любом современном дистрибутиве Linux. Все действия, которые мы будем совершать в XCA можно сделать и в режиме командной строки с помощью утилит OpenSSL и pkcs11-tool, но для большей простоты и наглядности в этой статье мы их приводить не будем.

Начало работы

Создаём нашу базу данных для CA — /root/CA.xdb
Мы рекомендуем хранить базу данных Certificate Authority в папке, куда есть доступ только у администратора. Это важно для защиты закрытых ключей корневых сертификатов, которые используются для подписывания всех остальных сертификатов.

Создаём ключи и сертификат root CA

В основе инфраструктуры открытых ключей (PKI) лежит иерархическая система. Главным в этой системе является корневой центр сертификации или root CA. Его сертификат и надо создать в первую очередь.

1. Создаём для CA закрытый ключ RSA-2048. Для этого на вкладке Private Keys нажимаем New Key и выбираем соответствующий тип.
2. Задаём имя для новой ключевой пары. Я её назвал — CA Key.
3. Выписываем сам сертификат CA, с использованием созданной ключевой пары. Для этого переходим на вкладку Certificates и нажимаем New Certificate.
4. Обязательно выбираем SHA-256, потому что использование SHA-1 уже не может считаться безопасным.
5. В качестве шаблона обязательно выбираем [default] CA. Не забудьте нажать на Apply all, иначе шаблон не применяется.
6. На вкладке Subject выбираем нашу ключевую пару. Там же вы можете заполнить все основные поля сертификата.

Создаём ключи и сертификат https-сервера

Создаём ключи и сертификат для пользователя

1. Закрытый ключ пользователя будет храниться на нашем токене. Для работы с ним необходимо установить PKCS#11 библиотеку с нашего сайта. Для популярных дистрибутивов мы распространяем готовые пакеты, которые лежат тут — https://www.rutoken.ru/support/download/pkcs/. У нас также есть сборки для arm64, armv7el, armv7hf, e2k, mipso32el, которые можно взять в нашем SDK — https://www.rutoken.ru/developers/sdk/. Кроме сборок для linux также есть сборки для macOS, freebsd и android.
2. Добавляем новый PKCS#11 Provider в XCA. Для этого идём в меню Options на вкладку PKCS#11 Provider.
3. Жмём Add и выбираем путь до библиотеки PKCS#11. В моём случае это \usr\lib\librtpkcs11ecp.so.
4. Нам понадобится отформатированный токен Рутокен ЭЦП PKI. Скачиваем утилиту rtAdmin — https://dev.rutoken.ru/pages/viewpage.action?pageId=7995615
5. Выполняем

В качестве типа ключа выбираем — ключ RSA-2048 на Рутокен ЭЦП PKI. Я назвал этот ключ Client Key.

Вводим PIN-код. И ждём завершения аппаратной генерации ключевой пары

Сертификат для пользователя создаём по аналогии с сертификатом сервера. На этот раз выбираем шаблон [default] HTTPS_client и не забываем нажать Apply all.

На вкладке Subject вводим информацию о пользователе. На запрос о сохранении сертификата на токен отвечаем утвердительно.

В итоге на вкладке Сертификаты в XCA должна получиться примерно такая картинка.

Этого минимального набора ключей и сертификатов достаточно для того, чтобы приступать к настройке непосредственно серверов.

Для настройки нам необходимо выполнить экспорт сертификата УЦ, сертификата сервера и закрытого ключа сервера.

Для этого надо выбрать нужную запись на соответствующей вкладке в XCA и нажать Export.

Nginx

Как установить и запустить nginx-сервер, писать не буду — на эту тему достаточно статей в интернете, не говоря уже об официальной документации. Приступим сразу к настройке HTTPS и двухфакторной аутентификации по токену.

Добавляем в секцию server в nginx.conf следующие строки:

Подробное описание всех параметров, касающихся настройки ssl в nginx можно найти тут — https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_client_certificate

Я лишь коротко опишу те, которые сам задал:

• ssl_verify_client — указывает, что необходимо проверить цепочку доверия к сертификату.
• ssl_verify_depth — определяет глубину поиска доверенного корневого сертификата в цепочке. Так как у нас сертификат клиента сразу подписан на корневом сертификате, то и глубина задана — 1. Если сертификат пользователя подписывается на промежуточном CA, то в этом параметре необходимо указать 2, и так далее.
• ssl_client_certificate — указывает путь до доверенного корневого сертификата, который используется при проверке доверия к сертификату пользователя.
• ssl_certificate/ssl_certificate_key — указывают путь до сертификата/закрытого ключа сервера.

Не забываем выполнить nginx -t, чтобы проверить, что в конфиге нет опечаток, а все файлики лежат где надо и так далее.

И собственно всё! Как видите настройка очень простая.

Проверяем работу в Firefox

Раз уж мы всё полностью делаем в Linux, то будем считать, что и наши пользователи тоже работают в Linux (если у них Windows, то смотрите инструкцию по настройке браузеров в предыдущей статье.

1. Запускаем Firefox.
2. Попробуем в начале зайти без токена. Получаем вот такую картинку:

Заходим на about:preferences#privacy, и идём в Security Devices…

Жмём Load, чтобы добавить новый PKCS#11 Device Driver и указываем путь до нашей librtpkcs11ecp.so.

Для проверки того, что сертификат видится можно зайти в Certificate Manager. Отобразится запрос на ввод PIN-кода. После корректного ввода можно проверить, что на вкладке Your Certificates появился наш сертификат с токена.

Теперь заходим с токеном. Firefox предлагает выбрать сертификат, который будет выбран на сервер. Выбираем наш сертификат.

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

Apache

Так же как и с nginx проблем с установкой apache ни у кого не должно возникнуть. Если же вы не знаете, как установить этот web-сервер, просто воспользуйтесь официальной документацией.

А мы приступаем к настройке нашего HTTPS и двухфакторной аутентификации:

Для начала необходимо активировать mod_ssl:

А затем включить настройки HTTPS сайта по умолчанию:

Теперь редактируем файл конфигурации: /etc/apache2/sites-enabled/default-ssl.conf:

Как видите, названия у параметров практически совпадает с названиями параметров в nginx, поэтому пояснять я их не буду. Опять же кому интересны подробности — добро пожаловать в документацию.
Теперь перезапускаем наш сервер:

Как видите настроить двухфакторную аутентификацию на любом веб-сервере, что в Windows, что в Linux дело одного часа максимум. А настройка браузеров занимает около 5 минут. Многие считают, что настройка и работа с двухфакторной аутентификацией это сложно и непонятно. Надеюсь наша статья хоть немного, но развенчивает этот миф.

Источник