Utelåst av en VPN-försöksslinga: stoppa klienten först

Klockan 02:40 låses kontot och ingen sitter vid tangentbordet. En klient på en hylla fortsätter att presentera lösenordet den sparade förra månaden, gatewayen fortsätter att avvisa det, och räknaren bakom utelåsningen stiger utan att en människa är inblandad. Det här är en försöksslinga och inte en attack, och den måste stoppas innan kontot kan återställas.

Behandla det som två problem i en fast ordning. Stoppa först avsändaren och återställ sedan åtkomsten, för den omvända ordningen startar om slingan inom några minuter.

Ta reda på vilken process som skickar felen

Börja med tidsstämplarna i identitetssystemet och jämför dem med varje klient som har kontot. En hanterad profil, en tjänst utan övervakning, en telefon i en låda och en reservdator med gamla inloggningsuppgifter kan alla autentisera sig som samma person. Den som misslyckas varannan sekund är slingan, och den som misslyckas en gång om dagen är oftast en människa som glömt det. Båda matar samma räknare, och det är fällan.

Skilj på ett avslag och en oåtkomlig gateway medan du tittar. En tidsgräns, ett namnmatchfel eller en stängd port ökar normalt inte en felräknare, medan ett slutfört autentiseringsutbyte som returnerar ett resultat om dåliga inloggningsuppgifter gör det. Att blanda de två ger fel åtgärd, eftersom den ena kräver att klienten stoppas och den andra att vägen repareras.

Tre förhållanden som avgör svaret

Tre fakta begränsar detta till ett svar. För det första om posten visar ett uttryckligt avslag eller ett transportfel. För det andra om identiteten delas mellan enheter eller tjänster. För det tredje om klienten som försöker igen är en du administrerar eller en som någon annan kontrollerar.

Ett uttryckligt avslag från en enda klient som du kontrollerar innebär att du stoppar den klienten, låser upp via den godkända vägen och gör en enda medveten inloggning. En delad identitet skjuter svaret mot etablering i stället för upplåsning, eftersom slingan återupptas i samma stund som den andra enheten ansluter igen. Transportfel pekar på nätverkslagret, där kontoskydd inte alls är frågan.

Ingen av dessa grenar innebär att skyddet försvagas. Utelåsningströsklar och hastighetsgränser finns eftersom samma signal som irriterar dig under ett avbrott är den signal som bromsar ett försök att gissa ett lösenord.

Stoppa avsändaren innan du låser upp

Stoppa enheten eller anslutningen som fortsätter att autentisera, och stoppa den på ett sätt som överlever en omstart. Att pausa klienten räcker inte när dess tjänst är inställd på att starta automatiskt vid uppstart.

# which unit is presenting the credential?
journalctl -u openvpn-client@home --since '20 min ago' | grep -i 'auth\|error'

# stop it, and keep it stopped across reboots
sudo systemctl stop openvpn-client@home
sudo systemctl disable openvpn-client@home
systemctl is-active openvpn-client@home

Vänta några minuter och bekräfta att felräknaren slutar röra sig. Den pausen är beviset på att du hittade rätt källa. Om felen fortsätter kommer slingan någon annanstans ifrån och upplåsningssteget skulle vara bortkastat.

Först då ska du använda operatörens dokumenterade upplåsnings- eller återställningsprocess, och följa den med exakt en kontrollerad inloggning från den enhet du tänker behålla. Exakta trösklar, nedkylningsperioder och formuleringen av återställningen är tjänstespecifika, så läs dem i stället för att gissa en siffra.

Ta bort orsaken så att den inte kommer tillbaka

Uppdatera den sparade inloggningsuppgiften där den ägs: i operativsystemets nyckelring, i klientprofilen eller i konfigurationen för tjänstekontot. Att rensa den på ett ställe medan ett annat behåller en kopia är hur slingan kommer tillbaka en vecka senare, oftast när en bärbar dator som var offline kommer tillbaka och spelar upp sitt cachade värde.

Ge automatiseringen en egen identitet. Ett separat etablerat konto med egen inloggningsuppgift och egna gränser hindrar att ett maskinfel låser en person ute från e-post, och det gör felet spårbart i loggarna. Lägg till en tillbakadragning i klienten så att en avvisad inloggningsuppgift stoppar försöken i stället för att upprepa dem, och larma vid upprepade autentiseringsfel så att nästa slinga upptäcks inom minuter och inte klockan 02:40.

När rapporten går till support, behåll kontoidentifieraren, tidsstämplarna och klientnamnet. Lösenord och återställningsmaterial hör aldrig hemma i den posten.