Autentificare în doi pași (2FA): Cum activați protecția avansată pe WordPress și Linux

Autentificare în doi pași (2FA): Cum activați protecția avansată pe WordPress și Linux, pentru conturile care controlează site-ul și serverul: administratorii WordPress, contul cPanel, accesul SSH. O parolă furată prin phishing sau scursă dintr-o altă bază de date nu mai ajunge pentru a intra, fiindcă atacatorul nu are al doilea factor: codul din telefon sau cheia fizică. Microsoft și Google raportează că al doilea factor blochează peste 99% dintre atacurile automate asupra conturilor; pe site-urile pe care le administrăm, tentativele de autentificare cu parole corecte, dar fără al doilea factor, apar în jurnale lunar.

Ghidul acoperă metodele (și care dintre ele sunt de evitat), configurarea pe WordPress, configurarea SSH pe Ubuntu și AlmaLinux cu cheie plus cod, codurile de rezervă și greșelile care blochează administratorul în afara propriului server.

Autentificare în doi pași (2FA): Cum activați protecția avansată pe WordPress și Linux

Metodele, de la cea mai sigură la cea mai slabă

1. Chei fizice (FIDO2/WebAuthn, de tip YubiKey) sau passkeys: rezistente la phishing, fiindcă răspund doar site-ului legitim. Cea mai bună opțiune pentru administratori.
2. Coduri TOTP din aplicație (Google Authenticator, Microsoft Authenticator, Aegis, 1Password): coduri de șase cifre, regenerate la 30 de secunde, calculate local din secretul partajat la configurare. Nu au nevoie de rețea. Sunt standardul pentru WordPress și SSH.
3. Notificări push în aplicație: comode, dar vulnerabile la „oboseala de aprobare” (atacatorul trimite cereri până când victima apasă da).
4. Coduri pe e-mail: mai bune decât nimic; dacă parola de e-mail e aceeași cu cea a site-ului, nu protejează nimic.
5. SMS: interceptabil prin duplicarea cartelei (SIM swap) și prin phishing; de evitat pentru conturi importante.

Pe WordPress

Alegerea modulului

Două module acoperă nevoile obișnuite: WP 2FA (metode multiple, politici pe rol, perioadă de grație pentru utilizatori) și Two-Factor (cel întreținut de echipa WordPress, minimal, cu TOTP, e-mail, coduri de rezervă și chei FIDO). Wordfence include și el 2FA, dacă îl folosiți deja pentru firewall. Alegeți unul singur; două module de autentificare se calcă pe picioare.

Configurarea

1. Instalați modulul și activați-l.
2. Din profilul propriu (Users, Profile), secțiunea Two-Factor: alegeți TOTP, scanați codul QR cu aplicația de pe telefon, introduceți codul afișat pentru confirmare.
3. Generați codurile de rezervă și salvați-le în managerul de parole, nu într-un fișier pe desktop.
4. Deconectați-vă și autentificați-vă din nou, ca test, înainte de a impune regula altora.
5. Din setările modulului, faceți al doilea factor obligatoriu pentru rolurile Administrator și Editor, cu o perioadă de grație de câteva zile în care utilizatorii îl configurează singuri.

Rolurile cu drepturi mai mici (Author, Contributor) pot rămâne fără, dacă nu publică direct; distincțiile sunt în ghidul despre rolurile și permisiunile din WordPress. Al doilea factor completează, nu înlocuiește, protecția paginii de autentificare: limitarea încercărilor și blocarea XML-RPC rămân necesare, fiindcă atacurile de ghicire consumă resurse chiar dacă nu reușesc.

Aplicațiile care se conectează la site

Aplicația WordPress de pe telefon, clienții de publicare și integrările folosesc parole de aplicație (Application Passwords, în profil), separate de parola contului și fără al doilea factor; sunt legate de un singur scop și se revocă individual. API-ul REST cu autentificare de bază funcționează cu ele, cum descriem în ghidul despre WordPress REST API.

Pe Linux, pentru SSH

Obiectivul corect este cheie SSH plus cod TOTP, nu parolă plus cod: parola rămâne dezactivată, iar al doilea factor se adaugă peste cheie. Pașii, pe Ubuntu (pe AlmaLinux, pachetul este google-authenticator din EPEL, iar serviciul se numește sshd):

sudo apt install libpam-google-authenticator -y
google-authenticator -t -d -f -r 3 -R 30 -w 3      # rulată ca utilizatorul care se conectează

Comanda afișează un cod QR de scanat, secretul și cinci coduri de rezervă; opțiunile setează TOTP (-t), interzic refolosirea codurilor (-d), scriu fișierul fără întrebări (-f), limitează la 3 încercări în 30 de secunde și acceptă o toleranță de timp de un cod. Salvați codurile de rezervă înainte de a merge mai departe.

sudo tee -a /etc/pam.d/sshd <<'EOT'
auth required pam_google_authenticator.so nullok
EOT
sudo tee /etc/ssh/sshd_config.d/70-2fa.conf <<'EOT'
KbdInteractiveAuthentication yes
PasswordAuthentication no
AuthenticationMethods publickey,keyboard-interactive
EOT
sudo sshd -t && sudo systemctl restart ssh

Ce face fiecare parte: rândul din PAM cere codul; nullok lasă utilizatorii care nu au configurat încă un secret să intre fără cod (scoateți-l după ce toți l-au configurat). AuthenticationMethods spune că sunt necesare AMBELE: cheia și apoi codul. Pe Ubuntu, dezactivați și rândul @include common-auth din /etc/pam.d/sshd, altfel serverul cere și parola. Păstrați sesiunea curentă deschisă și testați dintr-o fereastră nouă; dacă nu intrați, reparați din sesiunea deschisă.

Pe AlmaLinux, SELinux trebuie să permită citirea fișierului .google_authenticator din dosarul personal; dacă autentificarea eșuează fără motiv vizibil, ausearch -m avc arată refuzul, iar contextul este descris în ghidul despre SELinux. Restul întăririi SSH, de la chei la fail2ban, este în ghidul despre blocarea atacurilor brute force pe SSH.

Când nu puneți 2FA pe SSH

Pe conturile de serviciu folosite de scripturi (copii de siguranță, rsync, deploy), al doilea factor interactiv nu are sens și le blochează. Folosiți directiva Match User pentru ele, cu AuthenticationMethods publickey, și limitați cheia la comanda necesară, cum arătăm în ghidul despre utilizatorii cu acces limitat.

cPanel și celelalte conturi

cPanel are autentificare în doi pași nativă, în Security, Two-Factor Authentication, cu TOTP; activați-o pe fiecare cont, fiindcă panoul dă acces la fișiere, baze de date și e-mail deodată. Contul de client la găzduire și la registrar, contul Google (Search Console, Analytics, Business Profile), contul Cloudflare și e-mailul administratorului sunt la fel de importante: un atacator care intră în contul de registrar mută domeniul, iar al doilea factor pe site nu ajută cu nimic.

Chei fizice și passkeys, pentru administratori

Codurile TOTP pot fi cerute de un site de phishing bine făcut: victima introduce parola și codul pe pagina falsă, iar atacatorul le folosește în cele 30 de secunde. Cheile fizice (FIDO2) și passkey-urile elimină acest scenariu, fiindcă semnătura este legată de domeniul real; pe un domeniu fals, cheia nu răspunde. Modulul Two-Factor pentru WordPress acceptă chei FIDO din interfața de profil (Security Keys); cPanel și conturile Google le acceptă și ele. Pentru cele două-trei persoane care administrează site-ul și serverul, două chei fizice (una de rezervă, în alt loc) costă cât o oră de curățare a unui site compromis. Pentru SSH, cheile FIDO se folosesc direct ca tip de cheie (ed25519-sk), cu atingerea cheii la fiecare conectare, fără PAM.

Politica de 2FA într-o firmă mică

1. Inventarul conturilor care controlează site-ul: registrar, DNS (Cloudflare), găzduire, cPanel, WordPress (administratori), e-mailul administratorului, Google (Search Console, Analytics, Business Profile), contul de plăți.
2. Al doilea factor obligatoriu pe toate, cu TOTP sau chei; SMS-ul doar unde nu există altă opțiune.
3. Codurile de rezervă și secretele într-un manager de parole partajat al firmei, nu în telefonul unei singure persoane.
4. La plecarea unui angajat: revocarea accesului în aceeași zi, cu verificarea dispozitivelor înregistrate pentru 2FA.
5. O verificare trimestrială a listei: conturi noi, persoane noi, dispozitive vechi.

Recuperarea: ce faceți când pierdeți telefonul

• Codurile de rezervă, generate la configurare și păstrate în managerul de parole, sunt calea principală. Fiecare cod merge o singură dată.
• Pentru WordPress, un al doilea administrator cu propriul 2FA poate dezactiva factorul contului blocat; sau, prin WP-CLI, se șterg meta-datele 2FA ale utilizatorului.
• Pentru SSH, consola furnizorului (KVM sau consola din panou) nu trece prin SSH; de acolo ștergeți sau regenerați fișierul .google_authenticator.
• Aplicațiile cu copie în cloud (Microsoft Authenticator, Aegis cu export criptat, 1Password) refac secretele pe telefonul nou; Google Authenticator le sincronizează cu contul Google dacă opțiunea e activă.
• Două dispozitive înregistrate de la început (telefon și cheie fizică, sau telefon și tabletă) elimină problema.

Greșeli pe care le vedem

• Ceasul serverului sau al telefonului decalat: codurile TOTP depind de oră; chronyd sau systemd-timesyncd trebuie să fie active pe server.
• 2FA pe WordPress, dar contul cPanel cu parola din 2019 și fără al doilea factor.
• Coduri de rezervă salvate într-un fișier text pe desktop, sau deloc.
• nullok lăsat permanent în PAM: utilizatorii noi intră fără cod.
• Al doilea factor pe SMS pentru contul de registrar, exact contul cu cea mai mare valoare.
• Configurarea SSH testată abia după închiderea sesiunii; blocarea afară costă o oră cu consola.

Al doilea factor este măsura cu cel mai bun raport între efort și protecție din tot ce descriem în ghidul despre securizarea unui site WordPress și în cel despre securitatea serverului AlmaLinux 9; se configurează într-o oră și rămâne.

Surse

• Documentația WordPress, autentificarea și protecția ei: parole, al doilea factor, parolele de aplicație.
• Documentația Ubuntu Server, securitate: configurarea OpenSSH și a modulelor PAM.