Cum securizezi un VPS: SSH keys, firewall, Fail2Ban și bune practici

Un VPS nou trebuie securizat înainte să găzduiești aplicații sau date importante pe el. Configurația minimă include actualizarea sistemului, un utilizator administrativ separat de root, autentificare SSH cu cheie, firewall, Fail2Ban, actualizări automate, backup și monitorizare. Ordinea este importantă: dacă dezactivezi parola sau accesul root înainte să verifici noua metodă de conectare, te poți bloca în afara serverului.

Ghidul de mai jos este conceput pentru Ubuntu Server și Debian. Comenzile trebuie adaptate dacă folosești AlmaLinux, Rocky Linux sau o distribuție cu alt manager de pachete. Păstrează sesiunea SSH curentă deschisă până când testezi cu succes o a doua conexiune.

Înainte să începi

Asigură-te că ai acces la consola VPS-ului din panoul furnizorului. Consola este metoda de recuperare dacă firewallul sau configurația SSH blochează accesul prin rețea. Dacă serverul conține deja date, creează un backup înaintea modificărilor.

Verifică sistemul de operare și utilizatorul curent:

cat /etc/os-release
whoami
hostnamectl

În exemple folosim utilizatorul adminvps. Îl poți înlocui cu un nume propriu, diferit de root. Nu folosi în comenzi ghilimelele sau parantezele din explicații.

1. Actualizează sistemul de operare

Actualizările corectează vulnerabilități și erori cunoscute. Pe Ubuntu sau Debian rulează:

sudo apt update
sudo apt upgrade -y

Dacă ești conectat direct ca root, comenzile funcționează și fără sudo. Verifică dacă sistemul solicită repornire:

test -f /var/run/reboot-required && cat /var/run/reboot-required || echo "Nu este necesară repornirea"

Dacă este necesară, repornește serverul într-un moment potrivit:

sudo reboot

Așteaptă revenirea VPS-ului și reconectează-te înainte să continui.

2. Creează un utilizator administrativ separat

Folosirea permanentă a contului root mărește riscul unei greșeli și oferă atacatorilor un nume de utilizator cunoscut. Creează un cont normal și acordă-i dreptul de a folosi sudo:

sudo adduser adminvps
sudo usermod -aG sudo adminvps

Verifică apartenența la grupuri:

id adminvps

Deschide o a doua conexiune SSH și testează autentificarea:

ssh adminvps@ADRESA_IP

După conectare, verifică accesul administrativ:

sudo whoami

Rezultatul trebuie să fie root. Nu dezactiva încă accesul root și nici autentificarea cu parolă.

3. Configurează autentificarea SSH cu cheie

O cheie SSH folosește o pereche criptografică: cheia privată rămâne pe calculatorul tău, iar cheia publică este instalată pe server. Cheia privată nu trebuie trimisă nimănui și nu trebuie copiată pe VPS.

Generează cheia pe calculatorul tău

Pe Linux, macOS sau Windows PowerShell rulează local:

ssh-keygen -t ed25519 -a 100

Alege o parolă pentru cheia privată. Aceasta protejează cheia dacă fișierul ajunge pe un dispozitiv pierdut sau compromis.

Copiază cheia publică pe VPS

Dacă ai comanda ssh-copy-id pe calculator:

ssh-copy-id adminvps@ADRESA_IP

Pe Windows poți afișa cheia publică astfel:

type $env:USERPROFILE\.ssh\id_ed25519.pub

Copiază numai linia cheii publice, cea care începe de obicei cu ssh-ed25519. Pe server, conectat ca utilizatorul adminvps, creează structura necesară:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys

Lipește cheia publică pe o singură linie, salvează fișierul, apoi setează permisiunile:

chmod 600 ~/.ssh/authorized_keys

Deschide încă o conexiune nouă și verifică autentificarea cu cheia:

ssh adminvps@ADRESA_IP

Continuă numai dacă această conexiune funcționează. Păstrează deschise sesiunea inițială și sesiunea nouă până la finalul configurării SSH.

4. Întărește configurația SSH

Pe Ubuntu modern este recomandat să păstrezi modificările într-un fișier separat din /etc/ssh/sshd_config.d/. Pentru majoritatea directivelor OpenSSH este folosită prima valoare găsită, de aceea alegem un nume care se încarcă înaintea altor fragmente de configurare:

sudo nano /etc/ssh/sshd_config.d/00-zerolag-hardening.conf

Adaugă:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
X11Forwarding no
MaxAuthTries 3

Înainte să reîncarci serviciul, verifică sintaxa:

sudo sshd -t

Dacă nu apare niciun mesaj, configurația este validă. Poți vedea valorile efective importante cu:

sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication|maxauthtries'

Reîncarcă serviciul SSH:

sudo systemctl reload ssh.service

Nu închide sesiunile existente. Deschide o conexiune nouă și verifică din nou accesul cu utilizatorul administrativ și cheia SSH. După confirmare, autentificarea directă ca root și autentificarea SSH prin parolă nu ar trebui să mai funcționeze.

Trebuie schimbat portul SSH?

Schimbarea portului poate reduce zgomotul produs de scanările automate, dar nu înlocuiește cheia SSH, firewallul și actualizările. Dacă alegi un port personalizat, permite noul port în firewall înainte să modifici SSH și verifică accesul într-o sesiune separată. Un pas executat în ordinea greșită poate bloca administrarea serverului.

5. Activează firewallul UFW

Firewallul trebuie să permită numai serviciile folosite. Instalează UFW:

sudo apt install ufw -y

Setează politica implicită:

sudo ufw default deny incoming
sudo ufw default allow outgoing

Permite SSH înainte să activezi firewallul:

sudo ufw allow OpenSSH

Dacă SSH rulează deja pe un port diferit de 22, permite portul real în locul profilului OpenSSH, de exemplu sudo ufw allow NUMARUL_PORTULUI/tcp. Confirmă portul activ cu sudo sshd -T | grep '^port' înainte să activezi firewallul.

Dacă VPS-ul va găzdui un site, permite HTTP și HTTPS:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Activează firewallul și verifică regulile:

sudo ufw enable
sudo ufw status verbose

Pentru o bază de date folosită doar local de aplicație, nu deschide portul public. Servicii precum MySQL, PostgreSQL și Redis trebuie expuse în internet numai dacă există o nevoie clară, restricții de IP și o configurație sigură.

6. Verifică serviciile și porturile expuse

Vezi ce procese ascultă pe rețea:

sudo ss -tulpn

Pentru fiecare port, stabilește dacă serviciul trebuie să fie accesibil public. Oprește și dezactivează serviciile nefolosite:

sudo systemctl disable --now NUME_SERVICIU

Înlocuiește NUME_SERVICIU numai după ce identifici corect procesul. Nu dezactiva SSH, rețeaua sau alt serviciu critic fără să înțelegi rolul lui.

Poți verifica serviciile active cu:

systemctl --type=service --state=running

7. Instalează și configurează Fail2Ban

Fail2Ban urmărește autentificările eșuate și poate bloca temporar adresele care repetă încercările. Nu înlocuiește firewallul și nu repară o parolă slabă, dar adaugă protecție împotriva atacurilor automate.

Instalează pachetul:

sudo apt install fail2ban -y

Nu copia întregul fișier jail.conf. Creează numai configurația locală necesară:

sudo nano /etc/fail2ban/jail.d/sshd.local

Adaugă:

[sshd]
enabled = true
backend = systemd
bantime = 1h
findtime = 10m
maxretry = 5

Dacă folosești un port SSH personalizat, adaugă în secțiunea [sshd] și linia port = NUMARUL_PORTULUI.

Testează configurația, activează serviciul și verifică jail-ul SSH:

sudo fail2ban-client -t
sudo systemctl enable --now fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

Dacă serviciul nu pornește, verifică jurnalul:

sudo journalctl -u fail2ban --no-pager -n 100

8. Activează actualizările automate de securitate

Un VPS securizat astăzi poate deveni vulnerabil dacă nu este actualizat. Instalează mecanismul de actualizări automate:

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades

Verifică dacă actualizările periodice sunt activate:

cat /etc/apt/apt.conf.d/20auto-upgrades

Poți testa procesul fără instalarea efectivă a actualizărilor:

sudo unattended-upgrade --dry-run --debug

Actualizările automate reduc fereastra de expunere, dar nu înlocuiesc administrarea. Unele actualizări pot necesita repornire, iar serviciile importante trebuie monitorizate după schimbări.

9. Configurează backupul înainte să ai nevoie de el

Backupul VPS-ului trebuie să acopere datele aplicației, bazele de date, fișierele de configurare și secretele necesare restaurării. Păstrează cel puțin o copie în afara VPS-ului. Dacă atacatorul sau o eroare poate șterge simultan serverul și backupul, copia nu oferă suficientă protecție.

Un snapshot este util înaintea unei actualizări importante sau pentru revenire rapidă, dar nu trebuie să fie singura metodă de backup. Definește o politică în funcție de câtă informație îți permiți să pierzi și cât timp poate rămâne serviciul indisponibil.

Testează restaurarea. Un fișier de backup care nu poate fi verificat sau restaurat nu trebuie considerat o copie sigură.

10. Activează monitorizarea și verifică jurnalele

Monitorizează cel puțin disponibilitatea, procesorul, memoria, spațiul pe disc și serviciile importante. Pentru verificări rapide:

uptime
free -h
df -h
systemctl --failed

Verifică autentificările și jurnalul SSH:

last -a | head
sudo journalctl -u ssh.service --since today

Configurează alerte înainte de incident. Un disc plin, un serviciu oprit sau o creștere neobișnuită a consumului trebuie observate automat, nu după ce un client raportează că aplicația nu funcționează.

Măsuri suplimentare recomandate

Păstrează AppArmor activ

Ubuntu folosește AppArmor pentru a limita acțiunile anumitor aplicații. Verifică starea cu:

sudo aa-status

Nu dezactiva protecțiile sistemului doar pentru a ocoli o eroare. Identifică regula sau configurația care trebuie corectată.

Folosește autentificare cu doi factori unde este posibil

Panoul furnizorului, contul de email și sistemele de backup trebuie protejate cu 2FA. Securizarea SSH nu ajută dacă un atacator poate intra în panoul VPS-ului și poate folosi consola sau reinstalarea.

Separă secretele de cod

Nu păstra parole, tokenuri și chei API în repository-uri publice sau direct în cod. Folosește variabile de mediu, fișiere cu permisiuni restrictive sau un sistem dedicat de gestionare a secretelor.

Rulează aplicațiile cu privilegii minime

Serverul web, baza de date și aplicațiile nu trebuie să ruleze ca root. Creează utilizatori de sistem separați și acordă fiecărui serviciu numai accesul de care are nevoie.

Greșeli frecvente care pot bloca accesul

• dezactivarea parolei înainte ca autentificarea cu cheia să fie testată;
• activarea UFW înainte de permiterea portului SSH;
• închiderea singurei sesiuni active înainte de testarea noii configurații;
• modificarea SSH fără rularea comenzii sshd -t;
• schimbarea simultană a utilizatorului, portului, firewallului și autentificării;
• copierea integrală a jail.conf în jail.local;
• considerarea snapshotului drept singurul backup;
• expunerea publică a bazei de date sau a Redis fără o nevoie reală.

Aplică modificările în pași mici și verifică accesul după fiecare etapă. Dacă apare o problemă, vei ști ce schimbare trebuie anulată.

Checklist pentru securizarea unui VPS

• sistemul de operare este actualizat;
• există un utilizator administrativ separat de root;
• conectarea SSH cu cheie a fost testată într-o sesiune nouă;
• loginul direct root și autentificarea SSH cu parolă sunt dezactivate;
• configurația SSH trece testul sshd -t;
• firewallul permite numai porturile necesare;
• serviciile nefolosite sunt oprite;
• Fail2Ban este activ și jail-ul sshd funcționează;
• actualizările automate de securitate sunt configurate;
• backupurile sunt păstrate separat și restaurarea este testată;
• monitorizarea și alertele sunt active;
• 2FA este activat în panoul furnizorului și pe conturile importante.

Întrebări frecvente

Este suficient să schimb portul SSH?

Nu. Un port diferit poate reduce scanările automate vizibile în loguri, dar nu oferă protecție reală împotriva unui atacator care verifică toate porturile. Folosește chei SSH, dezactivează loginul prin parolă, limitează accesul prin firewall și menține sistemul actualizat.

Când pot dezactiva autentificarea prin parolă?

Numai după ce ai testat autentificarea cu cheia într-o conexiune nouă și ai confirmat că utilizatorul poate folosi sudo. Păstrează sesiunea inițială deschisă până la finalul testului.

Fail2Ban înlocuiește firewallul?

Nu. Firewallul stabilește ce porturi sunt accesibile. Fail2Ban analizează încercările eșuate și poate bloca temporar sursele abuzive. Cele două mecanisme au roluri diferite și trebuie folosite împreună.

Pot dezactiva complet contul root?

Poți dezactiva autentificarea directă root prin SSH și poți administra serverul cu un utilizator normal care folosește sudo. Contul de sistem root continuă să existe pentru operațiunile administrative.

Snapshotul VPS-ului este un backup?

Este o copie utilă pentru revenire rapidă, dar nu trebuie să fie singurul backup. Păstrează copii separate și testează restaurarea datelor importante.

Cât de des trebuie verificat un VPS?

Monitorizarea trebuie să fie permanentă, iar alertele să fie automate. Actualizările, logurile, backupurile și serviciile trebuie revizuite periodic și după orice schimbare importantă.

Ce fac dacă m-am blocat în afara serverului?

Folosește consola disponibilă în panoul furnizorului pentru a corecta regula de firewall sau configurația SSH. De aceea, accesul la consolă trebuie verificat înainte de modificări.

Concluzie

Securizarea unui VPS nu se termină după instalarea firewallului. Este un proces continuu bazat pe actualizări, acces cu privilegii minime, monitorizare, copii de siguranță și verificarea periodică a serviciilor expuse.

Dacă încă analizezi ce resurse și ce tip de server se potrivesc proiectului, citește ghidul despre ce este un VPS și când ai nevoie de unul. Pentru infrastructură virtualizată KVM găzduită în România, poți consulta și configurațiile VPS ZEROLAG.