Kontolås kontra adressförbud: där OpenVPN faktiskt räknar

Att blockera en adress och att låsa ett konto är två olika mekanismer, och de misslyckas i motsatta riktningar. Ett adressförbud stoppar en källa och målkontot går fortfarande att nå från annat håll; en kontolås stoppar identiteten överallt, även på användarens egen bärbara dator.

För ett VPN som delegerar autentiseringen till PAM är räknaren det PAM-stacken når fram till, inte det lyssnaren loggade.

Två räknare, två olika offer

En hastighetsbegränsare tittar på en källa och frågar hur många försök som nyligen kom därifrån. En låsning tittar på en identitet och frågar hur många fel kontot har samlat. Den första skyddar tillgängligheten, den andra inloggningsuppgifterna; ingen ersätter den andra.

Därför är meningen vi blockerar IP-adressen efter fem fel inte ett svar på en rapport om credential stuffing. Angriparen roterar källor, varje får få försök, och kontot räknas aldrig. Omvänt låter en låsning utan källkontroll angriparen hålla kontot låst på obestämd tid genom att medvetet misslyckas.

De två kontrollerna har också olika återställningshistorier. Ett adressförbud löper ut på en timer som ingen behöver tänka på; en kontolås kan kräva en administratör, en dokumenterad väntetid eller en självbetjäningsåterställning.

Hitta lagret som redan äger räkningen

Innan du lägger till något, ta reda på om det redan finns ett fellager. Ett lokalt Linux-konto, en katalogtjänst och en extern identitetsleverantör har var sin räkning, och en PAM-modul framför dem skapar en ny i stället för att utöka den första.

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

Läs den tjänstefil som VPN-et verkligen anger och följ dess inkluderingsrader. I många distributioner inkluderar VPN-tjänsten en gemensam fil, vilket betyder att räkningen du justerar också gäller SSH och lokala inloggningar.

Om katalogen redan genomdriver en låsning är den användbara frågan hur PAM-samtalet når det beslutet och hur VPN-et rapporterar det. En lokal räkning ovanpå blir inte katalogens räknare, och de två policyerna kan vara oense om när kontot låses upp.

pam_faillock har tre anropspositioner, inte en

Modulen skiljer tre operationer som en kopierad rad vanligen suddar ut: kontrollera om kontot redan är låst, registrera ett fel och rensa historiken efter en lyckad inloggning.

Det är här en migrering från en äldre räknemodul oftast går fel. Att kopiera en rad från ett fungerande pam_tally2-exempel till en pam_faillock-stack är inte en omdöpning; den dokumenterade konfigurationen är annorlunda, och ett felplacerat anrop kan registrera fel utan att någonsin kontrollera dem.

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

Inspektionsverktyget är det snabbaste sättet att se om räknaren är verklig: det visar de registrerade felen för ett konto och kan rensa dem. Om ett kontrollerat fel inte ändrar den utskriften är anropets position fel.

Ett eget tjänstenamn är inte isolering

Att ge VPN-et en egen PAM-tjänstefil gör den avsedda policyn synlig, men begränsar inte effekten. Varje inkludering av en gemensam fil drar in vad den filen gör, inklusive räkningar för hela systemet.

Bestäm uttryckligen om låsningen ska omfatta bara VPN-åtkomst eller varje tjänst som autentiserar samma konto. Båda svaren är försvarbara; felet är att tro att du valde det ena medan stacken genomför det andra.

Ta sedan hänsyn till kostnaden. En angripare kan utlösa låsningen, och användaren som drabbas äger kontot. Tröskel, väntetid och den administrativa återställningsvägen är en del av policyn, och återställningen får inte bero på att VPN-et konfigureras om under en incident.

Acceptera sekvensen, inte en enda avvisning

Testa med utpekade identiteter enligt en godkänd plan, och testa en kedja i stället för en enskild händelse: ett giltigt konto autentiserar, ett medvetet fel lösenord flyttar räknaren, den konfigurerade låsningen träder i kraft och den dokumenterade återställningen ger tillbaka åtkomsten.

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

Titta på beteendet vid framgång lika noga som vid fel. Om en lyckad inloggning inte rensar historiken låses kontot efter en långsam ansamling av vanliga fel. Om den rensar allt från varje tjänst är räknaren svagare än policyn påstår.

Stoppa slutligen obevakade klienter innan du utropar seger. Sparade inloggningsuppgifter som försöker igen i bakgrunden återskapar felen minuter efter en återställning och låser kontot igen. Källbaserad hastighetsbegränsning kan stå kvar som en extra kontroll, men det är inte kontopolicyn.