Можно ли применять CIS Benchmark Ubuntu без проверки роли сервера?

Нет, не следует переносить CIS-профиль или готовый baseline без проверки. Сначала нужно зафиксировать роль хоста, опубликованные сервисы, зависимости и допустимые изменения. Универсальные запреты могут отключить нужную службу, нарушить доступ приложения к данным, мониторинг, резервное копирование или удалённое управление.

Можно ли использовать EOL-версию CentOS для нового сервера?

Нет, неподдерживаемую ветку CentOS не стоит использовать для нового сервера без отдельно принятого и документированного риска. Перед настройкой baseline нужно проверить, получает ли конкретный выпуск security updates. Статус поддержки зависит от версии ОС, а для части продуктов Red Hat — также от подписки.

Можно ли одновременно управлять firewall через UFW, firewalld и nftables?

Нет, для одной политики нужно выбрать один поддерживаемый способ управления. UFW, firewalld, ручные команды nftables, iptables и скрипты приложений используют Netfilter, но могут перезаписывать правила или формировать неочевидный итоговый ruleset. После изменения проверяйте фактически действующие правила и доступность сервисов.

Что делать, если SELinux или AppArmor заблокировал приложение?

AppArmor и SELinux не взаимозаменяемы: в Ubuntu и Debian обычно проверяют AppArmor и применимые профили, а в RHEL и совместимых системах — SELinux и режим политики. Поэтому исправление нужно выполнять средствами конкретного дистрибутива, а не переносить настройки между механизмами. При отказе сначала сохраните рабочий канал управления и выясните, какой процесс, файл, сокет или операция были запрещены. Проверьте журналы отказов и штатный сценарий приложения: открытого порта недостаточно, так как сервис может слушать сокет, но не выполнять запросы из-за MAC-политики. Затем скорректируйте конфигурацию приложения, метку, Boolean или профиль. Глобальное отключение MAC может временно скрыть проблему, но не является постоянным решением. После изменения убедитесь, что механизм контроля остаётся включённым, новые отказы не появляются, а приложение и его зависимости работают штатно.

Почему нельзя менять SSH и firewall в единственной сессии?

Изменения доступа выполняйте в окно обслуживания, сохраняя текущую SSH-сессию и независимый аварийный путь: консоль виртуальной машины, out-of-band-консоль или иной предусмотренный канал. До включения ограничений определите, как вернуть прежнюю конфигурацию SSH и firewall-правила. Сначала подтвердите вход по SSH в новой сессии с предусмотренной схемой аутентификации, затем меняйте политику SSH и firewall. После каждого изменения проверьте новое SSH-подключение с разрешённого административного узла, доступность опубликованного сервиса и итоговые правила выбранного менеджера firewall. IPv4 и IPv6 оценивайте отдельно. Если тест не пройден, не закрывайте рабочую сессию: через неё или консольный канал восстановите прежние правила. Успешное выполнение команды настройки само по себе не подтверждает, что административный доступ и прикладной сервис сохранились.

Нужно ли отдельно проверять firewall для IPv4 и IPv6?

Да. Разрешённые административные и прикладные потоки нужно оценивать отдельно для IPv4 и IPv6. Правило, которое сохраняет доступ по одному протоколу, не гарантирует его по другому. После изменения проверьте новое SSH-подключение, опубликованный сервис и фактический набор правил.

Hardening Linux-сервера: чек-лист для Ubuntu, Debian и RHEL

Начинайте hardening не с запрета SSH или копирования CIS-профиля, а с фиксации роли хоста, исходного состояния и рабочего аварийного канала управления. Затем применяйте изменения небольшими этапами: обновления, сокращение поверхности атаки, доступ, firewall, штатный MAC-контроль, параметры ядра и аудит. После каждого этапа проверяйте не только успешное выполнение команды, но и SSH, сеть, DNS, время и прикладной сервис; это позволяет откатить изменение до того, как недоступность станет аварией.

Изменения могут оборвать управление сервером

SSH, firewall, отключение unit-файлов, SELinux, AppArmor и sysctl способны нарушить удалённый доступ или работу приложения. Выполняйте их в окно обслуживания, сохраняя действующую SSH-сессию и независимый аварийный канал: консоль виртуальной машины, out-of-band-консоль или иной предусмотренный путь. Управление BMC рассматривается отдельно в статье «Защита BMC: безопасная настройка iDRAC, iLO и отдельной сети управления».

Что различается между Ubuntu, Debian и RHEL-совместимыми системами

Этапы базовой защиты Linux одинаковы, но штатные механизмы различаются. Ubuntu и Debian обычно используют APT и пакет unattended-upgrades; RHEL использует DNF, а для автоматизации — dnf-automatic. В RHEL-совместимых системах, включая Rocky Linux, доступность пакетов, репозиториев, политик и режимов поддержки определяется конкретным выпуском и его поставщиком: их нельзя считать полностью идентичными RHEL без такой проверки.

В Ubuntu обычно поставляется и используется AppArmor; Debian также поддерживает AppArmor, но фактическое наличие профилей и состояние службы зависят от выпуска и установленной конфигурации. В RHEL штатным механизмом мандатного контроля доступа обычно является SELinux. Оба механизма используют каркас Linux Security Modules, но не взаимозаменяемы по модели политик и инструментам.

Обычные штатные механизмы; подтверждайте их для конкретного релиза ОС

Задача	Ubuntu	Debian	RHEL и совместимые системы
Пакеты и обновления	APT; автоматизация обычно через `unattended-upgrades`	APT; автоматизация обычно через `unattended-upgrades`	DNF; автоматизация обычно через `dnf-automatic`
MAC-контроль	AppArmor	AppArmor поддерживается и может быть установлен или включён	SELinux
Firewall-фронтенд	UFW доступен как типичный фронтенд	Netfilter; применимый фронтенд зависит от выпуска и выбранной конфигурации	firewalld — обычный поддерживаемый фронтенд
Низкоуровневый стек firewall	Netfilter, обычно через nftables-совместимый стек	Netfilter; соотношение nftables и iptables зависит от выпуска	Netfilter; актуальные выпуски обычно используют nftables как backend для firewalld

Проверяйте документацию именно своего выпуска

Имена пакетов, журналов, unit-файлов, доступные параметры и поведение утилит зависят от семейства, версии ОС, ядра, репозиториев и уже установленной конфигурации. Перед изменением сверяйте их с официальной документацией Ubuntu, Debian, Red Hat или поставщика совместимого дистрибутива. Это относится и к срокам поддержки: актуальный статус security updates нужно смотреть в таблицах жизненного цикла Ubuntu, Debian и Red Hat; он зависит от версии релиза и, для части продуктов Red Hat, от подписки. Не используйте неподдерживаемую ветку CentOS для нового сервера без отдельно принятого и документированного риска.

Чек-лист hardening Linux: безопасная последовательность

Применение security baseline к новому серверу

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

1
Определите роль сервера и допустимые изменения
Запишите назначение хоста, владельца, критичность, опубликованные сервисы, администраторов, источники подключений, зависимости от DNS, времени, хранилищ, каталогов, очередей и внешних API. Для каждого открытого порта и привилегированной учётной записи должен быть ответственный и рабочее обоснование. Это исходный материал для базовой конфигурации безопасности, а не перечень универсальных запретов.
2
Зафиксируйте исходное состояние
Сохраните сведения об ОС, ядре, пакетах, сетевых слушателях, unit-файлах, учётных записях, текущих правилах firewall, статусе MAC и конфигурации приложения. Экспортируйте работающие конфигурации и определите, где находятся резервные копии. Ожидаемый результат — снимок, с которым можно сравнить состояние после изменения и по которому понятен откат.
3
Подготовьте аварийный доступ и проверки отката
Проверьте вход через независимый канал управления и оставьте текущую SSH-сессию открытой. Определите, как вернуть прежний файл конфигурации, включить остановленную службу или восстановить предыдущие firewall-правила. Проверьте, что отдельная аварийная учётная запись, если она предусмотрена, контролируется и не является общей постоянной привилегированной учётной записью.
4
Проверьте поддержку ОС и установите плановые обновления
Убедитесь, что релиз получает security updates, проверьте настроенные репозитории и предварительный план пакетной транзакции. Устанавливайте обновления в согласованное окно с учётом перезапусков сервисов и возможной перезагрузки ядра. Автоматизацию обновлений включайте только после определения уведомлений, журналов и порядка обработки перезагрузок.
5
Сократите поверхность атаки
Сопоставьте работающие службы, сокеты, таймеры, задания и локальные учётные записи с ролью хоста. Отключайте или удаляйте только подтверждённо ненужные компоненты, по одному логическому изменению. До отключения проверьте зависимости приложения, мониторинга, резервного копирования и средств управления.
6
Ограничьте административный и сетевой доступ
Сначала подтвердите рабочий вход по SSH в новой сессии, затем меняйте политику SSH и firewall. Разрешения должны отражать реально нужные административные и прикладные потоки; правила для IPv4 и IPv6 оценивайте отдельно. Не создавайте независимые наборы правил одновременно через UFW, firewalld, ручные nftables и iptables-команды.
7
Сохраните или включите штатный MAC-контроль
На Ubuntu и Debian проверьте AppArmor и применимые профили; на RHEL и совместимых системах — SELinux и режим политики. Не отключайте MAC глобально для устранения ошибки приложения: сначала установите, какой процесс и какая операция были заблокированы, затем исправьте конфигурацию, метку, Boolean или профиль по процедуре дистрибутива.
8
Оцените sysctl и параметры ядра
Рассматривайте каждый параметр относительно роли сервера и фактической нагрузки. Сначала примените изменение временно или на тестовом хосте, затем проверьте сеть, приложение и мониторинг; только после этого решайте вопрос о постоянной конфигурации. Не переносите готовый sysctl.conf из чужого чек-листа.
9
Настройте аудит и контроль изменений
Определите сценарии, которые нужны для расследования: входы, изменения привилегий, изменения критичных файлов и конфигурации, действия администраторов. Проверьте, что журналы создаются, имеют достаточно места, ротируются и доступны владельцу процесса расследования. При необходимости добавьте контроль целостности и централизованный сбор.
10
Зафиксируйте отклонения и назначьте повторную проверку
Сохраните итоговую конфигурацию, результаты проверок, владельцев правил и обоснованные исключения. Повторяйте оценку после обновления ОС, изменения роли хоста, публикации нового сервиса, смены firewall-политики, установки агента или существенной конфигурации приложения.

Снимите исходное состояние до первого ограничения

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

Фиксирует семейство и выпуск ОС, версию работающего ядра и идентичность хоста. Если `hostnamectl` отсутствует или работает в ограниченной среде, сохраните доступные поля из `/etc/os-release` и `uname`.

cat /etc/os-release; uname -r; hostnamectl

Показывает запущенные службы и unit-файлы, включённые для автозапуска. Отдельно просматривайте сокеты и таймеры: служба может запускаться по запросу или расписанию.

systemctl list-units --type=service --state=running; systemctl list-unit-files --state=enabled

Вывод:

Ожидаемый результат: список unit-файлов для сверки с ролью сервера. Неизвестный unit — повод определить пакет-владельца, назначение и зависимые сервисы, а не немедленно отключать его.

Показывает socket activation, таймеры systemd и слушающие TCP/UDP-сокеты. Сведения о связанных процессах в выводе `ss` могут быть неполными без root или соответствующих capabilities. Сверьте каждый внешний слушатель с реестром опубликованных сервисов.

systemctl list-units --type=socket --all; systemctl list-timers --all; ss -lntup

Показывает системную таблицу cron, файлы периодических заданий и crontab текущей учётной записи. Прочитайте найденные файлы и с достаточными правами отдельно проверьте crontab административных и сервисных пользователей через `crontab -u <пользователь> -l`. Учитывайте также планировщики внутри приложений и контейнерных платформ: они не отображаются как systemd timers или задания cron.

cat /etc/crontab 2>/dev/null; ls -la /etc/cron.d /etc/cron.{hourly,daily,weekly,monthly} 2>/dev/null; crontab -l

Показывает учётные записи и группы, которые настроенные источники NSS допускают перечислить, а также фактические права конкретного пользователя через sudo. Локальные записи отдельно сверяйте с `/etc/passwd` и `/etc/group`; каталоговые источники могут не поддерживать полное перечисление. Подставляйте существующее имя пользователя и выполняйте команду с правами, достаточными для просмотра политики.

getent passwd; getent group; sudo -l -U <пользователь>

Для unit-файлов важно различать состояния. Остановка службы прекращает её сейчас, отключение убирает обычный автозапуск, а маскирование делает запуск unit невозможным, включая запуск зависимостью, пока маска не снята. Маскирование применяйте только когда уверены, что такой запуск недопустим. После изменения проверяйте и состояние unit, и функцию, которую он обслуживал.

Для каждой необходимой службы проверьте, от какой учётной записи и групп она работает, какие capabilities получает, к каким файлам, каталогам и сокетам имеет доступ. Сокращайте привилегии только после проверки штатного сценария и зависимостей: произвольная смена пользователя службы, удаление capability или включение ограничений systemd может нарушить запуск, обновление либо доступ приложения к данным. Итоговые права и обоснованные исключения включайте в baseline.

Проверка после каждого этапа

Успешный код возврата пакетного менеджера, systemctl или firewall-клиента подтверждает только выполнение операции. Эффективное состояние нужно проверять отдельной командой и внешним тестом с точки зрения пользователя или зависимого узла.

Минимальный набор проверок после изменения

Что изменили	Что проверить	Если проверка не пройдена
Обновления	Версии пакетов, состояние нужных служб, необходимость перезагрузки, журнал пакетного менеджера	Не продолжать baseline; изучить транзакцию, восстановить сервис или применить утверждённый откат
Служба, сокет, таймер	`systemctl status`, список слушающих портов, функцию приложения и мониторинг	Вернуть unit в предыдущее состояние, если отключённая функция необходима
Учётные записи и sudo	Вход отдельным тестовым пользователем, `sudo -l`, выполнение разрешённой административной операции	Использовать сохранённую аварийную сессию и исправить правило через `visudo`
SSH и firewall	Новое SSH-подключение с разрешённого источника, доступность опубликованного сервиса, итоговые правила	Не закрывать рабочую сессию; восстановить предыдущие правила через консольный канал
AppArmor или SELinux	Режим MAC, журналы отказов, штатный сценарий приложения	Разобрать отказ и исправить политику или конфигурацию; не отключать MAC как постоянное решение
sysctl	`sysctl` для эффективного значения, DNS, сетевую связность, работу приложения и агентов	Вернуть прежнее значение и документировать несовместимость
auditd и журналы	Статус службы, поступление тестовых событий, доступное место и ротацию	Исправить правила, права, хранение или объём до включения дополнительных событий

Запускайте с отдельного административного узла после каждого изменения доступа и проходите предусмотренную схему аутентификации. Ожидаемый результат — успешное подключение, ожидаемое имя хоста и нужная учётная запись. Для автоматической проверки ключевого входа без интерактивных факторов можно отдельно использовать `BatchMode=yes`, но такой тест не подходит для парольной аутентификации и схем, требующих интерактивного подтверждения.

ssh -o ConnectTimeout=10 <администратор>@<сервер> 'hostname; id'

Проверяет разрешение имени через настроенные NSS/DNS-источники, состояние времени и общее состояние systemd. Статус `degraded` требует определить неудавшийся unit; он не всегда означает недоступность основной функции, но игнорировать его нельзя.

getent hosts <имя_зависимости>; timedatectl status; systemctl is-system-running

Проверку прикладного сервиса выполняйте его реальным сценарием: запросом к адресу проверки работоспособности, тестовой транзакцией, подключением клиента или предусмотренной командой диагностики. Проверка открытого порта недостаточна: процесс может слушать сокет, но возвращать ошибки из-за прав, MAC-политики, DNS, времени или недоступной зависимости.

Обновления безопасности Linux и поддержка релиза

Перед обновлением проверьте, что выпуск ОС ещё поддерживается, репозитории доступны и транзакция не затронет удержанные либо критичные пакеты неожиданным образом. В Ubuntu и Debian механизм unattended-upgrades может автоматически устанавливать подходящие обновления из настроенных источников. В RHEL-совместимых системах аналогичную роль обычно выполняет dnf-automatic. Их доступность и конкретное поведение зависят от выпуска, установленных пакетов и репозиториев.

Типичная проверка доступных обновлений в Ubuntu и Debian. Список требует анализа: он не обязательно состоит только из security-пакетов.

apt update && apt list --upgradable

Типичная проверка доступных обновлений в RHEL и совместимых системах. Код возврата, означающий наличие обновлений, не равен ошибке; интерпретируйте его по документации DNF используемого выпуска.

dnf check-update

После установки подтвердите версии, состояние сервисов и перезагрузку, если она нужна для ядра или обновлённых библиотек. Планирование патчей, настройка unattended-upgrades и dnf-automatic, а также безопасная перезагрузка разобраны в статье «Обновления безопасности Linux: APT, DNF, автоматизация и окно обслуживания».

Доступ, SSH, sudo и firewall в baseline

Защита учётных записей строится на персональных административных аккаунтах, минимальных правах sudo и контролируемом аварийном доступе. Не передавайте общий пароль root и не проверяйте изменение sudo в единственной сессии. Детальная настройка пользователей, PAM, парольной политики и sudo приведена в статье «Учётные записи, sudo и парольная политика в Linux».

SSH меняйте только после проверки ключевого или иного предусмотренного метода входа в новой сессии. Ограничения root-входа, паролей, пользователей, ключей и forwarding требуют отдельной процедуры: «Безопасная настройка SSH: ключи, root и ограничение доступа».

Firewall реализует сетевую часть baseline: он ограничивает входящие и при необходимости исходящие потоки согласно роли сервера, но не заменяет аутентификацию, обновления и контроль прав. Политику запрета по умолчанию проектируют после инвентаризации разрешённых потоков, а не включают до разрешения административного доступа.

Один источник управления правилами

Не управляйте одной политикой независимо через UFW, firewalld, ручные nftables-команды, iptables и скрипты приложения. Они используют стек Netfilter, но могут перезаписывать правила или создавать неочевидный итоговый ruleset. Выберите один поддерживаемый способ управления и проверяйте именно его фактический результат.

Показывает эффективный набор правил nftables, если утилита установлена. На системах с иным стеком или фронтендом дополнительно используйте документированную команду выбранного менеджера: например, статус UFW или firewalld.

nft list ruleset

Для Ubuntu UFW является распространённым фронтендом. В RHEL-совместимых системах обычно применяется firewalld, различающий runtime- и permanent-конфигурацию. Debian может использовать чистый nftables или другой выбранный фронтенд в зависимости от выпуска и конфигурации. Проектирование правил — в «Firewall сервера: default deny, порядок правил и политика доступа»; практические шаги для UFW и firewalld — в «UFW и firewalld: настройка firewall в Ubuntu и RHEL», для nftables — в «Настройка nftables: правила, sets, IPv6 и диагностика», для iptables — в «Настройка iptables: открыть порт, ограничить доступ и сохранить правила».

SELinux и AppArmor: сохраняйте штатный слой MAC

SELinux и AppArmor дополняют обычную модель владельцев и прав файлов Linux: разрешение на уровне DAC не гарантирует, что действие разрешит MAC-политика. На RHEL-совместимых системах проверьте режим SELinux и не переводите систему в Disabled ради удобства. На Ubuntu и Debian проверьте, загружены ли профили AppArmor и ограничивают ли они нужные сервисы. Режим, политики и набор утилит зависят от версии дистрибутива и установленных пакетов.

Типичная проверка режима SELinux в RHEL-семействе. Ожидаемый результат для защищаемого штатного сценария обычно — Enforcing, если политика совместима с ролью сервера. Недоступность команды может означать отсутствие установленного набора SELinux-утилит; сначала уточните конфигурацию ОС.

getenforce; sestatus

Показывает состояние AppArmor и загруженные профили, если утилита доступна. Результат сопоставляйте с назначением сервера и журналами отказов.

aa-status

Для диагностики допустим временный контролируемый режим, который позволяет собрать сведения об отказах, но он не должен становиться постоянным обходом. SELinux, контексты и AVC рассматриваются в «SELinux на сервере: Enforcing, контексты, Boolean-переменные и устранение отказов»; жизненный цикл профиля AppArmor — в «AppArmor на сервере: профили, режимы enforce и диагностика отказов».

sysctl и Linux kernel hardening: оценивайте эффект до закрепления

Параметры sysctl изменяют поведение ядра во время работы. В baseline обычно рассматривают защитные параметры файловой системы, управление core dump процессов, ASLR и сетевые параметры IPv4/IPv6. Но это не универсальный набор значений: часть настроек способна изменить маршрутизацию, обработку пакетов, работу контейнеров, отладку, мониторинг или поведение приложения.

Снимает доступные текущие параметры ядра для инвентаризации. Не используйте вывод как список параметров, которые нужно менять: многие из них относятся к конкретным подсистемам и драйверам.

sysctl -a 2>/dev/null | less

Проверяет эффективное значение одного параметра перед и после изменения. Подставьте конкретный параметр, предварительно подтвердив его назначение в документации ядра и совместимость с ролью сервера.

sysctl <параметр>

Не переносите чужой sysctl.conf и не применяйте найденные значения массово через sysctl --system. Сначала определите требуемый эффект, оцените затронутые компоненты, испытайте изменение и проверьте сетевую связность, DNS, IPv4/IPv6 при использовании, контейнеры и прикладной сценарий. Если эффект не соответствует ожидаемому, верните предыдущее значение и оформите исключение либо альтернативный контроль.

Аудит, журналы и контроль целостности

auditd дополняет systemd journal, журналы аутентификации и логи приложений, но не заменяет их. Начинайте не с включения максимального числа правил, а со сценариев: вход администратора, изменение учётной записи, изменение конфигурации сервиса, прав или критичных файлов. Слишком широкие правила создают нагрузку и поток записей, в котором трудно заметить значимое событие.

Проверяет состояние службы Linux Audit и параметры подсистемы, если auditd установлен. Ожидаемый результат — работающий сервис и доступное состояние аудита. При ошибке сначала проверьте пакет, unit и журнал службы.

systemctl status auditd --no-pager; auditctl -s

Пути журналов зависят от дистрибутива и конфигурации. В типичных Debian и Ubuntu события аутентификации часто пишутся в /var/log/auth.log, в RHEL-семействе — в /var/log/secure; Linux Audit часто использует /var/log/audit/audit.log. Однако journald, rsyslog, настройки auditd и ротация могут изменить это поведение, поэтому подтверждайте фактические источники на хосте. Правила аудита, хранение и поиск событий разобраны в «Аудит безопасности Linux: auditd, журналы входов и контроль действий»; внешнее хранение — в «Централизованный сбор журналов безопасности: события, корреляция и оповещения».

Контроль целостности файлов полезен для выбранных критичных объектов, но его доверенная база должна быть создана на заведомо контролируемой системе и пересматриваться после легитимных изменений. Это отдельный слой, а не доказательство отсутствия компрометации. Границы AIDE, проверки пакетов и rootkit-сканеров описаны в «Антивирус и контроль целостности сервера: Defender, ClamAV, AIDE и rootkit-проверка».

CIS Benchmark, OpenSCAP и Lynis: использовать для оценки, а не как кнопку настройки

CIS Benchmark, OpenSCAP и Lynis помогают выявить расхождения и сформировать очередь проверки. Они не знают автоматически о всех зависимостях конкретного сервера. Профиль CIS или SCAP должен соответствовать точному семейству и выпуску ОС, а также выбранному уровню жёсткости; CIS Benchmark для Ubuntu не следует применять как профиль для Debian или RHEL.

Не запускайте автоматический remediation без анализа

Автоматическое исправление по SCAP, CIS или сканеру может изменить SSH, firewall, PAM, sysctl, права, загрузку служб и параметры аудита. Сначала просмотрите отчёт, сопоставьте каждую находку с ролью сервера, испытайте исправления на представительной системе и подготовьте откат. Результат сканера — сигнал для проверки, а не доказательство небезопасности или готовая конфигурация.

Как документировать исключения и предотвращать конфигурационный дрейф

Не каждое отклонение от baseline является ошибкой. Например, сервису может быть нужен нестандартный порт, дополнительная capability, исключение MAC-политики или sysctl-параметр для контейнерной нагрузки. Но исключение должно быть управляемым: иначе оно становится конфигурационным дрейфом и ухудшает конфигурационное соответствие.

Характеристика	Значение
Объект и параметр	Хост, сервис, правило, файл, sysctl-параметр или контроль, от которого есть отклонение
Причина	Подтверждённая техническая или бизнес-зависимость, а не общее «иначе не работает»
Риск	Что именно ослабляется и какой остаточный риск принимается
Компенсирующая мера	Например, ограничение источников, дополнительный аудит, сегментация или контроль доступа
Владелец и срок пересмотра	Кто подтверждает исключение и когда его нужно оценить повторно
Проверка	Как подтвердить, что исключение всё ещё необходимо и не расширилось сверх согласованной области

ХарактеристикаОбъект и параметр

ЗначениеХост, сервис, правило, файл, sysctl-параметр или контроль, от которого есть отклонение

ХарактеристикаПричина

ЗначениеПодтверждённая техническая или бизнес-зависимость, а не общее «иначе не работает»

ХарактеристикаРиск

ЗначениеЧто именно ослабляется и какой остаточный риск принимается

ХарактеристикаКомпенсирующая мера

ЗначениеНапример, ограничение источников, дополнительный аудит, сегментация или контроль доступа

ХарактеристикаВладелец и срок пересмотра

ЗначениеКто подтверждает исключение и когда его нужно оценить повторно

ХарактеристикаПроверка

ЗначениеКак подтвердить, что исключение всё ещё необходимо и не расширилось сверх согласованной области

Перепроверяйте baseline после обновления ОС или ядра, изменения репозиториев, смены роли хоста, установки нового сервиса, изменения опубликованных портов, перехода на другой firewall-фронтенд и существенных изменений приложения. Также назначьте регулярную периодическую проверку: сравнивайте фактические службы, слушающие порты, учётные записи, правила firewall, режим MAC, sysctl и аудит с утверждённым эталоном.

Термины в статье

AppArmor: AppArmor — система мандатного контроля доступа Linux, ограничивающая программы профилями; профиль обычно выбирается по пути исполняемого файла, а файловые правила сопоставляются с путями.
CIS Benchmark: CIS Benchmark — набор рекомендаций CIS по безопасной конфигурации конкретной ОС, платформы или сервиса с проверяемыми параметрами и уровнями жёсткости.
Hardening: Hardening — процесс усиления защищённости системы через отключение лишних функций, ограничение доступа и настройку безопасных параметров для снижения доступной поверхности атаки.
Linux Security Modules: Linux Security Modules — каркас ядра Linux для подключения модулей контроля доступа, перехватывающих операции с объектами системы по заданным политикам.
Lynis: Lynis — инструмент аудита защищённости Unix-подобных систем, проверяющий настройки ОС и служб по набору тестов и выдающий рекомендации по усилению конфигурации.
Netfilter: Netfilter — подсистема ядра Linux для перехвата и обработки сетевых пакетов в контрольных точках стека; правила iptables и nftables используют её механизмы.
OpenSCAP: OpenSCAP — набор открытых инструментов и библиотек для обработки SCAP-контента, оценки конфигураций и формирования отчётов о соответствии заданным правилам.
UFW: UFW — утилита упрощённого управления правилами межсетевого экрана в Linux, создающая правила Netfilter по командам высокого уровня.
auditd: auditd — служба Linux Audit, принимающая от ядра сообщения аудита, в том числе отобранные по правилам, и записывающая их в журнал для расследований, анализа доступа и проверки соответствия.
firewalld: firewalld — служба управления межсетевым экраном в Linux, применяющая правила через зоны, сервисы и политики без прямого редактирования полного набора правил.
iptables: iptables — утилита Linux для управления правилами пакетной фильтрации Netfilter через таблицы, цепочки и цели; это не самостоятельный межсетевой экран.
nftables: nftables — подсистема Linux и интерфейс управления правилами Netfilter, использующие единый набор правил, выражения, множества и атомарное обновление конфигурации.
Базовая конфигурация безопасности: Базовая конфигурация безопасности — утверждённый набор обязательных параметров защиты для однотипных систем, используемый как эталон развёртывания и контроля отклонений.
Запрет по умолчанию: Запрет по умолчанию — политика контроля доступа, при которой разрешаются только явно разрешённые правилами обращения или действия, а всё остальное блокируется.
Конфигурационное соответствие: Конфигурационное соответствие — степень, в которой фактические параметры ИТ-объекта отвечают утверждённой политике, шаблону или базовой линии.
Конфигурационный дрейф: Конфигурационный дрейф — накопившееся отклонение фактической конфигурации системы от утверждённого эталона вследствие несогласованных или незафиксированных изменений.
Межсетевой экран: Межсетевой экран — средство контроля сетевого трафика, разрешающее или блокирующее его по правилам на границе или между сегментами сети.
Поверхность атаки: Поверхность атаки — совокупность точек, через которые можно воздействовать на систему или получить к ней доступ; включает интерфейсы, учётные записи, ПО и зависимости.