Подробный гайд: Восстановление Fly, SSH, su в Astra Linux после установки Dallas Lock - Часть 6

Подробный гайд: Восстановление Fly, SSH, su в Astra Linux после установки Dallas Lock - Часть 6

12. Если проблема точно в политике Dallas Lock

Если по логам видно, что отказ даёт именно СЗИ, лучше действовать не через обход, а через корректировку политики.

Что обычно нужно проверить в политике:

1. Разрешён ли запуск:

• /usr/sbin/sshd;
• /bin/su;
• /usr/bin/sudo;
• /usr/bin/fly*;
• /usr/lib/xorg/Xorg;
• dbus-daemon;
• пользовательских оболочек.

2. Разрешён ли сетевой доступ:

• входящий порт 22;
• адреса администраторов;
• интерфейсы управления.

---

---

3. Разрешены ли группы пользователей:

• администраторы;
• пользователи графической среды;
• доменные группы.

4. Нет ли правила:

• запретить su;
• запретить SSH;
• запретить графический вход;
• разрешить вход только с определённых терминалов;
• запретить вход вне рабочего времени;
• ограничить количество одновременных сеансов.

5. Нет ли требования:

• смарт-карта;
• OTP;
• смена пароля;
• регистрация устройства;
• актуальная лицензия;
• связь с сервером управления.

6. Не включён ли режим блокировки при:

• сбое агента;
• отсутствии лицензии;
• нарушении целостности;
• попытке удаления/остановки службы.

Если продукт управляется централизованно, локальные правки могут перезаписываться политикой. В этом случае изменения надо вносить на сервере управления.

---

13. Если нужно восстановить работу максимально быстро

Временные меры, которые часто помогают вернуть доступ:

1. Зайти через консоль или под аварийным администратором.

2. Проверить и разблокировать пользователя:

faillock --user username --reset 2>/dev/null || true
passwd username
chage -E -1 username

3. Проверить, нет ли /etc/nologin:

ls -l /etc/nologin /run/nologin 2>/dev/null

4. Проверить sshd:

/usr/sbin/sshd -t
ss -ltnp | grep ':22'

5. Проверить su:

grep -n 'pam_rootok' /etc/pam.d/su
SU_BIN=$(readlink -f "$(command -v su)")
ls -l "$SU_BIN"

6. Если проблема в PAM СЗИ и разрешено — временно закомментировать строки СЗИ в:

/etc/pam.d/common-auth
/etc/pam.d/common-account
/etc/pam.d/common-session

7. Если проблема в скриптах окружения СЗИ — временно вынести их из:

/etc/profile.d/
/etc/X11/Xsession.d/
/etc/xdg/autostart/

8. Если проблема в сетевом фильтре — разрешить порт 22 на время диагностики.
9. Если проблема в контроле приложений — добавить исключения для sshd, su, fly, Xorg, dbus.
10. После восстановления вернуть защиту в рабочее состояние уже корректно, а не оставлять систему открытой.

---

14. Что собрать для обращения в поддержку

Если проблема не решается быстро, соберите комплект:

14.1. Версии

cat /etc/os-release
uname -r
dpkg -l | grep -Ei 'dallas|dlk|lock|fly|openssh|libpam|xserver|dbus'

14.2. Журналы

journalctl -b --no-pager > /root/diag-journal-current.txt
journalctl -b -1 --no-pager > /root/diag-journal-previous.txt 2>/dev/null
tail -n 1000 /var/log/auth.log > /root/diag-auth.txt 2>/dev/null
tail -n 1000 /var/log/syslog > /root/diag-syslog.txt 2>/dev/null
cp /var/log/Xorg.0.log /root/diag-Xorg.0.log 2>/dev/null
cp ~/.xsession-errors /root/diag-xsession-errors.txt 2>/dev/null

14.3. Конфигурации без секретов

Важно: не отправляйте приватные ключи и /etc/shadow.

tar --exclude='/etc/ssh/ssh_host_*_key' \
    --exclude='/etc/shadow' \
    --exclude='/etc/gshadow' \
    -czf /root/diag-etc.tar.gz \
    /etc/os-release \
    /etc/pam.d \
    /etc/security \
    /etc/ssh \
    /etc/X11 \
    /etc/profile.d \
    /etc/environment \
    /etc/systemd/system \
    /usr/share/pam-configs \
    2>/dev/null

14.4. Диагностика сервисов и сети

systemctl --failed --no-pager > /root/diag-failed-units.txt
systemctl status ssh sshd display-manager --no-pager > /root/diag-services.txt 2>/dev/null
ss -ltnp > /root/diag-listen.txt
ip a > /root/diag-ip.txt
/usr/sbin/sshd -T > /root/diag-sshd-effective.txt 2>/dev/null
dmesg -T > /root/diag-dmesg.txt
df -h > /root/diag-df.txt
df -i > /root/diag-inodes.txt

14.5. Описание проблемы

Подготовьте ответы:

1. Когда именно возникла проблема: после установки, после перезагрузки, после применения политики?
2. Какие ошибки показываются пользователю?
3. Локальный вход работает?
4. Графический вход работает?
5. Текстовый вход работает?
6. SSH работает хотя бы для одного пользователя?
7. su работает от root?
8. sudo работает?
9. Проблема у всех пользователей или у одного?
10. Локальные пользователи работают, доменные нет, или наоборот?
11. Менялись ли парольные политики?
12. Обновлялись ли пакеты/ядро перед проблемой?
13. Есть ли централизованное управление Dallas Lock?
14. Есть ли лицензия и активна ли она?
15. Видны ли события блокировки в логах СЗИ?

---

---

---

15. Чек-лист

Можно использовать как короткую шпаргалку.

Доступ

• [ ] Есть консоль или аварийный доступ.
• [ ] Есть рабочая учётка с правами администратора.
• [ ] Сделана резервная копия /etc.

Учётные записи

• [ ] Пользователь существует.
• [ ] Пароль не заблокирован.
• [ ] Пароль не истёк.
• [ ] Учётная запись не просрочена.
• [ ] Нет блокировки через faillock.
• [ ] Пользователь состоит в нужных группах.

Система

• [ ] Диск не переполнен.
• [ ] Inodes не закончились.
• [ ] Корневая ФС не в режиме read-only.
• [ ] Нет /etc/nologin или /run/nologin.
• [ ] Нет OOM-убийств.

PAM

• [ ] /etc/pam.d/common-auth не содержит отсутствующих модулей.
• [ ] /etc/pam.d/common-account не блокирует все учётки.
• [ ] /etc/pam.d/common-session не роняет сеанс.
• [ ] pam_systemd доступен и корректен.
• [ ] Нет подозрительного pam_exec.
• [ ] Нет строк СЗИ, которые не отрабатывают.

SSH

• [ ] Служба активна.
• [ ] Порт 22 слушается.
• [ ] sshd -t проходит без ошибок.
• [ ] Нет AllowUsers/DenyUsers, запрещающих вход.
• [ ] PasswordAuthentication/PubkeyAuthentication соответствуют ожиданиям.
• [ ] Права на ~/.ssh корректны.
• [ ] Файрвол не блокирует 22.
• [ ] Нет блокировки в fail2ban/TCP Wrappers.

su

• [ ] /etc/pam.d/su содержит auth sufficient pam_rootok.so.
• [ ] Нет лишнего pam_wheel, если он не требуется.
• [ ] /bin/su имеет setuid.
• [ ] Файловые системы не в режиме nosuid.
• [ ] su не заблокирован политикой приложений.

Fly

• [ ] graphical.target является целью по умолчанию, если нужен графический вход.
• [ ] display-manager активен и не в failed.
• [ ] /etc/X11/default-display-manager указывает на существующий файл.
• [ ] В /usr/share/xsessions есть корректный файл сессии.
• [ ] В ~/.xsession-errors нет ошибок.
• [ ] В Xorg.0.log нет критичных (EE) ошибок.
• [ ] dbus, systemd-logind, пользовательская шина работают.
• [ ] /run/user/UID существует.
• [ ] Домашний каталог доступен пользователю на запись.
• [ ] Нет блокировки исполнения со стороны СЗИ/МАС.

Dallas Lock

• [ ] Службы СЗИ в ожидаемом состоянии.
• [ ] В логах нет ошибок лицензии, целостности, tamper.
• [ ] Политика не запрещает sshd, su, fly.
• [ ] Сетевой фильтр СЗИ не блокирует порт 22.
• [ ] Контроль приложений не блокирует нужные бинарники.
• [ ] Локальные правки не перезаписываются центральной политикой.
• [ ] Версия СЗИ совместима с текущей версией Astra и ядром.

---

16. Краткая логическая схема

Если коротко:

1. Есть ли локальный административный доступ?

• Нет → восстановление через rescue/KVM.
• Да → идём дальше.

2. Работает ли вход хотя бы для одного администратора?

• Нет → проверяем общий PAM, /etc/nologin, блокировки, диски, целостность.
• Да → проверяем конкретного пользователя и сервисы.

3. Что именно не работает?

• Только SSH → служба, конфиг, сеть, ключи, AllowUsers, firewall.
• Только su → pam_rootok, pam_wheel, setuid, nosuid, политика приложений.
• Только Fly → дисплейный менеджер, сессия, Xorg, dbus/logind, пользовательский профиль, блокировки исполнения.
• Всё сразу → общий PAM, учётные записи, политика СЗИ, системные ошибки.

---

---

4. Ломаются ли все пользователи или один?

• Один → домашний каталог, профиль, группы, метки, пароль.
• Все → системные конфиги, СЗИ, PAM, службы.

5. Есть ли следы блокировки в журналах?

• Да → правим политику/исключения.
• Нет → проверяем конфигурацию ОС и зависимости.

---

17. Практический минимум команд «на один экран»

Если нужен быстрый прогон:

U=username

echo "== OS =="
cat /etc/os-release
uname -r

echo "== Failed units =="
systemctl --failed --no-pager

echo "== Services =="
systemctl status ssh sshd display-manager --no-pager || true

echo "== SSH listen =="
ss -ltnp | grep ':22' || true

echo "== sshd config test =="
/usr/sbin/sshd -t || true

echo "== Account =="
id "$U"
passwd -S "$U" || true
chage -l "$U"
faillock --user "$U" 2>/dev/null || pam_tally2 --user "$U" 2>/dev/null || true

echo "== su =="
grep -n 'pam_rootok' /etc/pam.d/su
grep -n 'pam_wheel' /etc/pam.d/su
ls -l /bin/su /usr/bin/su 2>/dev/null

echo "== PAM =="
grep -nE 'dallas|dlk' /etc/pam.d/common-auth /etc/pam.d/common-account /etc/pam.d/common-session /etc/pam.d/sshd /etc/pam.d/su 2>/dev/null

echo "== nologin =="
ls -l /etc/nologin /run/nologin 2>/dev/null

echo "== Disk =="
df -h / /var /var/log /tmp /home
df -i / /var /home

echo "== Auth log tail =="
tail -n 100 /var/log/auth.log 2>/dev/null || journalctl -b -p warning..err --no-pager | tail -n 100

---

18. Самые вероятные виновники в вашем случае

Если после установки СЗИ одновременно ломаются Fly, SSH и su, я бы в первую очередь проверял именно эти пункты:

1. Модуль или правила СЗИ в PAM

Особенно /etc/pam.d/common-auth, common-account, common-session.

2. Блокировка пользователей после нескольких неудачных попыток

Особенно если кто-то пробовал входить до того, как политика была полностью применена.

3. Политика контроля приложений

Может блокировать su, sshd, оболочки, fly, Xorg.

4. Сетевой фильтр СЗИ

Может закрывать порт 22.

5. Скрипты в /etc/profile.d или /etc/X11/Xsession.d

Если они завершают сеанс, будут падать интерактивные входы и графика.

6. Отсутствие pam_systemd или проблема с dbus/logind

Часто приводит к тому, что графический сеанс не стартует нормально.

7. Изменение прав, меток или режима запуска

Особенно снятие setuid с su/Xorg или блокировка исполнения мандатным механизмом.

8. Несовместимость версии СЗИ с версией Astra Linux или ядра

Особенно если установка шла на свежую систему без проверки матрицы совместимости.

---

Если хотите, я могу дальше помочь сузить проблему.

Для этого пришлите, пожалуйста, в обезличенном виде:

1. вывод:

cat /etc/os-release
uname -r
dpkg -l | grep -Ei 'dallas|dlk|lock|fly|openssh|libpam'

2. ошибки из:

tail -n 100 /var/log/auth.log
journalctl -b -p warning..err --no-pager | tail -n 100
tail -n 100 ~/.xsession-errors 2>/dev/null

3. точное сообщение при:

• локальном входе;
• SSH;
• su;
• запуске Fly.

---

Информация предоставлена в ознакомительных целях. Применение описанных настроек в системах, должно осуществляться только после согласования с ответственными за информационную безопасность и в соответствии с требованиями ФСТЭК, ФСБ и иных уполномоченных органов.

---