Как да одитирате 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 споменава “Активни интернет връзки”, v0.2.0 само извлича публичния IP и прави инвентар на локални слушачи. Тъй като има нужда от привилегирана видимост, първо контролирайте кой файл получава достъп до sudo.

Преди да дадете sudo на изтеглен скрипт

Този Debian/Ubuntu работен процес изисква SSH достъп, sudo и стандартните инструменти, използвани по-долу. Работете в директория за еднократна употреба. Ако липсва инструмент, спрете вместо да променяте базовата конфигурация чрез инсталирането му.

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

Неговият таг сочи към commit 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. Разделът ограничения обяснява защо статусът на слушателя не следва тези променливи.

⚠️ Предупреждение: Закрепването, хеширането, целевата проверка и проверката на синтаксиса подобряват възпроизводимостта, но не установяват доверие. Commit-ът е неподписан, а издаването не предоставя актив за контролна сума или подпис.

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

Накрая, разберете файла без да изпълнявате неговите нормални команди, след което добавете разрешение за изпълнение само ако разбирането успее:

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 услуги работят”, броят е наблюдението; “намалете повърхността на атака” е съвет, основан на генеричен праг. Потвърдете броя, идентифицирайте услугите и след това решете дали този съвет отговаря на сървъра.

Задайте три въпроса на всеки резултат: Точна ли е стойността? Преднамерена ли е? Какъв е реалистичният ефект? Родните команди проверяват стойността; контекстът на работния товар определя останалото.

SSH-портът WARN е базиран на политика: 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-login и password-authentication, въпреки че състоянието на акаунта, 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 аутентификация или правила на отдалечения firewall от тази последователност на команди. Грешка може да ви заключи. Преди отстраняване, потвърдете тестван достъп чрез ключ и валидирайте новата конфигурация. Держите втора сесия отворена и уверете се, че конзолата или достъпът за възстановяване работи.

Обработвайте всяко отстраняване като отделен работен процес. Картирайте зависимостите преди спиране на услуги, класифицирайте актуализации преди планирането им и проверете собственост и контролни суми преди промяна на SUID разрешения.

Където vps-audit’s View Stops

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, Ubuntu 24.04 CIS Benchmark или професионален преглед.

Заключение: Проверете, приоритизирайте и преревизирайте

Держите оригиналния отчет в приватност и поддържайте редактирано копие. Запишете SHA-256 на скрипта, етикета и commit заедно с времето на изпълнение, предвидените услуги, резултатите от проверката и опашката на действия.

1. Проверете находки с висок приоритет с помощта на собствени команди преди да променяте сървъра.
2. Коригирайте потвърдени високорискови проблеми безопасно, разследвайте неизвестни и документирайте преднамерени изключения.
3. Преизпълнете същата закрепена версия след промени или по график, след това сравнете отчетите ръчно.

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

vps-audit няма базова база данни, планировчик, анализ на тенденциите или механизъм за сравнение. Неговата стойност идва от повторяема навика: изпълнете, проверете, приоритизирайте и преревизирайте.