что такое pam cracklib
Что такое pam cracklib
This module can be plugged into the password stack of a given application to provide some plug-in strength-checking for passwords.
The action of this module is to prompt the user for a password and check its strength against a system dictionary and a set of rules for identifying poor choices.
The first action is to prompt for a single password, check its strength and then, if it is considered strong, prompt for the password a second time (to verify that it was typed correctly on the first occasion). All being well, the password is passed on to subsequent modules to be installed as the new authentication token.
The strength checks works in the following manner: at first the Cracklib routine is called to check if the password is part of a dictionary; if this is not the case an additional set of strength checks is done. These checks are: Palindrome Is the new password a palindrome of the old one? Case Change Only Is the new password the the old one with only a change of case? Similar Is the new password too much like the old one? This is primarily controlled by one argument, difok which is a number of characters that if different between the old and new are enough to accept the new password, this defaults to 10 or 1/2 the size of the new password whichever is smaller.
This module with no arguments will work well for standard unix password encryption. With md5 encryption, passwords can be longer than 8 characters and the default settings for this module can make it hard for the user to choose a satisfactory new password. Notably, the requirement that the new password contain no more than 1/2 of the characters in the old password becomes a non-trivial constraint. For example, an old password of the form «the quick brown fox jumped over the lazy dogs» would be difficult to change. In addition, the default action is to allow passwords as small as 5 characters in length. For a md5 systems it can be a good idea to increase the required minimum size of a password. One can then allow more credit for different kinds of characters but accept that the new password may share most of these characters with the old password.
OPTIONS
(N ucredit= N (N >= 0) This is the maximum credit for having upper case letters in the new password. If you have less than or N upper case letters each letter will count +1 towards meeting the current minlen value. The default for ucredit is 1 which is the recommended value for minlen less than 10.
(N > 0) This is the minimum number of upper case letters that must be met for a new password. lcredit= N (N >= 0) This is the maximum credit for having lower case letters in the new password. If you have less than or N lower case letters, each letter will count +1 towards meeting the current minlen value. The default for lcredit is 1 which is the recommended value for minlen less than 10.
(N ocredit= N (N >= 0) This is the maximum credit for having other characters in the new password. If you have less than or N other characters, each character will count +1 towards meeting the current minlen value. The default for ocredit is 1 which is the recommended value for minlen less than 10.
(N use_authtok This argument is used to force the module to not prompt the user for a new password but use the one provided by the previously stacked password module. dictpath= /path/to/dict Path to the cracklib dictionaries.
MODULE SERVICES PROVIDED
Only he password service is supported.
RETURN VALUES
PAM_SUCCESS The new password passes all checks. PAM_AUTHTOK_ERR No new password was entered, the username could not be determined or the new password fails the strength checks. PAM_AUTHTOK_RECOVERY_ERR The old password was not supplied by a previous stackked module or got not requested from the user. The first error can happen if use_authtok is specified. PAM_SERVICE_ERR A internal error occured.
EXAMPLES
For an example of the use of this module, we show how it may be stacked with the password component of pam_unix (8)
Another example (in the /etc/pam.d/passwd format) is for the case that you want to use md5 password encryption:
And here is another example in case you don’t want to use credits:
SEE ALSO
AUTHOR
pam_cracklib was written by Cristian Gafton
Настройка политики паролей на сервере CentOS 6
Что такое политика паролей?
Политика паролей – это набор правил, которых нужно придерживаться при установке пароля. Политика паролей является важным фактором в области компьютерной безопасности. Поскольку именно пароли пользователей системы чаще всего становятся причиной взломов и других проблем и нарушений, большинство компаний и организаций включают политику паролей в официальный регламент. Все пользователи и пароли должны соответствовать официальной политике паролей компании.
Политика паролей, как правило, определяется следующими факторами:
1: Настройка срока действия и длины пароля
Контроль срока действия пароля и его длины осуществляется при помощи файла /etc/login.defs. Срок действия пароля (англ. password aging) определяет максимальное количество дней действия, минимальное количество дней между изменениями пароля, а также количество дней, в течение которых предупреждается о необходимости смены пароля. Длина пароля (англ. password length) определяет минимальное количество символов, которое должен содержать пароль. Итак, чтобы настроить срок действия и длину пароля, отредактируйте файл /etc/login.defs и установите значения директив PASS согласно политике паролей.
Примечание: данные параметры не повлияют на уже существующих пользователей, они будут действительны только для новых учетных записей!
Пример конфигураций файла /etc/login.defs:
2: Настройка сложности и повторного использования пароля
В файле /etc/pam.d/system-auth можно настроить сложность и повторное использование пароля. Сложность пароля определяется сложностью комбинации символов, использованных в пароле. Параметры повторного использования пароля запрещают определенное количество паролей пользователя, которые были использованы ранее. При установке сложности пароля можно указать количество цифр, символов, заглавных и строчных букв, которое должен содержать пароль. Если стандарты сложности пароля не выполнены, такой пароль не будет принят системой.
Примечание: замените Х требуемым числом. Например:
password requisite pam_cracklib.so try_first_pass retry=3 type= ucredit=-2 lcredit=-2 dcredit=-2 ocredit=-2
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok remember=5
Пример конфигураций файла /etc/pam.d/system-auth:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so
account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid
3: Ограничение количества неправильных попыток ввода пароля
Количество неправильных попыток ввода пароля устанавливается в файле /etc/pam.d/password-auth.
Этот параметр задает количество неправильных попыток ввода пароля, которое может совершить пользователь, прежде чем он будет заблокирован. Позже системный администратор может разблокировать учетную запись. Чтобы настроить количество неудачных попыток входа, добавьте две новые строки в файл /etc/pam.d/password-auth.
Параметр deny=X задает разрешенное количество неудачных попыток, прежде чем пользователь будет заблокирован (замените Х нужным числом).
auth required pam_tally2.so deny=3
account required pam_tally2.so
PAM на страже ваших компьютеров
Давайте начнем с самого начала и рассмотрим, как программа аутентифицирует пользователя. Если не будет единого базового механизма аутентификации, тогда каждая программа должна содержать в себе логику аутентификации, такую как просмотр файла /etc/passwd на наличие пользователя и соответствия введенного пароля. Но что если таких программ много? Придется включать одну и ту же логику в каждую из них? А если требования к безопасности изменятся? Что, придется модифицировать и перекомпилировать все эти программы? Очевидно, это плохой метод и наверняка не самый безопасный. Как бы сделать так, чтобы все приложения сразу обновлялись до требуемого метода аутентификации и удовлетворяли новым требованиям безопасности?
Проект PAM предоставляет решение путем добавления дополнительного программного уровня. Программа, которой требуется аутентификация, должна использовать стандартную библиотеку или API (Application Programming Interface, Прикладной программный интерфейс), а системный администратор должен указать порядок аутентификации для данной конкретной программы (проверки осуществляются отдельными модулями; можно даже запрограммировать собственные модули). Таким образом, можно динамически изменять требования безопасности, причем все программы будут автоматически следовать вашим новым указаниям. Другими словами, можно модифицировать механизмы аутентификации программ (которые собраны с поддержкой PAM) без пересборки самих программ. С точки зрения программиста это очень хороший подход, ведь ему не требуется связываться с механизмами аутентификации. Когда мы используем модули PAM, требуемые проверки выполняются автоматически (см. рисунок 1).
Библиотека PAM разбивает механизм аутентификации на четыре группы (см. таблицу 1). Обратите внимание, что не всем программам требуются все четыре действия. К примеру, команде passwd требуется лишь последняя группа. Подсказка: как определить, использует ли программа PAM? Нужно вывести с помощью утилиты ldd все разделяемые библиотеки, используемые данной программой, и найти среди них libpam.so; пример см. в листинге 1.
Рисунок 1. Когда программа делает запрос аутентификации, библиотека PAM исполняет код модулей, указанных в конфигурационном файле и принимает решение, принять (успех) или отклонить (неудача) этот запрос.
Листинг 1. Чтобы узнать, использует ли программа PAM, воспользуйтесь утилитой ldd и найдите в ее выводе библиотеку libpam.so. Нужно писать полный путь до исполняемого файла. Если не знаете полный путь, узнайте его с помощью команды whereis. Например:
Таблица 1. Проверки PAM подразделяются на четыре группы, организованных в виде очереди. Задействование тех или иных групп определяется запросами пользователя.
auth | Относится к аутентификации пользователей, к примеру, когда нужно ввести пароль. Обычно эти проверки идут первыми. |
account | Относится к управлению учетными записями, к примеру, сюда входит проверка устаревания пароля и проверки по времени доступа. Когда пользователь идентифицирован с помощью модулей auth, модули account определяют, можно ли пользователю давать доступ. |
session | Относится к управлению соединениями, например, журналирование входов в систему, журналирование выполненных действий или выполнение очистки по завершению сессии. |
password | Содержит функции, например, обновление пароля пользователя. |
Таблица 2. Модули выполняются последовательно в каждой группе, в зависимости от их управляющих флагов. Требуется указать, является ли проверка обязательной, желательной и т.п.
required | Этот модуль должен завершиться успешно. Если он завершается неудачей, вся проверка также завершается неудачей. Если все модули помечены как required, тогда непрохождение любой из проверок будет означать отказ в доступе, хотя все другие модули в группе также будут исполнены. |
requisite | Работает аналогично required, однако в случае неудачи, возврат происходит незамедлительно, и остальные модули группы даже не исполняются. |
sufficient | Если этот модуль завершается успешно, остальные модули не исполняются, и вся проверка завершается успешно. |
optional | Если этот модуль завершается неудачно, тогда окончательное решение зависит от результата исполнения других модулей. Если в конфигурации нет модулей типа required или sufficient, тогда для разрешения доступа хотя бы один из модулей типа optional должен завершиться успешно. |
Настройка PAM
Для каждой службы (такой как login или SSH), необходимо указать, какие проверки будут сделаны в каждой группе. Список этих действий называется стеком. В завимости от результата исполнения в каждом стеке, пользователю будет разрешен или отклонен доступ, либо что-то будет позволено или не позволено. Исполняемые действия задаются для каждой службы в отдельном файле в каталоге /etc/pam.d (новый метод), либо в едином файле /etc/pam.conf (старый метод). В данной статье рассмотрен первый, новый метод.
Внимание! Помните, что безрассудная правка конфигурационных файлов может сделать вашу систему неработоспособной! К примеру, удалив все конфигурационные файлы, вы не сможете вновь войти в систему. Поэтому убедитесь, что у вас под рукой есть резервная копия всех конфигов и загрузочный CD.
Каждый стек состоит из модулей, выполняющихся последовательно в заданном порядке. Для каждого модуля нужно указать, является ли он обязательным (неудача автоматически запрещает доступ), достаточным (успех автоматически разрешает доступ) либо желательным (проводит альтернативные проверки). В таблице 2 расписаны эти управляющие флаги. Файл конфигурации каждой службы состоит из списка правил, каждое начинается с новой строки (длинные строки можно разбивать с помощью символа \, но это требуется крайне редко). Строки, начинающиеся с символа решетки (#), являются комментариями и поэтому игнорируются. Каждое правило состоит из трех полей: контекст (таблица 1), управляющие флаги (таблица 2) и модуль, который требуется исполнить, с дополнительными (необязательными) параметрами. К примеру, спецификации PAM-проверок для программы login можно найти в файле /etc/pam.d/login.
Рекомендую провести беглый осмотр всех файлов в /etc/pam.d. Если найдете файлы неиспользуемых приложений, просто переименуйте их, и PAM задействует стандартную конфигурацию «other». Если позже программа понадобится, переименуйте соответствующий конфигурационный файл обратно, и все встанет на свои места.
Листинг 2. Безопасные правила «other» отклоняют все запросы доступа к службе, для которой не указаны другие правила. Модуль pam_deny.so всегда завершается неудачей, поэтому все попытки получения доступа будут отклонены, вдобавок к этому модуль pam_warn.so отправит системному администратору уведомление об этом событии.
Листинг 3. Правила PAM, эквивалентные стандартным правилам безопасности UNIX. Замечание: в некоторых дистрибутивах нужно указывать модуль pam_unix.so.
Листинг 4. Файл /etc/pam.d/sshd содержит правила безопасности для SSH-соединений. Обратите внимание, что модуль pam_access.so добавляет дополнительные проверки (см. листинг 5).
Листинг 5. Файл /etc/security/access.conf используется модулем pam_access.so, чтобы определить, каким пользователям позволено входить в систему и с каких IP-адресов. В данном примере, в систему теоретически может войти любой пользователь локальной сети, но лишь пользователю remoteKereki позволен удаленный доступ извне.
Листинг 6. Секция password в файле /etc/pam.d/passwd определяет хорошие требования, предъявляемые к новым паролям.
Безопасный удаленный доступ
Если вы взглянете на файл /etc/pam.d/sshd, который установлен в вашей системе, вы наверняка увидите то же самое, только не будет модуля pam_access. Он и представляет здесь наибольший интерес. Этот модуль обеспечивает дополнительные проверки, определяемые файлом /etc/security/access.conf. В нем я указал тех, кто может получать доступ к моему компьютеру (листинг 5). Первая строка определяет, что войти в систему может любой пользователь (ALL) из внутренней домашней сети. Вторая строка означает, что пользователь remoteKereki может войти в систему из любой точки мира, а последняя строка однозначно завершает политику доступа, запрещая доступ всем, кто не указан в предыдущих строках. Я создал пользователя remoteKereki с минимумом прав, чтобы я сам мог войти в систему, затем, выполнив su, стать собственно собой или пользователем root, если потребуется. Если злоумышленник угадает пароль для remoteKereki, это ему не поможет, ведь атакующему придется еще угадывать пароль для других, более полезных пользователей. Таким образом, пользователь remoteKereki является дополнительным барьером для злоумышленников.
Нужны хорошие пароли
Можно вызвать модуль с параметрами (их полный перечень смотри в man pam_pwcheck), которые описывают дополнительные правила:
Сходную функциональность предоставляет другой модуль, под названием pam_cracklib.so, однако у него другие параметры. К примеру, в нем можно указать, в скольких символах должны отличаться старый и новый пароли, нужно ли включать цифры, символы в верхнем и нижнем регистрах, а также неалфавитные символы. Более подробную информацию можно найти в руководстве man pam_cracklib.
Заключение
В Linux все не так, как в британском музее, и для обеспечения безопасности используется PAM. Даже не прибегая к написанию собственных модулей, можно достаточно гибко настроить механизмы аутентификации, удовлетворяя любые требования безопасности. При этом можно быть уверенным в том, что программы задействуют эти новые правила автоматически.
Модули, модули кругом
Источники информации
Как заставить пользователей использовать сильные пароли в Debian, Ubuntu
Сильный пароль должен содержать не менее 14 символов, включая по крайней мере один специальный символ, один цифровой символ, одну заглавную и строчную букву.
Что еще более важно, пароли не должны быть легко предсказуемыми и не должны основываться на словарных словах.
Некоторые нетехнические люди, однако, не поймут или не заботятся о безопасности.
Они будут продолжать использовать легко предсказуемые пароли, такие как pass123, welcome123, Welcome @ 1 и т.д.,которые можно легко сломать несколькими попытками.
Кроме того, они не изменят пароли на века.
Как безопасника, ваша работа заключается в обеспечении надежной политики паролей для защиты ваших систем от атак на основе словарей и брутфорса..
В этом кратком руководстве вы узнаете, как заставить пользователей использовать надежные пароли в дистрибутивах на основе DEB, таких как Debian, Ubuntu, Linux Mint и т. д., Используя подключаемые модули аутентификации (PAM).
Я проверил это руководство в версии Ubuntu 16.04 LTS.
Хотя инструкции, опубликованные здесь, одинаковы для Debian и других дистрибутивов Debian и Ubuntu, таких как Linux Mint, Elementary OS и т.д.
Заставить пользователей использовать сильные пароли в Debian, Ubuntu, Linux Mint
PAM устанавливается по умолчанию в системах на основе DEB.
Однако вам необходимо установить дополнительный модуль libpam-cracklib.
Для этого запустите следующую команду из терминала:
В системах на основе DEB политики паролей определяются в файле /etc/pam.d/common-password.
Перед внесением любых изменений создайте резервную копию этого файла.
Теперь отредактируйте файл /etc/pam.d/common-password:
Найдите следующую строку и отредактируйте или измените ее, как показано ниже.
Давайте разберем эту строку и посмотрим, что делает каждый вариант.
Надеюсь, вы получили базовое представление о вышеуказанных параметрах.
Как определено в вышеприведенном файле, пользователи теперь могут использовать пароль с оценкой сложности пароля 12.
Тем не менее, вы можете отключить кредиты, назначив отрицательные значения и заставить пользователя использовать комбинацию разных символов с минимальной длиной.
Как определено выше, пользователи должны использовать пароль длиной 8 символов, включая 1 строчную букву, 1 прописную букву, 2 цифры и 1 другой символ.
Обратите внимание, что эти ограничения применяются для обычных пользователей, но не для пользователя root.
Пользователь root может использовать любой тип пароля.
Создание политики паролей в Linux
И снова здравствуйте! Уже завтра начинаются занятия в новой группе курса «Администратор Linux», в связи с этим публикуем полезную статью по теме.
Долгое время обычным подходом к паролям было заставить пользователя использовать в них символы верхнего и нижнего регистра, цифры или иные символы. Эти базовые правила сложности паролей активно пропагандируются в последние десять лет. Было множество дискуссий о том, является это хорошей практикой или нет. Основным аргументом против установки таких сложных условий было то, что пользователи записывают пароли на бумажках и небезопасно хранят.
Другая политика, которая недавно была поставлена под сомнение, заставляет пользователей менять свои пароли каждые x дней. Были проведены некоторые исследования, которые показали, что это также наносит ущерб безопасности.
На тему этих дискуссий было написано множество статей, которые обосновывали ту или другую точку зрения. Но это не то, что мы будем обсуждать в этой статье. Эта статья расскажет о том, как корректно задать сложность пароля, а не управлять политикой безопасности.
Параметры политики паролей
Еще одна странная вещь, которую вы, возможно, заметили, заключается в том, что поля [u,l,d,o]credit содержат отрицательное число. Это потому что числа больше или равные 0 дадут кредит на использование символа в вашем пароле. Если поле содержит отрицательное число, это значит, что требуется определенное количество.
Что такое кредиты (credit)?
Я называю их кредитами, поскольку это максимально точно передает их назначение. Если значение параметра больше 0, вы прибавляете количество «кредитов на символы» равное «х» к длине пароля. Например, если все параметры (u,l,d,o)credit установить в 1, а требуемая длина пароля была 6, то вам понадобится 6 символов для удовлетворения требования длины, потому что каждый символ верхнего регистра, нижнего регистра, цифра или иной символ дадут вам один кредит.
Если вы установите dcredit в 2, вы теоретически сможете использовать пароль длиной в 9 символов и получить 2 кредита на символы для цифр и тогда длина пароля уже может быть 10.
Посмотрите на этот пример. Я установил длину пароля 13, установил dcredit в 2, а все остальное в 0.
Моя первая проверка провалилась, поскольку длина пароля была меньше 13 символов. В следующий раз я изменил букву “I” на цифру “1” и получил два кредита за цифры, что приравняло пароль к 13.
Утилита pwscore читает из stdin. Просто запустите утилиту и напишите свой пароль, она выдаст ошибку или значение от 0 до 100.
Показатель качества пароля соотносится с параметром minlen в файле конфигурации. В целом показатель меньше 50 рассматривается как «нормальный пароль», а выше – как «сильный пароль». Любой пароль, который проходит проверки на качество (особенно принудительную проверку cracklib ) должен выдержать атаки словаря, а пароль с показателем выше 50 с настройкой minlen по умолчанию даже brute force атаки.