Wybierz właściwy punkt obserwacji do skanu VPN na telefonie
Nasłuch VPN telefonu, usługa na telefonie i routowany host LAN to trzy powierzchnie. Przejdź przez te pięć kroków i zatrzymaj się tam, gdzie kończy się zakres.
Autoryzowana ocena VPN hostowanego na telefonie kończy się po cichu niepowodzeniem, gdy skaner siedzi po niewłaściwej stronie tunelu. Otrzymujesz wyniki, wyglądają wiarygodnie i odpowiadają na pytanie, którego nikt nie zadał. Przejdź przez pięć kontroli poniżej po kolei. Każda ma warunek zatrzymania, a wcześniejsze zatrzymanie jest tańsze niż ponowne testowanie od zera po napisaniu raportu.
Krok 1: nazwij powierzchnię, którą chcesz osiągnąć
Trzy powierzchnie są rutynowo mylone, bo łączy je jedno urządzenie. Wykonują inny kod i inną politykę, więc zapisz, która jest w zakresie, zanim cokolwiek się zacznie.
| Assessment target | What the path exercises |
|---|---|
| Public VPN listener on the handset | Reachability before login, plus the exposed VPN daemon |
| A service on the handset, by its tunnel address | Access after admission to something hosted locally |
| A LAN host behind the handset gateway | Forwarding, the return path and downstream access policy |
Jeśli zatwierdzony zakres nie mówi, która z trzech, zatrzymaj się i zapytaj. Rootowanie telefonu nie odpowiada na to pytanie i zmienia rzecz testowaną, a nie punkt obserwacji.
Zapisz cele, dozwolone adresy źródłowe, okno czasowe i limit intensywności jednocześnie. Tunel prowadzi cię do tego zakresu; nie daje licencji na badanie wszystkiego, co potrafi routować.
Krok 2: wybierz źródło, które widzi tę powierzchnię
Skaner siedzący wewnątrz VPN nie może odtworzyć nieuwierzytelnionego obserwatora internetu. Ma już trasy, poświadczenia i uprawnienia, których zewnętrzny obserwator nie ma, więc jego wyniki opisują widok po dopuszczeniu, nawet gdy powierzchnia docelowa jest ta sama. Odwrotny błąd jest równie częsty. Publiczny skan portu VPN nie mówi prawie nic o prywatnej usłudze za logowaniem, a przedstawianie go tak, jakby to mówił, przecenia ekspozycję w jedną stronę i nie docenia jej w drugą.
Zatrzymaj się, jeśli źródło, które możesz uzyskać, nie pasuje do powierzchni. Oceny wykonanej z partnera wewnątrz tunelu nie należy przedstawiać jako wyniku sprzed uwierzytelnienia, a testu wymagającego zatwierdzonego źródła zewnętrznego nie należy po cichu przenosić do środka, by uniknąć papierkowej roboty.
Krok 3: potwierdź trasę i drogę odpowiedzi przez telefon
Gdy urządzenie przekazuje do innej podsieci, skaner potrzebuje dozwolonej trasy, a cel działającej drogi powrotnej. Potwierdź obie zamiast zakładać, że odpowiedź ping oznacza pełną drogę.
ip route get 10.20.0.8
tcpdump -ni any host 10.20.0.8NAT źródłowy zmienia to, co widzi usługa poniżej. Jeśli telefon tłumaczy adres skanera, reguły dostępu i logi w celu dotyczą przetłumaczonego adresu, więc usługa, która wygląda na to, że cię przyjmuje, może przyjmować telefon, a nie skaner.
Uważaj też na nakładanie się z własną siecią skanera. Jeśli telefon routuje 192.168.1.0/24, a skaner siedzi w sieci LAN ponumerowanej w ten sam sposób, sondy trafiają w lokalne urządzenia, a raport opisuje je jako cel. Sprawdź trasę, której użyłby sam skaner, zanim wyślesz choć jeden pakiet.
Skanuj rzeczywisty adres celu i zachowaj nazwę hosta potrzebną aplikacji do tożsamości TLS i hostingu wirtualnego. Osiągnięcie bramy dowodzi, że brama odpowiada; nie testuje usługi za nią.
Krok 4: traktuj wykrywanie jako sondę z założeniami
Wykrywanie hostów to miejsce, w którym wyniki oceny najczęściej się mylą. Lokalne wykrywanie przez Ethernet nie przechodzi przez routowany VPN, więc sondy działające w płaskiej sieci LAN po prostu nie docierają. Zablokowane sondy wykrywania sprawiają wtedy, że osiągalna, autoryzowana usługa wygląda na nieobecną.
Zdecyduj świadomie, czy pominąć wykrywanie i skanować znane adresy bezpośrednio, i powiedz to w raporcie. Odpowiadający port nie jest dowodem, że uwierzytelnienie VPN się powiodło, a filtrowana odpowiedź nie jest dowodem, że nic nie nasłuchuje. Tempo jest częścią tego samego problemu. Telefon, który dławi lub gubi pakiety przy szybkim skanie, tworzy stany filtrowane należące do telefonu, a nie do usługi, więc zmniejsz współbieżność i zeskanuj ponownie, zanim zapiszesz port jako zamknięty.
Warunkiem zatrzymania jest tu interpretacja, nie technika: jeśli nie możesz powiedzieć, co stan oznacza dla tej drogi, wynik należy do załącznika, a nie do ustaleń.
Krok 5: utrzymaj okno, a potem je zamknij
Telefon to zły serwer, bo jest zaprojektowany do spania. Optymalizacja baterii, doze i zarządzanie energią Wi-Fi mogą zawiesić aplikację w środku oceny, a ponowne połączenie tunelu może zmienić adres używany przez cel. Przebieg obejmujący jedno z tych zdarzeń ma nieważne okno wyników.
Utrzymuj rolę bramy w najmniejszym zakresie, na jaki pozwala zatwierdzone zadanie, obserwuj tunel, dopóki przebieg trwa, i zapisuj początek oraz koniec każdego raportowanego okna. Gdy ocena się kończy, usuń dostęp tymczasowy przez jego właściciela, zachowaj zapis źródła i trasy oraz chroń wynik jak każdy inny artefakt testowy.
Jeśli potrzebujesz powtarzalnego punktu obserwacji, a nie jednorazowego sukcesu, to jest wynik, o który warto argumentować.odnośnik o wykrywaniu hostów wyjaśnia, które sondy zakładają segment lokalny, i właśnie ten szczegół zmienia pusty wynik w obronione twierdzenie.