Blocarea contului sau interdicția adresei: unde OpenVPN numără cu adevărat

Blocarea unei adrese și blocarea unui cont sunt două mecanisme diferite și eșuează în direcții opuse. O interdicție de adresă oprește o singură sursă, iar contul țintă rămâne accesibil din altă parte; blocarea contului oprește acea identitate peste tot, inclusiv pe laptopul utilizatorului însuși.

Pentru un VPN care deleagă autentificarea către PAM, contorul este ceea ce atinge stiva PAM, nu ceea ce a înregistrat ascultătorul.

Două contoare, două victime diferite

Un limitator de viteză privește o sursă și întreabă câte încercări au venit de acolo recent. O blocare privește o identitate și întreabă câte eșecuri a acumulat contul. Primul protejează disponibilitatea, al doilea acreditările; niciunul nu îl înlocuiește pe celălalt.

De aceea propoziția blocăm IP-ul după cinci eșecuri nu este un răspuns la un raport despre umplerea acreditărilor. Atacatorul rotește sursele, fiecare primește puține încercări, iar contul nu este niciodată numărat. Invers, o blocare fără control al sursei îi permite atacatorului să țină contul blocat la nesfârșit eșuând intenționat.

Cele două controale au și povești de recuperare diferite. O interdicție de adresă expiră după un temporizator la care nimeni nu trebuie să se gândească; o blocare de cont poate cere un administrator, o perioadă de așteptare documentată sau o resetare în autoservire.

Găsiți depozitul care deține deja numărul

Înainte de a adăuga ceva, aflați dacă există deja un depozit al eșecurilor. Un cont Linux local, un serviciu de director și un furnizor extern de identitate țin fiecare propriul număr, iar un modul PAM pus în fața lor creează un al doilea în loc să îl extindă pe primul.

grep -rnE 'faillock|pam_tally|pam_unix' /etc/pam.d/
ls -l /etc/pam.d/ | head -20

Citiți fișierul de serviciu pe care VPN-ul îl numește efectiv și urmăriți liniile lui de includere. În multe distribuții serviciul VPN include un fișier comun, ceea ce înseamnă că numărul pe care îl reglați se aplică și pentru SSH și pentru autentificările locale.

Dacă directorul impune deja o blocare, întrebarea utilă este cum ajunge conversația PAM la acea decizie și cum o raportează VPN-ul. Un contor local peste ea nu devine contorul directorului, iar cele două politici pot să nu fie de acord cu privire la momentul deblocării contului.

pam_faillock are trei poziții de apel, nu una

Modulul separă trei operații pe care o singură linie copiată le estompează de obicei: verificarea dacă contul este deja blocat, înregistrarea unui eșec și ștergerea istoricului după un succes.

Aici greșește de obicei migrarea de la un modul de numărare mai vechi. Copierea unei linii dintr-un exemplu pam_tally2 funcțional într-o stivă pam_faillock nu este o redenumire; configurația documentată este diferită, iar un apel plasat greșit poate înregistra eșecuri fără a le verifica vreodată.

faillock --user alice
faillock --user alice --reset

Utilitarul de inspecție este cea mai rapidă cale de a vedea dacă contorul este real: afișează eșecurile înregistrate pentru un cont și le poate șterge. Dacă un eșec controlat nu schimbă acea ieșire, poziția apelului este greșită.

Un nume de serviciu dedicat nu este izolare

A da VPN-ului propriul fișier de serviciu PAM face politica dorită vizibilă, dar nu limitează efectul. Orice includere a unui fișier comun aduce cu ea ce face acel fișier, inclusiv contoare pentru întregul sistem.

Decideți explicit dacă blocarea acoperă doar accesul VPN sau fiecare serviciu care autentifică același cont. Ambele răspunsuri sunt defendabile; eșecul este să credeți că ați ales unul în timp ce stiva îl implementează pe celălalt.

Apoi luați în calcul costul. Un atacator poate declanșa blocarea, iar utilizatorul care suferă este proprietarul contului. Pragul, perioada de așteptare și calea administrativă de recuperare fac parte din politică, iar recuperarea nu trebuie să depindă de reconfigurarea VPN-ului în timpul unui incident.

Acceptați secvența, nu o singură respingere

Testați cu identități desemnate conform unui plan aprobat și testați un lanț, nu un singur eveniment: un cont valid se autentifică, o parolă deliberat greșită mișcă contorul, blocarea configurată intră în vigoare, iar recuperarea documentată redă accesul.

faillock --user test-vpn-01
journalctl -u openvpn-server@lab -n 30 --no-pager | grep -i 'auth\|pam'

Urmăriți comportamentul la succes la fel de atent ca la eșec. Dacă o autentificare reușită nu șterge istoricul, contul se va bloca după o acumulare lentă de greșeli obișnuite. Dacă șterge totul din fiecare serviciu, contorul este mai slab decât susține politica.

În final, opriți clienții nesupravegheați înainte de a declara victoria. Acreditările salvate care reîncearcă în fundal vor recrea eșecurile la câteva minute după o recuperare și vor bloca din nou contul. Limitarea vitezei după sursă poate rămâne ca un control suplimentar, dar nu este politica contului.