Błędna próba VPN: która klasa danych uwierzytelniających przekroczyła granicę?
Nieudana próba mogła nic nie wysłać albo przekazać hasło temu, kto odpowiedział. Sklasyfikuj artefakt, zanim zdecydujesz, co unieważnić.
Połączyłeś się z niewłaściwym VPN, a klient zgłosił błąd. To, czy miało to znaczenie, zależy od tego, co przeszło przez łącze przed błędem, a samo słowo tego nie mówi. Niektóre uzgodnienia nie niosą żadnego sekretu, a inne przekazują hasło każdemu, kto odpowiedział na adres. Ustal, który z tych dwóch przypadków nastąpił, zanim cokolwiek unieważnisz.
Zatrzymaj się i zachowaj dowody
Zachowaj dziennik klienta, wybrany profil, wpisany adres i przybliżony czas. Zapisz je poza klientem, ponieważ edycja profilu lub ponowna instalacja niszczy zapis, którego będziesz potrzebować. Wstrzymaj każdą dalszą próbę, dopóki punkt końcowy nie zostanie potwierdzony drogą, którą kontrolujesz.
Nigdy nie publikuj nieocenzurowanego profilu ani dziennika na publicznym forum, pytając, czy próba była bezpieczna. Te dokumenty często zawierają ścieżkę klucza prywatnego, wewnętrzną nazwę hosta lub token, więc najpierw ocenzuruj i udostępnij administratorowi, do którego należy punkt końcowy.
Co może przekroczyć granicę
Większość zamieszania wynika z traktowania każdego błędu jako jednego rodzaju zdarzenia. Po drugą stronę mogą dotrzeć cztery różne rzeczy: publiczny certyfikat, podpis dowodzący użycia klucza, hasło lub kod jednorazowy oraz plik, który sam wybrałeś. Każda ma swoją konsekwencję i swoje naprawienie. Sklasyfikowanie artefaktu to krok, który rozstrzyga wszystko później.
Przypadek certyfikatu jest najłagodniejszy, ponieważ to, co podróżuje, jest z założenia publiczne, a jego pola identyfikacyjne są już widoczne dla każdego, kto się łączy. Podpis nad wyzwaniem mówi, że klucz został użyty, a nie że został wysłany. Hasło to przypadek odwrotny: kto je otrzyma, może spróbować go gdzie indziej, a usługa zbudowana do weryfikacji haseł jest zamierzonym odbiorcą dokładnie tej wartości.
Dowód klucza to nie wysłanie klucza
Nowoczesny TLS celowo rozdziela te dwie idee. RFC 8446 opisuje komunikat CertificateVerify, w którym klient podpisuje wyzwanie kluczem prywatnym pasującym do jego certyfikatu. Podpis wykazuje posiadanie bez przenoszenia klucza, dlatego próba uwierzytelniona certyfikatem nie jest automatycznie kompromitacją klucza.
To uspokojenie ma granicę, którą warto wskazać. Dowód pokazuje, że klucz brał udział w tej wymianie, i nie mówi nic o tym, co lokalny program na maszynie mógł już przeczytać. Nie mówi też, jak daleko naprawdę dotarła nieznana próba, dlatego dziennik nadal znaczy więcej niż teoria.
Hasła podlegają zupełnie innemu modelowi zaufania. Koncentrator skonfigurowany z zewnętrznym weryfikatorem może przekazać dalej przesłaną wartość, więc jej odbiór jest zamierzoną funkcją, a zły cel to rzeczywiste ujawnienie, a nie teoretyczne.
Odtwórz próbę z dziennika
Cztery fakty odtwarzają próbę: adres, z którym faktycznie się połączono, czy tożsamość serwera została zweryfikowana, która metoda uwierzytelniania została wybrana i gdzie proces się zatrzymał. Każdy z nich pojawia się w dzienniku klienta i każdy wyklucza inną wersję. Błąd dotyczący tras lub przydzielonego adresu nie mówi nic o tym, co już było na łączu, ponieważ uwierzytelnianie mogło się zakończyć, zanim nie powiodło się ustawienie tunelu.
Wyciągnij te fakty z dziennika samego klienta, a nie z pamięci. Wąski filtr utrzymuje wynik wystarczająco krótki, by go ocenzurować i udostępnić:
grep -n -i -E 'verify|authentication|certificate|error|timeout' client.log | tail -30Nie zastępuj nazwy hosta żadnym z tych elementów. Znana nazwa, bieżąca odpowiedź DNS i ostrzeżenie o certyfikacie pokazywane przez oprogramowanie opisują teraźniejszość, a nie wcześniejsze połączenie. Monit o hasło również nie dowodzi, że coś wysłano, ponieważ klient mógł zawieść przed jego przesłaniem.
Zdecyduj, potem działaj
Decyzja wynika z artefaktu, a nie z tego, jak alarmujący wydawał się błąd. Przeczytaj cztery wiersze wobec odtworzonych faktów:
| Decision | Evidence that puts you here | Evidence that rules it out |
|---|---|---|
| Change the password now | A password was submitted and a server reply arrived | The log stops before any submission |
| Review active sessions | A one-time code was accepted by the wrong endpoint | The code was never sent, or was rejected before use |
| Revoke and reissue | The file you selected contained key material, not just settings | The upload was a profile with no embedded key |
| No further action | The attempt ended before any authentication value was offered | You later find an earlier attempt you had forgotten |
Jeśli hasło dotarło do niepożądanej usługi, zmień je kanałem zarządzania kontem i sprawdź, gdzie jeszcze zostało użyte ponownie. Wygasły kod jednorazowy zamyka tę drogę, ale utworzona nim sesja nie, więc poproś administratora tożsamości o przegląd sesji. Jeśli plik klucza rzeczywiście został przesłany, postępuj zgodnie z procedurą unieważnienia organizacji wydającej, zamiast czekać na dowody nadużycia.
Następnie zapisz ograniczony wynik: co wysłano, co pozostaje nieznane i które dane uwierzytelniające wymagają działania. To ten zapis poprosi późniejszy przegląd i jest on użyteczniejszy niż którykolwiek z dwóch wygodnych wniosków.