Рекомендации ФСТЭК по безопасной настройке Linux: ядро, права, sysctl и проверка

У ФСТЭК России есть методический документ «Рекомендации по безопасной настройке операционных систем Linux». Он не привязан к дистрибутиву и описывает конкретные параметры: права на файлы, вход root, параметры ядра. Ниже эти меры разобраны по пунктам с командами, указано, что может сломаться, и дан скрипт, который проверяет систему, ничего не меняя. Общий контекст и соответствие группам мер: hardening Linux.

Нумерация пунктов (2.1.1 … 2.6.6) дана по разбору документа на BI.ZONE (8 октября 2025). Это пересказ, а не текст документа: оригинал, его номер и действующую редакцию ищите на fstec.ru.

Для кого это обязательно

• Для государственных информационных систем и объектов КИИ на Linux, который не сертифицирован ФСТЭК: выполнение требований обязательно до замены на сертифицированную ОС. Так это описывает BI.ZONE, уточняйте формулировку в документе.
• Для остальных это перечень проверенных мер, не привязанный к дистрибутиву: подходит для Debian, Ubuntu, RHEL-семейства.
• BI.ZONE приводит данные своего SOC: около 90% компаний не соблюдают хотя бы одно требование. Это данные одного вендора, но порядок величины понятен: на практике почти всегда что-то не выполнено.

Не применяйте меры на боевом сервере сразу целиком. Порядок: тестовая копия, проверка сервисов, затем боевой узел. Часть мер (ptrace, user namespaces, IOMMU, SMT) ломает конкретные сценарии.

2.1. Авторизация

Остальные настройки SSH и PAM: раздел 5 общей статьи.

2.2. Ограничение получения привилегий

2.3. Права доступа к объектам файловой системы

Идея всех пунктов одна: файл, который исполняется с повышенными правами или влияет на вход, не должен быть изменяем посторонними, как и каталоги выше него. Ниже проверки только на чтение: сначала найдите отклонения, потом правьте осознанно.

Команды поиска отклонений:

# 2.3.1 права на файлы учётных записей
stat -c '%a %U:%G %n' /etc/passwd /etc/group /etc/shadow

# 2.3.2 исполняемые файлы запущенных процессов, доступные на запись группе или остальным
for p in /proc/[0-9]*/exe; do readlink -f "$p" 2>/dev/null; done | sort -u \
  | xargs -r stat -c '%A %U %n' | awk 'substr($1,6,1)=="w" || substr($1,9,1)=="w"'

# 2.3.3, 2.3.6, 2.3.7 cron
sudo find /etc/crontab /etc/cron.* /var/spool/cron -type f -perm /022 -ls

# 2.3.5 стартовые скрипты и юниты
sudo find /etc/rc*.d /etc/systemd/system /usr/lib/systemd/system -type f -perm /002 -ls

# 2.3.8 системные каталоги и модули ядра
sudo find /bin /sbin /usr/bin /usr/sbin /lib /lib64 /usr/lib /usr/lib64 /lib/modules -xdev ! -type l -perm /022 -ls 2>/dev/null

# 2.3.9 SUID/SGID: сохраните список как эталон
sudo find / -xdev -type f \( -perm -4000 -o -perm -2000 \) -ls

# 2.3.10, 2.3.11 домашние каталоги и их файлы
stat -c '%a %n' /home/*
sudo find /home /root -maxdepth 2 -type f \( -name '.*history' -o -name '.bash*' -o -name '.profile' -o -name '.rhosts' \) -perm /077 -ls

Исправление выполняется командами вида chmod go-w ФАЙЛ, chmod 700 /home/ИМЯ, chmod -s ФАЙЛ (снять лишний SUID/SGID). Для /etc/shadow в Debian и Ubuntu штатно 640 root:shadow: приведение к 600 закрывает требование, но может нарушить работу вспомогательных программ, читающих пароли через группу shadow. Проверьте вход по SSH и sudo после правки, и держите вторую сессию открытой.

2.4. Защита ядра

2.5. Сокращение периметра атаки ядра

2.6. Защита пользовательского пространства со стороны ядра

Параметры fs.protected_* по описанию не влияют на нормальную работу и блокируют только вредоносные сценарии: их можно включать сразу.

Готовые файлы настройки

Файл /etc/sysctl.d/99-fstek.conf. Закомментированы пункты с заметной ценой: включайте их осознанно.

kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
net.core.bpf_jit_harden = 2
kernel.perf_event_paranoid = 3
kernel.kexec_load_disabled = 1
kernel.unprivileged_bpf_disabled = 1
vm.unprivileged_userfaultfd = 0
dev.tty.ldisc_autoload = 0
vm.mmap_min_addr = 4096
kernel.randomize_va_space = 2
kernel.yama.ptrace_scope = 2
fs.protected_symlinks = 1
fs.protected_hardlinks = 1
fs.protected_fifos = 2
fs.protected_regular = 2
fs.suid_dumpable = 0
# ломает rootless-контейнеры, Flatpak, песочницы браузеров:
# user.max_user_namespaces = 0
# необратимо до перезагрузки, ломает отладчики:
# kernel.yama.ptrace_scope = 3

sudo sysctl --system

Параметры загрузки добавьте в GRUB_CMDLINE_LINUX:

init_on_alloc=1 slab_nomerge randomize_kstack_offset=1 vsyscall=none debugfs=off tsx=off
# отдельно, после проверки производительности и оборудования:
# iommu=force iommu.strict=1 iommu.passthrough=0
# mitigations=auto,nosmt

# Debian/Ubuntu
sudo nano /etc/default/grub && sudo update-grub
# RHEL-семейство
sudo grubby --update-kernel=ALL --args="init_on_alloc=1 slab_nomerge randomize_kstack_offset=1 vsyscall=none debugfs=off tsx=off"
sudo reboot

Если ядро не знает параметр, оно его проигнорирует: после перезагрузки проверьте результат скриптом ниже. Ошибки в параметрах загрузки могут привести к неработающей загрузке: держите консольный доступ и предыдущее ядро в меню GRUB.

Скрипт проверки (только чтение)

Сохраните как fstek-linux-check.sh. Скрипт ничего не меняет, показывает OK, FAIL или N/A (параметра нет в этом ядре) и возвращает код 1, если есть отклонения.

#!/usr/bin/env bash
# Проверка параметров ядра и загрузки по рекомендациям ФСТЭК. Ничего не изменяет.
fail=0

chk() {   # chk ПАРАМЕТР ОЖИДАЕМОЕ
  local cur
  cur=$(sysctl -n "$1" 2>/dev/null) || { printf 'N/A   %s\n' "$1"; return; }
  if [ "$cur" = "$2" ]; then printf 'OK    %s = %s\n' "$1" "$cur"
  else printf 'FAIL  %s = %s (ожидается %s)\n' "$1" "$cur" "$2"; fail=1; fi
}

chkboot() {   # chkboot ВАРИАНТ1|ВАРИАНТ2 ...
  local alt ok=0 IFS='|'
  for alt in $1; do
    case " $(cat /proc/cmdline) " in *" $alt "*) ok=1;; esac
  done
  if [ $ok = 1 ]; then printf 'OK    boot: %s\n' "$1"
  else printf 'FAIL  boot: %s\n' "$1"; fail=1; fi
}

chk kernel.dmesg_restrict 1
chk kernel.kptr_restrict 2
chk net.core.bpf_jit_harden 2
chk kernel.perf_event_paranoid 3
chk kernel.kexec_load_disabled 1
chk kernel.unprivileged_bpf_disabled 1
chk vm.unprivileged_userfaultfd 0
chk dev.tty.ldisc_autoload 0
chk kernel.randomize_va_space 2
chk kernel.yama.ptrace_scope 3
chk fs.protected_symlinks 1
chk fs.protected_hardlinks 1
chk fs.protected_fifos 2
chk fs.protected_regular 2
chk fs.suid_dumpable 0
chk user.max_user_namespaces 0
[ "$(sysctl -n vm.mmap_min_addr)" -ge 4096 ] && echo 'OK    vm.mmap_min_addr' || { echo 'FAIL  vm.mmap_min_addr'; fail=1; }

chkboot 'init_on_alloc=1'
chkboot 'slab_nomerge'
chkboot 'randomize_kstack_offset=1|randomize_kstack_offset=on'
chkboot 'vsyscall=none'
chkboot 'debugfs=off|debugfs=no-mount'
chkboot 'tsx=off'
chkboot 'iommu=force'
chkboot 'iommu.strict=1'
chkboot 'iommu.passthrough=0'
chkboot 'mitigations=auto,nosmt'

# 2.1.1, 2.1.2
[ -z "$(awk -F: '($2=="") {print $1}' /etc/shadow 2>/dev/null)" ] && echo 'OK    пустых паролей нет' || { echo 'FAIL  есть пустые пароли'; fail=1; }
sshd -T 2>/dev/null | grep -qi '^permitrootlogin no' && echo 'OK    PermitRootLogin no' || { echo 'FAIL  PermitRootLogin'; fail=1; }

exit $fail

sudo bash fstek-linux-check.sh

В скрипте ожидается ptrace_scope=3 и max_user_namespaces=0 как в документе. Если вы сознательно выбрали 2 или оставили пространства имён включёнными, это будет «FAIL»: запишите такое отклонение с причиной, а не меняйте скрипт молча.

Что ещё предлагают независимые руководства, и что из этого подходит серверу

Дополнительные меры взяты из Linux Hardening Guide Madaidan’а (последнее изменение 19 марта 2022, часть сведений могла устареть) и рекомендаций проекта KSPP. Автор прямо пишет, что руководство нельзя копировать вслепую, оно ориентировано на десктоп и строгую модель угроз. Ниже оценка применимости к серверу.

hidepid для /proc

sudo groupadd proc
# /etc/fstab
proc  /proc  proc  nosuid,nodev,noexec,hidepid=2,gid=proc  0 0
sudo mkdir -p /etc/systemd/system/systemd-logind.service.d
printf '[Service]\nSupplementaryGroups=proc\n' | sudo tee /etc/systemd/system/systemd-logind.service.d/hidepid.conf
sudo systemctl daemon-reload
sudo mount -o remount /proc
ps aux | head

Без дополнения для systemd-logind сессии пользователей могут работать некорректно. Администраторов, которым нужно видеть все процессы, добавьте в группу proc.

Ограничение службы средствами systemd

Параметры песочницы добавляются в override-файл службы (sudo systemctl edit ИМЯ). Пример для службы, которой не нужен доступ к домашним каталогам и системным файлам; подгоняйте под своё приложение, иначе оно не запустится:

[Service]
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
PrivateDevices=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
CapabilityBoundingSet=
SystemCallFilter=@system-service
ReadWritePaths=/var/lib/ИМЯ

sudo systemctl daemon-reload && sudo systemctl restart ИМЯ
systemd-analyze security ИМЯ

Команда systemd-analyze security показывает оценку и перечень оставшихся возможностей службы. Улучшайте оценку по одному параметру за раз, проверяя запуск. MemoryDenyWriteExecute=yes ломает приложения с JIT (Java, Node.js), поэтому его не включайте вслепую.

Как внедрять в организации

BI.ZONE справедливо отмечает: исправление конфигураций — процесс, а не разовая правка. Что из этого нужно закрепить:

• Эталон конфигурации для каждой роли сервера: допустимые значения, исключения и порядок изменений. Хранить его в Git.
• Согласование и журнал. Любая правка параметров проходит согласование, фиксируется кем и когда сделана.
• Применение автоматикой, а не руками на каждом узле. Пример для Ansible:

- name: Параметры ядра по рекомендациям ФСТЭК
  ansible.posix.sysctl:
    name: "{{ item.key }}"
    value: "{{ item.value | string }}"
    sysctl_file: /etc/sysctl.d/99-fstek.conf
    reload: true
  loop: "{{ fstek_sysctl | dict2items }}"

• Золотой образ. Безопасные настройки включайте в образ, из которого разворачиваются новые серверы, иначе старые ошибки вернутся.
• Тест на изолированной копии и периодическая проверка соответствия скриптом выше или сканером: OpenSCAP, USG.

Как проверить результат

1. Скрипт проверки выдаёт OK по всем пунктам, которые вы решили применять, а остальные внесены в список исключений с причиной.
2. Команды поиска из раздела 2.3 возвращают пустой вывод (кроме эталонного списка SUID/SGID).
3. Приложения, SSH, sudo, контейнеры и мониторинг работают так же, как до изменений.
4. Сохранены вывод скрипта «до» и «после» и версия документа, по которому проводилась проверка.

Дальше: общий перечень по CIS, чек-лист hardening, статьи для Astra Linux и РЕД ОС, где при сертифицированной сборке часть этих параметров уже определена производителем.