Не отключайте SELinux. Настройте. Прямо сейчас. Большинство проблем с безопасностью в окружениях на базе отечественных дистрибутивов начинаются с этого. В логах – «Permission denied», в системе – дыры. Проверить режим можно так:
getenforce
Если получаете Permissive или, хуже, Disabled – это срочно к пересмотру. Вы должны видеть Enforcing. Меняется через конфигурацию:
vi /etc/selinux/config
Анализируйте. Используйте audit2allow для генерации политик. Не лезьте руками в контекст без понимания. Это не просто метки. Это контур доступа. Он держит всю систему.
Важно помнить: отключённый SELinux – это скомпрометированная безопасность без логов и сигналов тревоги.
Дальше – сетевые службы. Не запускайте по умолчанию sshd на всех интерфейсах. Зачем? Зачем открывать наружу всё подряд? Правильно, ограничить:
sshd_config: ListenAddress 192.168.10.1
Желательно – с ключевой авторизацией. Пароли – прошлый век. Генерируем:
ssh-keygen -t ed25519
Копируем:
ssh-copy-id user@host
Логика простая: не пускай, если не уверен. Нет авторизации по ключу – нет доступа.
Следующий узел – обновления. Не тяните. Используйте dnf с включённым репозиторием безопасности. Пример cron-задачи:
0 4 * * * /usr/bin/dnf -y --security update
Внимание! Обновления ядра требуют перезагрузки. Планируйте простоевое окно заранее.
Теперь о десктопах. Если используете графику – настраивайте политики через polkit. Это не игрушка. Это контроль привилегий на уровне GUI. Без правильной настройки – любой может поднять gnome-disks и сделать беду.
И последнее в этом блоке – журналирование. Используйте journalctl с фильтрами. Настройте ротацию:
vi /etc/systemd/journald.conf
Убедитесь, что SystemMaxUse не съедает весь раздел. Да, журнал может вырасти до десятков гигабайт, если его не ограничивать.
Зачем это всё? Чтобы не бегать потом, не разбираться в аномалиях и не латать дырки в боевом режиме. Всё просто: настрой один раз – забудь на год. Или не настрой – и жди сюрпризов. Выбирай.
Содержание статьи
Интеграция Red OS с системами управления доступом на предприятии
Подключайте SSSD. Без него – никакой централизованной аутентификации. Только локальные пользователи. Настроить можно так:
dnf install sssd realmd oddjob oddjob-mkhomedir adcli samba-common-tools -y
Затем ищем контроллер:
realm discover example.local
Присоединяемся:
realm join --user=админ example.local
Провал? Проверяйте часы. Отставание больше 5 секунд – тикеты Kerberos летят в мусорку. Настройка времени – строго через chronyd.
Права. Кто будет логиниться? Не все подряд, только указанные группы:
realm permit -g linux_users
Проверка работы:
id user@example.local
Если пусто – где-то провал в NSS. Разбирайтесь через:
sss_cache -E && systemctl restart sssd
Далее – автоматическое создание домашней директории:
authconfig --enablemkhomedir --update
Внимание! Убедитесь, что PAM-файлы не переписаны сторонними скриптами или GUI-настройщиками.
Теперь про ограничения. Вы не хотите, чтобы к серверу логинились пользователи из отдела продаж. Только devops, только hardcore. Пример конфигурации в /etc/sssd/sssd.conf:
access_provider = simple
simple_allow_groups = devops
Убедитесь, что права доступа на конфиг – 600. Иначе SSSD не стартует.
Важно помнить: неправильный доступ к sssd.conf – это сбой всего механизма авторизации. Без логов. Без жалоб. Просто черный экран входа.
Хотите MFA? Настраивайте FreeIPA или интеграцию с внешним RADIUS через pam_radius_auth. Простое подключение через PAM выглядит так:
auth required pam_radius_auth.so
Но проверьте, чтобы этот модуль был установлен. И да, он не входит в базовые репозитории. Ставим вручную или собираем.
Ограничение доступа по IP – через tcp_wrappers устарело. Используйте sshd_config:
Match Address 192.168.1.0/24
AllowUsers *@example.local
Никаких AllowUsers root. Это не тестовый стенд.
И логика простая. Всё что не явно разрешено – запрещено. Это правило железное. Особенно при работе в связке с AD и внешними LDAP.
А ещё. Проверьте лог /var/log/sssd/sssd_DOMAIN.log при любой аномалии. Не /var/log/messages. Не journalctl. Только sssd. Там вся правда.
Нет логина – ищем по уровням:
- Kerberos:
kinit,klist - LDAP:
ldapsearch - SSSD: вышеуказанный лог
- PAM:
pam-auth-updateиauthconfig
Механика простая. Не работает логин – это цепочка. Рвется звено – падает вся конструкция. Находите слабое место. Чините. И не доверяйте интерфейсам. Только терминал. Только ручной контроль.
Настройка групповых политик безопасности в среде Red OS
Начните с authselect. Не трогайте напрямую /etc/nsswitch.conf или /etc/pam.d/ – сломаете всё. Работать надо через профили:
authselect select sssd with-faillock --force
Это включит блокировку после неудачных попыток входа. Настройка:
/etc/security/faillock.conf:
deny = 5
unlock_time = 900
По умолчанию это не включено. А значит любой может брутить ssh хоть до утра. Контроль нужен жёсткий.
Теперь – sudo. Никаких ALL=(ALL) NOPASSWD:ALL. Выдавайте права точечно, через группы. Пример:
%admins ALL=(ALL) ALL
А группу admins создаёте в LDAP или FreeIPA, привязываете только нужных. Без этих самодельных user1:x:1001:user1.
Важно! Никогда не редактируйте
/etc/sudoersнапрямую. Используйтеvisudo. Один пробел – и вы без рута.
Дальше – запрет USB. Вопрос частый: как отключить флешки массово? Решение:
vi /etc/modprobe.d/usb-storage.conf
install usb-storage /bin/true
После перезагрузки – никаких съёмных устройств. Если надо вернуть – уберите строку и перезапустите udev.
А вот ограничение доступа к tty. Только нужные логинятся через консоль:
vi /etc/securetty
оставьте только: tty1
Теперь про ограничения по времени. Хочешь логиниться ночью – нет, нельзя. Используйте PAM-модуль:
vi /etc/security/time.conf
login;*;devops;!Al0000-0800
Это запрет входа группе devops с полуночи до 8:00. Не актуально для продакшена? Ошибка. Всё, что не нужно – отключено.
Для автоматического контроля – auditd. Настройка слежения за файлами sudo:
auditctl -w /etc/sudoers -p wa -k sudo_watch
И, конечно, настройка логирования попыток доступа к важным конфигурациям. Всё фиксируется в:
/var/log/audit/audit.log
Ищите по ключу:
ausearch -k sudo_watch
Хотите централизованно? Подключайте rsyslog к syslog-серверу. Конфигурация:
*.* @@192.168.0.10:514
Помните: если политики безопасности нигде не зафиксированы, значит, их не существует. Это не мнение. Это факт.
Группы – это каркас. Политики – арматура. Без них вся структура управления доступом проваливается при первой нагрузке. Настрой правильно. Один раз. Или будет поздно.
Использование Red OS для автоматизации рабочих процессов в отделах
Первое – cron. Не используете? Значит задачи делают вручную. Хаос. Пример: резервное копирование каталогов бухучета каждый вечер в 21:30.
30 21 * * * rsync -a /mnt/1C/ /backup/1C/ >> /var/log/backup.log 2>&1
Где лог? Вот он. Где отчёт? Вот он. Никаких сюрпризов. Всё чётко. Всё фиксируется.
Второе – systemd timers. Крон мёртв для приложений. Запускаем сервис по времени:
/etc/systemd/system/db-sync.service:
[Service]
Type=oneshot
ExecStart=/usr/local/bin/sync_db.sh
/etc/systemd/system/db-sync.timer:
[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true
[Install]
WantedBy=timers.target
Запускаем:
systemctl enable --now db-sync.timer
Работает как часы. Авария? Проверка логов через journalctl -u db-sync.service. Ошибка? Правим скрипт.
Третье – автоматическая установка пакетов. Не руками. Не через yum/dnf в консоли. Используем Ansible:
- hosts: бухгалтерия
tasks:
- name: Установить LibreOffice
dnf:
name: libreoffice
state: present
Один playbook – и весь отдел готов к отчётному периоду.
Надо настроить принтеры? Пример:
lpadmin -p HP_Laser -E -v socket://192.168.10.5 -m everywhere
Готово. Все пользователи отдела печатают без плясок с GUI.
Помните: всё, что делается руками, обязательно сломается. Скрипты не забывают. Админы – да.
Дальше – автоматизация монтирования сетевых папок. Только через autofs. Не fstab. Пример:
/etc/auto.master:
/mnt/smb /etc/auto.smb --timeout=60
/etc/auto.smb:
1C -fstype=cifs,rw,credentials=/etc/smb.passwd ://fileserver/1C
Папка монтируется по требованию. Никаких зависаний на загрузке, если сервера нет. Надёжно. Предсказуемо.
Автозапуск приложений при логине? У GNOME – gsettings. Пример скрипта:
gsettings set org.gnome.settings-daemon.plugins.media-keys custom-keybindings/custom0/ command '/usr/bin/keepassxc'
И не надо просить сотрудников запускать руками. Запускается само.
Внимание! Всегда проверяйте автоматизации на стенде. Один неправильный символ – и весь отдел без доступа к данным.
Сценарии для бухгалтеров. Планировщики для юристов. Распечатка отчётов для HR. Всё это можно автоматизировать на системном уровне. Без стороннего ПО. Без зависимости от конкретных людей.
Главное – не бояться писать bash-скрипты. Пример отправки ежедневного отчёта по почте:
echo "Отчёт готов" | mail -s "Ежедневный отчёт" user@domain.local
Не работает mail? Установите mailx и настройте ssmtp. Всё тривиально.
Мониторинг и аудит событий в Red OS с помощью встроенных инструментов
Начать нужно с auditd. Не включён – значит всё мимо. Установка стандартная:
dnf install audit -y
systemctl enable --now auditd
Проверка статуса:
auditctl -s
Работает? Идём дальше. Правила аудита на лету добавлять бессмысленно. После перезагрузки всё пропадёт. Используем /etc/audit/rules.d/. Пример отслеживания изменения конфигурации sudo:
-w /etc/sudoers -p wa -k sudo_change
Применение:
augenrules --load
Поиск событий:
ausearch -k sudo_change
Расшифровка – через aureport или ausearch -i. Без -i лог нечитаемый. Только raw.
Теперь мониторинг логинов. Добавляем правило:
-a always,exit -F arch=b64 -S execve -F euid=0 -k root_cmd
Слишком много? Фильтруем по пользователю:
-F auid=1000
Теперь о journalctl. Забудьте про /var/log/messages. Всё уже здесь:
journalctl -u sshd
Последние 100 строк:
journalctl -u sshd -n 100
Фильтрация по времени:
journalctl --since "2025-05-01" --until "2025-05-23"
Для слежения за изменением групп, паролей, прав доступа – только /var/log/audit/audit.log. Всё остальное – ложная безопасность.
Хотите алерты? Подключите auditd к syslog-ng или rsyslog, настройте отправку по сети:
/etc/rsyslog.conf:
:programname, isequal, "auditd" @@192.168.0.100:514
И получаете контроль в реальном времени. Проверили – отреагировали. Не проверили – поздно.
Теперь psacct. Старый, но работает. Устанавливаем:
dnf install psacct -y
systemctl enable --now psacct
Смотрим, кто запускал что:
sa
lastcomm user123
Можно увидеть: кто запустил rm, когда, с какими параметрами. Аргументы сохраняются. Аргументы – улика.
Внимание! Без настроенного аудита никакая служба безопасности не докажет, что root сделал то или это. Всё будет «по слухам».
Теперь контроль изменений файлов в системных разделах. Используем AIDE. Настройка:
dnf install aide -y
aide --init
mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
Проверка:
aide --check
Любое изменение – будет в отчёте. Файл изменился, размер совпал, но время – другое? Уже повод копать глубже.
Важно помнить: если у вас нет лога – у вас нет инцидента. Есть догадки. Только логи превращают догадки в доказательства.
Дополнительно – включите auditbeat, если у вас Elastic Stack. Но это уже не встроенное. А встроенное – работает не хуже. Главное – включить и не забыть, что оно там есть.