Brama czy przekazany klient? Jak czytać adres źródłowy

Serwer WWW rejestruje jeden adres, a wszyscy zakładają, że należy on do procesu samej bramy. Może należeć do przekazanego klienta, którego prywatny adres zniknął na etapie tłumaczenia. Cel widzi widoczne źródło sieciowe i nic więcej. To stwierdzenie granicy, a nie twierdzenie, że pochodzenia nigdy nie można ustalić.

Co cel naprawdę widzi

Weź klienta pod 10.20.0.7, bramę o adresie zewnętrznym 198.51.100.10 i cel w internecie. Jeśli brama tłumaczy źródło klienta, gniazdo celu rejestruje 198.51.100.10. Prywatny adres znika z pakietu, a cel nie może go odczytać z tego nagłówka. Te liczby są ilustracyjne, a nie zapisem z twojej sieci.

Obserwacja nadal jest użyteczna: wskazuje źródło sieciowe, które cel musi dopuścić lub zablokować. Po prostu nie wskazuje osoby ani procesu za nim. Dla operatora celu ta różnica decyduje, czy blokada jest decyzją sieciową, czy decyzją dotyczącą konta.

Stan tłumaczenia nie jest widoczny dla celu

Brama przechowuje mapowanie między przetłumaczonym połączeniem a pierwotnym klientem, i właśnie tego stanu celowi brakuje. tradycyjny opis NAT oddziela zapis tłumaczenia od nagłówków widocznych później. Odczyt jednej strony nie daje drugiej.

Różne rozwiązania dają różne dowody. Ruch routowany z zachowanymi adresami źródłowymi pokazuje prawdziwy adres klienta, podczas gdy proxy aplikacji kończy połączenie i tworzy nowe. Trasa z zachowanym źródłem wymaga też, aby adres klienta był routowalny z powrotem od celu, czego nie oferuje każde wdrożenie. Zapytaj, jakie rozwiązanie jest wdrożone, zanim zinterpretujesz linię logu.

conntrack -L -s 198.51.100.10
tcpdump -ni eth0 host 198.51.100.10

TTL i odciski palców to wskazówki, nie dowody

TTL w IPv4 zależy od wartości początkowej wybranej przez nadawcę i od liczby przeskoków, które pokonał pakiet. Bez obu tych faktów wartość nie może dowieść, że nastąpił przeskok VPN. Znany dodatkowy routowany przeskok też nie odróżnia routera LAN, ścieżki tunelu ani innego układu przekazywania. Traktuj różnicę TTL jako pytanie, a nie wniosek.

Inne sygnały zachowują się tak samo. Nagłówek User-Agent może ustawić aplikacja, a podobieństwo czasu może odzwierciedlać wspólną infrastrukturę, a nie wspólną osobę. Kilku użytkowników może dzielić jedno wyjście, a jeden użytkownik może zmieniać ścieżki między sesjami. Zebrane razem, kilka słabych sygnałów może uzasadniać bliższe spojrzenie na zapisy bramy, ale nie stają się silnymi dowodami przez nagromadzenie.

Autoryzuj po tożsamości, nie po adresie

Jeśli cel musi oddzielić administrację bramy od aktywności zdalnego użytkownika, daj tym rolom osobne uwierzytelnione tożsamości i dozwolone operacje. Wspólne publiczne źródło nadal może służyć jako ograniczenie sieciowe, ale nie zastępuje uwierzytelnienia użytkownika lub urządzenia.

Trzymaj dowody oznaczone: zaobserwowane źródło, uwierzytelnione konto, czas i rozważany wniosek. Nie tłumacz „tu nie widać wewnętrznego źródła” jako „nigdzie nie jest możliwe przypisanie”. Oznaczenie ma znaczenie, gdy ktoś, kto nie brał udziału w dochodzeniu, czyta zapis miesiące później.

Zapisz datę obserwacji i system, który ją wytworzył. Nieprzypisany wyciąg z logu trudno później obronić.