Jak przeprowadzić audyt Linux VPS za pomocą vps-audit—i prawidłowo odczytać wyniki

Szybka audyt VPS to punkt wyjścia, a nie werdykt

Twoja strona się ładuje i SSH odpowiada, ale to nie ujawnia oczekujących aktualizacji, permisywnych ustawień SSH ani nieoczekiwanych nasłuchiwaczy. Audyt pierwszego przejścia ujawnia te pytania.

vps-audit to lista kontrolna Bash dla Debian i Ubuntu, która zamienia sygnały konfiguracji lokalnej, konserwacji, nasłuchiwaczy i zasobów w raport kodowany kolorami. Jak deska rozdzielcza pojazdu, wskazuje obszary wymagające inspekcji bez diagnozowania każdej przyczyny.

Ten przewodnik bezpiecznie uruchamia przypięty vps-audit v0.2.0, sprawdza ważne wyniki za pomocą natywnych narzędzi i zamienia je w priorytety. Przykład używa jednego AlexHost Ubuntu VPS z systemem Ubuntu 24.04 LTS. Obrazy innych dostawców mogą się różnić, a niezarządzany system operacyjny gościa pozostaje odpowiedzialnością operatora.

Co vps-audit sprawdza—i czego nie może udowodnić

vps-audit sprawdza lokalne wskaźniki bez wyczerpującego badania żadnego obszaru. Ta tabela pokazuje, co każdy wynik może—i nie może—ci powiedzieć.

SUID pozwala programowi działać z efektywnymi uprawnieniami właściciela pliku. Legalne programy systemowe go używają, więc zbadaj nieoczekiwany plik SUID zamiast go usuwać. Fail2ban i CrowdSec mogą blokować wrogą ruch, ale sama instalacja lub aktywny status nie dowodzi, że chronią zamierzoną usługę.

Skrypt stosuje ogólne progi do użycia zasobów, usług, nieudanych logowań i nasłuchiwaczy. To nie są wyniki ryzyka świadome obciążenia; różne role VPS mogą osiągnąć ten sam kolor z różnych powodów.

Narzędzie nie sprawdza złośliwego oprogramowania, znanych luk w zabezpieczeniach, aplikacji, kontenerów, zapór dostawcy, zgodności ani trendów. Chociaż jego README wspomina o „Aktywnych połączeniach internetowych”, v0.2.0 pobiera tylko publiczny IP i kataloguje lokalne nasłuchiwaczy. Ponieważ wymaga uprzywilejowanej widoczności, najpierw kontroluj, który plik otrzymuje dostęp sudo.

Zanim przyznasz uprawnienia sudo pobranym skryptom

Ten przepływ pracy Debian/Ubuntu wymaga dostępu SSH, sudo i standardowych narzędzi użytych poniżej. Pracuj w katalogu tymczasowym. Jeśli brakuje narzędzia, zatrzymaj się zamiast zmieniać linię bazową poprzez jego instalację.

Przykład używa vps-audit v0.2.0, opublikowanego 10 sierpnia 2026 i nadal najnowszego po sprawdzeniu 8 września 2026.

Jego tag wskazuje na commit 57c323d46b48026740f0b35b9bad6cd6127c757b. Pinowanie unika późniejszych zmian z mutable main.

Utwórz dedykowany katalog i pobierz dokładnie ten oznaczony skrypt przez 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

To zapisuje vps-audit.sh w nowym katalogu. Opcja -f kończy się niepowodzeniem przy błędach HTTP, podczas gdy -L podąża za przekierowaniami.

Następnie zapisz lokalny odcisk SHA-256 i wyświetl ustawienia istotne dla tego przewodnika:

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

Wyjście odciskowuje plik i pokazuje ścieżkę raportu, progi i żądanie do api.ipify.org. Pełne źródło oznaczone tagiem również odczytuje stan lokalny, symuluje apt-get -s upgrade i rekurencyjnie wyszukuje pliki SUID. Nie jest tylko do odczytu: zapisuje raport, może utworzyć jego katalog i kontaktuje się z usługą zewnętrzną. Przejrzyj źródło przed przyznaniem podwyższonych uprawnień, jeśli potrafisz czytać kod powłoki.

Progi zasobów to 50% dla WARN i 80% dla FAIL. Uruchomione usługi używają 20/40, nieudane logowania 10/50, nasłuchujące nominalnie 10/20 i długość hasła 12. Sekcja ograniczeń wyjaśnia, dlaczego status nasłuchującego nie podąża za tymi zmiennymi.

⚠️ Ostrzeżenie: Pinowanie, haszowanie, ukierunkowana inspekcja i sprawdzanie składni poprawiają powtarzalność, ale nie ustalają zaufania. Commit jest niepodpisany, a wydanie nie zawiera zasobu sumy kontrolnej lub podpisu.

Przechowuj hash wraz z notatkami audytu. Przed uruchomieniem porównaj go z plikiem. Dopasowanie pokazuje, że kopie zawierają te same bajty. Różnica może wynikać z innego wydania, zmienionego pobrania lub lokalnej edycji. Zapisanie tagu i hasha łączy każdy raport ze skryptem, który go wygenerował.

Na koniec przeanalizuj plik bez uruchamiania jego normalnych poleceń, a następnie dodaj uprawnienie wykonania tylko jeśli analiza się powiedzie:

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

To potwierdza tylko, że Bash może przeanalizować plik i że uprawnienie wykonania zostało dodane. Przypięty skrypt jest teraz gotowy do jednego niezmienionego uruchomienia.

Uruchom vps-audit i Zlokalizuj Raport

Skrypt wypisuje szczegóły systemu i statusy kolorów, a następnie zapisuje raport w formacie zwykłego tekstu. Jego rekurencyjne wyszukiwanie SUID powoduje zmienność czasu wykonania, dlatego zmierz go.

Uruchom przypięty plik raz i zachowaj status wyjścia procesu powłoki:

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"

Na testowanym VPS audyt rozpoczął się o 13:12:10 UTC 14 września 2026 i zakończył się w 58.412 sekund. Zwrócił 0 i zapisał ./vps-audit-report-20260914_131210.txt.

Elapsed real to czas rzeczywisty; wartości user i system mierzą czas CPU. Status wyjścia 0 oznacza, że proces się zakończył, a nie że każde sprawdzenie przeszło. v0.2.0 zwraca 0 nawet z wynikami FAIL.

Wybierz nowy raport, sprawdź jego metadane i wyodrębnij liczby i przykłady bez wyświetlania pełnego poufnego pliku.

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"

Czas modyfikacji raportu 13:13:08 UTC odpowiadał przebiegowi. Zawierał 17 wyników: sześć PASS, trzy WARN i osiem FAIL. Są to klasyfikacje, a nie wynik bezpieczeństwa.

Sumy statusów są przydatne przy porównywaniu przebiegów tej samej wersji, ale zawsze sprawdzaj linie za zmianą. Niższa liczba FAIL może wynikać z innego wejścia lub zachowania parsera, a nie z ulepszenia. Niezmieniona suma może również ukrywać jeden rozwiązany problem i jeden nowy.

Raport o rozmiarze 2,665 bajtów należał do root:root z trybem 644 (-rw-r--r--), jak oczekiwano z sudo i domyślnym ENABLE_CHOWN=false. Użytkownicy grupy i inni mogą czytać ten tryb, jeśli uprawnienia katalogu pozwalają im dotrzeć do pliku. Sama własność root nie czyni go prywatnym.

❗ Ważne: Raport zawiera nazwę hosta, publiczny IP, szczegóły systemu i ustalenia. Zachowaj go w tajemnicy i usuń identyfikatory, monity i poufne informacje o usługach przed udostępnieniem.

Jeśli przyszły przebieg będzie pozbawiony jednego statusu, zanotuj tę nieobecność zamiast rekonfigurować VPS, aby wytworzyć kolor.

Jak czytać PASS, WARN i FAIL bez przesady

Etykiety na pulpicie pokazują, jak każdy test pasował do reguł v0.2.0:

Oddziel obserwację od rekomendacji. W „22 uruchomione usługi” liczba jest obserwacją; „zmniejsz powierzchnię ataku” to rada oparta na ogólnym progu. Potwierdź liczbę, zidentyfikuj usługi, a następnie zdecyduj, czy ta rada pasuje do serwera.

Zadaj trzy pytania każdemu wynikowi: Czy wartość jest dokładna? Czy jest zamierzona? Jaki jest realny wpływ? Polecenia natywne sprawdzają wartość; kontekst obciążenia określa resztę.

WARN portu SSH jest oparty na polityce: v0.2.0 oznacza port 22. Przeniesienie SSH może zmniejszyć zautomatyzowany szum, ale nie może zastąpić silnego uwierzytelniania ani kontroli dostępu. Znana usługa na porcie 22 może mieć mniejsze znaczenie niż nieznany słuchacz wieloznaczny.

W przypadku FAIL sprawdź regułę przed zaproponowaniem poprawki. Test logowania root akceptuje tylko PermitRootLogin no, więc odrębne ustawienie prohibit-password nadal zawodzi. Sprawdź OpenSSH bezpośrednio przed podjęciem działań.

PASS również wymaga kontekstu. W przypadku unattended-upgrades skrypt potwierdza tylko, że pakiet istnieje—nie jego konfigurację ani historię uruchamiania.

Weryfikuj Ważne Ustalenia za Pomocą Natywnych Poleceń

Użyj poleceń natywnych tylko do odczytu, aby sprawdzić dostęp SSH, filtrowanie hosta i lokalne nasłuchiwacze. Najpierw zapytaj, co OpenSSH faktycznie rozwiązuje po połączeniu ustawień domyślnych i dołączonej konfiguracji:

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

Ubuntu ładuje /etc/ssh/sshd_config.d/*.conf blisko początku swojej głównej konfiguracji. sshd -T rozwiązuje połączone ustawienia, co stanowi silniejszy dowód niż przeszukiwanie jednego pliku.

OpenSSH rozwiązał port 22 na adresach IPv4 i IPv6 z symbolem wieloznacznym. Zwrócił również permitrootlogin yes, passwordauthentication yes, pubkeyauthentication yes i kbdinteractiveauthentication no. Rozwiązana konfiguracja potwierdza ustalenia skryptu dotyczące logowania root i uwierzytelniania hasłem, chociaż stan konta, PAM i reguły Match mogą nadal wpłynąć na konkretne logowanie.

Po drugie, zapytaj, co sam UFW raportuje o swoim stanie i zarządzanej polityce:

sudo ufw status verbose

Ubuntu dokumentuje UFW jako domyślny interfejs zapory. Tutaj był aktywny z rejestrowaniem na niskim poziomie i polityką domyślnego odrzucania dla ruchu przychodzącego i trasowanego. Reguły zezwalały na porty przychodzące 22, 80, 443 i 37985 przez IPv4 i IPv6. To potwierdza stan UFW, a nie czy każda reguła jest odpowiednia.

Po trzecie, zinwentaryzuj lokalne nasłuchiwacze TCP i UDP, adresy wiązania i procesy będące właścicielami:

sudo ss -lntup

Opcje wybierają numeryczne nasłuchiwacze TCP i UDP oraz żądają szczegółów procesu. Porty 53, 62789, 8404 i 11111 były tylko dla loopback; porty 22, 80, 2096, 5678 i 37985 używały adresów wieloznacznych. Nie pojawiły się żadne szczegóły procesu, więc ich właściciele i cele pozostają nieznane.

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

Porty 22, 80 i 37985 miały zarówno nasłuchiwacze wieloznaczne, jak i reguły zezwalające UFW. UFW zezwolił na 443 bez nasłuchiwacza, podczas gdy 2096 i 5678 miały nasłuchiwacze bez wyświetlonych reguł zezwalających.

Reguła zapory i nasłuchiwacz odpowiadają na różne pytania. Reguła zezwala na ruch, jeśli usługa jest tam, aby go zaakceptować; nasłuchiwacz pokazuje usługę czekającą, ale nie czy ruch sieciowy może do niej dotrzeć. Czytanie obu razem zawęża śledztwo bez twierdzenia o zewnętrznym narażeniu.

📝 Uwaga: ss pokazuje lokalny stan wiązania, a UFW pokazuje jedną zaporę hosta. Żaden z nich nie dowodzi dostępności Internetu w sieciach dostawcy lub NAT; wymaga to autoryzowanego testowania z innego systemu.

v0.2.0 niemniej etykietuje tę samą listę „Total” i „Public” po odrzuceniu adresów wiązania, chociaż cztery z dziewięciu portów TCP były tylko dla loopback. Jego filtr LISTEN również pomija wiersze UDP oznaczone UNCONN. Przeczytaj ten wynik jako liczbę lokalnych portów TCP, a nie publiczne narażenie.

Zamień zweryfikowane ustalenia w praktyczną kolejkę działań

Ustaw priorytet na podstawie pewności, ekspozycji, wpływu i intencji. Priorytet 1 obejmuje potwierdzone słabości wymagające działania. Priorytet 2 obejmuje ważne ustalenia, które nadal wymagają badania, podczas gdy Priorytet 3 obejmuje elementy o niższym ryzyku lub napędzane polityką. Jeśli ustawienie jest celowe, udokumentuj dlaczego, wszelkie kontrole kompensacyjne i kiedy je przejrzeć.

Tabela stosuje to podejście do tego uruchomienia; niekompletne dowody utrzymują priorytet jako wstępny:

Priorytet 2 nie oznacza nieszkodliwości; dowody pozostają niekompletne. Przypisz każdemu nierozwiązanemu elementowi właściciela i termin. Podnieś go, jeśli weryfikacja potwierdzi ekspozycję lub słabość. Jeśli jest celowy i kontrolowany, wyraźnie zanotuj decyzję.

Etykieta raportu nie określa kolejności: weryfikacja i kontekst to robią.

⚠️ Ostrzeżenie: Nie zmieniaj uwierzytelniania SSH ani reguł zapory sieciowej z tej sekwencji poleceń. Błąd może Cię zablokować. Przed naprawą potwierdź przetestowany dostęp klucza i zweryfikuj nową konfigurację. Utrzymuj drugą sesję otwartą i upewnij się, że dostęp do konsoli lub odzyskiwania działa.

Obsługuj każdą naprawę jako oddzielny przepływ pracy. Zmapuj zależności przed zatrzymaniem usług, sklasyfikuj aktualizacje przed zaplanowaniem ich i zweryfikuj właścicielstwo i sumy kontrolne przed zmianą uprawnień SUID.

Gdzie zatrzymuje się widok vps-audit

vps-audit v0.2.0 to lista kontrolna Bash z określonym momentem. Nie może ustalić ekspozycji zewnętrznej, wykryć luk w zabezpieczeniach lub złośliwego oprogramowania, sprawdzić obciążeń, analizować przechowywanych dzienników ani zapewniać ciągłego monitorowania. Nie jest testem penetracyjnym ani oceną CIS Benchmark.

Kod dodaje ważne zastrzeżenia.

• Status portu staje się PASS poniżej trzech przeanalizowanych portów TCP, WARN przy trzech lub czterech i FAIL przy pięciu lub więcej—pomimo nominalnych zmiennych 10/20.
• PASS dla unattended-upgrades sprawdza tylko pakiet, nie jego konfigurację, timer ani historię uruchomień.
• Test aktualizacji używa buforowanych metadanych dla ogólnego apt-get -s upgrade, a następnie każdy wymieniony pakiet nazywa „aktualizacją bezpieczeństwa”.

Test sudo-logging odczytuje tylko /etc/sudoers, pomijając /etc/sudoers.d/ i normalne rekordy dziennika lub syslog. Problem #33, otwarty podczas sprawdzenia 8 września 2026, dokumentuje to fałszywe FAIL na Ubuntu 20.04 i 24.04. Analiza może również zawieść z danymi wyjściowymi w języku innym niż angielski, co jest śledzone w otwartym problemie #37. Pomimo sformułowania README, ta wersja nie wyświetla nawiązanych połączeń.

Poszerz przegląd w razie potrzeby. Podejrzane zachowanie wymaga analizy przechowywanych dzienników i obciążeń. Dla ważnego VPS potwierdź przetestowane kopie zapasowe i rozważ autoryzowane testy zewnętrzne. Systemy krytyczne lub regulowane mogą wymagać Lynis, Ubuntu 24.04 CIS Benchmark lub profesjonalnego przeglądu.

Podsumowanie: Weryfikuj, Ustalaj Priorytety i Sprawdzaj Ponownie

Zachowaj oryginalny raport jako prywatny i utrzymuj zredagowaną kopię. Zapisz SHA-256 skryptu, tag i commit razem z czasem uruchomienia, zamierzonymi usługami, wynikami weryfikacji i kolejką działań.

1. Weryfikuj ustalenia o dużym wpływie za pomocą natywnych poleceń przed zmianą serwera.
2. Bezpiecznie napraw potwierdzone problemy wysokiego ryzyka, zbadaj nieznane i udokumentuj celowe wyjątki.
3. Uruchom ponownie tę samą przypiętą wersję po zmianach lub zgodnie z harmonogramem, a następnie porównaj raporty ręcznie.

Porównując raporty, skoncentruj się na zmianach uwierzytelniania, regułach zapory, nasłuchiwaczach i rozwiązanych ustaleniach. Znaczniki czasu i odczyty zasobów będą się zmieniać. Zanotuj celowe zmiany, aby następny recenzent zrozumiał, dlaczego wyniki się różnią.

vps-audit nie ma bazowej bazy danych, harmonogramu, analizy trendów ani silnika porównawczego. Jego wartość wynika z powtarzalnego nawyku: uruchom, weryfikuj, ustalaj priorytety i sprawdzaj ponownie.