Безопасное хранение паролей пользователей в Red OS

Используйте только yescrypt в /etc/login.defs. Все остальные методы, включая md5 и sha512, уже не рассматриваются. Забудьте. Это слабое звено.

Конкретно: параметр ENCRYPT_METHOD yescrypt должен быть установлен по умолчанию, но проверьте – это не шутка. После обновлений возможен откат на старые схемы.

Зачем это знать? Потому что да, yescrypt замедляет перебор. Уровень сложности можно задать в /etc/security/pwquality.conf. В Red OS он обычно равен 5. Но стоит повысить хотя бы до 8. Есть ресурсы? Поднимите до 12.

Важно! Всегда пересоздавайте хеши после смены алгоритма. Иначе защита остается на прежнем уровне. Это ловушка.

Хеши находятся в /etc/shadow. Не в /etc/passwd. Не путать. Доступ имеет только root. В системе SELinux? Проверьте контекст system_u:object_r:shadow_t:s0. Без него даже root не гарантирует доступности.

Не стоит: использовать внешние PAM-модули из сомнительных источников. Особенно те, что якобы «ускоряют аутентификацию». Да, ускоряют. И вашу утечку тоже.

Интересно? Red OS умеет работать с модулями типа pam_faillock.so. Локдаун после 3 неудачных попыток. Параметры: deny=3 unlock_time=600. Установите через /etc/pam.d/system-auth. Мгновенно снижает шанс перебора.

Внимание! Не оставляйте пользователей с правами sudo без ограничений по timestamp_timeout. В /etc/sudoers задайте Defaults timestamp_timeout=0. Это минимизирует время окна атаки.

Под капотом: Red OS использует glibc. Значит, уязвимости типа glibc getaddrinfo stack-based overflow теоретически влияют на PAM. Патчи выходят регулярно. Но никто не мешает вам отставать. И это критично.

Как проверить? Выполните authconfig --test | grep hashing. Если не видите yescrypt – вы под угрозой.

Работаете в инфраструктуре с LDAP? Используйте только ldappasswd с TLS. Никаких запросов по 389 порту. Никогда. Только 636. В Red OS TLS реализован через openldap и nss-pam-ldapd. Неправильно настроили сертификаты – хэш можно считать перехваченным.

Механизмы шифрования паролей в Red OS: что используется и как это работает

Выбирайте yescrypt. Только он. Остальные варианты не соответствуют текущим требованиям к устойчивости. В Red OS используется libxcrypt, поддерживающий устаревшие и актуальные схемы. По умолчанию – SHA512. Это слабая политика.

Проверьте настройки с помощью команды:

authselect current

Если видите with-faillock и yescrypt – всё в порядке. Если нет – срочно переключайтесь на custom profile с заданным алгоритмом:

authselect create-profile secure --base-on sssd
authselect select custom/secure --force

Далее отредактируйте /etc/authselect/custom/secure/system-auth:

password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok

Замените на:

password sufficient pam_unix.so yescrypt shadow nullok try_first_pass use_authtok

Важно помнить: yescrypt устойчив к атаке по радужным таблицам. Он использует соль и параметр времени вычисления, что замедляет перебор даже на GPU. Простым языком – ресурс атакующего сгорает быстрее, чем его интерес к цели.

Ищете подтверждение? В /etc/login.defs должно быть:

ENCRYPT_METHOD yescrypt

Также рекомендуется указать:

YESCRYPT_COST_FACTOR 10

Эта настройка увеличивает задержку при создании хеша. Проверяйте вручную. Автоматические обновления не всегда корректно перезаписывают значения.

Внимание! Проверяйте, чтобы старые учетные записи были переведены на новый алгоритм. Хеши, созданные раньше, не обновляются сами по себе. Это ловушка.

Проверка текущих хешей в /etc/shadow доступна через grep:

grep -E '$y$' /etc/shadow

Если видите $6$ – это sha512. $y$ – признак yescrypt. Всего два символа – и вы знаете, что система не дырявая.

Не используйте md5. Ни при каких обстоятельствах. Это не алгоритм – это дыра. В Red OS поддержка осталась ради обратной совместимости, но это не означает, что ей нужно пользоваться.

Работаете в домене? Настройте sssd с опцией ldap_pwd_policy=shadow. Без этого аутентификация уходит в open-text. Уязвимость будет мгновенной.

Помните! Переход на yescrypt – не опция. Это требование времени. Всё остальное – компромисс, за который вы не хотите платить.

Процесс аутентификации в Red OS: защита от подмены и перехвата

Запретите вход через Telnet. Сразу. Без обсуждений. Только SSH с включённым протоколом версии 2. Проверка:

grep Protocol /etc/ssh/sshd_config
Protocol 2 – иначе вас взломают быстрее, чем вы успеете дочитать лог.

Обязательно включите строгую проверку ключей:

StrictModes yes
PermitRootLogin no
PubkeyAuthentication yes

Отключите PasswordAuthentication, если используете ключи. Удалите лазейку:

PasswordAuthentication no

Внимание! Атаки по перебору не имеют смысла, если пароли не принимаются в принципе.

Добавьте PermitEmptyPasswords no, иначе получите бэкдор своими руками.

Для усиления защиты на стороне PAM настройте модуль pam_tally2 или pam_faillock. Пример для /etc/pam.d/system-auth:

auth required pam_faillock.so preauth silent audit deny=3 unlock_time=900
auth [default=die] pam_faillock.so authfail audit deny=3 unlock_time=900

Три ошибки – и блокировка. Чётко. Жёстко. Без пощады ботам.

Для системной аутентификации через GUI используйте только GDM с Wayland. Не X11. X11 уязвим по определению. Не обсуждается. Настройка через /etc/gdm/custom.conf:

WaylandEnable=true

Для входа в систему по сети – только через VPN. OpenVPN, WireGuard – неважно. Главное, не пускать трафик в открытом виде. Любой прямой SSH из внешки – это как отдать ключи от квартиры случайному прохожему.

Используете FreeIPA? Включите 2FA. Настройка через ipa otptoken-add и ipa user-add-otp. Поддержка есть. Не пользуетесь – значит, не защищены.

Важно помнить: любой вход, не обёрнутый в TLS, считается прослушанным. Даже если вы об этом не знаете. Особенно если не знаете.

Проверьте, что SSSD работает в режиме строгой валидации. В /etc/sssd/sssd.conf:

ldap_id_use_start_tls = true
ldap_tls_reqcert = demand

Если ldap_tls_reqcert = allow – вы уже сдали свой каталог.

Не доверяйте локальной сети. Даже если это дата-центр. Даже если VLAN. Даже если вы – админ. Потому что вы – не один.

Итог: заблокируйте слабые протоколы. Принудите ключевую аутентификацию. Включите блокировку после неудачных попыток. Используйте шифрованные каналы. Не надейтесь на DMZ. Смотрите в лог /var/log/secure чаще, чем в календарь. Тогда у вас есть шанс.

Настройка политики хранения паролей в Red OS: минимизация рисков утечки

Запретите слабые комбинации. Жёстко. Через pam_pwquality.so. Файл /etc/security/pwquality.conf:

minlen = 14
dcredit = -1
ucredit = -1
ocredit = -1
lcredit = -1
retry = 3

14 символов минимум, все типы символов обязательны. Логика простая: нет хаоса – нет защиты.

Проверьте PAM-цепочку. В /etc/pam.d/system-auth строка должна выглядеть так:

password requisite pam_pwquality.so try_first_pass local_users_only

Нет этой строки – значит, пустили мимо важнейший барьер.

Далее – срок действия. Включите ограничение срока действия учётных данных. Команда:

chage --maxdays 90 --mindays 7 --warn 5 имя_учетной_записи

Текущие параметры можно проверить через:

chage -l имя_учетной_записи

Важно помнить: 90 дней – не мода. Это срок, после которого вероятность компрометации резко растёт. Сбрасывайте чаще, если в системе есть критические роли.

Заблокируйте повторное использование. В /etc/pam.d/system-auth:

password required pam_pwhistory.so remember=5 use_authtok

Без этого меняют один символ и обходят весь контроль.

Удаляйте неактивные учётки. Скрипт cron, раз в неделю. Пример:

awk -F: '$7!="/sbin/nologin" && $1!="root" {system("passwd -S "$1)}' | grep "LK"

Любая учётка в статусе LK должна быть либо разблокирована, либо удалена. Мёртвые профили – это бомба с таймером.

Ограничьте права смены ключей. Только через passwd с правами root или sudo. В /etc/sudoers:

%admin_group ALL=(ALL) NOPASSWD: /usr/bin/passwd [A-Za-z]*

Не давайте доступ к /etc/shadow даже под предлогом автоматизации. Права: 0000. Владелец: root:root. Проверка:

ls -l /etc/shadow

Должно быть: ---------- 1 root root

Помните! Даже один файл с неправильными правами – это не ошибка. Это инцидент. Утечка – вопрос времени.

Активируйте аудит всех операций смены ключей. Настройка через audit.rules:

-w /usr/bin/passwd -p x -k password_change
-w /etc/shadow -p wa -k shadow_watch

Проверка через ausearch -k password_change покажет, кто менял что и когда. Без этой информации вы слепы.