Аудит безопасности: чек-лист для быстрой проверки Linux-сервера

Введение: зачем нужен экспресс-аудит безопасности

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

Небезопасная инфраструктура теряет данные, деньги и репутацию. Одна открытая уязвимость вроде CVE-2026-75501 в роутерах Calix GS7 XGS позволяет удалённому атакующему создавать правила проброса портов через WAN-интерфейс по TCP-порту 5000 и получать доступ к устройствам внутри сети. Исправления для этой уязвимости нет, поэтому единственная защита - отключить UPnP через административный интерфейс роутера в разделе Advanced → Security → UPnP.

Чек-лист ниже рассчитан на системных администраторов и DevOps-инженеров, которым нужна быстрая проверка перед релизом, миграцией или плановым обновлением. Все команды проверены на Debian/Ubuntu и CentOS/RHEL. Для более глубокого аудита используйте комплексный план аудита IT-инфраструктуры с готовыми чек-листами и шаблоном отчёта.

Подготовка к аудиту

Перед проверкой зафиксируйте область аудита: один сервер, кластер или весь периметр. Убедитесь, что у вас есть SSH-доступ и права root или sudo. Сделайте резервную копию конфигураций, которые планируете менять: /etc/nginx/, /etc/ssh/sshd_config, /etc/login.defs. Запишите текущие версии ПО, чтобы после исправлений сравнить состояние.

Что понадобится для проверки

SSH-доступ к целевому серверу
Права sudo или root
Утилиты: ss, netstat, nmap, openssl, nginx -T
Доступ к файлам конфигурации: /etc/nginx/nginx.conf, /etc/ssh/sshd_config, /etc/login.defs

Если часть утилит отсутствует, установите их пакетным менеджером. Для Debian/Ubuntu: apt install nmap openssl curl. Для CentOS/RHEL: yum install nmap openssl curl. Базовые утилиты вроде ss и netstat уже входят в стандартные пакеты.

Шаг 1: Проверка обновлений системы

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

Для Debian/Ubuntu выполните:

sudo apt update
sudo apt list --upgradable

Для CentOS/RHEL:

sudo yum check-update

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

sudo debsecan --suite=$(lsb_release -sc) --only-fixed

debsecan показывает установленные пакеты с известными уязвимостями, для которых уже есть исправления. Если утилиты нет, установите её: sudo apt install debsecan.

Интерпретация вывода: какие обновления критичны

Обновления с пометкой security в репозитории Debian или security в названии репозитория CentOS требуют немедленной установки. Критичны пакеты, связанные с ядром (linux-image-*), openssl, openssh-server, libssl, nginx. Пример вывода apt list --upgradable:

openssl/jammy-updates 3.0.2-0ubuntu1.18 amd64 [upgradable from: 3.0.2-0ubuntu1.17]
openssh-server/jammy-updates 1:8.9p1-3ubuntu0.10 amd64 [upgradable from: 1:8.9p1-3ubuntu0.9]

Обе строки указывают на обновления безопасности для критичных компонентов. Установите их сразу: sudo apt upgrade openssl openssh-server. Обычные обновления, например для текстового редактора, можно отложить до планового окна обслуживания.

Шаг 2: Анализ открытых портов

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

Внутренний просмотр слушающих портов:

sudo ss -tulpn

Вывод покажет протокол, локальный адрес, порт, процесс и PID. Пример:

tcp   LISTEN 0      511    0.0.0.0:80    0.0.0.0:*    users:(("nginx",pid=1234,fd=6))
tcp   LISTEN 0      128    127.0.0.1:5432  0.0.0.0:*    users:(("postgres",pid=2345,fd=7))

Первая строка: Nginx слушает порт 80 на всех интерфейсах, это ожидаемо для веб-сервера. Вторая строка: PostgreSQL слушает порт 5432 только на localhost, это правильная конфигурация.

Внешнее сканирование для проверки, что видит атакующий:

sudo nmap -sS -p- -T4 <IP-адрес>

Сравните результаты ss и nmap. Если nmap показывает порт, который не должен быть открыт наружу, это проблема. Например, порт 22 (SSH) открыт на всех интерфейсах - нормально, если вы подключаетесь удалённо. Порт 3306 (MySQL) открыт наружу - критично, если база данных не должна быть доступна извне.

Как определить, какие порты можно закрыть

Закрывайте порт, если выполняется любое из условий:

Сервис не используется. Пример: порт 23 (telnet) или 21 (FTP) на современном сервере.
Порт открыт на всех интерфейсах, но должен быть только на localhost. Пример: PostgreSQL, Redis, Memcached.
Сервис устарел и имеет известные уязвимости. Пример: старые версии OpenSSL или Apache.

Для закрытия порта настройте файрвол. На серверах с UFW: sudo ufw deny 3306. Для firewalld: sudo firewall-cmd --permanent --remove-port=3306/tcp && sudo firewall-cmd --reload. Подробное руководство по настройке файрвола с готовыми конфигами для firewalld и nftables есть в статье про hardening Linux-сервера.

Шаг 3: Оценка надежности паролей

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

Получите хэши паролей из /etc/shadow:

sudo cat /etc/shadow

Каждая строка содержит имя пользователя, хэш пароля и параметры срока действия. Хэш начинается с $1$ (MD5), $5$ (SHA-256), $6$ (SHA-512) или $y$ (yescrypt). MD5 - устаревший и легко взламываемый алгоритм. Если вы видите $1$ , пароли нужно срочно пересоздать.

Для офлайн-атаки на хэши используйте John the Ripper или hashcat:

sudo john --format=sha512crypt /etc/shadow

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

Проверка политики паролей

Проверьте PAM-модуль pam_pwquality в файле /etc/pam.d/common-password (Debian/Ubuntu) или /etc/pam.d/system-auth (CentOS/RHEL):

password requisite pam_pwquality.so retry=3 minlen=12 difok=3

Параметр minlen=12 задаёт минимальную длину 12 символов. Если minlen меньше 12 или модуль отсутствует, политика слабая. Проверьте также /etc/login.defs:

PASS_MIN_LEN    12
PASS_MAX_DAYS   90
PASS_MIN_DAYS   1

PASS_MAX_DAYS 90 заставляет менять пароль каждые 90 дней. Рекомендации: минимальная длина 12 символов, обязательное использование менеджеров паролей, запрет повторного использования старых паролей через remember=5 в PAM.

Шаг 4: Проверка конфигурации Nginx

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

Получите полную конфигурацию:

sudo nginx -T

Эта команда выводит все директивы, включая подключённые файлы из conf.d/ и sites-enabled/. Анализируйте вывод по трём направлениям: TLS, заголовки, доступ.

Проверка TLS-конфигурации

Проверьте поддерживаемые протоколы:

openssl s_client -connect localhost:443 -tls1_2
openssl s_client -connect localhost:443 -tls1_3

Если первая команда возвращает сертификат и параметры соединения, TLS 1.2 работает. Если вторая возвращает ошибку, TLS 1.3 не настроен. Проверьте, что старые протоколы отключены:

openssl s_client -connect localhost:443 -tls1_1

Ошибка соединения означает, что TLS 1.1 отключён - это правильно. Уязвимости POODLE и BEAST эксплуатируют старые протоколы SSLv3 и TLS 1.0, поэтому они должны быть отключены.

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

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;

Директива ssl_protocols должна содержать только TLS 1.2 и TLS 1.3. Если в списке есть TLSv1 или TLSv1.1, удалите их. Полное руководство по аудиту TLS, заголовков и контроля доступа в Nginx есть в статье про аудит безопасности Nginx.

Проверка заголовков безопасности

Проверьте, какие заголовки отправляет сервер:

curl -I https://localhost

В выводе ищите:

X-Frame-Options: DENY - защита от clickjacking
X-Content-Type-Options: nosniff - защита от MIME-sniffing
Content-Security-Policy: ... - ограничение источников контента
Strict-Transport-Security: max-age=... - принудительный HTTPS

Если заголовки отсутствуют, добавьте их в конфигурацию Nginx:

add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Content-Security-Policy "default-src 'self'" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

После изменения конфигурации проверьте синтаксис и перезагрузите Nginx:

sudo nginx -t
sudo systemctl reload nginx

Отключите раскрытие версии Nginx директивой server_tokens off; в блоке http. Это скрывает точную версию сервера от атакующих, что усложняет подбор эксплойтов.

Интерпретация результатов и приоритизация исправлений

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

Пример таблицы приоритетов

Находка	Уровень риска	Рекомендация	Срок устранения
Открытый SSH с парольной аутентификацией	Высокий	Включить аутентификацию по ключам, отключить пароли	Немедленно
Неустановленные обновления безопасности для openssl	Высокий	Установить обновления	Немедленно
Открытый порт 3306 (MySQL) на всех интерфейсах	Высокий	Закрыть порт файрволом или привязать к localhost	Немедленно
Отсутствует заголовок X-Frame-Options	Средний	Добавить заголовок в конфигурацию Nginx	В течение недели
Пароли с хэшем MD5	Средний	Пересоздать пароли с SHA-512 или yescrypt	В течение недели
Раскрытие версии Nginx (server_tokens on)	Низкий	Установить server_tokens off	При следующем обслуживании

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

Автоматизация регулярного аудита

Ручная проверка занимает 30-60 минут, но регулярность важнее разовой тщательности. Автоматизируйте базовые проверки скриптом и cron.

Пример простого скрипта для экспресс-проверки

#!/bin/bash
# Экспресс-аудит безопасности
echo "=== Обновления безопасности ==="
apt list --upgradable 2>/dev/null | grep -i security
echo "=== Открытые порты ==="
ss -tulpn
echo "=== Политика паролей ==="
grep -E "PASS_MIN_LEN|PASS_MAX_DAYS" /etc/login.defs
echo "=== Заголовки Nginx ==="
curl -sI https://localhost | grep -E "X-Frame-Options|X-Content-Type-Options|Strict-Transport-Security"

Сохраните скрипт как /usr/local/bin/security-check.sh, сделайте исполняемым:

sudo chmod +x /usr/local/bin/security-check.sh

Добавьте в cron для еженедельного запуска:

sudo crontab -e
0 3 * * 1 /usr/local/bin/security-check.sh | mail -s "Еженедельный аудит безопасности" admin@example.com

Скрипт запускается каждый понедельник в 3:00 и отправляет отчёт на почту. Для более глубокого аудита используйте Lynis: sudo lynis audit system. Lynis проверяет сотни параметров и выдаёт структурированный отчёт с рекомендациями. Готовые скрипты и инструменты для автоматизации, включая OpenVAS, Trivy и Wazuh, описаны в статье про автоматизацию аудита безопасности.

Заключение

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

Внедрите чек-лист в регулярную практику команды. Начните с проверки обновлений и открытых портов, затем добавьте анализ паролей и конфигурации Nginx. Для более глубокого аудита используйте пошаговое руководство по аудиту IT-инфраструктуры с планированием и структурированным отчётом.