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

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

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

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

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

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

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

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

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

В Astra Linux Special Edition x.7 и более поздних обновлениях, включая 1.7 и 1.8, используются три уровня защищённости и соответствующие варианты лицензирования. Уровень определяет, какие функции безопасности доступны системе. Это не прямой аналог класса ГИС, уровня защищённости ИСПДн или категории значимого объекта КИИ: выбор обосновывают категорией информации, моделью угроз, применимыми требованиями, требуемыми функциями и приобретённой лицензией.

sudo astra-modeswitch list
sudo astra-modeswitch get
sudo astra-modeswitch getname
# Пример повышения до усиленного уровня:
sudo astra-modeswitch set advanced
sudo reboot
# После перезагрузки:
sudo astra-modeswitch getname
sudo astra-security-monitor

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

Рекомендации по безопасной среде функционирования описывают то, что должно быть сделано вокруг ОС: доверенная загрузка, защита BIOS/UEFI и СВТ, физическая защита и безопасное сетевое взаимодействие. Номер раздела различается между редакциями 1.7 и 1.8, поэтому ориентируйтесь по названию и точной версии документа.

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

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

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

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

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

Планирование безопасной установки Astra

Этот раздел — контрольный ориентир для проектирования установки, а не отдельная лабораторная работа и не универсальный профиль. Точные параметры выбирают по документации к установленному обновлению Astra Linux, модели угроз, проекту защиты, условиям лицензии и назначению узла. Практические работы курса перечислены отдельно в конце раздела.

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

Пример логической структуры диска

Показанная структура иллюстративна. Защитное преобразование поддерживаемых разделов или групп томов, размеры и набор точек монтирования выбирают в программе установки по руководству точного обновления и проекту защиты; для 1.8.3 руководство допускает защитное преобразование в том числе при ручной разметке.

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

1. Применить параметры безопасности по руководству по КСЗ именно для установленного обновления; номера разделов между версиями меняются.
2. Проверить беспроводные интерфейсы и отключить неиспользуемые устройства в UEFI/BIOS или аппаратно. При необходимости блокировать конкретные драйверы штатной конфигурацией modprobe после проверки зависимостей. Не удалять вручную файлы из /lib/modules: ими управляет пакетный менеджер, а обновление ядра восстановит их.
3. Конфигурирование параметров ядра через отдельный файл в /etc/sysctl.d/ (см. раздел 07 — пример набора, который необходимо адаптировать и проверить).
4. Применить рекомендованную конфигурацию — двумя способами на выбор:
   • Вариант А. Настроить применимые параметры по таблице конфигураций актуальной редакции рекомендаций (для x.8 — таблица 4.1; обзор см. в разделе 10 лекции).
   • Вариант Б. Применить утверждённый профиль штатным средством, если он поддерживается точным обновлением и предварительно испытан на роли узла.
5. Перезагрузить ОС.
6. Проверить настройки подсистем КСЗ с помощью Монитора безопасности и Профиля системы.
7. Проверить функции безопасности через astra-security-monitor и штатные тесты, предусмотренные документацией установленного обновления. Наличие и пути отдельных тестовых сценариев сначала проверяют по руководству по КСЗ.

Конфигурация ядра: пример контрольного набора

Таблица показывает 16 групп параметров, которые встречаются в рекомендациях по hardening. Это не готовый универсальный профиль: sysctl-параметры и опции загрузки выбирают по роли узла, архитектуре, версии ядра и модели угроз. Значения sysctl обычно задают отдельным файлом в /etc/sysctl.d/; опции загрузки добавляют к существующему GRUB_CMDLINE_LINUX, после чего выполняют update-grub и перезагрузку.

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

# 1) Сохранить резервную копию и внести только обоснованные sysctl
sudo cp -a /etc/default/grub /etc/default/grub.before-hardening
sudo nano /etc/sysctl.d/99-hardening.conf

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

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

# 4) После согласованной перезагрузки проверить sysctl и фактическую строку ядра
sudo sysctl kernel.yama.ptrace_scope
sudo sysctl fs.protected_symlinks
cat /proc/cmdline

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

Рекомендации отдельно рассматривают конфигурирование сетевых служб; в актуальной редакции x.8 этот материал находится в подразделе установки и настройки служб. Ниже приведены ориентиры для SSH, Samba и Apache, которые необходимо сопоставить с ролью сервера и точным обновлением.

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

После изменения проверяйте не только синтаксис (sshd -t), но и эффективные значения (sshd -T -C user=<user>,host=<host>,addr=<client-ip>), в том числе отдельно для user=root. Сначала откройте вторую контрольную сессию и только затем закрывайте исходную. Исправный SSH-клиент отвечает на server-alive даже при полном простое пользователя; политику именно пользовательского idle-timeout проектируют отдельно с учётом версии OpenSSH, оболочки и прикладного протокола.

Samba (/etc/samba/smb.conf)

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

Не смешивайте baseline и адаптацию. Согласованный профиль рекомендаций Astra для Apache задаёт консервативные KeepAlive Off и LimitXMLRequestBody 10485760. Для конкретного сервиса допустима документированная риск-ориентированная адаптация после нагрузочных и функциональных испытаний; именно такой учебный вариант для статического сайта показан ниже и в лабораторной работе 3.

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

Рекомендации по Astra 1.7 и 1.8 нельзя сопоставлять только по номерам разделов: структура менялась между редакциями. В актуальном документе x.8 настройки подробнее связаны с мерами ФСТЭК (ОПС, ЗИС, РСБ), а точные инструменты и поддерживаемые ядра зависят от оперативного обновления.

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

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

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

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

Ниже — выборка тем из таблицы 4.1 актуальной редакции рекомендаций x.8. Таблица связывает конкретные настройки с мерами ФСТЭК: ОПС — ограничение программной среды, ЗИС — защита информационной системы, РСБ — регистрация событий безопасности. Это обзор, а не полный перечень.

Здесь показана только часть строк таблицы 4.1. Точный состав, коды мер, значения и пошаговые указания проверяйте по актуальной редакции рекомендаций для установленного обновления Astra Linux 1.8.

Аудит и контроль в Astra Linux

Аудит даёт доказательства событий безопасности и изменений конфигурации. В актуальной редакции рекомендаций x.8 настройки регистрации и анализа представлены среди строк таблицы 4.1 и связаны с мерами РСБ.3 и РСБ.4; их точный состав зависит от редакции документа и проектного профиля аудита.

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

• Включение и проверка подсистемы аудита (РСБ.3): состояние службы auditd, загрузка требуемых правил и обработка отказов.
• Набор регистрируемых событий: вход и выход, изменение конфигурации, привилегированные действия и доступ к определённым проектом объектам.
• Производительность: оценка нагрузки, ёмкости очереди и риска потери событий.
• Управление журналами: размер, ротация, реакция на заполнение, передача и защита от несанкционированного изменения.
• Контроль и анализ событий (РСБ.4): периодичность просмотра, корреляция, оповещение и документирование результатов.

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

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

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

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

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

• Текущий уровень проверен командой astra-modeswitch getname и соответствует модели угроз, проекту, лицензии и условиям применения ОС.
• Доверенная загрузка реализована и проверена, если она предусмотрена применимыми требованиями и проектом.
• Задан пароль на BIOS/UEFI; отключена загрузка с внешних носителей.
• Задан взломостойкий пароль на GRUB.
• Разметка диска соответствует документации установленного обновления, модели угроз и проектной нагрузке; критичные данные защищены предусмотренным проектом способом.
• Неиспользуемые беспроводные устройства отключены аппаратно, в UEFI/BIOS или утверждённой политикой модулей; состояние проверено после обновления ядра.
• Применены и проверены обоснованные параметры ядра — sysctl и, при необходимости, опции загрузки GRUB (см. раздел 07).
• Обоснованные опции загрузки добавлены без потери действующих параметров; результат после перезагрузки проверен через /proc/cmdline.
• Отключены неиспользуемые сервисы (Bluetooth, Avahi, CUPS если нет принтера и т.д.).
• Включён Монитор безопасности; настроены контрольные срабатывания.
• МРД и МКЦ включены и настроены, если они предусмотрены проектом и доступны на выбранном уровне.
• ЗПС включена, если предусмотрена проектом; состав доверенного ПО и совместимость проверены.
• Подсистема аудита (auditd) запущена; правила аудита настроены под нужный профиль.
• Установлен сертифицированный антивирус (если требуется по классу системы).
• Регулярные проверки выполняются штатными средствами, доступными в установленном обновлении, и по соответствующему руководству по КСЗ; результаты и журналы сохраняются.

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

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

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

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

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

• Текущий уровень защищённости проверен и соответствует категории информации, модели угроз, применимым требованиям, лицензии и условиям сертификата.
• Физическая защита: серверная с контролем доступа, опечатывание корпуса.
• Доверенная загрузка реализована, если она предусмотрена применимыми требованиями и проектом.
• Используются только предусмотренные проектом сетевые интерфейсы; неиспользуемое оборудование отключено без удаления файлов пакетного менеджера.
• Обоснованные параметры ядра (sysctl + GRUB) применены и проверены; сетевые значения учитывают маршрутизацию и использование IPv6.
• SSH настроен по образцу: PermitRootLogin no, аутентификация по ключам, минимальные AllowUsers/AllowGroups, закрытие неотвечающих соединений и проверка эффективной конфигурации, включая контекст user=root; политика простоя пользователя при необходимости определена отдельно.
• Если используется Samba — настройки по образцу: guest ok = no, invalid users = root, hosts allow со списком.
• Если используется Apache — безопасное значение AstraMode обосновано, включены ServerTokens Prod, Options -Indexes, TLS и защитные заголовки; конфигурация протестирована.
• Межсетевой экран (узловой) включён; политика 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

0 */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+ контрольных вопросов

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

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