Configurare firewall UFW si Fail2ban: opreste atacurile SSH

Majoritatea oamenilor afla asta pe pielea lor: din momentul in care un VPS nou primeste o adresa IP publica, roboti automati incep sa incerce sa se logheze pe el. Nu peste o saptamana si nici dupa ce iti publici site-ul, ci in cateva minute. Deschide logul SSH al oricarui server care sta online de o zi si vei gasi sute de logari esuate pentru utilizatori ca root, admin, ubuntu sau test, venite de la adrese din toata lumea. Nimic din toate astea nu e personal, e zgomotul de fond al internetului, dar e un zgomot de care merita sa te ocupi din prima zi.

In acest tutorial construim doua straturi simple de aparare pe care ar trebui sa le aiba orice server Linux. Primul este o configurare de firewall cu UFW care blocheaza totul implicit si deschide doar porturile pe care chiar le folosesti. Al doilea este Fail2ban, un serviciu mic care urmareste logurile SSH si baneaza automat adresele IP care tot incearca parole. Lucram pe Debian 13 si Ubuntu 24.04, explicam fiecare comanda si iti aratam unde se comporta diferit cele doua distributii. Socoteste cam 20 de minute, majoritatea pentru citit.

De ce are nevoie un VPS nou de firewall

Inainte sa scriem comenzi, e bine sa intelegem ce protejam si cum. Trei concepte scurte acopera tot ce ai nevoie.

Ce este, de fapt, un port

Un server are o singura adresa IP, dar ruleaza multe programe care comunica prin retea: serverul SSH cu care te conectezi, un server web, poate o baza de date. Ca sa le separe traficul, fiecare conexiune de retea tinteste un port, un numar intre 1 si 65535. Prin conventie, SSH asculta pe portul 22, HTTP pe 80 si HTTPS pe 443. Porturile vin in doua variante: TCP (conexiuni sigure, folosite de SSH si site-uri) si UDP (pachete usoare, folosite de DNS, unele VPN-uri si HTTP/3).

Problema e ca de multe ori aplicatiile asculta pe mai multe porturi decat iti dai seama. O baza de date instalata pentru teste, un panou de administrare, un agent de monitorizare: fiecare e o usa, iar fiecare usa deschisa pe un IP public e vizibila pentru scannerele care matura tot internetul de cateva ori pe zi.

Ce face un firewall si ce inseamna “default deny”

Un firewall este un set de reguli care decide, pentru fiecare pachet care intra, daca are voie sau nu. Kernelul Linux are un motor de firewall integrat, numit netfilter, configurat cu uneltele iptables sau nftables. Sunt unelte puternice, dar destul de verbose, asa ca vom folosi o interfata mai prietenoasa.

Cea mai importanta idee din acest articol este default deny: tot ce vine din exterior e blocat, cu exceptia a ceea ce o regula permite explicit. Abordarea inversa, sa permiti totul si sa blochezi ce stii ca e periculos, nu functioneaza niciodata, pentru ca nu poti enumera tot ce e periculos. Cu default deny, o baza de date pe care ai uitat-o ramane invizibila din internet, pentru ca nimeni nu i-a deschis portul.

UFW: Uncomplicated Firewall

UFW (Uncomplicated Firewall) este o unealta de linie de comanda care transforma comenzi scurte si usor de citit, ca ufw allow 443/tcp, in regulile netfilter corecte, atat pentru IPv4 cat si pentru IPv6. Vine din proiectul Ubuntu, e disponibila si pe Debian si isi tine regulile in fisiere text simple, in /etc/ufw/. Atat pe Debian 13 cat si pe Ubuntu 24.04 lucreaza peste backend-ul nftables, deci nu trebuie sa-ti bati capul cu motorul de dedesubt.

Unde intra Fail2ban in poveste

Un firewall nu poate bloca SSH complet, pentru ca ai nevoie de SSH ca sa administrezi serverul. Aici apar atacurile brute-force: un robot se conecteaza pe portul 22 si incearca mii de combinatii de utilizator si parola, sperand ca una o sa mearga. Fail2ban citeste logul SSH, observa cand acelasi IP esueaza de mai multe ori intr-un interval scurt si adauga o regula temporara de firewall care blocheaza acel IP. Fail2ban foloseste trei termeni pe care ii vei vedea in configuratie: filter (tiparele care recunosc o logare esuata in log), action (ce sa faca, aici: sa adauge o regula UFW) si jail (un filtru plus o actiune plus pragurile, pentru un serviciu).

De ce ai nevoie

• Un VPS DreamServer cu Debian 13 sau Ubuntu 24.04 si IP public. Un VPS KVM e cazul cel mai simplu (vezi nota despre LXC mai jos).
• Un utilizator obisnuit cu drepturi sudo. Toate comenzile de mai jos incep cu sudo, deci nu trebuie sa te loghezi ca root.
• O sesiune SSH deschisa catre server si, ideal, posibilitatea de a deschide inca una pentru test.
• Acces la consola out-of-band din zona de client (consola web a VPS-ului), ca plasa de siguranta daca iti blochezi singur accesul.
• Adresa ta IP publica, daca e fixa. Iti aratam cum o afli la pasul 7.

Planul: 8 pasi in doua parti

Procedura are doua parti. Pasii 1-5 construiesc firewall-ul, pasii 6-8 adauga Fail2ban peste el. Ordinea conteaza: permitem SSH inainte sa activam firewall-ul si il activam abia dupa ce toate regulile sunt la locul lor.

Partea 1: configurare firewall UFW, pas cu pas

Pasul 1: Actualizeaza sistemul si instaleaza UFW

Incepem cu un sistem la zi, ca sa nu protejam pachete vechi:

sudo apt update && sudo apt upgrade -y
sudo apt install -y ufw

Aici apare prima diferenta intre cele doua distributii. Ubuntu 24.04 vine cu UFW deja instalat, dar inactiv, asa ca apt iti va spune doar ufw is already the newest version. Debian 13 nu il include implicit, deci apt il instaleaza impreuna cu dependintele (pachetul iptables, care pe Debian 13 foloseste backend-ul nftables).

Daca actualizarea a instalat un kernel nou, reporneste serverul inainte sa continui. Pe Ubuntu poti verifica asa:

[ -f /var/run/reboot-required ] && echo "Trebuie restart" || echo "Nu trebuie restart"

Debian 13 nu creeaza implicit fisierul /var/run/reboot-required, deci pe Debian reporneste pur si simplu cu sudo reboot daca ai vazut un pachet linux-image in lista de actualizari.

Acum confirma ca UFW e instalat, dar inca inactiv:

sudo ufw status

Rezultatul asteptat: Status: inactive. Perfect, nu se blocheaza inca nimic si nu se va bloca nimic pana la pasul 5.

Pasul 2: Seteaza politicile implicite

Politicile implicite sunt regula de “tot restul”: ce se intampla cu traficul pe care nu il prinde nicio regula specifica. Vrem ca traficul de intrare sa fie refuzat si cel de iesire permis, ca serverul sa poata in continuare descarca actualizari, rezolva DNS si trimite emailuri:

sudo ufw default deny incoming
sudo ufw default allow outgoing

UFW raspunde cu Default incoming policy changed to 'deny' si cu o atentionare sa-ti actualizezi regulile. De fapt acestea sunt deja valorile implicite ale UFW, dar daca le setezi explicit intentia e clara si esti protejat in cazul in care cineva le-a schimbat inainte.

Cat suntem aici, verifica daca IPv6 e acoperit. Probabil VPS-ul tau are si o adresa IPv6, iar un firewall care filtreaza doar IPv4 lasa o a doua usa larg deschisa:

grep '^IPV6' /etc/default/ufw

Ar trebui sa vezi IPV6=yes. Daca scrie no, editeaza fisierul cu sudo nano /etc/default/ufw, schimba in yes si salveaza. De acum, fiecare regula pe care o adaugi se creeaza si pentru IPv4 si pentru IPv6, de aceea UFW afiseaza Rules updated si Rules updated (v6).

Pasul 3: Permite SSH inainte de orice altceva

Acesta e pasul care te fereste de greseala clasica: sa-ti blochezi singur accesul. Daca activezi un firewall default deny fara o regula pentru SSH, sesiunea curenta poate supravietui o vreme, dar urmatoarea logare va esua.

Mai intai, afla pe ce port asculta de fapt serverul SSH:

sudo sshd -T | grep -i '^port'

De obicei rezultatul e port 22. Daca tu sau furnizorul l-ati schimbat, vei vedea numarul personalizat. Acum permite-l, folosind limit in loc de un simplu allow:

sudo ufw limit 22/tcp comment 'SSH'

limit permite in continuare SSH, dar adauga o limitare de rata: un IP care deschide 6 sau mai multe conexiuni in 30 de secunde primeste refuz la conexiunile noi. Doar asta incetineste robotii cei mai simpli inainte ca Fail2ban sa-i vada. Daca portul tau nu e 22, inlocuieste numarul, de exemplu sudo ufw limit 2222/tcp comment 'SSH'.

Daca ai un IP public fix (o linie de birou, un VPN cu adresa de iesire fixa), poti merge mai departe si sa permiti SSH doar de la acea adresa, in locul regulii de mai sus:

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp comment 'SSH din birou'

Fa asta doar daca esti sigur ca IP-ul nu se schimba, altfel vei avea nevoie de consola web ca sa intri inapoi.

O nota despre schimbarea portului SSH mai tarziu: pe Debian 13, un sudo systemctl restart ssh aplica noul port. Pe Ubuntu 24.04, SSH porneste prin socket activation din systemd (ssh.socket), asa ca dupa ce editezi portul ai nevoie de sudo systemctl daemon-reload urmat de sudo systemctl restart ssh.socket. In ambele cazuri, adauga regula UFW pentru noul port inainte de restart.

Pasul 4: Deschide doar porturile de care ai nevoie

Hai sa vedem ce asculta de fapt pe server:

sudo ss -tulpn

Comanda listeaza fiecare socket TCP si UDP care asculta, impreuna cu programul care il detine. Coloana importanta e Local Address:Port. 0.0.0.0:3306 sau [::]:3306 inseamna “asculta pe toate interfetele”, deci accesibil din exterior daca firewall-ul permite. 127.0.0.1:3306 inseamna “doar de pe serverul insusi”, exact ce vrei pentru baze de date.

Pentru un server web tipic ai nevoie de HTTP si HTTPS:

sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'

Daca serverul web suporta HTTP/3 (QUIC), foloseste si UDP pe portul 443: sudo ufw allow 443/udp comment 'HTTP/3'. Daca nu esti sigur, sari peste, browserele trec automat pe TCP.

Pentru serviciile pe care doar tu sau un alt server trebuie sa le accesati, permite-le de la o adresa anume, nu din toata lumea. De exemplu, o baza de date PostgreSQL la care se conecteaza doar serverul de aplicatie de la 198.51.100.20:

sudo ufw allow from 198.51.100.20 to any port 5432 proto tcp comment 'Postgres de la aplicatie'

Regula de baza: daca nu poti explica cine are nevoie de un port si de ce, nu-l deschide. Pentru ca UFW e inca inactiv, poti revedea tot ce ai adaugat pana acum cu:

sudo ufw show added

Pasul 5: Activeaza UFW si verifica regulile

Verifica inca o data ca regula de SSH apare in lista show added. Apoi activeaza firewall-ul:

sudo ufw enable

UFW te avertizeaza: Command may disrupt existing ssh connections. Proceed with operation (y|n)?. Scrie y. Raspunsul ar trebui sa fie Firewall is active and enabled on system startup. De acum UFW se incarca automat la fiecare pornire, atat pe Debian cat si pe Ubuntu.

Nu inchide inca sesiunea curenta. Deschide un terminal nou pe calculatorul tau si conecteaza-te din nou prin SSH. Daca merge, regula de SSH e corecta. Daca nu, intoarce-te in sesiunea veche (sau in consola web) si corecteaza regula, ori ruleaza sudo ufw disable ca sa o iei de la capat.

Acum uita-te la imaginea completa:

sudo ufw status verbose

Rezultatul ar trebui sa arate asa:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     LIMIT IN    Anywhere                   # SSH
80/tcp                     ALLOW IN    Anywhere                   # HTTP
443/tcp                    ALLOW IN    Anywhere                   # HTTPS
22/tcp (v6)                LIMIT IN    Anywhere (v6)              # SSH
80/tcp (v6)                ALLOW IN    Anywhere (v6)              # HTTP
443/tcp (v6)               ALLOW IN    Anywhere (v6)              # HTTPS

Ca sa stergi o regula, listeaz-o cu numere si sterge-o dupa numar:

sudo ufw status numbered
sudo ufw delete 3

Ruleaza din nou status numbered dupa fiecare stergere, pentru ca numerele se decaleaza. Poti sterge si repetand regula, de exemplu sudo ufw delete allow 80/tcp.

UFW logheaza implicit pachetele blocate la nivelul low. Unde le citesti depinde de distributie: Ubuntu 24.04 are de obicei rsyslog instalat si le scrie in /var/log/ufw.log, pe cand Debian 13 nu are rsyslog implicit si le pastreaza in journal-ul systemd. Pe Debian foloseste sudo journalctl -k | grep UFW, pe Ubuntu sudo tail -f /var/log/ufw.log.

Partea 2: blocarea atacurilor brute-force pe SSH cu Fail2ban

Firewall-ul ascunde acum tot, cu exceptia SSH si a porturilor web. SSH ramane totusi deschis catre toata lumea, iar asta protejeaza Fail2ban.

Cum decide Fail2ban pe cine sa baneze

Trei setari conduc orice jail. maxretry e numarul de esecuri permise, findtime e fereastra de timp in care se numara, iar bantime e cat dureaza banul. Cu maxretry = 5, findtime = 10m si bantime = 1h, un IP care esueaza de 5 ori in 10 minute e blocat o ora. Vom activa si banurile progresive, ca un IP care revine dupa ban sa primeasca 2 ore, apoi 4 si tot asa, pana la o saptamana.

Pasul 6: Instaleaza Fail2ban

sudo apt install -y fail2ban python3-systemd
sudo systemctl enable --now fail2ban

python3-systemd ii permite lui Fail2ban sa citeasca direct journal-ul systemd. Conteaza pe Debian 13, unde nu exista fisierul /var/log/auth.log pentru ca rsyslog nu e instalat. Pe Ubuntu 24.04 auth.log exista de obicei, dar citirea din journal functioneaza la fel si ne pastreaza configuratia identica pe ambele sisteme.

Verifica daca serviciul ruleaza:

systemctl status fail2ban --no-pager

Vrei sa vezi active (running). Pe Ubuntu 24.04, daca serviciul cade cu o eroare Python care pomeneste asynchat, pachetul Fail2ban e vechi: ruleaza sudo apt update && sudo apt upgrade ca sa primesti versiunea reparata. Debian 13 vine cu Fail2ban 1.1.x, Ubuntu 24.04 cu 1.0.2 plus patch-uri ale distributiei, iar configuratia de mai jos merge pe ambele.

Pasul 7: Configureaza jail-ul SSH in jail.local

Configuratia principala a Fail2ban sta in /etc/fail2ban/jail.conf, dar nu edita niciodata acel fisier: actualizarile de pachet il suprascriu. In schimb, creeaza /etc/fail2ban/jail.local, care se citeste dupa el si suprascrie tot ce redefineste. Atat Debian cat si Ubuntu vin si cu /etc/fail2ban/jail.d/defaults-debian.conf, care activeaza jail-ul sshd cu valorile distributiei. Fisierul nostru jail.local se incarca dupa el, deci valorile noastre castiga.

Mai intai afla adresa IP de pe care te conectezi, ca sa nu te banezi niciodata singur:

echo "$SSH_CLIENT" | awk '{print $1}'

Noteaza adresa afisata. Acum creeaza fisierul:

sudo nano /etc/fail2ban/jail.local

Lipeste urmatorul continut, inlocuind 203.0.113.10 cu IP-ul tau (sau sterge-l daca IP-ul de acasa se schimba des):

[DEFAULT]
# Nu bana niciodata aceste adrese: localhost si IP-ul tau
ignoreip = 127.0.0.1/8 ::1 203.0.113.10

# 5 esecuri in 10 minute = ban pentru 1 ora
bantime  = 1h
findtime = 10m
maxretry = 5

# Recidivistii primesc banuri tot mai lungi, pana la o saptamana
bantime.increment = true
bantime.maxtime   = 1w

# Aplica banurile prin UFW, ca sa apara in "ufw status"
banaction = ufw
banaction_allports = ufw

[sshd]
enabled  = true
port     = ssh
backend  = systemd
journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd + _COMM=sshd-session

Salveaza cu Ctrl+O, Enter si iesi cu Ctrl+X. Cateva linii merita explicate:

• banaction = ufw face ca Fail2ban sa baneze IP-uri adaugand o regula REJECT in varful listei de reguli UFW. Banul acopera toate porturile pentru acel IP, nu doar SSH, exact ce vrei pentru un atacator.
• backend = systemd ii spune lui Fail2ban sa citeasca journal-ul systemd in loc de un fisier de log.
• journalmatch alege ce intrari din journal sa citeasca. Unitatea serviciului SSH se numeste ssh.service atat pe Debian cat si pe Ubuntu, iar partile _COMM prind mesajele procesului sshd si ale lui sshd-session. Al doilea nume conteaza pe Debian 13: incepand cu OpenSSH 9.8, gestionarea logarilor s-a mutat intr-un proces separat, sshd-session, iar Debian 13 vine cu OpenSSH 10. Ubuntu 24.04 foloseste OpenSSH 9.6, unde totul vine inca de la sshd, si aceeasi linie merge si acolo.

Testeaza configuratia inainte s-o aplici, apoi reporneste serviciul:

sudo fail2ban-client -t
sudo systemctl restart fail2ban
sudo fail2ban-client status

Testul ar trebui sa afiseze OK: configuration test is successful, iar statusul sa arate un singur jail:

Status
|- Number of jail:	1
`- Jail list:	sshd

Pasul 8: Testeaza un ban si vezi-l in actiune

Cel mai sigur test nu blocheaza pe nimeni. Baneaza manual o adresa IP de documentatie si verifica daca ajunge in firewall:

sudo fail2ban-client set sshd banip 198.51.100.23
sudo ufw status | head -n 8

Ar trebui sa vezi o regula noua chiar in varf, inaintea regulilor tale allow:

Anywhere                   REJECT IN   198.51.100.23

Scoate-o la loc:

sudo fail2ban-client set sshd unbanip 198.51.100.23

Acum uita-te la statisticile reale ale jail-ului:

sudo fail2ban-client status sshd

Status for the jail: sshd
|- Filter
|  |- Currently failed:	2
|  |- Total failed:	57
|  `- Journal matches:	_SYSTEMD_UNIT=ssh.service + _COMM=sshd + _COMM=sshd-session
`- Actions
   |- Currently banned:	3
   |- Total banned:	12
   `- Banned IP list:	192.0.2.41 192.0.2.77 198.51.100.140

Linia Journal matches confirma ca suprascrierea noastra e activa. Pe un server online de cateva ore, Total failed creste repede, cea mai buna dovada ca detectia functioneaza. Daca vrei un test live, conecteaza-te din alta retea (de exemplu un hotspot de pe telefon, pentru ca IP-ul tau e in ignoreip) cu un utilizator care nu exista, de exemplu ssh fakeuser123@IP_VPS, si esueaza de cinci ori. A sasea incercare ar trebui sa primeasca Connection refused. Banurile se scriu si in /var/log/fail2ban.log pe ambele distributii, cu linii de tipul NOTICE [sshd] Ban 192.0.2.41.

Cata diferenta face, de fapt?

Cifrele variaza mult in functie de clasa de IP-uri si de cat timp a fost folosita, dar tiparul e mereu acelasi. O adresa IPv4 publica noua vede de obicei cateva mii de logari SSH esuate pe zi. Regula limit din UFW taie robotii cei mai rapizi, iar Fail2ban opreste fiecare IP atacator dupa o mana de incercari.

Fail2ban nu opreste primele cateva incercari de la fiecare IP nou, iar botnet-urile mari isi imprastie incercarile pe mii de adrese. De aceea Fail2ban e un filtru de zgomot, nu apararea ta principala. Apararea principala e autentificarea SSH cu chei, despre care vorbim la notele de securitate. Cu chei si fara parole, niciuna din acele incercari nu poate reusi oricum, iar Fail2ban iti pastreaza logurile lizibile si procesorul linistit.

Docker si UFW: capcana in care cade aproape oricine

Daca rulezi Docker pe acest server, citeste cu atentie. Cand publici un port de container cu -p 8080:80 sau cu o intrare ports: in Compose, Docker isi scrie propriile reguli netfilter care trimit traficul catre container inainte ca regulile UFW sa fie evaluate. Rezultatul: portul e accesibil din internet desi ufw status nu il pomeneste, chiar daca adaugi ufw deny 8080.

Cea mai simpla solutie e sa nu publici niciodata porturile containerelor pe toate interfetele. Leaga-le de localhost si pune in fata un reverse proxy (Nginx, Caddy, Traefik), care asculta pe porturile 80 si 443, deja controlate de UFW:

services:
  app:
    image: louislam/uptime-kuma:1
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - app_data:/app/data

volumes:
  app_data:

Cu 127.0.0.1:3001:3001 serviciul e accesibil doar de pe serverul insusi. Ruleaza docker compose up -d dupa modificare si verifica de pe alt calculator ca portul nu mai raspunde.

O nota despre containerele LXC neprivilegiate

Tot ce am facut mai sus functioneaza complet pe un VPS KVM, care are propriul kernel. Intr-un container LXC neprivilegiat, firewall-ul e impartit cu kernelul gazdei, iar containerul are drepturi limitate: UFW poate esua la incarcarea modulelor de kernel sau la aplicarea setarilor sysctl, iar unele reguli pot sa nu functioneze deloc. Cum actiunea ufw din Fail2ban depinde de UFW, e afectata si ea. Daca esti pe un plan LXC, testeaza cu atentie, cu consola web la indemana, iar daca UFW raporteaza erori, intreaba echipa noastra de suport despre filtrare la nivel de gazda.

Probleme frecvente si greseli comune

• Te-ai blocat dupa ufw enable. Intra prin consola web din zona de client si ruleaza sudo ufw allow 22/tcp (sau portul tau personalizat), ori sudo ufw disable ca sa o iei de la capat. De aceea pastram o sesiune deschisa pana verificam pasul 5.
• ERROR: Could not find a profile matching 'OpenSSH'. Profilurile de aplicatie difera intre distributii. Foloseste numere de port, ca in acest tutorial, si merg peste tot.
• O regula deny nu functioneaza. UFW verifica regulile de sus in jos si se opreste la prima potrivire. Un deny adaugat dupa un allow pentru acelasi port nu e atins niciodata. Foloseste sudo ufw insert 1 deny from 192.0.2.50 ca sa-l pui in varf.
• Fail2ban nu porneste. Citeste motivul cu sudo journalctl -u fail2ban -n 50 --no-pager. Pe Debian, o eroare despre fisiere de log lipsa inseamna ca jail-ul nu foloseste backend = systemd sau ca lipseste python3-systemd. Pe Ubuntu 24.04, o eroare asynchat inseamna ca pachetul trebuie actualizat.
• Total failed ramane la 0. Verifica daca esecurile SSH chiar se logheaza, cu sudo journalctl -u ssh -n 30 --no-pager. Verifica daca linia Journal matches din fail2ban-client status sshd corespunde configuratiei noastre si tine minte ca incercarile de la IP-urile din ignoreip nu se numara niciodata.
• Te-ai banat singur. Din consola web sau de pe alt IP, ruleaza sudo fail2ban-client unban IP_TAU, sau sudo fail2ban-client unban --all ca sa stergi toate banurile. Apoi adauga IP-ul in ignoreip.
• ufw limit iti blocheaza unealta de deployment. Unelte ca Ansible pot deschide repede multe conexiuni SSH. Adauga o regula allow from pentru IP-ul de administrare deasupra regulii limit, cu sudo ufw insert 1 allow from 203.0.113.10 to any port 22 proto tcp.
• Un port de container e accesibil desi ai UFW. Vezi sectiunea Docker de mai sus: leaga porturile publicate de 127.0.0.1.

Note de securitate

• Foloseste chei SSH si dezactiveaza logarea cu parola. E cea mai eficienta protectie impotriva brute-force. Dupa ce cheia functioneaza, creeaza /etc/ssh/sshd_config.d/10-hardening.conf cu linia PasswordAuthentication no, verifica sintaxa cu sudo sshd -t, apoi reporneste SSH (sudo systemctl restart ssh). Pastreaza o sesiune deschisa cat testezi.
• Nu te loga ca root prin SSH. Debian si Ubuntu au deja implicit PermitRootLogin prohibit-password. Cu doar chei, ghicirea parolei de root nu are sens, dar un utilizator sudo obisnuit ramane obiceiul mai bun.
• Schimbarea portului SSH nu e securitate. Reduce zgomotul din loguri, dar orice scanner de porturi gaseste noul port in cateva minute. Trateaz-o ca pe ceva cosmetic, nu ca pe o protectie.
• Un firewall nu repara aplicatii. O aplicatie cu o vulnerabilitate pe portul 443 ramane expusa. Tine sistemul la zi, ideal cu pachetul unattended-upgrades pentru actualizarile de securitate.
• Nu uita de IPv6. Pastreaza IPV6=yes in /etc/default/ufw, altfel regulile tale protejeaza doar jumatate din adrese.
• Fa backup la reguli. UFW le tine in /etc/ufw/user.rules si /etc/ufw/user6.rules, iar Fail2ban in /etc/fail2ban/jail.local. Copiaza aceste fisiere cand reconstruiesti sau clonezi un server.
• Revizuieste periodic. Ruleaza sudo ufw status numbered la cateva luni si sterge regulile pentru servicii pe care nu le mai folosesti.

Deci, e VPS-ul tau securizat acum?

In aproximativ 20 de minute ai trecut de la un server care raspundea pe orice port pe care se intampla sa asculte, la unul care urmeaza o regula clara: refuza tot, permite doar SSH si web, si baneaza automat pe oricine tot incearca parole. Adauga cheile SSH peste toate astea si zgomotul obisnuit de brute-force din internet devine o linie intr-un fisier de log, nu un risc.

Daca ai nevoie de un server curat pe care sa exersezi, poti lua un VPS de la noi, cu Debian 13 sau Ubuntu 24.04, in cateva minute. Iar daca preferi ca altcineva sa se ocupe de firewall, jail-uri Fail2ban, securizarea SSH si actualizari, echipa noastra de administrare servere face exact asta, in fiecare zi.

Intrebari frecvente

UFW imi incetineste serverul?

Nu, nu intr-un mod pe care sa-l observi. UFW doar scrie reguli, filtrarea propriu-zisa o face motorul netfilter din kernel, care proceseaza milioane de pachete pe secunda. UFW nu consuma memorie in timp ce ruleaza, iar Fail2ban foloseste de obicei cateva zeci de MB de RAM.

Ar trebui sa schimb portul SSH in loc sa folosesc Fail2ban?

Poti face ambele, dar nu sunt echivalente. Un port diferit reduce numarul de incercari automate, pe cand Fail2ban blocheaza activ IP-urile care il gasesc totusi. Niciunul nu inlocuieste autentificarea cu chei SSH, care face ghicitul cu adevarat inutil.

Cum deblochez un IP banat de Fail2ban?

Ruleaza sudo fail2ban-client unban 192.0.2.41 ca sa-l scoti din toate jail-urile, sau sudo fail2ban-client set sshd unbanip 192.0.2.41 pentru un singur jail. Ca sa nu se mai intample, adauga adresa in ignoreip din /etc/fail2ban/jail.local si reporneste Fail2ban.

Poate Fail2ban sa-mi protejeze si site-ul?

Da. Fail2ban vine cu filtre pentru Nginx, Apache, Postfix, Dovecot si multe altele, in /etc/fail2ban/filter.d/. Le activezi adaugand sectiuni noi de jail in jail.local, la fel cum am facut pentru SSH. Incepe cu SSH, asigura-te ca merge, apoi adauga alte jail-uri pe rand.

Sa folosesc UFW sau sa scriu direct reguli nftables?

Pentru un singur VPS cu cateva servicii, UFW e alegerea mai buna: comenzi lizibile, IPv4 si IPv6 tratate impreuna si mai putin loc pentru greseli. nftables direct are sens cand ai nevoie de configuratii complexe, ca NAT, port forwarding intre retele sau lanturi foarte personalizate, de obicei pe routere sau pe infrastructura mai mare.