Cum să auditezi un Linux VPS cu vps-audit—și să citești corect rezultatele

O Audit Rapid de VPS Este un Punct de Plecare, Nu un Verdict

Website-ul tău se încarcă și SSH răspunde, dar asta nu relevă actualizări în așteptare, setări SSH permisive sau ascultători neașteptați. O audit de primă trecere ridică acele întrebări.

vps-audit este o listă de verificare Bash pentru Debian și Ubuntu care transformă semnalele de configurație locală, întreținere, ascultător și resurse într-un raport codificat după culoare. Ca un tablou de bord al unui vehicul, indică zonele care necesită inspecție fără a diagnostica fiecare cauză.

Acest ghid rulează în siguranță vps-audit v0.2.0, verifică rezultatele importante cu instrumente native și le transformă în priorități. Exemplul folosește un VPS Ubuntu AlexHost care rulează Ubuntu 24.04 LTS. Alte imagini de la furnizori pot diferi, iar sistemul de operare neadministrat rămas este responsabilitatea operatorului.

Ce verifică vps-audit—și ce nu poate dovedi

vps-audit verifică indicatori locali fără a examina nicio zonă exhaustiv. Acest tabel arată ce poate—și ce nu poate—să vă spună fiecare rezultat.

SUID permite unui program să ruleze cu privilegiile efective ale proprietarului fișierului. Programele de sistem legitime o folosesc, deci investigați un fișier SUID neașteptat în loc să-l ștergeți. Fail2ban și CrowdSec pot bloca traficul ostil, dar instalarea sau starea activă singură nu dovedește că protejează serviciul destinat.

Scriptul aplică praguri generice pentru utilizarea resurselor, servicii, autentificări eșuate și ascultători. Acestea nu sunt scoruri de risc conștiente de sarcină de lucru; roluri VPS diferite pot atinge aceeași culoare din motive diferite.

Instrumentul nu inspectează malware, vulnerabilități cunoscute, aplicații, containere, firewall-uri ale furnizorului, conformitate sau tendințe. Deși README-ul menționează “Active Internet Connections,” v0.2.0 doar preia IP-ul public și inventariază ascultători locali. Deoarece are nevoie de vizibilitate privilegiată, controlați mai întâi care fișier primește acces sudo.

Înainte de a da unui script descărcat sudo

Acest flux de lucru Debian/Ubuntu necesită acces SSH, sudo, și instrumentele standard utilizate mai jos. Lucrați într-un director jetabil. Dacă un instrument lipsește, opriți-vă mai degrabă decât să schimbați linia de bază instalând-o.

Exemplul folosește vps-audit v0.2.0, publicat pe 10 august 2026 și încă cel mai recent când a fost verificat pe 8 septembrie 2026.

Eticheta sa indică commit-ul 57c323d46b48026740f0b35b9bad6cd6127c757b. Fixarea evită o schimbare ulterioară din main mutabil.

Creați un director dedicat și descărcați acel script etichetat exact peste 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

Aceasta salvează vps-audit.sh în noul director. Opțiunea -f eșuează la erori HTTP, în timp ce -L urmărește redirecționările.

Apoi, înregistrați o amprentă SHA-256 locală și afișați setările relevante pentru această procedură:

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

Rezultatul amprentează fișierul și arată calea raportului, pragurile și cererea către api.ipify.org. Sursa completă etichetată citește, de asemenea, starea locală, simulează apt-get -s upgrade, și caută recursiv fișiere SUID. Nu este doar citire: scrie un raport, poate crea directorul acestuia și contactează un serviciu extern. Revizuiți sursa înainte de a acorda privilegii ridicate dacă puteți citi codul shell.

Pragurile de resurse sunt 50% pentru WARN și 80% pentru FAIL. Serviciile care rulează utilizează 20/40, logări eșuate 10/50, ascultători nominal 10/20, și lungimea parolei 12. Secțiunea limitări explică de ce starea ascultătorului nu urmează acele variabile.

⚠️ Avertisment: Fixarea, hashing-ul, inspecția țintită și verificarea sintaxei îmbunătățesc reproductibilitatea, dar nu stabilesc încrederea. Commit-ul este nesemnat, iar versiunea nu oferă niciun activ de checksum sau semnătură.

Păstrați hash-ul cu notele de audit. Înainte de o execuție, comparați-l cu fișierul. O potrivire arată că copiile conțin aceiași octeți. O diferență poate proveni dintr-o altă versiune, o descărcare schimbată sau o editare locală. Înregistrarea etichetei și hash-ului leagă fiecare raport de scriptul care l-a produs.

În final, analizați fișierul fără a executa comenzile sale normale, apoi adăugați permisiunea de execuție doar dacă analiza reușește:

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

Aceasta confirmă doar că Bash poate analiza fișierul și că permisiunea de execuție a fost adăugată. Scriptul fixat este acum gata pentru o execuție neschimbată.

Rulați vps-audit și Localizați Raportul

Scriptul afișează detaliile sistemului și statusurile colorate, apoi scrie un raport în text simplu. Căutarea recursivă SUID face runtime-ul variabil, deci măsurați-l.

Rulați fișierul fixat o dată și păstrați statusul de ieșire al procesului 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"

Pe VPS-ul testat, auditul a început la 13:12:10 UTC pe 14 septembrie 2026 și s-a încheiat în 58.412 secunde. A returnat 0 și a salvat ./vps-audit-report-20260914_131210.txt.

Elapsed real este timpul de perete; valorile user și system măsoară timpul CPU. Statusul de ieșire 0 înseamnă că procesul s-a încheiat, nu că fiecare verificare a trecut. v0.2.0 returnează 0 chiar și cu rezultate FAIL.

Selectați raportul nou, inspectați metadatele acestuia și extrageți numărări și exemple fără a afișa fișierul sensibil în întregime.

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"

Ora de modificare 13:13:08 UTC a raportului a corespuns rulării. Acesta conținea 17 rezultate: șase PASS, trei WARN și opt FAIL. Acestea sunt clasificări, nu un scor de securitate.

Totalurile statusului sunt utile atunci când comparați rulări ale aceleiași versiuni, dar inspectați întotdeauna liniile din spatele unei schimbări. Un număr mai mic de FAIL poate proveni din intrări diferite sau comportament parser mai degrabă decât o îmbunătățire. Un total neschimbat poate ascunde și o problemă rezolvată și una nouă.

Raportul de 2.665 de octeți aparținea root:root cu modul 644 (-rw-r--r--), așa cum era de așteptat cu sudo și ENABLE_CHOWN=false standard. Utilizatorii grup și alții pot citi acel mod dacă permisiunile directoarelor le permit să ajungă la fișier. Proprietatea root singură nu o face privată.

❗ Important: Raportul conține hostname-ul, IP-ul public, detaliile sistemului și constatările. Păstrați-l privat și redactați identificatorii, prompturile și informațiile sensibile ale serviciilor înainte de a le partaja.

Dacă o rulare viitoare lipsește un status, înregistrați acea absență mai degrabă decât reconfigurați VPS-ul pentru a fabrica o culoare.

Cum să citești PASS, WARN și FAIL Fără a Suprareacționa

Etichetele din dashboard raportează cum fiecare test s-a potrivit cu regulile v0.2.0:

Separă observația de recomandare. În “22 de servicii în execuție,” numărul este observația; “reduce suprafața de atac” este sfat bazat pe un prag generic. Confirmă numărul, identifică serviciile, și apoi decide dacă acel sfat se potrivește serverului.

Pune trei întrebări pentru fiecare rezultat: Este valoarea exactă? Este intenționată? Care este impactul realist? Comenzile native verifică valoarea; contextul sarcinii de lucru determină restul.

WARN-ul pentru portul SSH se bazează pe politică: v0.2.0 marchează portul 22. Mutarea SSH poate reduce zgomotul automatizat, dar nu poate înlocui autentificarea puternică sau controalele de acces. Un serviciu cunoscut pe portul 22 poate conta mai puțin decât un ascultător wildcard necunoscut.

Pentru un FAIL, inspectează regula înainte de a propune o reparație. Testul root-login acceptă doar PermitRootLogin no, deci setarea distinctă prohibit-password încă eșuează. Verifică OpenSSH direct înainte de a acționa.

Un PASS necesită, de asemenea, context. Pentru unattended-upgrades, scriptul confirmă doar că pachetul există—nu configurația sau istoricul rulării sale.

Verificați constatările cu impact ridicat cu comenzi native

Utilizați comenzi native read-only pentru a verifica accesul SSH, filtrarea gazdei și ascultătorii locali. În primul rând, întrebați ce rezolvă OpenSSH după ce implicițiile și configurația inclusă sunt combinate:

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

Ubuntu încarcă /etc/ssh/sshd_config.d/*.conf aproape de începutul configurației sale principale. sshd -T rezolvă setările combinate, făcând-o o dovadă mai puternică decât grep-ul unui singur fișier.

OpenSSH a rezolvat portul 22 pe adrese IPv4 și IPv6 wildcard. De asemenea, a returnat permitrootlogin yes, passwordauthentication yes, pubkeyauthentication yes, și kbdinteractiveauthentication no. Configurația rezolvată confirmă constatările scriptului privind autentificarea root-login și password-authentication, deși starea contului, PAM și regulile Match pot afecta în continuare o anumită autentificare.

În al doilea rând, întrebați ce raportează UFW despre starea și politica sa gestionată:

sudo ufw status verbose

Ubuntu documentează UFW ca frontend implicit al firewall-ului. Aici era activ cu înregistrare la nivel scăzut și politici default-deny pentru traficul de intrare și rutare. Regulile permiteau porturile de intrare 22, 80, 443 și 37985 peste IPv4 și IPv6. Aceasta confirmă starea UFW, nu dacă fiecare regulă este adecvată.

În al treilea rând, inventariați ascultătorii TCP și UDP locali, adresele de legare și procesele proprietare:

sudo ss -lntup

Opțiunile selectează ascultătorii TCP și UDP numerici și solicită detalii despre proces. Porturile 53, 62789, 8404 și 11111 erau doar loopback; porturile 22, 80, 2096, 5678 și 37985 utilizau adrese wildcard. Nu au apărut detalii despre proces, deci proprietarii și scopurile lor rămân necunoscute.

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

Porturile 22, 80 și 37985 aveau atât ascultători wildcard cât și reguli de permisiune UFW. UFW a permis 443 fără un ascultător, în timp ce 2096 și 5678 aveau ascultători fără reguli de permisiune afișate.

O regulă de firewall și un ascultător răspund la întrebări diferite. Regula permite traficul dacă un serviciu este acolo pentru a-l accepta; ascultătorul arată un serviciu în așteptare, dar nu dacă traficul de rețea poate ajunge la el. Citirea ambelor împreună restrânge investigația fără a pretinde expunere externă.

📝 Notă: ss arată starea legării locale, iar UFW arată un firewall gazdă. Nici una nu dovedește accesibilitatea pe Internet în rețelele furnizorului sau NAT; aceasta necesită testare autorizată dintr-un alt sistem.

v0.2.0 cu toate acestea etichetează aceeași listă “Total” și “Public” după eliminarea adreselor de legare, deși patru din nouă porturi TCP erau doar loopback. Filtrul LISTEN al acestuia pierde și rândurile UDP marcate UNCONN. Citiți acest rezultat ca un număr de port TCP local, nu expunere publică.

Transformă Constatările Verificate într-o Coadă de Acțiuni Practică

Stabilește prioritatea după încredere, expunere, impact și intenție. Prioritatea 1 acoperă slăbiciuni confirmate care necesită acțiune. Prioritatea 2 acoperă constatări importante care necesită încă investigație, în timp ce Prioritatea 3 acoperă elemente cu risc mai scăzut sau conduse de politică. Dacă o setare este intenționată, documentează de ce, orice control compensator și când să o revizuiești.

Tabelul aplică această abordare acestei execuții; dovezile incomplete păstrează o prioritate provizoriu:

Prioritatea 2 nu înseamnă inofensiv; dovezile rămân incomplete. Atribuie fiecărui element nerezolvat un proprietar și o dată limită. Promoveaz-o dacă verificarea confirmă expunere sau slăbiciune. Dacă este intenționată și controlată, înregistrează decizia clar.

Eticheta raportului nu stabilește ordinea: verificarea și contextul o fac.

⚠️ Avertisment: Nu modifica autentificarea SSH sau regulile firewall-ului la distanță din această secvență de comenzi. O greșeală te poate bloca. Înainte de remediere, confirmă accesul testat prin cheie și validează noua configurație. Ține deschisă o a doua sesiune și asigură-te că accesul la consolă sau recuperare funcționează.

Tratează fiecare remediere ca un flux de lucru separat. Mapează dependențele înainte de a opri serviciile, clasifică actualizările înainte de a le programa și verifică proprietatea și sumele de control înainte de a modifica permisiunile SUID.

Unde se oprește vizualizarea vps-audit

vps-audit v0.2.0 este o listă de verificare Bash într-un moment specific. Nu poate stabili expunerea externă, detecta vulnerabilități sau malware, inspecta sarcini de lucru, analiza jurnale stocate sau oferi monitorizare continuă. Nu este un test de penetrare sau o evaluare CIS Benchmark.

Codul adaugă avertismente importante.

• Starea portului devine PASS sub trei porturi TCP analizate, WARN la trei sau patru, și FAIL la cinci sau mai multe—în ciuda variabilelor nominale 10/20.
• O verificare PASS pentru unattended-upgrades verifică doar pachetul, nu configurația, timerul sau istoricul execuției acestuia.
• Testul de actualizare utilizează metadate în cache pentru o apt-get -s upgrade generală, apoi numește fiecare pachet listat o „actualizare de securitate”.

Testul de înregistrare sudo citește doar /etc/sudoers, lipsind /etc/sudoers.d/ și înregistrările normale din jurnal sau syslog. Problema #33, deschisă la verificarea din 8 septembrie 2026, documentează acest FAIL fals pe Ubuntu 20.04 și 24.04. Analiza poate eșua și cu ieșire în limba non-engleză, așa cum este urmărită în problema #37 deschisă. În ciuda redacției README, această versiune nu listează conexiuni stabilite.

Extindeți revizuirea atunci când este necesar. Comportamentul suspect necesită analiză jurnalelor stocate și a sarcinilor de lucru. Pentru un VPS important, confirmați copiile de siguranță testate și luați în considerare testarea externă autorizată. Sistemele critice sau reglementate pot necesita Lynis, Ubuntu 24.04 CIS Benchmark sau revizuire profesională.

Concluzie: Verifică, Prioritizează și Recontrolează

Păstrează raportul original privat și menține o copie redactată. Înregistrează SHA-256 al scriptului, tag-ul și commit-ul împreună cu timpul de execuție, serviciile destinate, rezultatele verificării și coada de acțiuni.

1. Verifică constatările cu impact ridicat cu comenzi native înainte de a modifica serverul.
2. Remediază problemele confirmate cu risc ridicat în siguranță, investighează necunoscutele și documentează excepțiile intenționate.
3. Reexecută aceeași versiune fixată după modificări sau conform unui program, apoi compară rapoartele manual.

Când compari rapoartele, concentrează-te pe modificările de autentificare, regulile firewall-ului, ascultători și constatările rezolvate. Marcajele de timp și citirile de resurse se vor schimba. Notează modificările deliberate pentru ca următorul revisor să înțeleagă de ce diferă rezultatele.

vps-audit nu are bază de date de referință, planificator, analiză de tendințe sau motor de comparație. Valoarea sa provine dintr-un obicei repetabil: execută, verifică, prioritizează și recontrolează.