Kontolås mot adresseforbod: kvar OpenVPN eigentleg tel

Å blokkere ei adresse og å låse ein konto er to ulike mekanismar, og dei sviktar i motsette retningar. Eit adresseforbod stoppar éi kjelde og lèt målkontoen vere tilgjengeleg frå andre stader; ein kontolås stoppar identiteten overalt, også på den brukaren si eiga berbare maskin.

For ein VPN som overlèt autentiseringa til PAM, er teljaren det PAM-stakken når fram til, ikkje det lyttetenesta skreiv i loggen.

To teljarar, to ulike offer

Ein hastigheitsavgrensar ser på ei kjelde og spør kor mange forsøk som nyleg kom derfrå. Ein lås ser på ein identitet og spør kor mange feil kontoen har samla. Den fyrste vernar tilgjenge, den andre påloggingsinformasjon; ingen av dei erstattar den andre.

Difor er setninga vi blokkerer IP-adressa etter fem feil ikkje eit svar på ein rapport om credential stuffing. Angriparen byter kjelder, kvar får få forsøk, og kontoen blir aldri talt. Motsett lèt ein lås utan kjeldekontroll angriparen halde kontoen låst på ubestemt tid ved å feile med vilje.

Dei to kontrollane har også ulike historier for gjenoppretting. Eit adresseforbod går ut på ein timer ingen treng å tenkje på; ein kontolås kan krevje ein administrator, ei dokumentert ventetid eller ei sjølvbetent tilbakestilling.

Finn lageret som alt eig teljinga

Før du legg til noko, må du finne ut om det alt finst eit feillager. Ein lokal Linux-konto, ein katalogteneste og ein ekstern identitetsleverandør har kvar si teljing, og ein PAM-modul framfor dei lagar ei ny i staden for å utvide den fyrste.

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

Les tenestefila VPN-et faktisk nemner, og følg inkluderingslinjene. I mange distribusjonar inkluderer VPN-tenesta ei felles fil, noko som betyr at teljinga du justerer også gjeld SSH og lokale innloggingar.

Viss katalogen alt handhevar ein lås, er det nyttige spørsmålet korleis PAM-samtalen kjem fram til den avgjerda, og korleis VPN-et rapporterer henne. Ei lokal teljing på toppen blir ikkje katalogen sin teljar, og dei to retningslinjene kan vere usamde om når kontoen låser seg opp.

pam_faillock har tre kalleposisjonar, ikkje éin

Modulen skil tre operasjonar som éi kopiert line vanlegvis viskar ut: kontrollere om kontoen alt er låst, registrere ein feil og slette historia etter ein suksess.

Det er her migreringa frå ein eldre teljemodul ofte går gale. Å kopiere ei line frå eit fungerande pam_tally2-døme inn i ein pam_faillock-stakk er ikkje ei omdøyping; oppsettet er dokumentert annleis, og eit feilplassert kall kan registrere feil utan å kontrollere dei.

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

Inspeksjonsverktøyet er den snøggaste måten å sjå om teljaren er ekte: det viser dei registrerte feila for ein konto og kan slette dei. Viss ein kontrollert feil ikkje endrar utdata, er kalleposisjonen feil.

Eit eige tenestenamn er ikkje isolasjon

Å gje VPN-et si eiga PAM-tenestefil gjer den tiltenkte retningslinja synleg, men avgrensar ikkje verknaden. Kvar inkludering av ei felles fil dreg med seg det fila gjer, inkludert teljingar for heile systemet.

Avgjer uttrykkeleg om låsen skal dekkje berre VPN-tilgang eller kvar teneste som autentiserer same konto. Begge svara er forsvarlege; feilen er å tru at du valde éin medan stakken gjennomfører den andre.

Ta så omsyn til kostnaden. Ein angripar kan utløyse låsen, og brukaren som lid er eigaren av kontoen. Terskel, ventetid og den administrative gjenopprettingsvegen er del av retningslinja, og gjenopprettinga må ikkje avhenge av å konfigurere VPN-et på nytt under ei hending.

Godta sekvensen, ikkje éi einskild avvising

Test med utpeika identitetar under ein godkjend plan, og test ei kjede i staden for ei einskild hending: ein gyldig konto autentiserer, eit med vilje feil passord flyttar teljaren, den sette låsen trer i kraft, og den dokumenterte gjenopprettinga gjev tilgangen attende.

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

Sjå på suksessåtferda like nøye som feilåtferda. Viss ei vellukka pålogging ikkje slettar historia, blir ein konto låst etter ei langsam opphoping av vanlege feil. Viss ho slettar alt frå kvar teneste, er teljaren svakare enn retningslinja hevdar.

Til slutt må du stoppe uovervaka klientar før du kunngjer siger. Lagra påloggingsinformasjon som prøver på nytt i bakgrunnen, gjenopprettar feila minutt etter ei gjenoppretting og låser kontoen att. Kjeldebasert hastigheitsavgrensing kan bli ståande som ein ekstra kontroll, men det er ikkje kontoretningslinja.