Как провести аудит Linux VPS с помощью vps-audit — и правильно прочитать результаты

Быстрый аудит VPS — это начало, а не приговор

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

vps-audit — это Bash чек-лист для Debian и Ubuntu, который превращает локальную конфигурацию, обслуживание, слушатели и сигналы ресурсов в цветной отчет. Как панель приборов автомобиля, он указывает на области, требующие проверки, без диагностики каждой причины.

Это руководство безопасно запускает закрепленный vps-audit v0.2.0, проверяет важные результаты с помощью встроенных инструментов и превращает их в приоритеты. Пример использует один AlexHost Ubuntu VPS под управлением Ubuntu 24.04 LTS. Образы других провайдеров могут отличаться, и неуправляемая гостевая ОС остается ответственностью оператора.

Что проверяет vps-audit — и что она не может доказать

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

SUID позволяет программе запускаться с эффективными привилегиями владельца файла. Легитимные системные программы используют его, поэтому исследуйте неожиданный файл SUID вместо его удаления. Fail2ban и CrowdSec могут блокировать враждебный трафик, но одна установка или активный статус не доказывают, что они защищают предполагаемый сервис.

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

Инструмент не проверяет вредоносное ПО, известные уязвимости, приложения, контейнеры, файерволы провайдера, соответствие требованиям или тренды. Хотя его README упоминает «Active Internet Connections», v0.2.0 только получает публичный IP и инвентаризирует локальные слушатели. Поскольку ему требуется привилегированный доступ, сначала контролируйте, какой файл получает доступ sudo.

Перед тем как дать загруженному скрипту sudo

Этот рабочий процесс Debian/Ubuntu требует SSH доступа, sudo и стандартных инструментов, используемых ниже. Работайте в одноразовом каталоге. Если инструмент отсутствует, остановитесь вместо того, чтобы изменять базовую конфигурацию путем его установки.

Пример использует vps-audit v0.2.0, опубликованный 10 августа 2026 года и остающийся последней версией при проверке 8 сентября 2026 года.

Его тег указывает на коммит 57c323d46b48026740f0b35b9bad6cd6127c757b. Привязка избегает более позднего изменения из изменяемой main.

Создайте выделенный каталог и загрузите этот точный помеченный скрипт через HTTPS:

mkdir -p "$HOME/vps-audit-test"
cd "$HOME/vps-audit-test"
curl -fL --proto '=https' --tlsv1.2 
  -o vps-audit.sh 
  https://raw.githubusercontent.com/nuver-labs/vps-audit/v0.2.0/vps-audit.sh

Это сохраняет vps-audit.sh в новом каталоге. Опция -f завершается с ошибкой при ошибках HTTP, а -L следует перенаправлениям.

Далее запишите локальный отпечаток SHA-256 и отобразите параметры, относящиеся к этому пошаговому руководству:

sha256sum vps-audit.sh
grep -nE '^(VPS_AUDIT_VERSION|RESOURCE_(WARN|FAIL)|SERVICES_(WARN|FAIL)|LOGINS_(WARN|FAIL)|OPEN_PORTS_(WARN|FAIL)|PASSWORD_MINLEN|DEFAULT_REPORT_DIR|ENABLE_CHOWN)=|api.ipify.org' vps-audit.sh

Выходные данные содержат отпечаток файла и показывают путь его отчета, пороги и запрос к api.ipify.org. Полный помеченный исходный код также читает локальное состояние, имитирует apt-get -s upgrade и рекурсивно ищет файлы SUID. Он не только для чтения: он записывает отчет, может создать его каталог и контактирует с внешним сервисом. Перед предоставлением повышенных привилегий просмотрите исходный код, если вы можете читать код оболочки.

Пороги ресурсов составляют 50% для WARN и 80% для FAIL. Запущенные сервисы используют 20/40, неудачные входы 10/50, слушатели номинально 10/20 и длину пароля 12. Раздел ограничений объясняет, почему статус слушателя не следует этим переменным.

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

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

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

bash -n vps-audit.sh 
  && chmod +x vps-audit.sh 
  && printf 'Syntax check: PASS; execute permission addedn'

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

Запустите vps-audit и найдите отчет

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

Запустите закрепленный файл один раз и сохраните статус выхода процесса оболочки:

printf 'Audit started: '
date -u '+%Y-%m-%d %H:%M:%S UTC'
TIMEFORMAT=$'Elapsed real: %3R secondsnUser CPU: %3U secondsnSystem CPU: %3S seconds'
time sudo ./vps-audit.sh
AUDIT_STATUS=$?
printf 'Audit exit status: %sn' "$AUDIT_STATUS"

На тестируемом VPS аудит начался в 13:12:10 UTC 14 сентября 2026 г. и завершился за 58.412 секунд. Он вернул 0 и сохранил ./vps-audit-report-20260914_131210.txt.

Elapsed real — это реальное время; значения user и system измеряют время CPU. Статус выхода 0 означает, что процесс завершился, а не то, что все проверки прошли успешно. v0.2.0 возвращает 0 даже при наличии результатов FAIL.

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

REPORT=$(ls -1t ./vps-audit-report-*.txt 2>/dev/null | head -n 1)
if [ -z "$REPORT" ]; then
    printf 'No vps-audit report found in the current directory.n' >&2
    exit 1
fi
printf 'Report selected: %sn' "$REPORT"
sudo stat --format='Owner: %U:%G | Mode: %A (%a) | Size: %s bytes | Modified: %y' "$REPORT"

for status in PASS WARN FAIL; do
    count=$(sudo grep -c "^\[$status\]" "$REPORT" || true)
    printf '%s: %sn' "$status" "$count"
done

sudo grep -E '^[(PASS|WARN|FAIL)] (Running Services|Disk Usage|Password Policy)' "$REPORT"

Время изменения отчета 13:13:08 UTC совпадало с временем запуска. Он содержал 17 результатов: шесть PASS, три WARN и восемь FAIL. Это классификации, а не оценка безопасности.

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

Отчет размером 2,665 байт принадлежал root:root с режимом 644 (-rw-r--r--), как и ожидалось при sudo и стандартном ENABLE_CHOWN=false. Пользователи группы и другие пользователи могут читать этот режим, если разрешения каталога позволяют им получить доступ к файлу. Только владение root не делает его приватным.

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

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

Как читать PASS, WARN и FAIL без паники

Метки на панели показывают, как каждый тест соответствует правилам v0.2.0:

Отделите наблюдение от рекомендации. В «22 запущенных сервиса» счёт — это наблюдение; «снизить поверхность атаки» — это совет на основе универсального порога. Подтвердите счёт, определите сервисы, а затем решите, подходит ли этот совет серверу.

Задайте три вопроса к каждому результату: Точно ли значение? Это намеренно? Какой реальный эффект? Встроенные команды проверяют значение; контекст рабочей нагрузки определяет остальное.

WARN по SSH-порту основан на политике: v0.2.0 помечает порт 22. Перемещение SSH может снизить автоматический шум, но не может заменить сильную аутентификацию или элементы управления доступом. Известный сервис на порту 22 может быть менее важен, чем неизвестный слушатель с подстановочным знаком.

Для FAIL проверьте правило перед предложением исправления. Тест root-login принимает только PermitRootLogin no, поэтому отличный параметр prohibit-password всё ещё не проходит. Проверьте OpenSSH напрямую перед действием.

PASS также требует контекста. Для unattended-upgrades скрипт подтверждает только наличие пакета — не его конфигурацию или историю запусков.

Проверьте высокоприоритетные результаты с помощью встроенных команд

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

sudo sshd -T 
  | grep -E '^(port|listenaddress|permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication) '

Ubuntu загружает /etc/ssh/sshd_config.d/*.conf в начале своей основной конфигурации. sshd -T разрешает объединенные параметры, что делает его более надежным доказательством, чем поиск в одном файле.

OpenSSH разрешил порт 22 на адресах IPv4 и IPv6 с подстановочным символом. Он также вернул permitrootlogin yes, passwordauthentication yes, pubkeyauthentication yes и kbdinteractiveauthentication no. Разрешенная конфигурация подтверждает результаты скрипта о входе root и аутентификации по паролю, хотя состояние учетной записи, PAM и правила Match все еще могут повлиять на конкретный вход.

Во-вторых, спросите, что сам UFW сообщает о своем состоянии и управляемой политике:

sudo ufw status verbose

Ubuntu документирует UFW как интерфейс брандмауэра по умолчанию. Здесь он был активен с низкоуровневым логированием и политиками отказа по умолчанию для входящего и маршрутизируемого трафика. Правила разрешали входящие порты 22, 80, 443 и 37985 через IPv4 и IPv6. Это подтверждает состояние UFW, а не то, является ли каждое правило надлежащим.

В-третьих, составьте инвентарь локальных прослушивателей TCP и UDP, адресов привязки и процессов-владельцев:

sudo ss -lntup

Параметры выбирают числовые прослушиватели TCP и UDP и запрашивают сведения о процессе. Порты 53, 62789, 8404 и 11111 были только для обратной связи; порты 22, 80, 2096, 5678 и 37985 использовали адреса с подстановочным символом. Сведения о процессе не появились, поэтому их владельцы и назначение остаются неизвестными.

process listener
    → bind address / interface
    → host firewall
    → provider-edge firewall or NAT
    → external network path

Порты 22, 80 и 37985 имели как прослушиватели с подстановочным символом, так и правила разрешения UFW. UFW разрешил 443 без прослушивателя, а 2096 и 5678 имели прослушиватели без отображаемых правил разрешения.

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

📝 Примечание: ss показывает локальное состояние привязки, а UFW показывает один брандмауэр хоста. Ни то, ни другое не доказывает доступность в Интернете через брандмауэры поставщика или NAT; это требует авторизованного тестирования с другой системы.

v0.2.0 тем не менее помечает один и тот же список как “Total” и “Public” после отбрасывания адресов привязки, хотя четыре из девяти портов TCP были только для обратной связи. Его фильтр LISTEN также пропускает строки UDP, отмеченные как UNCONN. Читайте этот результат как локальный счет портов TCP, а не как открытую доступность.

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

Установите приоритет по уверенности, воздействию, влиянию и намерению. Priority 1 охватывает подтвержденные слабости, требующие действия. Priority 2 охватывает важные результаты, которые все еще нуждаются в исследовании, а Priority 3 охватывает элементы с низким риском или управляемые политикой. Если параметр намеренный, задокументируйте причину, любой компенсирующий контроль и время проверки.

Таблица применяет этот подход к этому запуску; неполные доказательства сохраняют приоритет предварительным:

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

Метка отчета не устанавливает порядок: проверка и контекст делают это.

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

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

Где заканчивается обзор vps-audit

vps-audit v0.2.0 — это Bash-контрольный список на определённый момент времени. Он не может установить внешнее воздействие, обнаружить уязвимости или вредоносное ПО, проверить рабочие нагрузки, анализировать сохранённые журналы или обеспечивать непрерывный мониторинг. Это не тест на проникновение и не оценка CIS Benchmark.

Код добавляет важные оговорки.

• Статус порта становится PASS при трёх или менее разобранных TCP-портах, WARN при трёх или четырёх и FAIL при пяти или более — несмотря на номинальные переменные 10/20.
• PASS для unattended-upgrades проверяет только наличие пакета, а не его конфигурацию, таймер или историю запусков.
• Тест обновлений использует кэшированные метаданные для общей команды apt-get -s upgrade, а затем называет каждый указанный пакет «обновлением безопасности».

Тест логирования sudo читает только /etc/sudoers, пропуская /etc/sudoers.d/ и обычные записи журнала или syslog. Issue #33, открытая при проверке 8 сентября 2026 года, документирует этот ложный FAIL на Ubuntu 20.04 и 24.04. Разбор также может не работать с выводом на других языках, как отслеживается в открытой issue #37. Несмотря на формулировку в README, этот выпуск не перечисляет установленные соединения.

Расширьте проверку при необходимости. Подозрительное поведение требует анализа сохранённых журналов и рабочих нагрузок. Для важного VPS подтвердите протестированные резервные копии и рассмотрите авторизованное внешнее тестирование. Критические или регулируемые системы могут потребовать Lynis, CIS Benchmark для Ubuntu 24.04 или профессиональную проверку.

Итог: Проверьте, приоритизируйте и перепроверьте

Храните исходный отчет в приватном виде и ведите редактированную копию. Записывайте SHA-256 скрипта, тег и коммит вместе с временем выполнения, предполагаемыми сервисами, результатами проверки и очередью действий.

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

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

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