Чек-лист аудита безопасности Linux-сервера: пользователи, SSH, обновления и службы

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

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

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

Как провести аудит Linux-сервера и ничего не пропустить

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

Начните с паспорта сервера. Запишите имя узла, IP-адреса, владельца, назначение, дистрибутив, версию ядра, критичность приложения и дату проверки.

hostnamectl
cat /etc/os-release
uname -r
ip -br address
date -Is

Затем последовательно пройдите шесть блоков:

1. учетные записи, группы и локальные администраторы;
2. правила sudo и делегированные команды;
3. SSH и другие способы удаленного доступа;
4. обновления ОС и критичных пакетов;
5. запущенные службы, слушающие порты и сетевые ограничения;
6. локальное и централизованное логирование.

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

Зафиксируйте базовые условия:

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

Как фиксировать отклонения во время проверки

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

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

Правило аудита: критичное отклонение фиксируется в момент обнаружения. Исправление выполняется после оценки влияния и проверки возможности отката.

Пользователи, группы и права sudo

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

Какие учетные записи проверить в первую очередь

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

getent passwd
awk -F: '$7 ~ /(bash|sh|zsh|fish)$/ {print $1, $3, $6, $7}' /etc/passwd
getent group
lastlog

В первую очередь проверьте:

• учетные записи с оболочкой входа;
• локальных администраторов и владельцев сервисов;
• временные аккаунты, созданные для работ;
• записи без понятного владельца;
• давно не использовавшиеся учетные записи;
• аккаунты с UID 0, кроме согласованной системной записи.

Найдите пользователей с нулевым идентификатором:

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

Обычно прямой интерактивный доступ нужен ограниченному числу администраторов. Сервисным учетным записям задают оболочку вроде /usr/sbin/nologin или /bin/false, если рабочий процесс не требует входа.

Проверьте признаки блокировки и срок действия паролей:

sudo passwd -S USERNAME
sudo chage -l USERNAME
sudo awk -F: '($2 == "" || $2 !~ /^\!|^\*/) {print $1}' /etc/shadow

Последняя команда требует доступа к /etc/shadow. Не копируйте этот файл в отчет. Зафиксируйте только факт наличия или отсутствия незаполненных паролей и ограничьте доступ к результатам аудита.

Проверка групп и делегированных привилегий

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

getent group sudo
getent group wheel
getent group adm
getent group docker
id USERNAME
groups USERNAME

Группа docker требует отдельного внимания. Доступ к Docker-сокету часто позволяет получить права, сопоставимые с локальным администрированием. Сохраняйте такое членство только при понятной рабочей необходимости и контролируйте владельца доступа.

Проверьте правила sudo:

sudo -l -U USERNAME
sudo visudo -c
sudo find /etc/sudoers.d -maxdepth 1 -type f -print

В каждом правиле оцените:

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

Принцип минимальных привилегий означает, что оператор получает конкретные команды для конкретной задачи. Правило ALL=(ALL) NOPASSWD: ALL расширяет доступ до полного администрирования и требует обоснования на уровне политики. Удаляйте лишние права после проверки зависимостей и наличия отдельного аварийного доступа.

Настройки SSH и безопасность удаленного доступа

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

Аутентификация и учет ключей

Сначала определите эффективную конфигурацию, которую применяет демон SSH:

sudo sshd -T
sudo sshd -T | egrep '^(port|listenaddress|permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication|allowusers|allowgroups|authenticationmethods)'

Перед изменением файла конфигурации сохраните его копию и проверьте синтаксис:

sudo sshd -t
sudo systemctl reload sshd

В Debian и Ubuntu имя службы часто ssh, в RHEL-подобных системах обычно используется sshd. Перед перезагрузкой убедитесь, что команда соответствует вашему дистрибутиву.

Проверьте публичные ключи пользователей:

sudo find /home /root -type f -name authorized_keys -print
sudo awk '{print FNR, $1, $2}' /home/USERNAME/.ssh/authorized_keys

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

Ограничения входа и защита администрирования

Проверьте следующие параметры:

• PermitRootLogin, прямой вход root обычно ограничивают политикой доступа;
• PasswordAuthentication и KbdInteractiveAuthentication, если доступ по паролям не нужен;
• AllowUsers и AllowGroups, если доступ можно ограничить списком субъектов;
• AuthenticationMethods, если для администраторов требуется несколько факторов;
• ListenAddress и порт, чтобы SSH не слушал лишние интерфейсы;
• сетевые правила файрвола и ограничения по административным подсетям;
• защиту от перебора и оповещения о неудачных входах.

Проверьте активные входы и события SSH:

who
w
last -a | head -n 20
sudo journalctl -u ssh --since "24 hours ago"
sudo journalctl -u sshd --since "24 hours ago"

Если защита от перебора зависит от Fail2ban, системного файрвола или внешнего шлюза, подтвердите состояние каждого компонента отдельно. Учитывайте доступность сервера: изменение SSH без второго проверенного канала может заблокировать администрирование.

Практические настройки hardening и примеры для SSH, sudo, firewalld и nftables собраны в руководстве по hardening и аудиту Linux-сервера.

Проверка обновлений Linux-сервера

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

Как оценить актуальность системы

Зафиксируйте версию операционной системы и ядра:

cat /etc/os-release
uname -r
systemctl is-system-running

Для Debian и Ubuntu проверьте доступные обновления:

sudo apt update
apt list --upgradable
apt-cache policy openssh-server

Для RHEL-подобных систем используйте:

sudo dnf check-update
dnf list --updates
dnf info openssh-server

Команда dnf check-update может вернуть код 100, когда обновления найдены. Это не обязательно ошибка выполнения.

Сопоставьте результат с базовой версией, принятой для вашей среды. Отдельно выделите:

• неподдерживаемую версию дистрибутива;
• критичные обновления безопасности;
• пакеты SSH, PAM, ядра и сетевых компонентов;
• исключенные или заблокированные пакеты;
• репозитории, которые недоступны или не соответствуют политике;
• обновления, после которых нужна перезагрузка.

Признаки необходимости перезагрузки зависят от дистрибутива. Например, в некоторых системах доступен файл /var/run/reboot-required. Дополнительно сравните загруженное ядро с установленным пакетом и проверьте историю обновлений.

Что делать с отложенными обновлениями

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

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

Какие службы проверить на Linux-сервере

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

Инвентаризация запущенных и доступных служб

Получите список активных служб и процессов:

systemctl list-units --type=service --state=running
systemctl list-unit-files --state=enabled
ps aux --forest

Проверьте сетевые слушатели:

sudo ss -lntup
sudo lsof -nP -iTCP -sTCP:LISTEN
sudo ss -lnup

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

Сверьте фактический список с документацией роли сервера и сетевой схемой. На веб-сервере могут быть нужны HTTP или HTTPS, SSH и порт мониторинга. На сервере базы данных доступ извне часто ограничивают приложением, подсетью или локальным интерфейсом.

Как определить лишнюю сетевую службу

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

Перед остановкой проверьте зависимости:

systemctl status SERVICE_NAME
systemctl list-dependencies SERVICE_NAME
systemctl cat SERVICE_NAME
sudo journalctl -u SERVICE_NAME --since "7 days ago"

Порядок действий:

1. найдите владельца службы и подтвердите назначение;
2. проверьте зависимости, мониторинг и резервные процессы;
3. оцените влияние остановки на приложение;
4. сохраните текущую конфигурацию;
5. согласуйте отключение и план отката;
6. после изменения повторно проверьте порты, службы и журналы.

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

Настройка логирования Linux-сервера

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

Какие события должны попадать в центральный журнал

Минимальный набор событий включает:

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

Проверьте локальные журналы:

sudo journalctl --since "24 hours ago"
sudo journalctl -p warning..alert --since "24 hours ago"
sudo journalctl _COMM=sudo --since "7 days ago"
sudo journalctl -u ssh --since "7 days ago"

В системах с auditd дополнительно проверьте его состояние и события:

sudo systemctl status auditd
sudo ausearch -m USER_LOGIN,USER_ACCT,USER_CMD -ts recent

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

Проверка доставки, хранения и доступности логов

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

sudo systemctl --type=service | egrep 'rsyslog|journal|fluent|filebeat|audit'
sudo journalctl --since "24 hours ago" | egrep -i 'error|fail|drop|timeout|forward'

Минимальные критерии проверки:

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

Проверьте синхронизацию времени:

timedatectl
chronyc tracking 2>/dev/null || true
systemctl status chronyd 2>/dev/null || systemctl status systemd-timesyncd

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

Как оценить критичность отклонений и оформить результат

Что считать критичным отклонением

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

К критичным или высоким находкам обычно относят следующие сочетания:

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

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

Минимальный отчет по результатам аудита

Отчет должен позволять другому администратору восстановить ход проверки и понять, что делать дальше. Включите:

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

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

Итоговый чек-лист для регулярного внутреннего контроля

1. Определить роль сервера, владельца, версию ОС, дату и границы аудита.
2. Собрать список пользователей, интерактивных оболочек и давно не использовавшихся учетных записей.
3. Проверить UID 0, служебные аккаунты, владельцев доступа и состояние паролей.
4. Проверить членство в sudo, wheel, adm, docker и других привилегированных группах.
5. Проверить правила sudo, область команд, необходимость пароля и опасные исключения.
6. Проверить эффективную конфигурацию SSH, прямой вход root, доступ по паролю и разрешенных пользователей.
7. Проверить владельцев SSH-ключей, актуальность ключей и возможность их отзыва.
8. Проверить сетевую доступность SSH и защиту от перебора.
9. Зафиксировать версию ОС, состояние репозиториев, доступные исправления и необходимость перезагрузки.
10. Для каждого отложенного обновления указать причину, риск, владельца и дату повторной проверки.
11. Составить список активных служб, процессов, слушающих портов и интерфейсов.
12. Сопоставить сетевые службы с ролью сервера, владельцами и утвержденной сетевой схемой.
13. Проверить неизвестные и временные службы до их отключения, включая зависимости и план отката.
14. Проверить события SSH, sudo, учетных записей, служб, конфигураций и обновлений.
15. Проверить доставку журналов в центральную систему, задержки, срок хранения, права и целостность.
16. Немедленно зафиксировать критичные отклонения с доказательством, риском, ответственным и сроком.
17. Назначить действия для каждой находки и провести повторную проверку после исправления.
18. Сохранить отчет и сравнить результат с предыдущим циклом.

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

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