Регламент аудита безопасности Linux-серверов: структура и ключевые проверки

Регламент аудита безопасности Linux-серверов должен описывать четыре вещи: какие узлы проверяют, кто отвечает за проверку и исправления, какие команды используют, как оценивают находки и контролируют их закрытие. Минимальный технический охват включает учетные записи и привилегии, SSH-доступ, обновления, права на файлы и каталоги, журналы событий, сетевые настройки и состояние сервисов.

Практичный регламент превращает ручную проверку в повторяемую процедуру. Администратор получает единый чек-лист, аудитор фиксирует доказательства по каждому пункту, а руководитель видит сопоставимые результаты по серверам. В статье приведен готовый каркас документа, примеры формулировок, команды Linux и шаблон приложения, который можно адаптировать под Debian, Ubuntu, RHEL или CentOS.

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

Зачем нужен регламент аудита безопасности Linux-серверов

Проверка без единого регламента зависит от опыта конкретного администратора. Один специалист смотрит только SSH и firewall, другой дополнительно проверяет права на файлы и журналы, третий ограничивается отчетом сканера. Результаты таких проверок трудно сравнивать, а пропущенные пункты обнаруживаются уже после инцидента.

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

• Стандартизация: одинаковые серверы проверяют по одинаковым правилам.
• Воспроизводимость: другой специалист может повторить команды и подтвердить результат.
• Сопоставимость: состояние нескольких узлов сравнивают по единой шкале.
• Автоматизация: команды из чек-листа можно объединить в Ansible-задачу, shell-проверку или job в CI/CD.
• Контроль рисков: каждая находка получает владельца, приоритет и срок устранения.
• Доказательная база: отчет содержит конфигурации, вывод команд, дату проверки и сведения о сервере.

Фраза «сервер защищен» не дает проверяемого результата. Формулировка «в конфигурации SSH параметр PermitRootLogin имеет значение no, а подтверждение сохранено в отчете» задает конкретный критерий.

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

Структура регламента: обязательные разделы

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

Область применения и цели

В начале регламента укажите, какие Linux-серверы попадают под контроль. Перечислите продуктивные, тестовые, резервные и пограничные узлы, если для них действуют разные правила.

• дистрибутивы и поддерживаемые версии;
• виртуальные машины, физические серверы и облачные экземпляры;
• серверные роли: web, database, proxy, monitoring, backup, Kubernetes-ноды;
• сегменты сети и зоны с особыми требованиями;
• исключения, компенсирующие меры и порядок согласования исключений.

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

Пример формулировки:

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

Роли и ответственность

Названия ролей должны описывать конкретную ответственность. Общего указания «ИТ-отдел отвечает за безопасность» недостаточно.

Для каждого сервера назначьте владельца и резервного ответственного. В отчете храните имена или идентификаторы ролей, дату назначения, срок исправления и статус задачи.

Периодичность и условия внеплановых проверок

Периодичность зависит от критичности узла и скорости изменений. Для продуктивных серверов часто используют квартальный полный аудит и более частые автоматические проверки ключевых параметров. Тестовые узлы проверяют при создании, перед переносом в продуктивную среду и после значительных изменений.

Внеплановый аудит запускают после:

• подозрения на компрометацию или подтвержденного инцидента;
• изменения SSH, firewall, IAM, системы журналирования или гипервизора;
• установки нового публичного сервиса;
• смены владельца сервера или критичной серверной роли;
• обнаружения уязвимости, затрагивающей используемый пакет;
• восстановления узла из резервной копии или образа.

График должен учитывать доступность специалистов. Еженедельный ручной аудит сотен серверов быстро превращается в формальную отметку. Для частых проверок автоматизируйте сбор фактов, а ручную работу оставьте для анализа отклонений и принятия решений.

В регламенте укажите минимальный набор входных данных: имя узла, IP-адрес или инвентарный идентификатор, дистрибутив, версию ядра, роль, владельца, дату последнего изменения и окно допустимого влияния на сервис.

Ключевые области проверки безопасности Linux-серверов

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

Учетные записи и привилегии

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

Найдите учетные записи с UID 0:

awk -F: '($3==0){print $1}' /etc/passwd

В нормальной конфигурации UID 0 нужен только root, если отдельная учетная запись не согласована отдельно. Получите список локальных пользователей:

awk -F: '$3 >= 1000 && $1 != "nobody" {print $1, $3, $7}' /etc/passwd

Проверьте сроки действия паролей и состояние учетных записей:

chage -l имя_пользователя
passwd -S имя_пользователя

В отчете фиксируйте:

• неиспользуемые и заблокированные учетные записи;
• пользователей с интерактивной оболочкой, которым она не нужна;
• членство в группах sudo, wheel, docker и других привилегированных группах;
• наличие общих учетных записей и технических пользователей;
• правила выдачи, отзыва и периодического пересмотра доступа.

Проверьте конфигурацию sudo:

visudo -c
cat /etc/sudoers
grep -R -v '^#' /etc/sudoers.d 2>/dev/null | grep -v '^$'

Предпочтительны адресные правила для конкретных команд и групп. Запись с разрешением выполнять любые команды без пароля требует отдельного обоснования. Членство в группе docker фактически дает пользователю возможности, сопоставимые с доступом к root, поэтому его нужно включать в аудит привилегий.

SSH-доступ

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

Проверьте эффективную конфигурацию, а не только содержимое одного файла:

sshd -T
sshd -t
grep -E '^(PermitRootLogin|PasswordAuthentication|PubkeyAuthentication|AllowUsers|AllowGroups|MaxAuthTries|ClientAliveInterval|ClientAliveCountMax)' /etc/ssh/sshd_config

Базовые критерии для публичного сервера:

• PermitRootLogin no, если прямой вход root не нужен для аварийной процедуры;
• PasswordAuthentication no после проверки доступа по ключам и наличия резервного канала управления;
• PubkeyAuthentication yes для ключевой аутентификации;
• ограничение доступа через AllowUsers или AllowGroups;
• разумные значения MaxAuthTries, ClientAliveInterval и ClientAliveCountMax;
• отсутствие устаревших алгоритмов, если они не нужны для совместимости.

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

Зафиксируйте в регламенте порядок хранения и отзыва ключей, срок пересмотра authorized_keys, требования к passphrase и способ подтверждения экстренного доступа.

Актуальность обновлений

Аудит обновлений должен отвечать на два вопроса: получает ли сервер пакеты из разрешенных репозиториев и установлены ли доступные исправления безопасности.

Для Debian и Ubuntu используйте:

apt update
apt list --upgradable
apt-cache policy

Для RHEL и CentOS применяйте команды с учетом версии пакетного менеджера:

yum check-update
dnf check-update
yum repolist
dnf repolist

Проверяйте:

• дату последнего обновления индексов пакетов;
• наличие доступных security-обновлений;
• состояние репозиториев и их происхождение;
• наличие пакетов, которые требуют перезагрузки;
• политику автоматической установки критичных исправлений;
• сроки обновления ядра, OpenSSL, OpenSSH, web-сервера и других внешних компонентов.

Автоматические обновления снижают окно риска, но не отменяют контроль совместимости. Для критичных приложений регламент должен описывать тестирование, окно работ, резервное копирование и проверку после перезагрузки.

Права на файлы и каталоги

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

Критичные системные файлы обычно проверяют так:

stat /etc/passwd /etc/shadow /etc/group /etc/sudoers
ls -l /etc/passwd /etc/shadow /etc/group /etc/sudoers
getfacl /etc/passwd /etc/shadow /etc/sudoers 2>/dev/null

Найдите файлы с SUID и SGID:

find / -xdev -type f -perm /6000 -ls 2>/dev/null

Проверьте world-writable файлы и каталоги:

find / -xdev -type f -perm -0002 -ls 2>/dev/null
find / -xdev -type d -perm -0002 -ls 2>/dev/null

Каждый найденный SUID/SGID-файл сравнивайте с эталонным перечнем для конкретного дистрибутива. Сам факт наличия специального бита не всегда означает нарушение. Риск появляется, когда бинарник лишний, устарел, принадлежит неправильному владельцу или доступен через небезопасный каталог.

Отдельно проверяйте каталоги с резервными копиями, секретами, SSH-ключами, файлами окружения и конфигурациями приложений. Для временных каталогов оцените sticky bit, например режим 1777 для /tmp, если это предусмотрено политикой системы.

Журналы событий

Логирование должно позволять восстановить последовательность действий: кто вошел, откуда, какие привилегированные команды выполнил и какие службы изменили состояние. Проверьте, используется ли journald, rsyslog или другая схема, куда попадают события и кто может удалять или менять журналы.

systemctl is-active systemd-journald
systemctl is-active rsyslog
journalctl --disk-usage
journalctl -p warning..alert --since today
journalctl _COMM=sshd --since yesterday

В конфигурации аудита проверьте:

• входы, неудачные попытки аутентификации и операции sudo;
• события cron, systemd и запуск критичных служб;
• изменения учетных записей, групп и привилегий;
• ротацию, срок хранения и ограничение размера журналов;
• синхронизацию времени через утвержденный источник;
• передачу копий на отдельный сервер, если локальный журнал нельзя считать достаточным доказательством.

Проверьте права на каталоги и файлы журналов. Пользователь, который может без ограничений удалить auth.log или очистить journal, способен скрыть следы действий. Для критичных систем задайте оповещения о повторных неудачных входах, изменении sudoers, остановке журналирования и резком росте ошибок.

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

Сетевой аудит сопоставляет фактическое состояние узла с утвержденными потоками. Список открытых портов без понимания назначения сервиса дает неполную картину.

ss -tulpn
ss -s
ip addr
ip route

В отчете для каждого слушающего порта укажите процесс, пакет, владельца сервиса, интерфейс, источник разрешенного подключения и необходимость доступа из внешней сети.

Проверьте активный firewall. Набор команд зависит от используемого инструмента:

systemctl is-active firewalld
firewall-cmd --list-all
nft list ruleset
iptables -S

Критерии проверки:

• политика по умолчанию запрещает ненужный входящий трафик;
• разрешены только утвержденные порты и источники;
• правила сохранены после перезагрузки;
• административный доступ ограничен доверенной сетью или bastion-хостом;
• неиспользуемые интерфейсы, маршруты и сетевые службы отключены;
• правила firewall документированы и связаны с владельцами сервисов.

Для облачного сервера проверяйте сразу два уровня: локальный firewall и правила безопасности у провайдера. Например, облачный VDS можно использовать для отдельного тестового стенда, но сетевые ограничения самого сервера и правила внешней инфраструктуры нужно описывать раздельно. Для размещения Linux-узлов и Kubernetes-кластеров подойдет облачная инфраструктура Timeweb Cloud, если ее параметры включены в общую модель контроля.

Состояние сервисов

Каждая активная служба расширяет поверхность атаки. Список запущенных сервисов сравнивают с назначением сервера, заявкой на установку и картой зависимостей.

systemctl list-units --type=service --state=running
systemctl list-unit-files --type=service --state=enabled
systemctl --failed
systemctl status имя_сервиса

Для каждого сервиса зафиксируйте:

• зачем он нужен и кто владелец;
• под какой учетной записью он работает;
• какие порты открывает;
• какие файлы и каталоги читает или изменяет;
• как он получает обновления;
• какие ограничения systemd применяются: sandboxing, capability bounding set, private temporary directory;
• что происходит после сбоя и перезагрузки.

Ненужные службы отключайте только после проверки зависимостей. Команда systemctl disable --now меняет состояние немедленно, поэтому действие должно проходить через окно работ или тестовую среду. Для публичных web-сервисов отдельно проверяйте конфигурацию TLS, права рабочего пользователя, доступ к секретам и формат журналов.

Критерии оценки и приоритизация находок

Единая шкала нужна, чтобы два аудитора одинаково оценивали похожие нарушения. Приоритет определяют по сочетанию влияния, вероятности эксплуатации, доступности сервиса, наличия компенсирующих мер и сложности исправления.

Сроки из таблицы нужно закрепить в политике организации. Для критичной системы допустимый срок может быть короче, а для изолированного лабораторного узла применяют компенсирующие меры и отдельную оценку.

Примеры классификации находок

Критический риск: в /etc/ssh/sshd_config задано PermitRootLogin yes, а сервер доступен из интернета. Такое отклонение дает прямой путь к подбору или компрометации учетных данных root. Действия: ограничить доступ, запретить прямой вход, проверить журналы и ключи, повторить аудит.

Высокий риск: на сервере доступен устаревший пакет OpenSSH с известной уязвимостью, а обновления задержаны. Действия: проверить применимость уязвимости, установить исправление, перезапустить службу при необходимости, сохранить версию пакета и подтверждение проверки.

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

Низкий риск: на сервере отсутствует баннер SSH или не задан необязательный параметр таймаута. Такие пункты исправляют в плановом порядке, если они не нарушают внутреннюю политику.

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

Обработка результатов аудита: отчет и устранение

Отчет должен позволять перейти от факта к действию. Для каждой находки укажите сервер, компонент, проверяемое требование, фактическое значение, ожидаемое значение, риск, доказательство, владельца, срок и критерий закрытия.

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

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

Контроль устранения и закрытие находок

Находка закрывается после повторной проверки, а не после сообщения исполнителя. В тикет приложите новую конфигурацию, вывод команды, номер изменения и дату проверки.

1. Аудитор согласует формулировку нарушения и приоритет.
2. Владелец сервера назначает исполнителя и срок.
3. Исполнитель меняет настройку и проверяет доступность сервиса.
4. Аудитор повторяет исходную проверку тем же способом.
5. Ответственный закрывает задачу или продлевает риск с письменным обоснованием.

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

Типичные ошибки при составлении регламента и как их избежать

Регламент часто теряет практическую ценность не из-за отсутствия технических терминов, а из-за расплывчатых требований и отсутствия последующих действий.

Общие формулировки вместо проверяемых требований

Фраза «проверить SSH» не описывает результат. Замените ее набором измеримых пунктов:

• проверить эффективное значение PermitRootLogin через sshd -T;
• зафиксировать разрешенные группы в AllowGroups;
• проверить способ аутентификации и резервный канал доступа;
• сохранить вывод команды и дату проверки.

Каждый пункт должен иметь ожидаемое значение или допустимый диапазон.

Нет критериев оценки и приоритизации

Без единой шкалы один аудитор назовет отсутствие обновлений критическим риском, а другой запишет его как замечание. В регламенте задайте признаки уровней, максимальный срок исправления и правила учета компенсирующих мер.

Размытая ответственность

Формулировка «администратор устраняет проблему» создает спор о том, кто именно отвечает за сервер, пакет, сетевое правило или приложение. Используйте матрицу ролей и назначайте конкретного владельца каждой находке.

Нереалистичная периодичность

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

Регламент не описывает обработку результатов

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

Приложения к регламенту: чек-листы и шаблоны

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

Пример чек-листа аудита безопасности Linux-сервера

В шаблоне отчета добавьте поля для версии ОС, ядра, даты проверки, имени аудитора, окна работ, списка исключений и ссылок на тикеты. Для каждой команды храните пример ожидаемого вывода, если это помогает быстрее обнаруживать отклонения.

Внедрение и поддержание регламента в актуальном состоянии

Начните с пилотной проверки нескольких серверов с разными ролями. Возьмите публичный web-узел, внутренний сервер приложений, базу данных и тестовую машину. Такой набор выявит требования, которые подходят одной роли, но мешают другой.

1. Составьте первую версию регламента и чек-листа.
2. Проведите пилотный аудит и сохраните исходные доказательства.
3. Уберите пункты, которые нельзя выполнить или однозначно оценить.
4. Разделите обязательные проверки и рекомендации.
5. Назначьте владельцев, сроки и порядок эскалации.
6. Запустите повторную проверку после исправлений.
7. Перенесите стабильные проверки в автоматизацию.

Пересматривайте регламент минимум раз в год и после существенных изменений инфраструктуры. Причинами обновления могут стать новый дистрибутив, переход с iptables на nftables, изменение схемы SSH-доступа, появление Kubernetes-нод, перенос журналов в централизованную систему или новые требования безопасности.

Храните историю версий документа. Для каждой редакции укажите дату, автора, перечень изменений и затронутые проверки. Старые отчеты должны оставаться привязанными к версии регламента, по которой их подготовили.

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

Для общего аудита серверов, сетей, Kubernetes, web-слоя и баз данных используйте пошаговое руководство по аудиту ИТ-инфраструктуры. После получения отчета полезно отдельно проверить, какие риски действительно требуют немедленной реакции, используя алгоритм разбора критичных находок.

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