Låst ude af en VPN-forsøgsløkke: stop klienten først

Klokken 02:40 låses kontoen, og der er ingen ved tastaturet. En klient på en hylde bliver ved med at fremvise den adgangskode, den gemte i sidste måned, gatewayen bliver ved med at afvise den, og tælleren bag udelåsningen stiger, uden at et menneske er involveret. Det er en forsøgsløkke og ikke et angreb, og den skal stoppes, før kontoen kan gendannes.

Behandl det som to problemer i en fast rækkefølge. Stop først afsenderen, og gendan derefter adgangen, for den omvendte rækkefølge starter løkken igen inden for få minutter.

Find ud af, hvilken proces der sender fejlene

Start med tidsstemplerne i identitetssystemet, og sammenlign dem med hver klient, der har kontoen. En administreret profil, en uovervåget tjeneste, en telefon i en skuffe og en ekstra bærbar med gamle legitimationsoplysninger kan alle godkende som den samme person. Den, der fejler hvert par sekunder, er løkken, og den, der fejler en gang om dagen, er som regel et menneske, der har glemt det. Begge fodrer den samme tæller, og det er fælden.

Skeln mellem en afvisning og en utilgængelig gateway, mens du kigger. En timeout, en navneopløsningsfejl eller en lukket port øger normalt ikke en fejltæller, mens en gennemført godkendelsesudveksling, der returnerer et resultat om dårlige legitimationsoplysninger, gør. At blande de to giver den forkerte løsning, fordi den ene kræver klienten stoppet, og den anden kræver stien repareret.

Tre betingelser, der afgør reaktionen

Tre forhold indsnævrer det til ét svar. For det første, om registreringen viser en eksplicit afvisning eller en transportfejl. For det andet, om identiteten deles på tværs af enheder eller tjenester. For det tredje, om den klient, der forsøger igen, er en, du administrerer, eller en, nogen andre kontrollerer.

En eksplicit afvisning fra en enkelt klient, du kontrollerer, betyder, at du skal stoppe den klient, låse op ad den godkendte vej og foretage ét bevidst login. En delt identitet skubber svaret mod klargøring i stedet for oplåsning, fordi løkken genoptages i det øjeblik, den anden enhed opretter forbindelse igen. Transportfejl peger på netværkslaget, hvor kontobeskyttelse slet ikke er emnet.

Ingen af disse grene indebærer at svække beskyttelsen. Udelåsningstærskler og hastighedsgrænser findes, fordi det samme signal, der irriterer dig under et nedbrud, er det signal, der bremser et forsøg på at gætte en adgangskode.

Stop afsenderen, før du låser op

Stop den enhed eller forbindelse, der bliver ved med at godkende, og stop den på en måde, der overlever en genstart. Det er ikke nok at sætte klienten på pause, når dens tjeneste er indstillet til at starte automatisk ved opstart.

# 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

Vent et par minutter, og bekræft, at fejltælleren holder op med at bevæge sig. Den pause er beviset på, at du har fundet den rigtige kilde. Hvis fejlene fortsætter, kommer løkken fra et andet sted, og oplåsningstrinnet ville være spildt.

Brug først derefter operatørens dokumenterede oplåsnings- eller gendannelsesproces, og følg den med præcis ét kontrolleret login fra den enhed, du har tænkt dig at beholde. Præcise tærskler, afkølingsperioder og gendannelsesformuleringer er tjenestespecifikke, så læs dem i stedet for at gætte på et tal.

Fjern årsagen, så den ikke vender tilbage

Opdater den gemte legitimationsoplysning der, hvor den ejes: i operativsystemets nøglering, i klientprofilen eller i tjenestekontoens konfiguration. At rydde den ét sted, mens et andet sted beholder en kopi, er måden, løkken vender tilbage en uge senere, normalt når en bærbar, der var offline, kommer tilbage og afspiller sin cachelagrede værdi.

Giv automatisering sin egen identitet. En separat klargjort konto med egne legitimationsoplysninger og egne grænser forhindrer, at en maskinfejl låser en person ude af e-mail, og den gør fejlen tilskrivbar i loggene. Tilføj en tilbageholdenhed til klienten, så en afvist legitimationsoplysning stopper forsøgene i stedet for at gentage dem, og alarmér ved gentagne godkendelsesfejl, så den næste løkke bemærkes i løbet af minutter i stedet for klokken 02:40.

Når rapporten går til support, skal du beholde kontoidentifikatoren, tidsstemplerne og klientnavnet. Adgangskoder og gendannelsesmateriale hører aldrig i den registrering.