Kontolås eller adresseforbud: hvor OpenVPN virkelig teller

Å blokkere en adresse og låse en konto er to forskjellige mekanismer, og de feiler i motsatte retninger. Et adresseforbud stopper én kilde, og målkontoen er fortsatt tilgjengelig fra andre steder; en kontolås stopper identiteten overalt, også på brukerens egen maskin.

Når en VPN overlater autentiseringen til PAM, er telleren det PAM-stakken kommer frem til, ikke det som ble skrevet til loggen.

To tellere, to forskjellige ofre

En hastighetsbegrenser ser på en kilde og spør hvor mange forsøk som nylig kom derfra. En lås ser på en identitet og spør hvor mange feil kontoen har samlet opp. Den første verner tilgjengelighet, den andre påloggingsdetaljer; ingen av dem erstatter den andre.

Derfor er setningen vi blokkerer IP-adressen etter fem feil ikke et svar på en rapport om credential stuffing. Angriperen roterer kilder, hver får få forsøk, og kontoen telles aldri. Motsatt lar en lås uten kildekontroll angriperen holde kontoen låst på ubestemt tid ved å feile med vilje.

De to kontrollene har også forskjellige gjenopprettingshistorier. Et adresseforbud utløper på en timer ingen trenger å tenke på; en kontolås kan kreve en administrator, en dokumentert ventetid eller en selvbetjent tilbakestilling.

Finn lageret som allerede eier tellingen

Før du legger til noe, må du avklare om det allerede finnes et feillager. En lokal Linux-konto, en katalogtjeneste og en ekstern identitetsleverandør har hver sin telling, og en PAM-modul foran dem lager en ny i stedet for å utvide den første.

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

Les tjenestefilen VPN-et faktisk peker på, og følg inkluderingslinjene. I mange distribusjoner inkluderer VPN-tjenesten en felles fil, som betyr at tellingen du justerer også gjelder SSH og lokale innlogginger.

Hvis katalogen allerede håndhever en lås, er det nyttige spørsmålet hvordan PAM-samtalen kommer frem til avgjørelsen, og hvordan VPN-et rapporterer den. En lokal telling på toppen blir ikke katalogens teller, og de to policyene kan være uenige om når kontoen låses opp.

pam_faillock har tre kalleposisjoner, ikke én

Modulen skiller tre operasjoner som én kopiert linje vanligvis visker ut: kontrollere om kontoen allerede er låst, registrere en feil og slette historikken etter en vellykket pålogging.

Det er her migreringen fra en eldre tellemodul ofte går galt. Å kopiere en linje fra et fungerende pam_tally2-eksempel inn i en pam_faillock-stakk er ikke en omdøping; oppsettet er dokumentert annerledes, og et feilplassert kall kan registrere feil uten å kontrollere dem.

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

Inspeksjonsverktøyet er den raskeste måten å se om telleren er ekte: det viser de registrerte feilene for en konto og kan slette dem. Hvis en kontrollert feil ikke endrer utdataene, er kalleposisjonen feil.

Et eget tjenestenavn er ikke isolasjon

Å gi VPN-et sin egen PAM-tjenestefil gjør den tiltenkte policyen synlig, men begrenser ikke effekten. Enhver inkludering av en felles fil drar med seg det filen gjør, inkludert tellinger for hele systemet.

Bestem uttrykkelig om låsen skal dekke bare VPN-tilgang eller hver tjeneste som autentiserer samme konto. Begge svarene er forsvarlige; feilen er å tro at du valgte én mens stakken gjennomfører den andre.

Ta så hensyn til kostnaden. En angriper kan utløse låsen, og brukeren som lider er eieren av kontoen. Terskel, ventetid og den administrative gjenopprettingsveien er en del av policyen, og gjenopprettingen må ikke avhenge av å konfigurere VPN-et på nytt under en hendelse.

Godta sekvensen, ikke én enkelt avvisning

Test med utpekte identiteter under en godkjent plan, og test en kjede i stedet for en enkelt hendelse: en gyldig konto autentiserer, et med vilje feil passord flytter telleren, den konfigurerte låsen trer i kraft, og den dokumenterte gjenopprettingen gir tilgangen tilbake.

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

Se på suksessatferden like nøye som feilatferden. Hvis en vellykket pålogging ikke sletter historikken, låses kontoen etter en langsom opphopning av vanlige feil. Hvis den sletter alt fra hver tjeneste, er telleren svakere enn policyen hevder.

Til slutt må du stoppe uovervåkede klienter før du erklærer seier. Lagrede påloggingsdetaljer som prøver igjen i bakgrunnen, gjenoppretter feilene minutter etter en gjenoppretting og låser kontoen igjen. Kildebasert hastighetsbegrensning kan bli stående som en ekstra kontroll, men det er ikke kontopolicyen.