В Linux представлено множество базовых механизмов безопасности, которые позволяют штатными средствами обеспечить конфиденциальность, целостность и доступность данных на устройстве. Подсистемы аутентификации, логирования, авторизации, сетевой фильтрации, виртуальных сред, шифрования и множество других могут управляться инструментами из пользовательского пространства.
Так удобное решение PAM или же Pluggable Authentification Module позволяет объединить провайдеров аутентификации и предоставить свой API приложениям. К примеру, практически все системные утилиты для аутентификации пользователя взаимодействуют с PAM. Как его настроить и почему нужно использовать 2FA – разберем в данном материале.
Что такое PAM?
PAM или же Pluggable Authentification Module представляет собой сервис, который агрегирует разных провайдеров аутентификации и позволяет верифицировать пользователей. Это не поднятая служба и не модуль ядра, а библиотека которая хранится в системных путях, которую приложения вызывают сами. А это значит, что без обращения к ней аутентификация через PAM не возможна, убедитесь, что ваше приложение использует PAM!
Обычно процесс работы выглядит следующим образом:
При подключении через ssh пользовательское соединение обрабатывает демон sshd. Идентифицировав пользователя необходимо провести его аутентификацию, для этого ssh использует свои механизмы проверки и подключает к этому библиотеку аутентификации. PAM начинает искать необходимый сценарий для sshd и находит ехо по пути /etc/pam.d/sshd. Считав необходимые параметры, обращается к библиотекам для проверки подлинности данных пользователя и возвращает в sshd. Либо аутентифицирован с таким UID, GID.
По такой же схеме работают многие утилиты и ПО, когда вместо написания собственной аутентификации просто обращаются к PAM, где уже прописан сценарий. Разберем пример того, как настроить такую аутентификацию и добавить второй фактор!
Как настроить работу PAM?
Для примера возьмем тот же сервис sshd и настроим для него аутентификацию по ключам + по TOTP кодам. TOTP или временные пароли завязанные на времени, владея мастер ключом происходит преобразование текущего времени в 6 значный код. Он вычисляется, как на стороне клиента, так и сервера, что позволяет произвести аутентификацию по коду, который меняется каждые 30 секунд.
Для начала установим все необходимые зависимости, это модуль для аутентификации google_authentificator и сервис сетевого времени.
apt update && apt install ntp libpam-google-authenticator 
Настроим время сервера, так чтобы оно совпадало со временем нашего клиента, куда мы установим приложение. Запустим NTP сервис и проверим его работоспособность:
sudo systemctl start ntpd && sudo systemctl status ntpd 
Если вы хотите поменять пулы серверов, которые будут отвечать за синхронизацию времени, то необходимо перейти в конфиг:
nano /etc/ntpsec/ntp.conf 
Замените представленные пулы серверов, после чего перечитайте конфиги для служб и проверьте доступность источников времени:
systemctl daemon-reload && echo "peer" | ntpq
Отлично, конфигурация клиента NTP завершена, вы можете также дополнительно указать часовой пояс. Однако это не влияет на работу TOTP, так как он берет информацию о минутах и секундах для формирования временного кода. Перейдем к настройке google_authentificator:
google-authenticator 
Ответим yes на вопрос о использовании времени для создании кода и отсканируем qr или введем код в заранее скачанное приложение из AppStore или GooglePlay под таким же названием Google Authenticator. Ниже QR строка требует ввода временного кода с телефона, чтобы убедиться, что мастер ключ в QR корректен. А затем можно ответь yes на все остальные вопросы и опции сервиса. И наконец перейдем к самому PAM!
При нехватке собственных мощностей можно воспользоваться облачными серверами от Serverspace, для этого перейдем к созданию сервера, на любой из двух платформ vStack cloud или же VMware cloud. Нажмем на кнопку Создать сервер и выберем конфигурацию, подходящую под наши задачи, затем нажмем кнопку Создать:
Скриншот №7 — Создание сервера
Первое, что делает PAM – это занимается поиском сценария для утилиты, поэтому перейдем к нему по пути:
nano /etc/pam.d/sshd Логика работы заключается, в том что PAM проходит каждое действие сверху вниз по каждой строке и выполняет в соответствии с модулями проверку. Для понимания структуры файла быстро разберем основные компоненты, сначала прописываются типы используемых модулей:
- auth – модуль для аутентификации;
- account – модуль для авторизации;
- session – модуль для управления сессией;
- password – модуль повторной аутентификации в процессе работы.
В нашем случае будем модифицировать только модули аутентификации, следующий пункт строки представляет собой флаг контроля, который определяет требование к результату аутентификации. К примеру:
- required требует, чтобы результат работы был успешен, в случае неудачи передаст управление на следующие строки. Однако аутентификация будет считаться уже не успешной;
- requisite требует, чтобы результат работы был успешен, в случае неудачи закончит работу, не передавая управление ниже;
- optional результат модуля не имеет значения, если этот модуль единственный;
- sufficient требует, чтобы результат работы был успешен, в случае неудачи передаст управление на следующие строки. В случае успеха полностью аутентифицирует без дальнейших проверок;
- include подключает конфиги с такими же инструкциями, для того, чтобы повторяющиеся механизмы проверки можно было использовать повторно.
И так, в нашем случае представлены правила в виде строк, где есть пункт @include common-auth, именно он отвечает за аутентификацию по паролю. Отключим его, приписав # в начале строки и перед ним пропишем строку с требованием аутентификации по TOTP:
auth required pam_google_authenticator.so 
Остальной файл оставим неизменным, последним этапом будет настройка sshd_config для этого откроем его:
nano /etc/ssh/sshd_config И внесем дополнительные строки, где отключим аутентификацию по паролю, включим аутентификацию по ключам, а так же укажем методы для проверки:
UsePAM yes
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication yes
AuthenticationMethods publickey,keyboard-interactiveПосле сохраним файл и перезагрузим sshd через команду:
systemctl restart sshd Попробуем аутентифицироваться и проверим изменение наших настроек:
Как видим при обращении к серверу была произведена проверка ключей и только потом запрошен код от TOTP, после которого sshd авторизовала пользователя. Вариаций того, как использовать PAM и его модули ограничены только вашей фантазией и требованиями регулятора по защите. Можно настроить 3 этапа аутентификации по 3 разным факторам или даже 5 этапную, в этом и преимущество модульного решения!
