Narysuj odszyfrowaną ścieżkę: gdzie urządzenie VPN egzekwuje politykę

Diagramy dostawców zwykle kończą się na zaszyfrowanym nasłuchu, bo to część z publicznym adresem. Pytanie, które rozstrzyga o bezpieczeństwie, brzmi, co dzieje się po odszyfrowaniu, gdy pakiet staje się zwykłym IP i może dotrzeć wszędzie, gdzie pozwala tablica routingu. Jeśli nikt nie narysował tego odcinka, nikt go nie posiada. Runbook poniżej rysuje go najpierw, a potem porównuje umiejscowienia według tego, co odszyfrowane żądanie rzeczywiście przekracza.

Rysuj pakiet po odszyfrowaniu, nie przed

Ścieżka zewnętrzna to część, którą dokumentują dostawcy: publiczny punkt końcowy, polityka transportu, która dopuszcza połączenie, i usługa, która je kończy. Ścieżka wewnętrzna zaczyna się w momencie, gdy pakiet traci nagłówek tunelu, i odtąd rządzą nią reguły routingu i filtrowania, które nie mają nic wspólnego z tunelem. Umieść obie na jednej stronie, bo diagram tylko z pierwszą sugeruje, że dopuszczenie i autoryzacja to jedna decyzja. Nie są, i właśnie szczelina między nimi jest miejscem, w którym większość umiejscowień się myli.

Opisz wewnętrzny odcinek jako numerowaną sekwencję z nazwanymi typami urządzeń, a nie jako strzałkę. Strzałka ukrywa, czy żądanie przechodzi przez filtr, a przejście lub nie jest całym pytaniem. Każdy krok poniżej nazywa urządzenie i zbiór reguł, który tam działa, więc brakujący filtr pojawia się jako luka, a nie jako coś sugerowanego linią.

1. Klient zdalny: urządzenie użytkownika, które tworzy tunel.
2. Polityka brzegu: zbiór reguł, który dopuszcza transport zewnętrzny do publicznego nasłuchu.
3. Urządzenie kończące: punkt końcowy VPN, który dekapsuluje i przekazuje pakiet zwykłemu IP.
4. Filtr wewnętrzny: zbiór reguł przekazywania lub grup bezpieczeństwa, który ogranicza ruch od klienta do usługi.
5. Host aplikacji: usługa, która odbiera odszyfrowane żądanie.

Dwie polityki, dwóch właścicieli

Polityka zewnętrzna odpowiada na pytanie, kto może ustanowić tunel, i wyraża się w regułach, które dopuszczają transport do usługi kończącej. Polityka wewnętrzna odpowiada, do której usługi może dotrzeć uwierzytelniony użytkownik, i mieszka w regułach przekazywania, grupach bezpieczeństwa albo samej aplikacji. Jedno urządzenie może mieścić obie, a projekt z kilkoma urządzeniami nadal ma obie. Właśnie osobne ich nazwanie pozwala powiedzieć, która zawiodła, gdy użytkownik nie dociera do aplikacji.

Kontrole dopuszczenia, takie jak certyfikaty i uwierzytelnianie wieloskładnikowe, odpowiadają na tożsamość i na nic więcej. Nie decydują o umiejscowieniu i nie przyznają uprawnień do poszczególnych zasobów, gdy użytkownik jest już w środku.

Umiejscowienie decyduje, którą granicę przekracza żądanie

Trzy umiejscowienia są typowe i każde zmienia, którą granicę przekracza odszyfrowane żądanie. Porównaj je według tego, co tam się kończy, co może zobaczyć czysty tekst, która kontrola wciąż może odmówić żądaniu i co zawodzi razem z urządzeniem. Tabela poniżej używa tych czterech kolumn zamiast ogólnego pytania, bo każda odpowiedź to odrębna decyzja projektowa.

Trzecie umiejscowienie to to, które po cichu usuwa egzekwowanie, bo odcinek na segmencie chronionym daje urządzeniu bezpośrednią drogę, której diagram może nie pokazywać. Sprawdzaj interfejsy i trasy, a nie obrazek: ip route get 10.20.5.10 informuje, którym interfejsem pakiet by wyszedł, i odpowiedź często nie jest ta, którą zakładał projekt. Klasyczna rola zapory polegająca na kontrolowaniu ruchu między postawami, jak opisano wNIST SP 800-41, jest tu pożytecznym testem, bo urządzenie z nieograniczonym odcinkiem do chronionej sieci niewiele kontroluje. Sprawdzenie trasy jest uczciwszym diagramem niż ten z prezentacji.

Administracja należy do własnej, wyraźnie dozwolonej ścieżki. Umożliwienie użytkownikom dotarcia do aplikacji nigdy nie wymaga umożliwienia im dotarcia do interfejsu sterowania urządzenia, a oba uprawnienia powinny być nadawane różnymi regułami. Audytuj obie ścieżki osobno, bo wspólna reguła ukrywa, która została otwarta.

Tłumaczenie zmienia to, co widzą dalsze reguły

Tłumaczenie źródła jest wygodne i niszczy informację. Po masquerade każdy klient wygląda jak urządzenie, więc dalsza reguła napisana, by rozróżniać użytkowników, nie może już tego robić. To nie tylko problem logów, to problem polityki: reguła oparta na adresie klienta po cichu staje się regułą opartą na bramie. Jeśli polityka per użytkownik ma znaczenie, zachowaj źródło albo egzekwuj politykę przed tłumaczeniem.

Ścieżka odpowiedzi zasługuje na tę samą analizę. Zapisz, którą trasę wybiera cel dla pakietu zwrotnego, bo asymetryczny powrót omija inspekcję stanową i daje połączenie, które się nawiązuje, a potem zatyka. Oba kierunki muszą przekraczać narysowaną granicę, inaczej granica jest dekoracją.

sudo tcpdump -ni inside0 host 10.20.5.10
ip route get 10.20.5.10
sudo iptables -t nat -S POSTROUTING

Przyjmij jedną operację dozwoloną i jedną odrzuconą

Testuj z prawdziwego klienta zdalnego, a nie z hosta zarządzania, bo host zarządzania zwykle stoi tam, gdzie użytkownik nigdy nie będzie. Jedna operacja dozwolona dowodzi, że ścieżka działa, a jedna odrzucona dowodzi, że polityka w ogóle coś robi. Wykonuj obie po każdej zmianie umiejscowienia i zapisuj użyte tożsamość źródła i cel. Test, który dowodzi tylko sukcesu, nie odróżni poprawnej reguły od brakującej.

Potem testuj przypadki zmieniające stan: ponowne połączenie, sesję, która przeżyje rotację kluczy, i awarię samego urządzenia. Porównuj aktualizacje, wydajność i odzyskiwanie jako część tego samego układu, bo jedno urządzenie trzymające kilka kontroli logicznych to jedna domena awarii z kilkoma etykietami. Druga skrzynka też nie jest niezależna, gdy wspólne dane logowania administratora albo nieograniczona trasa niweczą granicę, którą miała stworzyć.

Udokumentuj punkt końcowy, odszyfrowaną ścieżkę i kontrolę, która ją ogranicza. Te trzy linie pozostają sensowne, jakkolwiek nazwie się implementację.