Kontolås mot adresseforbud: hvor OpenVPN egentlig teller

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

For en VPN som overlater autentiseringen til PAM, er telleren det PAM-stakken når frem til, ikke det som lyttetjenesten skrev i 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. Den første beskytter tilgjengeligheten, den andre påloggingsinformasjonen; 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 bytter 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å ulike historier for gjenoppretting. Et adresseforbud utløper på en timer som 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 finne ut 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 navngir, og følg inkluderingslinjene. I mange distribusjoner inkluderer VPN-tjenesten en felles fil, noe 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 den 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 eksplisitt 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 lås kan utløses av en angriper, 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 å rekonfigurere VPN-et under en hendelse.

Aksepter 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 autentiseres, 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åloggingsdata som prøver igjen i bakgrunnen, gjenoppretter feilene minutter etter en gjenoppretting og låser kontoen på nytt. Kildebasert hastighetsbegrensning kan bli stående som en ekstra kontroll, men det er ikke kontopolicyen.