Niezaufane VPN to trzy oddzielne granice, a nie jedna

„Nie ufam tej VPN” to zwykle trzy twierdzenia ubrane w jedno zdanie. Zdalni rówieśnicy w tej sieci mogą dotrzeć do usług na twoim hoście, operator prowadzący tunel może obserwować ruch, który przez niego przechodzi, a zainstalowane oprogramowanie klienckie może zmieniać politykę sieciową twojej maszyny. Przekonanie warte korekty to to, że reguła firewalla, maszyna wirtualna albo staranny wybór systemu operacyjnego odpowiadają na wszystkie trzy. Każdy środek odpowiada dokładnie na jedno z nich.

Mit: jedna kontrola pokrywa całe ryzyko

Powszechne założenie głosi, że dołączenie do niezaufanej sieci to jedna decyzja z jednym złagodzeniem. Ludzie wybierają kontrolę, której już ufają, stosują ją i uznają ryzyko za zamknięte: firewall jest włączony, przestrzeń robocza jest jednorazowa, klient pochodzi od renomowanego dostawcy.

Te kontrole nie nakładają się tak, jak sugeruje założenie. Firewall na hoście ogranicza, do czego może dotrzeć zdalny rówieśnik, i nie robi nic wobec operatora, który kończy twoje TLS. Maszyna wirtualna oddziela przestrzeń roboczą od plików hosta i nie robi nic wobec komponentu klienta, któremu wolno rekonfigurować stos sieciowy pod oboma. Nazwanie granicy, którą każda kontrola naprawdę tworzy, to całe ćwiczenie.

Ich rozdzielenie mówi też, jakie ryzyko wybrałeś zaakceptować. Większość realnych decyzji łagodzi jedną granicę i toleruje drugą, co jest w porządku, dopóki zapis zmiany mówi, która jest która.

Do czego zdalny rówieśnik naprawdę może dotrzeć

Zacznij od usług nasłuchujących. Interfejs tunelu traktowany jako szeroko zaufany, bo jego pakiety przyszły zaszyfrowane, to zwykły błąd, i czyni każdego lokalnego słuchacza możliwym celem dla wszystkich innych w tej sieci. Szyfrowanie chroni przewód między dwoma końcami; nie mówi nic o zamiarach rówieśnika po drugiej stronie.

ss -tulpn
sudo nft list ruleset
ip -br addr

Przypisz usługi do adresu, którego potrzebują, a nie do każdego interfejsu, i zezwalaj tylko na operacje wymagane przez zatwierdzone zadanie. Utrzymuj przekazywanie, mostkowanie i proxy aplikacji jako jawne, bo dwa przyłącza sieciowe same nie tworzą ścieżki tranzytowej, ale reguła proxy z pewnością może.

Zatwierdzona jednorazowa przestrzeń robocza zmniejsza to, do czego może dotrzeć sieć zdalna, ale tylko wtedy, gdy jej konfiguracja udostępniania odpowiada twierdzeniu. Udostępniane foldery, integracja schowka, agenci poświadczeń i kanały zarządzania przekraczają granicę, którą przestrzeń robocza miała stworzyć. Etykieta przestrzeni roboczej niczego nie dowodzi co do tego, które z nich są otwarte.

Architektura zerowego zaufania NIST formułuje zasadę stojącą za tym wszystkim: sama lokalizacja w sieci nie daje domniemanego zaufania. Uwierzytelnianie zasobów nadal ma zadanie po dopuszczeniu tunelu, podobnie jak pytanie, kto jeszcze dzieli tę sieć.

Co może zobaczyć operator na ścieżce

VPN przenosi twój ruch w inne miejsce ścieżki; nie dodaje szyfrowania aplikacji. Jeśli dostawca kończy twoje TLS, może czytać to, co przeglądarka inaczej by chroniła, i żadna lokalna reguła firewalla tego nie zmienia.

Zachowaj normalną walidację certyfikatów dla rzeczywistego celu i rozumiej ścieżkę resolwera oraz metadanych, bo zapytanie DNS może ujawnić więcej niż ładunek, który je poprzedza. Same metadane, czyli jakie adresy i kiedy odwiedziłeś, często odpowiadają na pytanie operatora bez żadnej potrzeby czytania treści. Dlatego „ruch jest szyfrowany” i „ruch jest prywatny” to różne twierdzenia.

Jeśli ta widoczność jest dla zadania nie do przyjęcia, odpowiedzią jest inna zatwierdzona architektura, a nie więcej lokalnego filtrowania. Lokalne filtrowanie nie może usunąć obserwatora ze ścieżki, na której wciąż siedzi.

Co wolno zmieniać lokalnemu klientowi

To jest granica, którą ludzie pomijają, i to ona czyni pozostałe dwie bez znaczenia. W Linuksie CAP_NET_ADMIN obejmuje konfigurację interfejsów, administrację firewallem i zmiany tras w swoim kontekście sieciowym. Oprogramowanie mające tę zdolność może przepisać politykę, którą właśnie napisałeś.

getcap /usr/sbin/openvpn
systemd-analyze security vpn-client.service
ip netns list

Przestrzeń nazw sieci to prawdziwa granica dla stanu sieci i słaba dla wszystkiego innego: nie izoluje systemu plików ani magazynu poświadczeń. Traktuj ją jako jedną warstwę, a nie kontener na cały problem.

Pozyskaj klienta i jego konfigurację z utrzymywanego źródła, przejrzyj uprawnienia, o które prosi, i trzymaj uprzywilejowane komponenty pod kontrolą administratora. Maszyna wirtualna może być częścią kwalifikowanej granicy oceny, nie stając się zgodą na uruchamianie niewyjaśnionego instalatora obok cennych poświadczeń. Instalator działa z jakimikolwiek uprawnieniami mu dasz, a te uprawnienia to granica.

Zapisz, którą granicę zaakceptowałeś

Zakończ zdaniem, które nazywa cztery rzeczy: zaufany kod lokalny, dozwolony dostęp zdalny, chronione dane aplikacji i pozostałą relację z operatorem. To zdanie jest warte więcej niż ogólne twierdzenie, że VM, system operacyjny lub produkt antywirusowy uczyniły wrogą sieć bezpieczną.

Następnie potwierdź, że wąska operacja działa i wymagana odmowa nadal obowiązuje, także po upadku tunelu. Granica, która istnieje tylko dopóki tunel jest podniesiony, nie jest granicą, którą udokumentowałeś.

Żaden test nie dowodzi, że każdej luki nie ma, a przegląd twierdzący inaczej przesadza. Uczciwy wynik nazywa ryzyko szczątkowe i osobę, która je zaakceptowała.