Безопасная настройка Astra Linux и ОС Linux

Зачем эта лекция

Настройка ОС «по умолчанию» — почти всегда не настройка для эксплуатации в защищённом контуре. ФСТЭК России выпустила три согласованных документа, которые превращают «голый» Linux и Astra Linux Special Edition в систему, готовую к работе в ГИС, ИСПДн и на объектах КИИ. Эта лекция — навигация по этим документам с практикой и сценариями.

Кому адресовано

Три документа ФСТЭК России

Все три документа выпущены или согласованы ФСТЭК России. Они применяются на разных типах систем и в разных контекстах сертификации.

Принцип применения

• Linux 2022 — это «базовый минимум» для несертифицированной ОС, который подлежит реализации до её замены на сертифицированную отечественную.
• Astra 1.7 / 1.8 — это эксплуатационные документы. Настройка сертифицированной ОС всегда осуществляется по документации разработчика; рекомендации ФСТЭК уточняют, что именно из настроек обязательно для эксплуатации в защищённом контуре.
• Все три документа покрывают одни и те же группы вопросов (загрузка, авторизация, права на файлы, ядро, сеть, журналы) — но с разной глубиной и разными конкретными настройками под платформу.

Три уровня защищённости Astra

Astra Linux Special Edition поставляется в трёх вариантах лицензирования, соответствующих трём уровням защищённости. Выбор уровня — это решение, которое нужно принять до установки: режим задаётся в инсталляторе и определяет набор включаемых функций безопасности.

Безопасная среда функционирования

Раздел 1 рекомендаций ФСТЭК по Astra 1.7 и 1.8 — про то, что должно быть сделано до ОС: доверенная загрузка, защита BIOS, защита самого СВТ, защита сетевого взаимодействия. Без этого даже корректно настроенная ОС не выдержит атаки на загрузчик или физический доступ к диску.

Четыре направления защиты среды

Что контролировать на загрузке

• MBR (главная загрузочная запись) — целостность критична на BIOS-системах.
• PBR (загрузочный сектор раздела) — целостность для каждого активного раздела.
• Сектора 1–63 относительно начала диска — место типового размещения буткитов.
• Раздел ESP (EFI System Partition) — содержит загрузчики UEFI, целостность критична.
• Настройки UEFI — ограничение модификации, отслеживание изменений.

Базовая настройка Linux: 6 направлений

Методический документ ФСТЭК России 2022 года описывает 6 направлений безопасной настройки любого Linux-дистрибутива. Это «база» — то, что должно быть сделано на любой системе на базе ядра Linux.

Безопасная установка Astra (по Модулю 11)

Пошаговая практика установки Astra Linux в максимальном режиме защищённости («Смоленск»). Это упражнение из практического сборника Группы Астра, которое студенты выполняют на учебной виртуальной машине.

Этап 1. Установка с учётом настроек безопасности

Рекомендуемая разметка диска (Модуль 11)

ЗПД — защитное преобразование данных (шифрование раздела на уровне Astra Linux по алгоритмам ГОСТ).

Этап 2. Настройки после установки

1. Применить параметры безопасности по «Руководству администратора по КСЗ, часть 1, п. 18.2».
2. Удалить драйверы беспроводных устройств на сервере: sudo rm -r /lib/modules/$(uname -r)/kernel/drivers/net/wireless.
3. Конфигурирование параметров ядра через /etc/sysctl.d/99-sysctl.conf (см. раздел 07 ниже — таблица 16 параметров).
4. Применить рекомендованную конфигурацию — двумя способами на выбор:
   • Вариант А. Настроить параметры по таблице 3.1 «Методических рекомендаций по безопасной настройке Astra Linux SE» (раздел 10 этой лекции).
   • Вариант Б. Применить готовый профиль безопасности системы (тип профиля задаёт преподаватель).
5. Перезагрузить ОС.
6. Проверить настройки подсистем КСЗ с помощью Монитора безопасности и Профиля системы.
7. Тестирование СЗИ встроенными средствами: в каталоге /usr/lib/parsec/tests/ расположены проверочные скрипты КСЗ (secdelrm.sh, тесты PARSEC и др.). Конкретный набор и команды запуска — по «Руководству по КСЗ. Часть 2».

Конфигурация ядра: 16 параметров (sysctl + опции загрузки)

Эта таблица — практический минимум параметров безопасности ядра для Astra Linux в защищённом контуре, предписанный в Модуле 11 и в рекомендациях ФСТЭК России. Большинство — это sysctl-параметры (применяются через /etc/sysctl.d/99-sysctl.conf и sysctl --system); две позиции (№ 12 и № 13) — опции загрузки ядра (прописываются в GRUB_CMDLINE_LINUX файла /etc/default/grub, применяются через update-grub и перезагрузку).

Применение и проверка

# 1) Внести параметры в файл
sudo nano /etc/sysctl.d/99-sysctl.conf

# 2) Применить без перезагрузки
sudo sysctl --system

# 3) Опции загрузки ядра — добавить в /etc/default/grub в GRUB_CMDLINE_LINUX
sudo nano /etc/default/grub
sudo update-grub

# 4) Проверка применения
sudo sysctl kernel.yama.ptrace_scope
sudo sysctl fs.protected_symlinks

Сетевые службы: SSH / Samba / Apache

Раздел 2.4 рекомендаций ФСТЭК по Astra 1.7/1.8 — конфигурирование наиболее уязвимых системных служб. Здесь — конкретные параметры, которые превращают «голый» сервис в защищённую конфигурацию.

SSH-сервер (/etc/ssh/sshd_config)

Samba (/etc/samba/smb.conf)

Apache 2 (/etc/apache2/apache2.conf)

Что изменилось в Astra 1.8 относительно 1.7

Документ ФСТЭК по Astra 1.8 в несколько раз объёмнее аналогичного по 1.7. Это отражает не «новые требования», а более детальную проработку мер защиты с явной привязкой к мерам ФСТЭК (ОПС, ЗИС, РСБ).

Ключевые отличия

Что осталось общим

• Структура документа (5 разделов: среда → установка → применение → очистка → аудит).
• Три уровня защищённости (Базовый «Орёл» / Усиленный «Воронеж» / Максимальный «Смоленск»).
• Общие принципы настройки сетевых служб (SSH, Samba, Apache).
• Большая часть sysctl-параметров (раздел 2.5).

Меры защиты ОПС / ЗИС в Astra 1.8

Раздел 3 рекомендаций ФСТЭК по Astra 1.8 — 17 конкретных мер защиты, каждая привязана к коду меры ФСТЭК (ОПС — ограничение программной среды; ЗИС — защита информационной системы; ОПС.1, ОПС.2, ЗИС.18, ЗИС.22, РСБ.3, РСБ.4 и др.).

Раздел 3 содержит 17 мер; раздел 4 — 2 меры (очистка памяти); раздел 5 — 8+ настроек подсистемы аудита (см. секцию 11 этой лекции). Для полного списка с пошаговыми указаниями — обращайтесь к оригинальному документу ФСТЭК по Astra Linux 1.8.

Аудит и контроль (раздел 5 Astra 1.8)

Аудит — это «глаза» защищённой системы. Без правильно настроенного аудита нельзя установить факт компрометации, обнаружить инсайдера или подтвердить соответствие требованиям. Раздел 5 рекомендаций ФСТЭК по Astra 1.8 содержит 8+ настроек, привязанных к мерам РСБ.3 и РСБ.4.

Меры подсистемы регистрации событий безопасности (РСБ)

• 5.1 — Включение подсистемы аудита (РСБ.3). Запуск службы auditd, проверка статуса.
• 5.2 — Включение событий по умолчанию. Настройка набора правил auditctl для типовых событий.
• 5.3 — Производительность. Подсистема аудита может оказывать существенное влияние; оценка нагрузки и оптимизация.
• 5.4–5.5 — Настройка правил аудита (РСБ.3). Определение, какие события системы регистрируются (вход/выход, изменение настроек, доступ к чувствительным файлам).
• 5.6 — Управление журналами. Параметры max_log_file, max_log_file_action, ротация.
• 5.7 — Дополнительные настройки регистрации (РСБ.3).
• 5.8 — Контроль и анализ событий (РСБ.4). Регулярный просмотр и анализ журналов.

Что проверять регулярно

1. Целостность журналов — журналы аудита защищены от модификации.
2. Сроки хранения — соответствуют политике (типично 1 год).
3. Размер свободного места для журналов — не доходит до критической отметки.
4. События привилегированных пользователей — все действия root и sudo фиксируются.
5. События подсистем безопасности — изменения МРД, МКЦ, ЗПС.
6. Ошибки и аварийные ситуации — отдельный мониторинг неудачных аутентификаций, попыток повышения привилегий.

Сценарий: настройка АРМ пользователя

АРМ (автоматизированное рабочее место) пользователя — самый массовый объект развёртывания Astra Linux. Здесь — типовой чек-лист настройки одного АРМ с нуля для работы в защищённом контуре.

Чек-лист настройки АРМ (15 пунктов)

• Уровень защищённости выбран на установке: «Воронеж» для большинства АРМ; «Смоленск» — если работа с гостайной.
• Установлен сертифицированный СДЗ или включён Secure Boot.
• Задан пароль на BIOS/UEFI; отключена загрузка с внешних носителей.
• Задан взломостойкий пароль на GRUB.
• Разметка диска — по рекомендациям Модуля 11 (отдельные разделы /tmp, /var, /parsec, /home; LVM + ЗПД).
• Удалены драйверы беспроводных устройств (если беспроводная сеть не требуется).
• Применены 16 параметров безопасности ядра — sysctl + опции загрузки GRUB (см. раздел 07).
• Опции загрузки ядра прописаны в GRUB: init_on_alloc=1, mitigations=auto, slab_nomerge.
• Отключены неиспользуемые сервисы (Bluetooth, Avahi, CUPS если нет принтера и т.д.).
• Включён Монитор безопасности; настроены контрольные срабатывания.
• МРД и МКЦ включены и настроены под политику предприятия.
• Замкнутая программная среда (ЗПС) включена; интерпретаторы заблокированы для непривилегированных.
• Подсистема аудита (auditd) запущена; правила аудита настроены под нужный профиль.
• Установлен сертифицированный антивирус (если требуется по классу системы).
• Регулярные проверки: /usr/lib/parsec/tests/run.sh -v, контроль журналов.

Особенности для ноутбуков и мобильных АРМ

• Шифрование всех разделов с данными — обязательно (ЗПД на уровне Astra или LUKS).
• Дополнительный пароль на ввод/вывод из спящего режима.
• Запрет работы с внешними беспроводными сетями (если требуется политикой).
• Контроль попадания за пределы охраняемой зоны (отдельные средства защиты).

Сценарий: настройка сервера

Сервер на Astra Linux чаще всего обслуживает другие защищённые узлы или предоставляет ресурсы пользователям. Hardening здесь идёт глубже, чем для АРМ — особое внимание сетевым службам и журналам аудита.

Чек-лист настройки сервера (18 пунктов)

• Уровень защищённости — «Воронеж» минимум; для сервера с гостайной — «Смоленск».
• Физическая защита: серверная с контролем доступа, опечатывание корпуса.
• Доверенная загрузка (СДЗ) обязательно.
• Только проводное сетевое подключение; беспроводные драйверы удалены.
• Все 16 параметров безопасности ядра (sysctl + GRUB) применены, в том числе сетевые: rp_filter, отключение ICMP redirect, отключение IPv6 если не используется.
• SSH настроен по образцу: смена порта, PermitRootLogin no, аутентификация по ключам, AllowUsers со списком, тайм-ауты.
• Если используется Samba — настройки по образцу: guest ok = no, invalid users = root, hosts allow со списком.
• Если используется Apache — AstraMode off при необходимости, ServerTokens Prod, Options -Indexes, тайм-аут 45 сек.
• Межсетевой экран (узловой) включён; политика deny by default.
• Все ненужные сетевые службы отключены — проверка через ss -tlnp.
• Включена и настроена подсистема аудита: auditd, правила под нужный профиль.
• Журналы аудита направляются на отдельный сервер (centralized logging).
• МРД, МКЦ, ЗПС включены и настроены под роль сервера.
• Сертификаты (TLS/SSL) выпущены доверенным УЦ; самоподписанные — только для тестов.
• Резервное копирование настроено; копии шифруются и хранятся отдельно.
• Регулярные обновления через сертифицированный канал.
• План реагирования на инциденты — отработан, контактные лица назначены.
• Документация на сервер — заполнена, согласована, актуальна.

Типовые серверные роли — что добавить

Найди недочёт: 6 кейсов из практики

Шесть фрагментов реальных конфигураций или вывода команд. В каждом есть нарушение рекомендаций ФСТЭК или явный недочёт hardening. Прочитайте, попробуйте найти проблему сами, потом раскройте подсказку.

$ ls -la /etc/shadow
-rw-r--r-- 1 root shadow 1825 апр 12 14:32 /etc/shadow

$ cat /etc/shadow
root:$6$abc.../...:19821:0:99999:7:::
postgres:$6$xyz.../...:19805:0:99999:7:::
sa:$6$qwe.../...:19815:0:99999:7:::

#       $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $
Port 22
PermitRootLogin yes
PasswordAuthentication yes
PubkeyAuthentication yes
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
PrintMotd no
AcceptEnv LANG LC_*

$ sudo sysctl -a 2>/dev/null | grep -E "ptrace_scope|dmesg_restrict|kptr_restrict|randomize_va_space"
kernel.dmesg_restrict = 0
kernel.kptr_restrict = 0
kernel.randomize_va_space = 0
kernel.yama.ptrace_scope = 0

$ cat /etc/crontab
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

* */6 * * *  root  /opt/backups/run-backup.sh

$ ls -la /opt/backups/run-backup.sh
-rwxrwxrwx 1 root root 1832 фев  5 09:14 /opt/backups/run-backup.sh

$ ls -ld /opt/backups
drwxrwxrwx 2 root root 4096 фев  5 09:14 /opt/backups

$ ls /lib/modules/$(uname -r)/kernel/drivers/net/wireless/
ath/        broadcom/   intersil/   marvell/    rsi/
ath10k/     cisco/     iwlwifi/    mediatek/   rt2x00/
ath11k/     intel/     iwldvm/     realtek/    rtl818x/
ath6kl/     intersil/ iwlmvm/     ti/         rtw88/

$ lsmod | grep -E "iwl|ath|wlan|wireless"
iwlwifi              368640  1 iwlmvm
cfg80211             946176  3 iwlmvm,iwlwifi

$ find / -perm -4000 -type f 2>/dev/null
/usr/bin/sudo
/usr/bin/su
/usr/bin/passwd
/usr/bin/chsh
/usr/bin/chfn
/usr/bin/newgrp
/usr/bin/gpasswd
/usr/bin/python3.11
/opt/internal/admin-tool
/home/sa/scripts/check-system

$ ls -la /opt/internal/admin-tool
-rwsr-xr-x 1 root root 28456 май  3 11:24 /opt/internal/admin-tool

Чек-лист готовности: 30+ контрольных вопросов

Финальный чек-лист — для самопроверки перед вводом системы в эксплуатацию или для эксперта при проведении аудита. Группа «нет» в любом разделе — это пробел, который нужно закрыть до выхода в эксплуатацию.

Часто задаваемые вопросы