Jak sprawdzić, co obejmuje wyłącznik awaryjny na przejętym hoście

Uruchom test przerwy, odczytaj wynik każdej warstwy i zobacz, gdzie zatrzymuje się wyłącznik awaryjny: blokuje ścieżki, a nie oprogramowanie czytające dane przed szyfrowaniem.

Włącz wyłącznik awaryjny, odłącz serwer tunelu i obserwuj, co maszyna nadal robi. Test warto wykonać, bo oddziela to, co naprawdę egzekwuje zapora, od tego, co zakładałeś, a wyniki są węższe, niż sugeruje większość stron produktów. Wyłącznik awaryjny zarządza ścieżkami sieciowymi; nie zarządza oprogramowaniem już działającym na urządzeniu. Wykonuję tę sekwencję na każdej maszynie, której klient twierdzi, że jest fail-closed, i trwa to około dziesięciu minut.

Zacznij od klienta, nie od serwera

Punktem egzekwowania jest host, przy którym siedzisz: zapora systemu operacyjnego, usługa pomocnicza lub sterownik samego klienta VPN. To ważne, bo wszystko, co wyłącznik może zrobić, jest ograniczone tym, co widzi ta warstwa. Jeśli klient realizuje blokadę regułą routingu i znacznikiem, wszystko z wystarczającymi uprawnieniami może dodać własną regułę; jeśli używa tabeli zapory jądra, te same uprawnienia mogą edytować tabelę. Siła szyfru nigdy nie wchodzi w to pytanie.

Najpierw trzeba więc ustalić, kto jest właścicielem polityki na tym urządzeniu i co wolno jej nadpisać. Na zarządzanej maszynie roboczej odpowiedzią jest zwykle agent punktu końcowego organizacji, a osobisty VPN nie usuwa tych możliwości, niezależnie od konfiguracji tunelu.

Krok pierwszy: potwierdź blokadę na ścieżkach, które twoim zdaniem obejmuje

Zdejmij tunel na dalekim końcu, a nie u klienta, aby klient nadal wierzył, że powinien być połączony. Potem spróbuj tego, czego naprawdę spróbowałby człowiek:

curl -m 5 -sS -o /dev/null -w '%{http_code}
' https://example.com
ping -c 2 1.1.1.1
ip route
nft list ruleset   # or: iptables -S

Chcesz klienta, który zawodzi szybko i czysto, a nie takiego, który wisi do limitu czasu przeglądarki. Wiszenie zwykle oznacza, że pakiety są po cichu odrzucane przez regułę bez odmowy, co jest dopuszczalne, ale może też oznaczać, że klient zostawił nieaktualną trasę domyślną wskazującą martwy interfejs. Przeczytaj tabelę routingu przy zdjętym tunelu: trasa domyślna nadal wskazująca urządzenie tunelu i reguła zapory blokująca tylko nowe połączenia wychodzące to dwa różne stany, a tylko jeden z nich jest fail-closed.

Powtórz te same polecenia z włączoną i wyłączoną opcją zezwalania na sieć lokalną. Ten przełącznik jest miejscem większości niespodzianek, bo otwiera ścieżkę, którą reszta polityki miała zamknąć.

Krok drugi: sprawdź DNS i IPv6 jako osobne ścieżki

Rozwiązywanie nazw to luka, która przetrwa większość wdrożeń, bo zapytanie może wyjść czymś innym niż resolver systemowy. Zapytaj narzędziem, które ignoruje konfigurację resolvera, i sprawdź przy tym stronę v6:

dig +short example.com
dig +short @1.1.1.1 example.com
curl -6 -m 5 -sS https://example.com -o /dev/null -w '%{http_code}
'
ip -6 route

Puste odpowiedzi na oba zapytania nazw przy zdjętym tunelu to wynik, którego chcesz. Jeśli drugie zapytanie odpowie, zaszyty adres resolvera jest osiągalny, a tunel nie jest jedyną drogą wyjścia z maszyny. Jeśli powiedzie się tylko żądanie v6, polityka obejmuje IPv4 i ignoruje IPv6, co jest tym samym wyciekiem w innej rodzinie adresów.

Przeglądarki utrudniają odczyt z zewnątrz, bo przeglądarka skonfigurowana do DNS przez HTTPS rozwiązuje zapytanie żądaniem HTTPS: zapytanie jest zablokowane tylko tak, jak zablokowany jest port 443 do tego punktu. Na hoście, gdzie polityka pozwala na podsieć lokalną, to żądanie nadal może dotrzeć do resolvera w sieci LAN.

Krok trzeci: oddziel ekspozycję sieciową od ekspozycji punktu końcowego

Teraz część, do której nie dociera żadna reguła zapory. Wyłącznik awaryjny blokuje ścieżki z maszyny; nie powstrzymuje oprogramowania na maszynie przed czytaniem danych przed ich zaszyfrowaniem i nie powstrzymuje tego oprogramowania przed legalnym korzystaniem z tunelu. Keylogger, złośliwe rozszerzenie, pozostawiony odblokowany ekran, klient synchronizacji z szerokimi uprawnieniami: wszystko to przenosi informacje połączeniem, na które wyłącznik chętnie pozwala.

To samo dotyczy oprogramowania monitorującego, które pracodawca zainstalował celowo. Blokowanie tras go nie usuwa, a kupno nowego serwera VPN nie jest naprawą, bo ekspozycja leży przed tunelem.

Menedżer schowka wysyłający do konta w chmurze pokazuje to ostro. Ruch jest szyfrowany, cel dozwolony, a wyłącznik awaryjny przez cały czas zgłasza zdrowy stan.

Krok czwarty: zapisz twierdzenie, które wspiera twój test

Po teście przerwy możesz podać konkretne fakty: które aplikacje zawiodły, które ścieżki się zatrzymały, jak zachowały się DNS i IPv6 i czy blokada wytrzymała, gdy tunel padł. Nie możesz twierdzić, że system jest czysty, ani że usługa na dalekim końcu utrzyma twoje logowanie w tajemnicy.

Trzymaj oba problemy osobno i daj każdemu własną kontrolę:

  • Wyłącznik awaryjny: zdefiniowany wymóg awarii, weryfikowany testem przerwy powtarzanym po każdej aktualizacji klienta.
  • Zaufanie urządzenia: wspierane aktualizacje, ochrona punktów końcowych z zaufanego źródła, przegląd niewyjaśnionych uprawnień i próśb o uwierzytelnienie.
  • Incydent: przy podejrzeniu przejęcia postępuj zgodnie z procesem platformy lub organizacji; nowy serwer nie jest krokiem czyszczenia.
  • Ujawnienie: prosząc o pomoc, nie wklejaj kluczy prywatnych ani całych archiwów diagnostycznych, bo logi i zrzuty ekranu niosą te same sekrety co połączenie.

Wykonaj sekwencję ponownie po następnej aktualizacji, bo wyłącznik awaryjny to konfiguracja, która przesuwa się wraz z wersjami. Test jest jedynym dowodem, że zachowanie, na którym polegasz, wciąż jest tym, które otrzymujesz.

Powiązane artykuły