John the Ripper и обеспечение соблюдения политик паролей

Введение

В современном цифровом пространстве надежные политики паролей имеют решающее значение для защиты конфиденциальной информации. Однако даже при наличии политик могут существовать уязвимости. Эта лабораторная работа проведет вас через процесс использования John the Ripper, мощного инструмента для взлома паролей, для оценки эффективности существующих политик паролей. Вы научитесь выявлять слабые места, рекомендовать более строгие политики и понимать, как внедрять автоматизированные проверки соответствия для повышения общей безопасности. Этот практический опыт предоставит вам навыки аудита и обеспечения соблюдения правил безопасности паролей.

Анализ существующих политик паролей

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

Сначала давайте рассмотрим файл /etc/login.defs, который содержит глобальные настройки конфигурации для набора утилит shadow password. Этот файл определяет такие параметры, как срок действия пароля, минимальная длина пароля и максимальный срок действия пароля.

Используйте команду grep для поиска настроек, связанных с паролями, в /etc/login.defs:

grep -E "PASS_MAX_DAYS|PASS_MIN_DAYS|PASS_WARN_AGE|ENCRYPT_METHOD" /etc/login.defs

Вы должны увидеть вывод, похожий на этот, хотя значения могут отличаться:

PASS_MAX_DAYS	99999
PASS_MIN_DAYS	0
PASS_WARN_AGE	7
ENCRYPT_METHOD SHA512

Далее мы рассмотрим /etc/pam.d/common-password, который является конфигурационным файлом PAM (Pluggable Authentication Modules), управляющим правилами сложности паролей. Этот файл часто включает модули, такие как pam_cracklib.so или pam_pwquality.so, которые применяют правила, требующие смешанного регистра, цифр и специальных символов.

Используйте cat для просмотра содержимого /etc/pam.d/common-password:

cat /etc/pam.d/common-password

Вы увидите много строк, но обратите внимание на строки, содержащие pam_pwquality.so или pam_cracklib.so, и их параметры (например, minlen, difok, ucredit, lcredit, dcredit, ocredit).

password        [success=1 default=ignore]      pam_unix.so obscure sha512 shadow
password        requisite                       pam_pwquality.so retry=3 minlen=8 difok=3 reject_username enforce_for_root
password        optional                        pam_gnome_keyring.so
password        optional                        pam_kwallet.so
password        optional                        pam_systemd.so

Наконец, давайте проверим файл /etc/security/pwquality.conf, который обеспечивает более детальный контроль над настройками качества паролей при использовании pam_pwquality.so.

cat /etc/security/pwquality.conf

Вы можете увидеть такие настройки, как minlen, dcredit, ucredit, lcredit, ocredit, maxrepeat и т. д.

## Configuration for the pam_pwquality module
#
## The setting of the PAM module is usually in /etc/pam.d/common-password
#
## minlen = 8
## difok = 3
## dcredit = -1
## ucredit = -1
## lcredit = -1
## ocredit = -1
## minclass = 0
## maxrepeat = 0
## maxsequence = 0
## gecoscheck = 0
## dictcheck = 1
## usercheck = 1
## enforce_for_root

Изучив эти файлы, вы сможете получить хорошее представление о текущих настройках политики паролей в системе.

Использование John the Ripper для проверки эффективности политик

На этом этапе вы будете использовать John the Ripper (JtR) для проверки эффективности политик паролей. Мы смоделируем сценарий, в котором у вас есть доступ к файлу хэшей паролей, и попытаемся взломать слабые пароли.

Сначала создадим фиктивный файл паролей для демонстрационных целей. Мы создадим файл с именем passwords.txt с несколькими слабыми паролями.

echo "user1:password123" > ~/project/passwords.txt
echo "user2:welcome" >> ~/project/passwords.txt
echo "user3:labexrocks" >> ~/project/passwords.txt

Теперь нам нужно преобразовать эти пароли в открытом тексте в формат, который John the Ripper может понять. Мы будем использовать unshadow (компонент JtR) для объединения фиктивного файла, похожего на /etc/passwd и /etc/shadow. Для простоты мы будем использовать файл passwords.txt напрямую с режимом stdin JtR для взлома.

Давайте создадим простой файл словаря с именем wordlist.txt, который John the Ripper будет использовать для попытки взлома паролей.

echo "password123" > ~/project/wordlist.txt
echo "welcome" >> ~/project/wordlist.txt
echo "labexrocks" >> ~/project/wordlist.txt
echo "secret" >> ~/project/wordlist.txt
echo "123456" >> ~/project/wordlist.txt

Теперь используйте John the Ripper для взлома паролей из passwords.txt с использованием wordlist.txt.

john --format=raw-md5 --wordlist=~/project/wordlist.txt ~/project/passwords.txt

Вы можете увидеть вывод, похожий на этот, указывающий на взломанные пароли:

Using default input encoding: UTF-8
Loaded 3 password hashes with no different salts (Raw-MD5 [MD5])
Will run 4 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
password123 (user1)
welcome (user2)
labexrocks (user3)
3g 0:00:00:00 DONE (2023-10-27 08:30) 100.0% 3g/s 100.0p/s 100.0c/s 100.0C/s password123 welcome labexrocks
Session completed.

Чтобы просмотреть взломанные пароли, вы можете использовать опцию --show:

john --show ~/project/passwords.txt

Вывод:

user1:password123

user2:welcome

user3:labexrocks

3 password hashes cracked, 0 left

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

Определение пробелов в политиках паролей

На этом этапе вы определите пробелы в смоделированных политиках паролей на основе результатов взлома из предыдущего шага. Тот факт, что John the Ripper смог легко взломать пароли, указывает на значительные уязвимости.

Исходя из взломанных паролей (password123, welcome, labexrocks), вот некоторые распространенные пробелы, которые позволили их взломать:

1. Отсутствие требований к сложности: Пароли welcome и labexrocks являются простыми словарными словами или легко угадываемыми фразами. password123 — распространенный шаблон. Сильная политика должна требовать сочетания прописных букв, строчных букв, цифр и специальных символов.
2. Недостаточная длина: Хотя password123 и labexrocks имеют длину 11 и 10 символов соответственно, они все еще уязвимы из-за своей простоты. Политики должны устанавливать минимальную длину, обычно 12 символов или более, чтобы увеличить пространство поиска для злоумышленников.
3. Отсутствие проверки словарных слов: Политика не запрещала пользователям выбирать распространенные словарные слова или простые вариации.
4. Отсутствие проверки распространенных шаблонов: Пароли, такие как password123, следуют предсказуемым шаблонам, которые часто включаются в списки слов для взлома.
5. Отсутствие истории паролей/предотвращения повторного использования: Если пользователям разрешено повторно использовать старые пароли, даже если они когда-то были сильными, они становятся уязвимыми, если эти старые пароли утекут.

Чтобы смоделировать выявление этих пробелов, давайте рассмотрим, как может выглядеть более строгая политика паролей. Например, если наша текущая политика допускает minlen=8 и не имеет конкретных требований к классам символов, то welcome (7 символов) не пройдет, а password123 (11 символов, без специальных символов) пройдет. Результаты взлома подчеркивают, что даже если пароль соответствует базовому требованию к длине, он все равно может быть слабым, если не применяются проверки сложности и словарных слов.

Подумайте, как можно настроить параметры модуля pam_pwquality.so (такие как minlen, dcredit, ucredit, lcredit, ocredit, dictcheck), чтобы предотвратить такие слабые пароли. Например, установка dcredit=-1 потребует как минимум одну цифру, ucredit=-1 — прописную букву и т. д.

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

Рекомендации по более строгим политикам паролей

На этом этапе вы сформулируете рекомендации по более строгим политикам паролей на основе выявленных пробелов. Эффективные политики паролей обеспечивают баланс между безопасностью и удобством использования.

Вот несколько рекомендаций для более надежной политики паролей:

1. Минимальная длина: Увеличьте минимальную длину пароля до 12-14 символов. Длинные пароли экспоненциально труднее взломать.
   • Пример настройки PAM: minlen=12 в /etc/security/pwquality.conf или pam_pwquality.so minlen=12 в /etc/pam.d/common-password.
2. Требования к сложности: Обеспечьте использование комбинации типов символов:
   • Прописные буквы (A-Z)
   • Строчные буквы (a-z)
   • Цифры (0-9)
   • Специальные символы (!@#$%^&*()_+-=[]{}|;':",./<>?)
   • Пример настройки PAM: dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1 в /etc/security/pwquality.conf или pam_pwquality.so dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1 в /etc/pam.d/common-password.
3. Проверка словарных слов и распространенных шаблонов: Запретите использование распространенных словарных слов, распространенных имен и легко угадываемых шаблонов (таких как password123, qwerty, 123456).
   • Пример настройки PAM: dictcheck=1 usercheck=1 в /etc/security/pwquality.conf или pam_pwquality.so dictcheck=1 usercheck=1 в /etc/pam.d/common-password.
4. История паролей/предотвращение повторного использования: Запретите пользователям повторно использовать определенное количество своих предыдущих паролей. Это снижает риск в случае компрометации старого пароля.
   • Пример настройки PAM: remember=5 с pam_unix.so в /etc/pam.d/common-password (например, password required pam_unix.so obscure sha512 shadow remember=5).
5. Политика блокировки учетной записи: Внедрите политику блокировки учетной записи после определенного количества неудачных попыток входа для предотвращения атак методом перебора.
   • Пример настройки PAM: Использование pam_tally2.so или pam_faillock.so в /etc/pam.d/common-auth (например, auth required pam_faillock.so deny=3 unlock_time=600).
6. Регулярная смена паролей (с осторожностью): Хотя это традиционно рекомендуется, частая обязательная смена паролей может привести к тому, что пользователи будут выбирать более простые и предсказуемые пароли. Лучший подход — обеспечить строгую сложность и длину, и требовать смены только в случае подозрения на утечку.

Чтобы продемонстрировать концептуальное изменение, давайте представим, что мы обновляем политику. Мы не будем фактически изменять системные файлы, но вы можете увидеть, как можно отредактировать файл pwquality.conf.

Откройте фиктивный файл для имитации рекомендаций по политике:

nano ~/project/recommended_policy.txt

Добавьте следующее содержимое в файл:

## Recommended Password Policy Settings
minlen = 14
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1
dictcheck = 1
usercheck = 1
maxrepeat = 3
maxsequence = 3

Сохраните и выйдите из nano (Ctrl+S, Ctrl+X).

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

Внедрение автоматизированных проверок соответствия политикам

На этом этапе вы узнаете о внедрении автоматизированных проверок соответствия политикам. В то время как прямое общесистемное применение политик осуществляется через PAM и другие конфигурационные файлы, автоматизированные проверки могут использоваться для регулярного аудита паролей пользователей или системных конфигураций на соответствие определенным политикам.

Для этой лаборатории мы смоделируем простую проверку соответствия с помощью скрипта оболочки. Этот скрипт проверит, соответствует ли пароль фиктивного пользователя базовому требованию к длине. В реальном сценарии такие скрипты были бы более сложными, потенциально интегрируясь с такими инструментами, как OpenSCAP, или пользовательскими скриптами для аудита фактических хэшей паролей (если это разрешено и этично) или конфигурационных файлов.

Сначала создадим фиктивного пользователя и файл с фиктивным хэшем пароля для имитации состояния системы. Мы не будем создавать реальных системных пользователей.

echo "testuser:\$6\$salt\$hashedpassword" > ~/project/dummy_shadow.txt

Теперь создайте простой скрипт оболочки с именем check_password_compliance.sh, который проверяет, превышает ли длина пароля для testuser в dummy_shadow.txt определенное значение (например, 10 символов).

nano ~/project/check_password_compliance.sh

Добавьте следующее содержимое в скрипт:

#!/bin/bash

## Этот скрипт имитирует базовую проверку соответствия длины пароля.
## В реальном сценарии вы бы парсили реальные записи файла shadow
## или использовали более сложные инструменты.

MIN_LENGTH=10
PASSWORD_HASH=$(grep "testuser" ~/project/dummy_shadow.txt | cut -d':' -f2)

## Для демонстрации мы просто проверим длину заполнителя хэша.
## В действительности вам пришлось бы взламывать или анализировать фактический хэш.
## Здесь мы просто проверяем, достаточно ли длинна сама строка хэша,
## что НЕ является тем, как работают реальные проверки длины пароля, но служит
## заполнителем для проверки соответствия.

if [ ${#PASSWORD_HASH} -ge $MIN_LENGTH ]; then
  echo "Compliance Check: testuser password hash length meets minimum requirement ($MIN_LENGTH characters)."
  exit 0
else
  echo "Compliance Check: testuser password hash length DOES NOT meet minimum requirement ($MIN_LENGTH characters)."
  exit 1
fi

Сохраните и выйдите из nano (Ctrl+S, Ctrl+X).

Сделайте скрипт исполняемым:

chmod +x ~/project/check_password_compliance.sh

Теперь запустите скрипт проверки соответствия:

~/project/check_password_compliance.sh

Вы должны увидеть вывод, указывающий на соответствие на основе длины фиктивного хэша:

Compliance Check: testuser password hash length meets minimum requirement (10 characters).

Этот простой пример иллюстрирует концепцию автоматизированной проверки соответствия. В производственной среде такие скрипты могут быть запланированы для периодического запуска с использованием cron для обеспечения постоянного соблюдения политик паролей. Более продвинутые проверки будут включать парсинг фактических хэшей паролей (если это разрешено и с надлежащими соображениями безопасности), проверку по спискам слов или интеграцию с фреймворками соответствия требованиям безопасности.

Резюме

В этой лаборатории вы получили практический опыт в аудите и обеспечении соблюдения политик паролей. Вы узнали, как анализировать существующие конфигурации политик паролей в системе Linux, изучая ключевые файлы, такие как /etc/login.defs, /etc/pam.d/common-password и /etc/security/pwquality.conf. Затем вы использовали John the Ripper, чтобы продемонстрировать, насколько легко можно взломать слабые пароли, подчеркнув важность надежных политик. На основе этих выводов вы сформулировали рекомендации по более строгим политикам паролей, сосредоточившись на длине, сложности и проверках по словарю. Наконец, вы изучили концепцию автоматизированных проверок соответствия, создав простой скрипт для проверки соблюдения политики паролей. Эта лаборатория дает фундаментальное понимание аудита безопасности паролей, вооружая вас навыками для выявления и устранения уязвимостей, связанных с паролями.