Zvolte správný pozorovací bod pro skenování VPN na telefonu
VPN listener na telefonu, služba na telefonu a směrovaný hostitel v LAN jsou tři plochy. Projděte těchto pět kroků a zastavte se tam, kde končí rozsah.
Autorizované posouzení VPN hostované na telefonu tiše selže, když skener sedí na špatné straně tunelu. Dostanete výsledky, vypadají věrohodně a odpovídají na otázku, kterou nikdo nepoložil. Projděte pět kontrol níže v pořadí. Každá má podmínku zastavení a zastavit se dřív je levnější než po napsání zprávy testovat znovu od nuly.
Krok 1: pojmenujte plochu, kterou chcete zasáhnout
Tři plochy se běžně pletou, protože je propojuje jedno zařízení. Provozují jiný kód a jinou politiku, takže si před začátkem zapište, která je v rozsahu.
| 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 |
Pokud schválený rozsah neříká která ze tří, zastavte se a ptejte se. Získání rootu na telefonu na tuto otázku neodpovídá a mění testovanou věc, ne pozorovací bod.
Zaznamenejte cíle, povolené zdrojové adresy, časové okno a limit intenzity současně. Tunel vás do tohoto rozsahu přivede; nedává licenci zkoumat vše, co dokáže směrovat.
Krok 2: vyberte zdroj, který tu plochu vidí
Skener sedící uvnitř VPN nedokáže napodobit neautentizovaného pozorovatele z internetu. Už má trasy, přihlašovací údaje a oprávnění, která vnější pozorovatel nemá, takže jeho výsledky popisují pohled po přijetí, i když je cílová plocha stejná. Opačná chyba je stejně častá. Veřejné skenování portu VPN neříká téměř nic o soukromé službě za přihlášením, a podávat to, jako by říkalo, přeceňuje expozici v jednom směru a podceňuje ji v druhém.
Zastavte se, pokud zdroj, který můžete získat, neodpovídá ploše. Posouzení provedené z protějšku uvnitř tunelu se nemá prezentovat jako výsledek před autentizací a test, který vyžaduje schválený vnější zdroj, se nemá tiše přesouvat dovnitř, aby se vyhnul papírování.
Krok 3: potvrďte trasu a cestu odpovědi přes telefon
Když telefon přeposílá do jiné podsítě, skener potřebuje povolenou trasu a cíl potřebuje funkční cestu zpět. Potvrďte obojí, místo abyste předpokládali, že odpověď na ping znamená, že cesta je úplná.
ip route get 10.20.0.8
tcpdump -ni any host 10.20.0.8Zdrojový NAT mění, co navazující služba vidí. Pokud telefon překládá adresu skeneru, pravidla přístupu a záznamy v cíli platí pro přeloženou adresu, takže služba, která jako by vás přijímala, může přijímat telefon, a ne skener.
Sledujte také překryv s vlastní sítí skeneru. Pokud telefon směruje 192.168.1.0/24 a skener sedí v LAN číslované stejně, sondy zasahují místní zařízení a zpráva je popisuje jako cíl. Ověřte trasu, kterou by použil sám skener, než odešlete jediný paket.
Skenujte skutečnou adresu cíle a zachovejte název hostitele, který aplikace potřebuje pro identitu TLS a virtuální hostování. Dosažení brány dokazuje, že brána odpovídá; netestuje službu za ní.
Krok 4: berte objevování jako sondu s předpoklady
Objevování hostitelů je místo, kde výsledky posouzení nejčastěji selhávají. Místní objevování po Ethernetu nepřekračuje směrovanou VPN, takže sondy, které fungují v ploché LAN, prostě nedorazí. Blokované sondy objevování pak činí dostupnou, autorizovanou službu jako nepřítomnou.
Vědomě rozhodněte, zda objevování přeskočit a skenovat známé adresy přímo, a řekněte to ve zprávě. Port, který odpovídá, není důkaz, že autentizace VPN uspěla, a filtrovaná odpověď není důkaz, že nic neposlouchá. Rychlost je součástí stejného problému. Telefon, který při rychlém skenování omezuje nebo zahazuje, vytváří filtrované stavy, které patří telefonu, a ne službě, takže snižte souběžnost a před zapsáním portu jako zavřeného skenujte znovu.
Podmínka zastavení je zde výklad, ne technika: pokud nedokážete říci, co nějaký stav pro tuto cestu znamená, výsledek patří do přílohy, a ne do zjištění.
Krok 5: podržte okno a pak je zavřete
Telefon je špatný server, protože je navržený ke spánku. Optimalizace baterie, doze a správa napájení Wi-Fi mohou aplikaci pozastavit uprostřed posouzení a opětovné připojení tunelu může změnit adresu, kterou cíl používá. Běh, který projde jednou z těchto událostí, má neplatné okno výsledků.
Držte roli brány v nejmenším rozsahu, který schválený úkol dovoluje, sledujte tunel, dokud běh běží, a zaznamenejte začátek a konec každého okna, které uvádíte. Když posouzení skončí, odeberte dočasný přístup přes jeho vlastníka, uchovejte záznam o zdroji a cestě a chraňte výstup jako každý jiný testovací artefakt.
Pokud potřebujete opakovatelný pozorovací bod místo jednorázového úspěchu, to je dodávka, za kterou stojí za to argumentovat. referenční materiál k objevování hostitelů vysvětluje, které sondy předpokládají místní segment, což je detail, který mění prázdný výsledek v obhajitelné tvrzení.