Cum blocați atacuri brute force pe SSH în Linux

Cum blocați atacuri brute force pe SSH în Linux este prima întrebare după ce vă uitați în jurnalul unui server nou: sute sau mii de încercări de autentificare pe zi, de la adrese din toată lumea, cu utilizatori precum root, admin, ubuntu, test și parole din liste publice. Nu sunt atacuri țintite; sunt roboți care încearcă orice adresă IP. Nu le puteți opri să încerce, dar le puteți face încercările inutile și, apoi, invizibile.

Ghidul prezintă măsurile în ordinea eficienței, nu a popularității: cea care contează cu adevărat este autentificarea cu chei, iar restul reduc zgomotul și închid căile rămase. La final, verificarea în jurnale, ca să vedeți efectul.

Cum blocați atacuri brute force pe SSH în Linux

Cum arată un atac în jurnal

sudo journalctl -u ssh --since today | grep -c "Failed password"          # Ubuntu
sudo journalctl -u sshd --since today | grep -c "Failed password"         # AlmaLinux
sudo journalctl -u ssh --since today | grep "Failed password" | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head

Prima comandă numără încercările eșuate de azi; a treia arată adresele cele mai insistente. Pe un server abia pornit, cifra e de ordinul sutelor pe zi; după măsurile de mai jos, rămâne aceeași, dar fiecare încercare eșuează instantaneu, fără să atingă o parolă.

Măsura 1: chei în loc de parole

Un atac brute force ghicește parole. Fără autentificare cu parolă, nu are ce ghici. Generați o cheie pe calculatorul propriu, copiați-o pe server, testați, apoi opriți parolele:

ssh-keygen -t ed25519 -C "admin@firma"           # pe calculatorul propriu
ssh-copy-id admin@server                          # copiază cheia publică
ssh admin@server                                  # trebuie să intre fără parolă

sudo tee /etc/ssh/sshd_config.d/10-chei.conf <<'EOT'
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
EOT
sudo sshd -t && sudo systemctl restart ssh    # AlmaLinux: sshd

Păstrați sesiunea curentă deschisă până testați dintr-o fereastră nouă. Cheia privată rămâne pe calculator, protejată cu o frază de acces; dacă mai multe persoane au acces, fiecare cu propria cheie, ca retragerea accesului să însemne ștergerea unui rând din authorized_keys, nu schimbarea unei parole comune.

Măsura 2: configurarea sshd

sudo tee /etc/ssh/sshd_config.d/20-intarire.conf <<'EOT'
PermitRootLogin no
MaxAuthTries 3
LoginGraceTime 20
MaxStartups 10:30:60
AllowUsers admin deploy
ClientAliveInterval 300
ClientAliveCountMax 2
EOT
sudo sshd -t && sudo systemctl restart ssh

• PermitRootLogin no: root nu se poate autentifica direct; intrați cu un utilizator și folosiți sudo. Jumătate din încercările din jurnal sunt pe root.
• MaxAuthTries 3: după trei încercări, conexiunea se închide.
• LoginGraceTime 20: clientul are 20 de secunde să se autentifice, altfel serverul închide conexiunea; reduce conexiunile ținute deschise de roboți.
• MaxStartups 10:30:60: peste 10 conexiuni neautentificate simultan, serverul începe să refuze aleatoriu 30% dintre cele noi, până la 60, când refuză tot. Protejează serverul de saturare.
• AllowUsers: doar utilizatorii listați se pot conecta; utilizatorii de sistem și cei creați pentru aplicații nu, chiar dacă au parolă.

Portul SSH se poate schimba (Port 2200), ceea ce reduce numărul de încercări de zeci de ori, fiindcă majoritatea roboților scanează doar 22. Nu este o măsură de securitate, ci de liniște în jurnale; pe AlmaLinux, portul nou trebuie anunțat și lui SELinux (semanage port -a -t ssh_port_t -p tcp 2200) și deschis în firewall înainte de repornirea serviciului.

Măsura 3: fail2ban

fail2ban citește jurnalul și blochează temporar, în firewall, adresele care greșesc de mai multe ori. Cu cheile activate, blocarea nu mai apără parolele, dar scapă serverul de mii de conexiuni pe zi:

sudo apt install fail2ban -y            # AlmaLinux: dnf install epel-release fail2ban
sudo tee /etc/fail2ban/jail.local <<'EOT'
[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 4
bantime.increment = true
bantime.maxtime = 1w
ignoreip = 127.0.0.1/8 203.0.113.10
[sshd]
enabled = true
mode = aggressive
EOT
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

bantime.increment dublează durata blocării la fiecare recidivă, până la o săptămână; modul aggressive prinde și încercările fără parolă (conexiuni închise înainte de autentificare). Puneți în ignoreip adresa biroului, ca o greșeală de tastare să nu vă blocheze pe dumneavoastră. Configurarea completă, cu închisori pentru serverul web și pentru e-mail, este în ghidul despre securizarea unui server Linux cu fail2ban.

Măsura 4: firewall-ul

Dacă vă conectați mereu de la aceleași adrese (birou, VPN), permiteți SSH doar de la ele. Este cea mai puternică restricție: roboții nici nu ajung la serviciu.

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw allow from 198.51.100.0/24 to any port 22 proto tcp
sudo ufw deny 22/tcp
sudo ufw status numbered

Pe AlmaLinux, aceeași regulă se scrie cu firewall-cmd și o regulă rich cu source address. Dacă adresa de acasă se schimbă, păstrați o cale de rezervă: consola furnizorului de server (KVM sau consola din panou), care nu trece prin SSH. Detaliile pentru ambele firewall-uri sunt în ghidul despre UFW pe Ubuntu și AlmaLinux. Când adresele nu sunt fixe, UFW poate limita ritmul conexiunilor (ufw limit 22/tcp permite 6 conexiuni în 30 de secunde de la aceeași adresă), o măsură ieftină care taie majoritatea încercărilor automate.

Măsura 5: autentificare în doi pași

Pentru serverele la care se conectează mai multe persoane, un al doilea factor (cod din aplicația de telefon) protejează și de o cheie privată furată. Pachetul libpam-google-authenticator (Ubuntu) sau google-authenticator (AlmaLinux, din EPEL) adaugă codul la autentificare; configurarea cu cheie plus cod, astfel încât parola să nu fie acceptată niciodată, este descrisă pas cu pas în articolul despre autentificarea în doi pași pentru WordPress și Linux.

Cazul serverelor cu mulți utilizatori

Pe un server de găzduire cu zeci de conturi, nu puteți impune chei tuturor clienților, iar parolele rămân o cale de intrare. Aici contează măsurile care nu depind de utilizator: fail2ban cu blocare progresivă, MaxAuthTries mic, AllowGroups cu un grup în care intră doar conturile care chiar au nevoie de SSH, și un port diferit de 22 pentru a scoate serverul din listele de scanare în masă. Cel mai eficient rămâne să nu dați deloc SSH conturilor care nu au nevoie: SFTP izolat pentru fișiere și panoul de control pentru restul acoperă majoritatea cazurilor. Politica de parole, dacă parolele rămân, se aplică din PAM (pachetul libpam-pwquality), cu lungime minimă 14 și verificare față de listele de parole comune.

Ce faceți dacă o autentificare a reușit

O linie „Accepted password” sau „Accepted publickey” de la o adresă necunoscută nu se ignoră. Ordinea: verificați ce a făcut sesiunea (comenzile din istoricul utilizatorului, fișierele modificate recent cu find / -mmin -120, procesele noi), schimbați imediat cheile și parolele contului respectiv, căutați chei străine în authorized_keys ale tuturor utilizatorilor și sarcini cron noi, apoi decideți dacă serverul se reinstalează. Pașii compleți sunt în ghidul despre răspunsul la incidente de securitate. Un server pe care un atacator a avut shell trebuie tratat ca nesigur până la reinstalare.

Măsuri pe care nu le recomandăm

• Port knocking: ascunde portul până la o secvență de conexiuni; funcționează, dar complică accesul de urgență și nu adaugă nimic peste chei plus firewall.
• Blocarea pe țări: listele de adrese pe țări sunt aproximative, atacurile vin prin servere din orice țară, iar clienții sau colaboratorii din străinătate rămân afară.
• Schimbarea portului ca unică măsură: scanerele de porturi găsesc SSH în câteva secunde, iar parolele rămân ghicibile.
• Dezactivarea jurnalelor „ca să nu se umple”: pierdeți singura dovadă a unui acces reușit.

Ordinea în care le aplicați

Dacă aveți zece minute: cheile, PermitRootLogin no și PasswordAuthentication no. Dacă aveți o oră: plus fail2ban și AllowUsers. Dacă serverul e important: plus firewall pe adrese sau limitare de ritm și al doilea factor. Fiecare pas se testează dintr-o sesiune nouă înainte de a închide sesiunea veche, iar consola furnizorului rămâne calea de rezervă pentru cazul în care o regulă vă închide afară.

Verificarea efectului

1. Numărul de „Failed password” trebuie să scadă la zero după oprirea parolelor; ce rămâne sunt rânduri de tip „Connection closed by authenticating user” sau „Invalid user”, adică încercări care nu au ajuns nicăieri.
2. fail2ban-client status sshd arată adresele blocate în prezent și totalul de blocări.
3. Rândurile „Accepted publickey for” sunt singurele autentificări reușite; orice „Accepted password” după configurare înseamnă că un fișier de configurare a suprascris setarea. Verificați cu sshd -T | grep -i passwordauth.
4. O dată pe lună, last și lastlog arată cine s-a conectat și de unde; o adresă necunoscută cu autentificare reușită este un incident.

Aceste măsuri fac parte din întărirea generală a serverului, alături de actualizări automate, firewall și SELinux, descrise în ghidul de securitate pentru AlmaLinux 9. Pentru conturile care nu au nevoie deloc de SSH interactiv (colaboratori care doar încarcă fișiere), soluția este SFTP izolat, din ghidul despre utilizatorii cu acces limitat; iar dacă serverul rulează cPanel, cPHulk face parte din protecție, cu setările din ghidul despre securitatea contului de găzduire.

Surse

• Documentația Ubuntu Server, securitate: configurarea OpenSSH, firewall-ul și autentificarea cu chei.
• Manualul de securizare Debian: întărirea serviciului SSH și limitarea accesului.