Välj rätt observationspunkt för en VPN-skanning på en telefon
Telefonens VPN-lyssnare, en tjänst på telefonen och en routad LAN-värd är tre ytor. Gå igenom dessa fem steg och stanna där omfattningen stannar.
En auktoriserad bedömning av en VPN som körs på en telefon misslyckas tyst när skannern sitter på fel sida av tunneln. Du får resultat, de ser rimliga ut och de svarar på en fråga som ingen ställde. Gå igenom de fem kontrollerna nedan i ordning. Varje har ett stoppvillkor, och att stanna tidigt är billigare än att testa om från början efter att rapporten skrivits.
Steg 1: namnge ytan du vill nå
Tre ytor förväxlas rutinmässigt eftersom en enda enhet kopplar ihop dem. De kör olika kod och olika policy, så skriv ned vilken som ligger inom omfattningen innan något startas.
| 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 |
Om den godkända omfattningen inte säger vilken av de tre, stanna och fråga. Att roota telefonen svarar inte på den frågan, och det ändrar det som testas, inte observationspunkten.
Notera målen, de tillåtna källadresserna, tidsfönstret och intensitetsgränsen samtidigt. Tunneln bär dig till den omfattningen; den ger ingen licens att undersöka allt den kan routa.
Steg 2: välj den källa som kan se den ytan
En skanner inne i VPN:en kan inte återskapa en oautentiserad internetobservatör. Den har redan rutter, inloggningsuppgifter och behörigheter som den utomstående observatören saknar, så resultaten beskriver vyn efter insläpp även när målytan är densamma. Det omvända felet är lika vanligt. En offentlig skanning av VPN-porten säger nästan ingenting om en privat tjänst bakom inloggningen, och att rapportera det som om den gjorde det överdriver exponeringen i en riktning och underskattar den i den andra.
Stanna om källan du kan skaffa inte motsvarar ytan. En bedömning som körs från en peer inne i tunneln bör inte presenteras som ett resultat före autentisering, och ett test som kräver en godkänd extern källa bör inte flyttas tyst inåt för att undvika pappersarbetet.
Steg 3: bekräfta rutten och returvägen genom telefonen
När enheten vidarebefordrar till ett annat subnät behöver skannern en tillåten rutt och målet en returväg som fungerar. Bekräfta båda i stället för att anta att ett ping-svar betyder att vägen är komplett.
ip route get 10.20.0.8
tcpdump -ni any host 10.20.0.8Käll-NAT ändrar vad tjänsten nedströms ser. Om telefonen översätter skannerns adress gäller åtkomstreglerna och loggarna på målet den översatta adressen, så en tjänst som verkar ta emot dig tar kanske emot telefonen och inte skannern.
Håll också ögonen på överlappning med skannerns eget nätverk. Om telefonen routar 192.168.1.0/24 och skannern sitter på ett LAN som numreras på samma sätt träffar sonderna lokala enheter och rapporten beskriver dem som målet. Kontrollera rutten som skannern själv skulle använda innan du skickar ett enda paket.
Skanna måladressen och behåll värdnamnet som applikationen behöver för TLS-identitet och virtuell hosting. Att nå en gateway bevisar att gatewayen svarar; det testar inte tjänsten bakom den.
Steg 4: behandla upptäckt som en sond med antaganden
Upptäckt av värdar är där bedömningsresultat oftast går fel. Lokal Ethernet-upptäckt korsar inte en routad VPN, så sonderna som fungerar på ett platt LAN kommer helt enkelt inte fram. Blockerade upptäcktssonder får då en nåbar, auktoriserad tjänst att se frånvarande ut.
Bestäm medvetet om du hoppar över upptäckt och skannar de kända adresserna direkt, och säg det i rapporten. En port som svarar är inte bevis för att VPN-autentiseringen lyckades, och ett filtrerat svar är inte bevis för att ingenting lyssnar. Hastigheten är en del av samma problem. En telefon som stryper eller tappar paket under en snabb skanning producerar filtrerade tillstånd som tillhör telefonen och inte tjänsten, så sänk samtidigheten och skanna om innan du registrerar en port som stängd.
Stoppvillkoret här är tolkning, inte teknik: om du inte kan säga vad ett tillstånd betyder för den här vägen hör resultatet hemma i en bilaga och inte i fynden.
Steg 5: håll fönstret och stäng det sedan
En telefon är en dålig server eftersom den är byggd för att sova. Batterioptimering, doze och Wi-Fi-strömstyrning kan pausa appen mitt i bedömningen, och en återanslutning av tunneln kan ändra adressen som målet använder. En körning som spänner över en av dessa händelser har ett ogiltigt resultatfönster.
Håll gatewayrollen inom den minsta omfattning som den godkända uppgiften tillåter, övervaka tunneln medan körningen är aktiv och logga början och slutet på varje fönster du rapporterar. När bedömningen är slut, ta bort den tillfälliga åtkomsten via dess ägare, behåll käll- och ruttposten och skydda utdata som vilken annan testartefakt som helst.
Om du behöver en repeterbar observationspunkt i stället för en engångsframgång är det den leveransen det är värt att argumentera för.referensen om upptäckt av värdar förklarar vilka sonder som förutsätter ett lokalt segment, och det är detaljen som gör ett tomt resultat till ett försvarbart påstående.