Як проводити аудит 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. Це не тільки для читання: він записує звіт, може створити його каталог і контактує зовнішній сервіс. Перегляньте джерело перед наданням підвищених привілеїв, якщо ви можете читати код shell.

Пороги ресурсів становлять 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 робить час виконання змінним, тому виміряйте його.

Запустіть закріплений файл один раз і збережіть статус виходу процесу shell:

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 були лише для loopback; порти 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 були лише для loopback. Його фільтр LISTEN також пропускає рядки UDP, позначені як UNCONN. Читайте цей результат як локальний підрахунок портів TCP, а не як публічну експозицію.

Перетворіть перевірені результати на практичну чергу дій

Встановіть пріоритет за впевненістю, експозицією, впливом та намірами. Пріоритет 1 охоплює підтверджені вразливості, які потребують дій. Пріоритет 2 охоплює важливі результати, які все ще потребують розслідування, а Пріоритет 3 охоплює елементи з низьким ризиком або керовані політикою. Якщо параметр навмисний, задокументуйте причину, будь-які компенсуючі контролі та коли його переглянути.

Таблиця застосовує цей підхід до цього запуску; неповні докази зберігають пріоритет попередньо:

Пріоритет 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 не має базової бази даних, планувальника, аналізу тенденцій або механізму порівняння. Його цінність полягає в повторюваній звичці: запустити, перевірити, визначити пріоритети та перевірити ще раз.