Kies het juiste observatiepunt voor een VPN-scan op een telefoon
De VPN-listener van de telefoon, een dienst op de telefoon en een gerouteerde LAN-host zijn drie oppervlakken. Doorloop deze vijf stappen en stop waar de scope ophoudt.
Een geautoriseerde beoordeling van een VPN die op een telefoon draait, mislukt geruisloos wanneer de scanner aan de verkeerde kant van de tunnel zit. Je krijgt resultaten, ze zien er plausibel uit, en ze beantwoorden een vraag die niemand stelde. Doorloop de vijf controles hieronder in volgorde. Elk heeft een stopvoorwaarde, en vroeg stoppen is goedkoper dan na het schrijven van het rapport opnieuw vanaf nul te testen.
Stap 1: benoem het oppervlak dat je wilt bereiken
Drie oppervlakken worden routinematig verward omdat één apparaat ze verbindt. Ze draaien andere code en ander beleid, dus schrijf vooraf op welke binnen de scope valt.
| 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 |
Als de goedgekeurde scope niet zegt welke van de drie, stop en vraag. De telefoon rooten beantwoordt deze vraag niet, en het verandert het geteste ding in plaats van het observatiepunt.
Leg de doelen, de toegestane bronadressen, het tijdvenster en de intensiteitslimiet tegelijk vast. De tunnel brengt je naar die scope; hij geeft geen licentie om alles te onderzoeken wat hij kan routeren.
Stap 2: kies de bron die dat oppervlak kan zien
Een scanner binnen de VPN kan een niet-geauthenticeerde internetwaarnemer niet reproduceren. Hij heeft al routes, inloggegevens en rechten die de buitenstaander mist, dus zijn resultaten beschrijven het beeld na toelating, zelfs wanneer het doelaanvlak hetzelfde is. De omgekeerde fout is even gangbaar. Een openbare scan van de VPN-poort zegt vrijwel niets over een particuliere dienst achter de login, en dat rapporteren alsof het dat wel doet, overschat de blootstelling in de ene richting en onderschat die in de andere.
Stop als de bron die je kunt verkrijgen niet bij het oppervlak past. Een beoordeling vanaf een peer binnen de tunnel hoort niet als resultaat vóór authenticatie te worden gepresenteerd, en een test die een goedgekeurde externe bron vereist, hoort niet stilletjes naar binnen te worden verplaatst om het papierwerk te vermijden.
Stap 3: bevestig de route en het antwoordpad via de telefoon
Wanneer het toestel doorstuurt naar een ander subnet, heeft de scanner een toegestane route nodig en het doel een werkend retourpad. Bevestig beide in plaats van aan te nemen dat een ping-antwoord betekent dat het pad compleet is.
ip route get 10.20.0.8
tcpdump -ni any host 10.20.0.8Source NAT verandert wat de downstreamdienst ziet. Als de telefoon het adres van de scanner vertaalt, gelden de toegangsregels en logs op het doel voor het vertaalde adres, dus een dienst die jou lijkt te accepteren, accepteert misschien de telefoon en niet de scanner.
Let ook op overlap met het eigen netwerk van de scanner. Als de telefoon 192.168.1.0/24 routeert en de scanner zit op een LAN met dezelfde nummering, raken de probes lokale apparaten en beschrijft het rapport ze als het doel. Controleer de route die de scanner zelf zou gebruiken voordat je één pakket verstuurt.
Scan het werkelijke doeladres en behoud de hostnaam die de applicatie nodig heeft voor TLS-identiteit en virtuele hosting. Een gateway bereiken bewijst dat de gateway antwoordt; het test de dienst erachter niet.
Stap 4: behandel ontdekking als een probe met aannames
Hostontdekking is waar beoordelingsresultaten het vaakst misgaan. Lokale Ethernet-ontdekking gaat niet door een gerouteerde VPN, dus de probes die op een plat LAN werken, komen simpelweg niet aan. Geblokkeerde ontdekkingsprobes laten dan een bereikbare, geautoriseerde dienst als afwezig lijken.
Beslis bewust of je ontdekking overslaat en de bekende adressen direct scant, en zeg dat in het rapport. Een poort die antwoordt is geen bewijs dat VPN-authenticatie is geslaagd, en een gefilterd antwoord is geen bewijs dat er niets luistert. Ook het tempo hoort bij hetzelfde probleem. Een telefoon die bij een snelle scan knijpt of pakketten laat vallen, produceert gefilterde toestanden die bij de telefoon horen en niet bij de dienst, dus verlaag de gelijktijdigheid en scan opnieuw voordat je een poort als gesloten vastlegt.
De stopvoorwaarde is hier interpretatie, geen techniek: als je niet kunt zeggen wat een toestand voor dit pad betekent, hoort het resultaat in een bijlage en niet in de bevindingen.
Stap 5: houd het venster vast en sluit het dan
Een telefoon is een slechte server omdat hij ontworpen is om te slapen. Batterij-optimalisatie, doze en Wi-Fi-energiebeheer kunnen de app midden in de beoordeling opschorten, en een herverbinding van de tunnel kan het adres wijzigen dat het doel gebruikt. Een run die een van die gebeurtenissen overbrugt, heeft een ongeldig resultaatvenster.
Houd de gatewayrol binnen de kleinste scope die de goedgekeurde taak toestaat, houd de tunnel in de gaten terwijl de run actief is, en log begin en einde van elk venster dat je rapporteert. Als de beoordeling eindigt, verwijder je de tijdelijke toegang via de eigenaar, bewaar je het bron- en routrecord, en bescherm je de uitvoer als elk ander testartefact.
Heb je een herhaalbaar observatiepunt nodig in plaats van een eenmalig succes, dan is dat het resultaat waarvoor je moet pleiten.de referentie over hostontdekking legt uit welke probes een lokaal segment veronderstellen, en dat is het detail dat een leeg resultaat in een verdedigbare uitspraak verandert.