Snort na krawędzi VPN: gdzie pakiety są widoczne

Prześledź jedno żądanie z odległego laptopa, a przechodzi ono przez kilka granic, zanim cokolwiek może je sprawdzić. Zewnętrzny tunel kończy się w procesie VPN, pakiet wewnętrzny pojawia się na interfejsie, a sesja HTTPS w środku trwa aż do aplikacji. Narzędzie inspekcyjne widzi tylko to, co jest widoczne w punkcie, w którym pakiety do niego docierają. Zainstaluj je bez decyzji o tym punkcie, a logi opiszą niewłaściwą warstwę.

Jeden pakiet przechodzi przez kilka granic

Przed zakończeniem VPN obserwator widzi jedno połączenie zewnętrzne, zwykle do portu VPN, z adresami i rozmiarami, ale bez struktury wewnętrznej. Po zakończeniu wewnętrzne adresy, porty i protokoły są dostępne w tym punkcie przetwarzania, który je przekazuje. Własny TLS aplikacji pozostaje zaszyfrowany, chyba że osobny projekt go zakończy. To trzy poziomy widoczności, a nazwa pakietu nie mówi, który kupiłeś.

Narysuj ścieżkę z zaznaczonymi granicami, a następnie umieść czujnik na linii, na której można odpowiedzieć na pytanie, bo lokalizacja jest częścią odpowiedzi. Granica, której nie potrafisz nazwać, to granica, której nie potrafisz przetestować.

Zobacz, co jest czytelne w każdym punkcie

Sprawdź interfejs i krótki zapis, zanim zaufasz jakiemukolwiek opisowi architektury.

ip -br link
tcpdump -ni tun0 -c 10 'tcp port 443'

Lista łączy pokazuje istniejące tunele i interfejsy fizyczne, a zapis pokazuje dokładnie to, co otrzymałby podłączony tam czujnik. Jeśli pokazuje adresy wewnętrzne, ale nie wiersze żądań HTTP, jesteś po zakończeniu VPN i nadal poza TLS aplikacji. To normalne miejsce do wykrywania sieci i niewłaściwe miejsce do inspekcji treści. Powtórz zapis na interfejsie zewnętrznym, aby porównać, co ujawnia druga granica.

Wykrywanie pasywne nie może blokować samo

Dokumentacja inspekcji Snorta oddziela obserwację pasywną od pracy w linii. Tryb pasywny może ostrzegać o ruchu bez zatrzymywania go na tej ścieżce.

snort -T -c /etc/snort/snort.lua

Tryb testowy sprawdza konfigurację bez uruchamiania czujnika, co jest właściwym pierwszym krokiem przed każdym wdrożeniem. Praca w linii wymaga zgodnego układu przechwytywania pakietów i odpowiedniej konfiguracji egzekwowania, a nie tylko dodatkowej flagi. Wpis w logu nie jest więc dowodem, że żądanie zostało zablokowane, a proces uruchomiony z opcją przypominającą pracę w linii nie dowodzi, że rzeczywisty przekazywany strumień przez niego przechodzi. Potwierdź, gdzie implementacja faktycznie przekazuje pakiety.

Wybierz tryb egzekwowania przed wdrożeniem

Zdecyduj, czy wymaganiem jest widoczność, czy zapobieganie, bo oba mają odmienne zachowanie przy awarii. Pasywny czujnik, który padnie, pozwala ruchowi płynąć i tworzy lukę w monitorowaniu; urządzenie w linii, które padnie, może przepuścić ruch albo go zatrzymać, a ten wybór musi być świadomy. Uzgodnij jeden dozwolony strumień, jeden strumień, który musi zostać odrzucony, oraz zachowanie, którego chcesz, gdy czujnik zawiedzie. Trzymaj odzyskiwanie zarządzania osobno od badanej ścieżki, aby błąd w czujniku nie odebrał także twojego dostępu.

Następnie zapisz widoczny ruch, punkt przetwarzania i zachowanie egzekwowania. Te trzy fakty, a nie zainstalowany pakiet, opisują, co wdrożenie faktycznie robi.