Zablokowany przez pętlę ponownych prób VPN: najpierw zatrzymaj klienta
Zapisane hasło plus automatyczne ponowne łączenie mogą zamienić jedno nieaktualne poświadczenie w blokadę konta. Znajdź nadawcę, zatrzymaj go, a następnie użyj zatwierdzonego procesu odzyskiwania.
O 02:40 konto zostaje zablokowane, a przy klawiaturze nie ma nikogo. Klient na półce wciąż przedstawia hasło zapisane w zeszłym miesiącu, brama wciąż je odrzuca, a licznik za blokadą rośnie bez udziału człowieka. To pętla ponownych prób, a nie atak, i trzeba ją zatrzymać, zanim konto będzie można odzyskać.
Traktuj to jako dwa problemy w ustalonej kolejności. Najpierw zatrzymaj nadawcę, potem przywróć dostęp, bo odwrotna kolejność wznawia pętlę w ciągu kilku minut.
Ustal, który proces wysyła błędy
Zacznij od znaczników czasu w systemie tożsamości i zestaw je z każdym klientem, który ma konto. Zarządzany profil, usługa bez nadzoru, telefon w szufladzie i zapasowy laptop ze starymi poświadczeniami — wszystkie mogą uwierzytelnić się jako ta sama osoba. Ten, który zawodzi co kilka sekund, to pętla, a ten, który zawodzi raz dziennie, to zwykle człowiek, który zapomniał. Oba zasilają ten sam licznik i w tym tkwi pułapka.
Podczas sprawdzania odróżnij odrzucenie od nieosiągalnej bramy. Przekroczenie limitu czasu, błąd rozwiązywania nazw lub zamknięty port zwykle nie zwiększają licznika niepowodzeń, natomiast zakończona wymiana uwierzytelniania zwracająca wynik błędnych poświadczeń zwiększa go. Mieszanie obu daje złą naprawę, bo jedno wymaga zatrzymania klienta, a drugie naprawy ścieżki.
Trzy warunki, które decydują o reakcji
Trzy fakty zawężają to do jednej odpowiedzi. Po pierwsze, czy zapis pokazuje wyraźne odrzucenie, czy awarię transportu. Po drugie, czy tożsamość jest współdzielona między urządzeniami lub usługami. Po trzecie, czy ponawiający klient jest tym, którym zarządzasz, czy tym, który kontroluje ktoś inny.
Wyraźne odrzucenie od jednego klienta, którego kontrolujesz, oznacza zatrzymanie tego klienta, odblokowanie zatwierdzoną drogą i wykonanie jednego świadomego logowania. Współdzielona tożsamość popycha odpowiedź w stronę zapewniania, a nie odblokowania, bo pętla wznowi się w chwili, gdy drugie urządzenie połączy się ponownie. Awarie transportu wskazują warstwę sieci, gdzie ochrona konta w ogóle nie jest tematem.
Żadna z tych gałęzi nie polega na osłabianiu ochrony. Progi blokady i limity szybkości istnieją, ponieważ ten sam sygnał, który irytuje cię podczas awarii, jest sygnałem, który spowalnia próbę zgadnięcia hasła.
Zatrzymaj nadawcę, zanim odblokujesz
Zatrzymaj jednostkę lub połączenie, które wciąż się uwierzytelnia, i zatrzymaj je tak, aby przetrwało restart. Wstrzymanie klienta nie wystarcza, gdy jego usługa jest ustawiona na automatyczny start przy uruchomieniu.
# 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
Poczekaj kilka minut i potwierdź, że licznik niepowodzeń przestał się ruszać. Ta pauza jest dowodem, że znalazłeś właściwe źródło. Jeśli niepowodzenia trwają, pętla pochodzi z innego miejsca i krok odblokowania byłby zmarnowany.
Dopiero wtedy użyj udokumentowanego procesu odblokowania lub odzyskiwania operatora i przeprowadź go z dokładnie jednym kontrolowanym logowaniem z urządzenia, które zamierzasz zachować. Dokładne progi, okresy wychładzania i sformułowania odzyskiwania są specyficzne dla usługi, więc przeczytaj je, zamiast zgadywać liczbę.
Usuń przyczynę, żeby nie wróciła
Zaktualizuj zapisane poświadczenia tam, gdzie są one własnością: w pęku kluczy systemu operacyjnego, w profilu klienta lub w konfiguracji konta usługi. Wyczyszczenie ich w jednym miejscu, gdy inne trzyma kopię, to sposób, w jaki pętla wraca tydzień później, zwykle gdy laptop, który był offline, wraca i odtwarza swoją zapisaną wartość.
Daj automatyzacji własną tożsamość. Osobno przygotowane konto z własnymi poświadczeniami i własnymi limitami nie pozwala awarii maszyny zablokować człowiekowi dostępu do poczty i czyni awarię możliwą do przypisania w logach. Dodaj wycofanie w kliencie, aby odrzucone poświadczenia zatrzymywały ponowienia zamiast je powtarzać, i ustaw alarm na powtarzające się błędy uwierzytelniania, aby następna pętla została zauważona w ciągu minut, a nie o 02:40.
Gdy raport trafia do wsparcia, zachowaj identyfikator konta, znaczniki czasu i nazwę klienta. Hasła i materiały do odzyskiwania nigdy nie należą do tego zapisu.