Wie man einen Linux VPS mit vps-audit überprüft – und die Ergebnisse richtig interpretiert

Ein schneller VPS-Audit ist ein Ausgangspunkt, keine Verdikt

Ihre Website lädt und SSH antwortet, aber das offenbart keine ausstehenden Updates, permissive SSH-Einstellungen oder unerwartete Listener. Ein First-Pass-Audit stellt diese Fragen auf.

vps-audit ist eine Bash-Checkliste für Debian und Ubuntu, die lokale Konfiguration, Wartung, Listener und Ressourcensignale in einen farbcodierten Bericht umwandelt. Wie ein Fahrzeug-Dashboard zeigt es Bereiche, die einer Überprüfung bedürfen, ohne jede Ursache zu diagnostizieren.

Dieses Handbuch führt pinned vps-audit v0.2.0 sicher aus, überprüft wichtige Ergebnisse mit nativen Tools und wandelt sie in Prioritäten um. Das Beispiel verwendet einen AlexHost Ubuntu VPS mit Ubuntu 24.04 LTS. Andere Provider-Images können unterschiedlich sein, und das verwaltete Gast-OS bleibt die Verantwortung des Betreibers.

Was vps-audit überprüft – und was es nicht beweisen kann

vps-audit überprüft lokale Indikatoren, ohne einen Bereich vollständig zu untersuchen. Diese Tabelle zeigt, was jedes Ergebnis – und was es nicht – aussagen kann.

SUID ermöglicht es einem Programm, mit den effektiven Berechtigungen des Dateieigentümers ausgeführt zu werden. Legitime Systemprogramme verwenden es, daher sollten Sie eine unerwartete SUID-Datei untersuchen, anstatt sie zu löschen. Fail2ban und CrowdSec können feindselige Datenverkehr blockieren, aber Installation oder aktiver Status allein beweist nicht, dass sie den beabsichtigten Service schützen.

Das Skript wendet generische Schwellenwerte auf Ressourcennutzung, Services, fehlgeschlagene Anmeldungen und Listener an. Dies sind keine Workload-bewussten Risikobewertungen; verschiedene VPS-Rollen können aus verschiedenen Gründen die gleiche Farbe erreichen.

Das Tool inspiziert keine Malware, bekannte Sicherheitslücken, Anwendungen, Container, Provider-Firewalls, Compliance oder Trends. Obwohl die README „Aktive Internetverbindungen” erwähnt, ruft v0.2.0 nur die öffentliche IP ab und inventarisiert lokale Listener. Da es privilegierte Sichtbarkeit benötigt, kontrollieren Sie zunächst, welche Datei sudo-Zugriff erhält.

Bevor Sie einem heruntergeladenen Script sudo geben

Dieser Debian/Ubuntu-Workflow erfordert SSH-Zugriff, sudo und die unten verwendeten Standardtools. Arbeiten Sie in einem wegwerfbaren Verzeichnis. Wenn ein Tool fehlt, stoppen Sie, anstatt die Baseline durch Installation zu ändern.

Das Beispiel verwendet vps-audit v0.2.0, veröffentlicht am 10. August 2026 und noch aktuell bei Überprüfung am 8. September 2026.

Sein Tag verweist auf Commit 57c323d46b48026740f0b35b9bad6cd6127c757b. Das Pinning vermeidet eine spätere Änderung des veränderlichen main.

Erstellen Sie ein dediziertes Verzeichnis und laden Sie das exakte getaggte Script über HTTPS herunter:

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

Dies speichert vps-audit.sh im neuen Verzeichnis. Die Option -f schlägt bei HTTP-Fehlern fehl, während -L Umleitungen folgt.

Erfassen Sie anschließend einen lokalen SHA-256-Fingerabdruck und zeigen Sie die für diese Anleitung relevanten Einstellungen an:

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

Die Ausgabe erstellt einen Fingerabdruck der Datei und zeigt ihren Berichtspfad, Schwellwerte und Anfrage an api.ipify.org. Der vollständige getaggte Quellcode liest auch den lokalen Status, simuliert apt-get -s upgrade und sucht rekursiv nach SUID-Dateien. Es ist nicht schreibgeschützt: Es schreibt einen Bericht, kann sein Verzeichnis erstellen und kontaktiert einen externen Service. Überprüfen Sie die Quelle, bevor Sie erhöhte Privilegien gewähren, falls Sie Shell-Code lesen können.

Ressourcenschwellwerte sind 50% für WARN und 80% für FAIL. Laufende Services verwenden 20/40, fehlgeschlagene Anmeldungen 10/50, Listener nominal 10/20 und Passwortlänge 12. Der Abschnitt Einschränkungen erklärt, warum der Listener-Status diese Variablen nicht befolgt.

⚠️ Warnung: Pinning, Hashing, gezielte Inspektion und Syntaxprüfung verbessern die Reproduzierbarkeit, begründen aber kein Vertrauen. Der Commit ist unsigniert, und die Veröffentlichung bietet kein Checksum- oder Signatur-Asset.

Bewahren Sie den Hash mit den Audit-Notizen auf. Vergleichen Sie ihn vor einem Lauf mit der Datei. Eine Übereinstimmung zeigt, dass Kopien die gleichen Bytes enthalten. Ein Unterschied kann von einer anderen Veröffentlichung, einem geänderten Download oder einer lokalen Bearbeitung stammen. Das Aufzeichnen des Tags und des Hash verknüpft jeden Bericht mit dem Script, das ihn erstellt hat.

Analysieren Sie abschließend die Datei, ohne ihre normalen Befehle auszuführen, und fügen Sie die Ausführungsberechtigung nur hinzu, wenn die Analyse erfolgreich ist:

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

Dies bestätigt nur, dass Bash die Datei analysieren kann und dass die Ausführungsberechtigung hinzugefügt wurde. Das gepinnte Script ist nun bereit für einen unveränderten Lauf.

Führen Sie vps-audit aus und lokalisieren Sie den Bericht

Das Skript gibt Systemdetails und farbige Status aus und schreibt dann einen Klartextbericht. Die rekursive SUID-Suche macht die Laufzeit variabel, daher messen Sie sie.

Führen Sie die angeheftete Datei einmal aus und bewahren Sie den Exit-Status des Shell-Prozesses:

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"

Auf der getesteten VPS begann die Prüfung am 14. September 2026 um 13:12:10 UTC und endete nach 58,412 Sekunden. Sie gab 0 zurück und speicherte ./vps-audit-report-20260914_131210.txt.

Elapsed real ist die Wanduhrzeit; user- und system-Werte messen CPU-Zeit. Exit-Status 0 bedeutet, dass der Prozess abgeschlossen wurde, nicht dass jede Prüfung bestanden wurde. v0.2.0 gibt 0 auch bei FAIL-Ergebnissen zurück.

Wählen Sie den neuen Bericht aus, überprüfen Sie seine Metadaten und extrahieren Sie Zählungen und Beispiele, ohne die sensible Datei vollständig anzuzeigen.

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"

Die Änderungszeit des Berichts um 13:13:08 UTC stimmte mit der Ausführung überein. Er enthielt 17 Ergebnisse: sechs PASS, drei WARN und acht FAIL. Dies sind Klassifizierungen, keine Sicherheitsbewertung.

Status-Summen sind nützlich beim Vergleich von Läufen derselben Version, aber überprüfen Sie immer die Zeilen hinter einer Änderung. Eine niedrigere FAIL-Anzahl kann aus unterschiedlichen Eingaben oder Parser-Verhalten stammen, nicht aus einer Verbesserung. Eine unveränderte Summe kann auch ein gelöstes Problem und ein neues verbergen.

Der 2.665-Byte-Bericht gehörte zu root:root mit Modus 644 (-rw-r--r--), wie erwartet mit sudo und Standard-ENABLE_CHOWN=false. Gruppen- und andere Benutzer können diese Berechtigung lesen, wenn Verzeichnisberechtigungen ihnen den Zugriff auf die Datei ermöglichen. Allein die Root-Eigentümerschaft macht sie nicht privat.

❗ Wichtig: Der Bericht enthält den Hostnamen, die öffentliche IP, Systemdetails und Ergebnisse. Halten Sie ihn privat und redigieren Sie Kennungen, Eingabeaufforderungen und sensible Dienstinformationen, bevor Sie ihn freigeben.

Wenn ein zukünftiger Lauf einen Status nicht aufweist, notieren Sie diese Abwesenheit, anstatt die VPS neu zu konfigurieren, um eine Farbe zu erzeugen.

Wie man PASS, WARN und FAIL liest, ohne überreagieren

Die Dashboard-Labels zeigen, wie jeder Test den Regeln von v0.2.0 entsprach:

Trennen Sie die Beobachtung von der Empfehlung. Bei „22 Services laufen” ist die Anzahl die Beobachtung; „Angriffsfläche reduzieren” ist ein Rat basierend auf einem generischen Schwellenwert. Bestätigen Sie die Anzahl, identifizieren Sie die Services und entscheiden Sie dann, ob dieser Rat zum Server passt.

Stellen Sie drei Fragen zu jedem Ergebnis: Ist der Wert genau? Ist er beabsichtigt? Welche realistische Auswirkung hat er? Native Befehle überprüfen den Wert; der Workload-Kontext bestimmt den Rest.

Die SSH-Port-WARN ist richtliniengestützt: v0.2.0 kennzeichnet Port 22. Das Verschieben von SSH kann automatisiertes Rauschen reduzieren, kann aber starke Authentifizierung oder Zugriffskontrolle nicht ersetzen. Ein bekannter Service auf Port 22 kann weniger wichtig sein als ein unbekannter Wildcard-Listener.

Überprüfen Sie bei einem FAIL die Regel, bevor Sie eine Lösung vorschlagen. Der Root-Login-Test akzeptiert nur PermitRootLogin no, daher schlägt die unterschiedliche Einstellung prohibit-password immer noch fehl. Überprüfen Sie OpenSSH direkt, bevor Sie handeln.

Ein PASS benötigt auch Kontext. Bei unattended-upgrades bestätigt das Skript nur, dass das Paket existiert – nicht seine Konfiguration oder Ausführungshistorie.

Überprüfen Sie hochwertige Erkenntnisse mit nativen Befehlen

Verwenden Sie schreibgeschützte native Befehle, um SSH-Zugriff, Host-Filterung und lokale Listener zu überprüfen. Fragen Sie zunächst, was OpenSSH nach Kombination von Standardeinstellungen und eingebundener Konfiguration tatsächlich auflöst:

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

Ubuntu lädt /etc/ssh/sshd_config.d/*.conf nahe dem Anfang seiner Hauptkonfiguration. sshd -T löst die kombinierten Einstellungen auf und ist damit ein stärkerer Beweis als das Durchsuchen einer einzelnen Datei.

OpenSSH hat Port 22 auf Wildcard-IPv4- und IPv6-Adressen aufgelöst. Es gab auch permitrootlogin yes, passwordauthentication yes, pubkeyauthentication yes und kbdinteractiveauthentication no zurück. Die aufgelöste Konfiguration bestätigt die Erkenntnisse des Skripts zu Root-Login und Passwortauthentifizierung, obwohl der Kontostatus, PAM und Match-Regeln einen bestimmten Login dennoch beeinflussen können.

Fragen Sie zweitens, was UFW selbst über seinen Status und seine verwaltete Richtlinie meldet:

sudo ufw status verbose

Ubuntu dokumentiert UFW als sein Standard-Firewall-Frontend. Hier war es aktiv mit Low-Level-Protokollierung und Deny-by-Default-Richtlinien für eingehenden und weitergeleitet Traffic. Regeln erlaubten eingehende Ports 22, 80, 443 und 37985 über IPv4 und IPv6. Dies bestätigt UFWs Status, nicht ob jede Regel angemessen ist.

Drittens: Inventarisieren Sie lokale TCP- und UDP-Listener, Bind-Adressen und besitzende Prozesse:

sudo ss -lntup

Die Optionen wählen numerische TCP- und UDP-Listener aus und fordern Prozessdetails an. Ports 53, 62789, 8404 und 11111 waren nur Loopback; Ports 22, 80, 2096, 5678 und 37985 verwendeten Wildcard-Adressen. Es erschienen keine Prozessdetails, daher bleiben ihre Besitzer und Zwecke unbekannt.

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

Ports 22, 80 und 37985 hatten sowohl Wildcard-Listener als auch UFW-Allow-Regeln. UFW erlaubte 443 ohne Listener, während 2096 und 5678 Listener ohne angezeigte Allow-Regeln hatten.

Eine Firewall-Regel und ein Listener beantworten unterschiedliche Fragen. Die Regel erlaubt Traffic, wenn ein Service vorhanden ist, um ihn zu akzeptieren; der Listener zeigt einen wartenden Service, aber nicht ob Netzwerk-Traffic ihn erreichen kann. Das Lesen beider zusammen grenzt die Untersuchung ein, ohne externe Exposition zu behaupten.

📝 Hinweis: ss zeigt lokalen Bind-Status und UFW zeigt eine Host-Firewall. Keines beweist Internet-Erreichbarkeit über Provider-Firewalls oder NAT; das erfordert autorisiertes Testen von einem anderen System.

v0.2.0 kennzeichnet dennoch die gleiche Liste als „Total” und „Public”, nachdem Bind-Adressen verworfen wurden, obwohl vier von neun TCP-Ports nur Loopback waren. Sein LISTEN-Filter übersieht auch UDP-Zeilen, die als UNCONN gekennzeichnet sind. Lesen Sie dieses Ergebnis als lokale TCP-Port-Anzahl, nicht als öffentliche Exposition.

Verifizierte Erkenntnisse in eine praktische Aktionswarteschlange umwandeln

Legen Sie die Priorität nach Konfidenz, Exposition, Auswirkung und Absicht fest. Priorität 1 umfasst bestätigte Schwachstellen, die Maßnahmen erfordern. Priorität 2 umfasst wichtige Erkenntnisse, die noch untersucht werden müssen, während Priorität 3 niedrigerrisiko- oder richtliniengesteuerte Elemente umfasst. Wenn eine Einstellung beabsichtigt ist, dokumentieren Sie, warum, welche kompensierenden Kontrollen vorhanden sind, und wann sie überprüft werden soll.

Die Tabelle wendet diesen Ansatz auf diesen Durchlauf an; unvollständige Beweise halten eine Priorität vorläufig:

Priorität 2 bedeutet nicht harmlos; Beweise bleiben unvollständig. Geben Sie jedem ungelösten Element einen Besitzer und eine Frist. Erhöhen Sie die Priorität, wenn die Verifizierung Exposition oder Schwachstelle bestätigt. Wenn es beabsichtigt und kontrolliert ist, dokumentieren Sie die Entscheidung deutlich.

Das Berichtsetikett legt nicht die Reihenfolge fest: Verifizierung und Kontext tun dies.

⚠️ Warnung: Ändern Sie SSH-Authentifizierung oder Remote-Firewall-Regeln nicht aus dieser Befehlssequenz. Ein Fehler kann Sie aussperren. Bestätigen Sie vor der Behebung getesteten Schlüsselzugriff und validieren Sie die neue Konfiguration. Halten Sie eine zweite Sitzung offen und stellen Sie sicher, dass Konsolen- oder Wiederherstellungszugriff funktioniert.

Behandeln Sie jede Behebung als separaten Workflow. Ordnen Sie Abhängigkeiten zu, bevor Sie Services beenden, klassifizieren Sie Updates, bevor Sie sie planen, und überprüfen Sie Besitz und Prüfsummen, bevor Sie SUID-Berechtigungen ändern.

Wo die Ansicht von vps-audit endet

vps-audit v0.2.0 ist eine Bash-Checkliste zu einem bestimmten Zeitpunkt. Sie kann externe Exposition nicht feststellen, Sicherheitslücken oder Malware nicht erkennen, Workloads nicht überprüfen, gespeicherte Protokolle nicht analysieren oder kontinuierliche Überwachung nicht bereitstellen. Es ist kein Penetrationstest oder CIS Benchmark-Bewertung.

Der Code fügt wichtige Einschränkungen hinzu.

• Der Port-Status wird unter drei geparsten TCP-Ports zu PASS, bei drei oder vier zu WARN und bei fünf oder mehr zu FAIL – trotz der nominalen 10/20-Variablen.
• Ein unattended-upgrades PASS prüft nur auf das Paket, nicht auf seine Konfiguration, seinen Timer oder seine Ausführungsverlauf.
• Der Update-Test verwendet zwischengespeicherte Metadaten für ein allgemeines apt-get -s upgrade, nennt dann jedes aufgelistete Paket ein „Sicherheits-Update”.

Der sudo-Logging-Test liest nur /etc/sudoers, übersieht /etc/sudoers.d/ und normale Journal- oder Syslog-Einträge. Issue #33, offen bei der Überprüfung am 8. September 2026, dokumentiert diesen falschen FAIL auf Ubuntu 20.04 und 24.04. Das Parsing kann auch bei nicht-englischer Ausgabe fehlschlagen, wie in der offenen Issue #37 verfolgt. Trotz der Formulierung in der README listet diese Version keine etablierten Verbindungen auf.

Erweitern Sie die Überprüfung bei Bedarf. Verdächtiges Verhalten erfordert Analyse von gespeicherten Protokollen und Workloads. Für einen wichtigen VPS bestätigen Sie getestete Backups und erwägen Sie autorisierte externe Tests. Kritische oder regulierte Systeme können Lynis, den Ubuntu 24.04 CIS Benchmark oder eine professionelle Überprüfung rechtfertigen.

Fazit: Überprüfen, Priorisieren und Erneut Überprüfen

Halten Sie den ursprünglichen Bericht privat und führen Sie eine geschwärzte Kopie. Notieren Sie das SHA-256, Tag und Commit des Skripts zusammen mit der Laufzeit, beabsichtigten Services, Überprüfungsergebnissen und Aktionswarteschlange.

1. Überprüfen Sie hochgradig auswirkungsreiche Erkenntnisse mit nativen Befehlen, bevor Sie den Server ändern.
2. Beheben Sie bestätigte Hochrisikoprobleme sicher, untersuchen Sie Unbekannte und dokumentieren Sie beabsichtigte Ausnahmen.
3. Führen Sie dieselbe angeheftete Version nach Änderungen oder nach einem Zeitplan erneut aus und vergleichen Sie die Berichte manuell.

Konzentrieren Sie sich beim Vergleich von Berichten auf Authentifizierungsänderungen, Firewall-Regeln, Listener und aufgelöste Erkenntnisse. Zeitstempel und Ressourcenablesungen werden sich ändern. Notieren Sie bewusste Änderungen, damit der nächste Prüfer versteht, warum sich die Ergebnisse unterscheiden.

vps-audit hat keine Basisdatenbank, keinen Planer, keine Trendanalyse oder Vergleichsmodul. Sein Wert ergibt sich aus einer wiederholbaren Gewohnheit: Ausführen, Überprüfen, Priorisieren und Erneut Überprüfen.