Velg riktig observasjonspunkt for en VPN-skanning på telefonen
Telefonens VPN-lytter, en tjeneste på telefonen og en rutet LAN-vert er tre flater. Gå gjennom disse fem trinnene, og stopp der omfanget stopper.
En autorisert vurdering av en VPN som driftes på en telefon, feiler lydløst når skanneren sitter på feil side av tunnelen. Du får resultater, de ser plausible ut, og de svarer på et spørsmål ingen stilte. Gå gjennom de fem kontrollene nedenfor i rekkefølge. Hver har en stoppbetingelse, og det er billigere å stoppe tidlig enn å teste på nytt fra bunnen etter at rapporten er skrevet.
Trinn 1: navngi flaten du vil nå
Tre flater forveksles rutinemessig fordi én enhet kobler dem sammen. De kjører ulik kode og ulik policy, så skriv ned hvilken som er innenfor omfanget før noe startes.
| 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 |
Hvis det godkjente omfanget ikke sier hvilken av de tre, stopp og spør. Rooting av telefonen svarer ikke på dette spørsmålet, og det endrer det som testes, ikke observasjonspunktet.
Noter målene, de tillatte kildeadressene, tidsvinduet og intensitetsgrensen samtidig. Tunnelen bærer deg til dette omfanget; den gir ikke lisens til å undersøke alt den kan rute.
Trinn 2: velg kilden som kan se den flaten
En skanner som sitter inne i VPN-en kan ikke gjenskape en uautentisert internettobservatør. Den har allerede ruter, påloggingsdata og tillatelser som den utenforstående observatøren mangler, så resultatene beskriver visningen etter innslipp selv når målflaten er den samme. Den motsatte feilen er like vanlig. En offentlig skanning av VPN-porten sier nesten ingenting om en privat tjeneste bak innloggingen, og å rapportere det som om den gjorde det, overdriver eksponeringen i én retning og underdriver den i den andre.
Stopp hvis kilden du kan skaffe ikke samsvarer med flaten. En vurdering kjørt fra en peer inne i tunnelen bør ikke presenteres som et resultat før autentisering, og en test som krever en godkjent ekstern kilde, bør ikke flyttes lydløst inn for å unngå papirarbeidet.
Trinn 3: bekreft ruten og returveien gjennom telefonen
Når enheten videresender til et annet subnett, trenger skanneren en tillatt rute og målet en returvei som virker. Bekreft begge i stedet for å anta at et ping-svar betyr at veien er komplett.
ip route get 10.20.0.8
tcpdump -ni any host 10.20.0.8Source NAT endrer hva den nedstrøms tjenesten ser. Hvis telefonen oversetter skannerens adresse, gjelder tilgangsreglene og loggene på målet for den oversatte adressen, så en tjeneste som ser ut til å godta deg, godtar kanskje telefonen og ikke skanneren.
Følg også med på overlapp med skannerens eget nettverk. Hvis telefonen ruter 192.168.1.0/24 og skanneren sitter på et LAN nummerert på samme måte, treffer probene lokale enheter, og rapporten beskriver dem som målet. Kontroller ruten skanneren selv ville brukt, før du sender én eneste pakke.
Skann mål-adressen og behold vertsnavnet applikasjonen trenger for TLS-identitet og virtuell hosting. Å nå en gateway beviser at gatewayen svarer; det tester ikke tjenesten bak den.
Trinn 4: behandle oppdagelse som en probe med antakelser
Vertsoppdagelse er der vurderingsresultater oftest går galt. Lokal Ethernet-oppdagelse krysser ikke en rutet VPN, så probene som virker på et flatt LAN, kommer rett og slett ikke frem. Blokkerte oppdagelsesprober får da en tilgjengelig, autorisert tjeneste til å se fraværende ut.
Bestem bevisst om du vil hoppe over oppdagelse og skanne de kjente adressene direkte, og si det i rapporten. En port som svarer, er ikke bevis for at VPN-autentiseringen lyktes, og et filtrert svar er ikke bevis for at ingenting lytter. Hastigheten er en del av samme problem. En telefon som struper eller slipper pakker under en rask skanning, produserer filtrerte tilstander som tilhører telefonen og ikke tjenesten, så senk samtidigheten og skann på nytt før du registrerer en port som lukket.
Stoppbetingelsen her er tolkning, ikke teknikk: hvis du ikke kan si hva en tilstand betyr for denne veien, hører resultatet hjemme i et vedlegg og ikke i funnene.
Trinn 5: hold vinduet, og lukk det så
En telefon er en dårlig server fordi den er laget for å sove. Batterioptimalisering, doze og Wi-Fi-strømstyring kan stanse appen midt i vurderingen, og en gjentilkobling av tunnelen kan endre adressen målet bruker. En kjøring som spenner over en av disse hendelsene, har et ugyldig resultatvindu.
Hold gatewayrollen til det minste omfanget den godkjente oppgaven tillater, overvåk tunnelen mens kjøringen er aktiv, og logg start og slutt på hvert vindu du rapporterer. Når vurderingen er over, fjern den midlertidige tilgangen via eieren, behold kilde- og ruteposten, og beskytt utdataene som enhver annen testartefakt.
Trenger du et repeterbart observasjonspunkt i stedet for en engangssuksess, er det den leveransen det er verdt å argumentere for.referansen om vertsoppdagelse forklarer hvilke prober som forutsetter et lokalt segment, og det er detaljen som gjør et tomt resultat til en forsvarlig uttalelse.