Bash-скрипт безопасной настройки Linux-хостов по требованиям ФСТЭК России.
Покрывает 40 пунктов методического документа от 25.12.2022 + 20 дополнительных мер = 60 позиций; из них 59 реализованы, 15.1 kernel.modules_disabled=1 временно не применяется автоматически.

Version Platform FSTEC License

SecureLinux-NG — инструмент управляемой безопасной настройки Linux-хостов в соответствии с «Рекомендациями по безопасной настройке операционных систем Linux» ФСТЭК России (методический документ от 25.12.2022).

Ключевые возможности:

• Три профиля: baseline / strict / paranoid
• JSON manifest — каждое изменение фиксируется, откат через --restore
• Preflight-анализ среды — Docker, K8s, desktop, container
• --check / --apply / --restore / --report / --dry-run
• Debian 12/13, Ubuntu 22.04/24.04

wget https://github.com/rasav65/SecureLinux-NG/archive/refs/heads/main.tar.gz
tar -xzf main.tar.gz
cd SecureLinux-NG-main

⚠ На рабочих серверах — всегда выполняйте --dry-run перед --apply.

# Просмотр изменений без применения
sudo ./securelinux-ng.sh --apply --dry-run --profile strict
# Применение
sudo ./securelinux-ng.sh --apply --profile baseline
sudo ./securelinux-ng.sh --apply --profile strict --config examples/config.strict.conf
# Проверка состояния
sudo ./securelinux-ng.sh --check --profile strict
# Откат
sudo ./securelinux-ng.sh --restore

Формулировку про «закрываются все 60» считать устаревшей: в текущей версии реализованы 59 из 60 позиций, а 15.1 kernel.modules_disabled=1 временно не применяется автоматически.

Подробная таблица совместимости: docs/compatibility.md

Все 40 пунктов разделов 2.1–2.6 методического документа реализованы и покрыты --check.

Осознанное отступление. Буквальное требование ФСТЭК 2.3.1 для /etc/shadow — chmod go-rwx (600). В проекте оставлено штатное поведение Debian/Ubuntu: 640 root:shadow, чтобы не нарушать дистрибутивную модель доступа через группу shadow. Это оформленное отступление и должно учитываться отдельно при оценке соответствия.

Подробная карта соответствия: docs/fstec-mapping.md

Меры из внутреннего стандарта организации и книги Чайка А.А. «Практическая безопасность Linux» (БХВ-Петербург, 2026) — не входят в разделы 2.x методдокумента ФСТЭК:

Дополнительные меры из книги «Практическая безопасность Linux» (Чайка А.А., 2026):

Чтобы избежать интерактивных вопросов при --apply, используйте --config FILE.

Без Docker/Podman/K8s:

PROFILE=strict
USER_NAMESPACES_LIMIT=0
UFW_EXTRA_RULES=15000/udp:Kaspersky

С Docker/Podman/K8s:

PROFILE=strict
USER_NAMESPACES_LIMIT=10000
UFW_EXTRA_RULES=15000/udp:Kaspersky

Готовые шаблоны: examples/config.baseline.conf, examples/config.strict.conf, examples/config.paranoid.conf

• --restore не удаляет установленные пакеты (chrony, auditd, ufw, AppArmor и др.)
• kernel.kexec_load_disabled=1 — необратимо до перезагрузки
• GRUB params — вступают в силу только после перезагрузки
• AppArmor, AIDE, apport — не восстанавливаются автоматически, требуют ручных действий
• restore 2.1.1: пустые поля пароля в /etc/shadow не восстанавливаются автоматически по соображениям безопасности
• UFW: если firewall был активен до --apply, restore остаётся partial — исходные правила и состояние до применения не откатываются автоматически
• unattended-upgrades в --check оценивается по факту включения автоматических обновлений (enabled), а не по постоянному active состоянию службы
• Для профиля baseline AppArmor не является обязательной мерой: если он не активен, --check помечает это как SKIP, а не как RISKY
• Password aging: скрипт применяет парольную политику через chage для существующих локальных УЗ. Для просроченных УЗ lastchg сдвигается на сегодня (bootstrap). Перед strict/paranoid рекомендуется проверить состояние УЗ
• user.max_user_namespaces — значение задаётся через USER_NAMESPACES_LIMIT или выбор администратора при apply; 0 может ломать Docker/Podman/K8s
• kernel.modules_disabled=1 — временно не применяется автоматически (несовместим с binfmt_misc и UFW при загрузке); запланирован в следующей версии; только paranoid

Подробно: docs/restore-model.md, docs/compatibility.md

• --check, --report, --apply --dry-run — от обычного пользователя
• --apply, --restore — требуют root
• ОС: Debian 12/13, Ubuntu 22.04/24.04
• Зависимости: bash, python3, systemctl, sysctl, stat, awk, grep, uname, date, visudo

1. Обратимость — каждое изменение фиксируется в JSON manifest. --restore восстанавливает из backup или удаляет созданные объекты.
2. Проверяемость — --check работает независимо от --apply, не изменяет систему, каждый модуль имеет отдельную check-функцию.
3. Трассируемость — каждая мера привязана к пункту ФСТЭК в docs/fstec-mapping.md и в JSON report.
4. Профильное ветвление — три профиля с явным profile_allows() без неявных зависимостей.
5. Безопасность применения — preflight определяет среду и добавляет policy_gate/warning для compatibility-sensitive мер; окончательное решение остаётся за администратором.

securelinux-ng.sh — основной скрипт
docs/
 fstec-mapping.md — карта соответствия требованиям ФСТЭК
 restore-model.md — модель отката
 architecture.md — архитектура проекта
 compatibility.md — совместимость и ограничения по средам
examples/
 config.baseline.conf — шаблон конфига для baseline
 config.strict.conf — шаблон конфига для strict
 config.paranoid.conf — шаблон конфига для paranoid
tests/
 syntax.sh — проверка синтаксиса
 smoke.sh — smoke-тесты

Меры внутреннего стандарта, которые намеренно не реализованы автоматически:

SecureLinux-NG реализует технические меры hardening уровня ОС, которые можно автоматически применить, проверить и, где это возможно, откатить.

Проект не заявляет автоматическое закрытие всех требований ФСТЭК целиком, потому что часть требований относится:

• к организационным мерам;
• к процессам администрирования и эксплуатации;
• к внешней инфраструктуре и принятым в организации политикам;
• к прикладным системам, журналированию, хранению данных и другим подсистемам вне уровня базового hardening ОС.

Поэтому в проекте используется модель статусов:

• done — мера реализована и поддерживается текущей моделью apply/check/restore;
• partial — мера реализована частично, требует reboot, ручных действий, отдельного обоснования или не имеет полного безопасного restore;
• not_applicable — мера осознанно не автоматизируется в текущей реализации.

Таким образом, SecureLinux-NG следует рекомендациям ФСТЭК в пределах автоматически реализуемых мер ОС hardening, а полная оценка соответствия должна выполняться с учётом корпоративного регламента, архитектуры системы, состава сервисов и организационных процедур.

• ФСТЭК России, 25.12.2022 — «Рекомендации по безопасной настройке ОС Linux» — основной нормативный источник
• Чайка А.А. «Практическая безопасность Linux» — БХВ-Петербург, 2026
• Habr / BI.ZONE — практические материалы по ФСТЭК
• fortress_improved.sh (captainzero93) — Docker-aware логика, preflight
• JShielder (JsiTech) — SSH hardening
• Hardening-Ubuntu-2024.sh (AndyHS-506) — kernel module blacklist, CIS