Kontolås kontra adresseforbud: hvor OpenVPN faktisk tæller

At blokere en adresse og at låse en konto er to forskellige mekanismer, og de fejler i modsatte retninger. Et adresseforbud stopper én kilde og lader målkontoen være tilgængelig fra andre steder; en kontolås stopper identiteten overalt, også på brugerens egen bærbare.

For en VPN, der delegerer godkendelse til PAM, er tælleren det, PAM-stakken når frem til, ikke det, lytteren loggede.

To tællere, to forskellige ofre

En hastighedsbegrænser ser på en kilde og spørger, hvor mange forsøg der for nylig kom fra den. En lås ser på en identitet og spørger, hvor mange fejl kontoen har samlet. Den første beskytter tilgængelighed, den anden legitimationsoplysninger; ingen af dem erstatter den anden.

Derfor er sætningen vi blokerer IP-adressen efter fem fejl ikke et svar på en rapport om credential stuffing. Angriberen skifter kilder, hver får få forsøg, og kontoen tælles aldrig. Omvendt lader en lås uden kildekontrol angriberen holde kontoen låst på ubestemt tid ved at fejle med vilje.

De to kontroller har også forskellige historier om genopretning. Et adresseforbud udløber på en timer, ingen skal tænke på; en kontolås kan kræve en administrator, en dokumenteret ventetid eller en selvbetjeningsnulstilling.

Find det lager, der allerede ejer tællingen

Før du tilføjer noget, skal du finde ud af, om der allerede findes et fejllager. En lokal Linux-konto, en katalogtjeneste og en ekstern identitetsudbyder holder hver deres egen tælling, og et PAM-modul foran dem opretter en ny i stedet for at udvide den første.

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

Læs den tjenestefil, VPN’en faktisk henviser til, og følg dens inkluderingslinjer. I mange distributioner inkluderer VPN-tjenesten en fælles fil, hvilket betyder, at den tælling, du justerer, også gælder for SSH og lokale logins.

Hvis kataloget allerede håndhæver en lås, er det nyttige spørgsmål, hvordan PAM-samtalen når den beslutning, og hvordan VPN’en rapporterer den. En lokal tælling ovenpå bliver ikke katalogets tæller, og de to politikker kan være uenige om, hvornår kontoen låses op.

pam_faillock har tre kaldspositioner, ikke én

Modulet adskiller tre handlinger, som én kopieret linje normalt slører: at kontrollere, om kontoen allerede er låst, at registrere en fejl og at rydde historikken efter en succes.

Det er her, en migrering fra et ældre tællemdul ofte går galt. At kopiere en linje fra et fungerende pam_tally2-eksempel ind i en pam_faillock-stak er ikke en omdøbning; opsætningen er dokumenteret anderledes, og et forkert placeret kald kan registrere fejl uden nogensinde at kontrollere dem.

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

Inspektionsværktøjet er den hurtigste måde at se, om tælleren er reel: det viser de registrerede fejl for en konto og kan rydde dem. Hvis en kontrolleret fejl ikke ændrer det output, er kaldspositionen forkert.

Et dedikeret tjenestenavn er ikke isolering

At give VPN’en sin egen PAM-tjenestefil gør den tilsigtede politik synlig, men begrænser ikke effekten. Enhver inkludering af en fælles fil trækker alt ind, hvad den fil gør, inklusive tællinger for hele systemet.

Beslut eksplicit, om låsen kun skal dække VPN-adgang eller hver tjeneste, der godkender den samme konto. Begge svar er forsvarlige; fejlen er at tro, man har valgt det ene, mens stakken udfører det andet.

Medregn derefter omkostningen. En lås kan udløses af en angriber, og den bruger, der lider, er ejeren af kontoen. Tærskel, ventetid og den administrative genopretningsvej er alle en del af politikken, og genopretningen må ikke afhænge af at omkonfigurere VPN’en under en hændelse.

Accepter sekvensen, ikke en enkelt afvisning

Test med udpegede identiteter under en godkendt plan, og test en kæde frem for en enkelt hændelse: en gyldig konto godkendes, en bevidst forkert adgangskode flytter tælleren, den konfigurerede lås træder i kraft, og den dokumenterede genopretning giver adgang igen.

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

Se på succesadfærden lige så omhyggeligt som på fejladfærden. Hvis et vellykket login ikke rydder historikken, låses en konto efter en langsom ophobning af almindelige fejl. Hvis det rydder alt fra alle tjenester, er tælleren svagere, end politikken hævder.

Til sidst skal du stoppe uovervågede klienter, før du erklærer sejr. Gemte legitimationsoplysninger, der prøver igen i baggrunden, genskaber fejlene minutter efter en genopretning og låser kontoen igen. Kildebaseret hastighedsbegrænsning kan blive som en ekstra kontrol, men det er ikke kontopolitikken.