Ei autorisert vurdering av ein VPN som køyrer på ein telefon, feilar lydlaust når skannaren sit på feil side av tunnelen. Du får resultat, dei ser plausible ut, og dei svarar på eit spørsmål ingen stilte. Gå gjennom dei fem kontrollane nedanfor i rekkjefølgje. Kvar har ein stoppbetingelse, og det er billegare å stoppe tidleg enn å teste på nytt frå botnen etter at rapporten er skriven.

Trinn 1: namnge flata du vil nå

Tre flater blir rutinemessig forveksla fordi éi eining koplar dei saman. Dei køyrer ulik kode og ulik policy, så skriv ned kva for ei som er innanfor omfanget før noko blir starta.

Assessment targetWhat the path exercises
Public VPN listener on the handsetReachability before login, plus the exposed VPN daemon
A service on the handset, by its tunnel addressAccess after admission to something hosted locally
A LAN host behind the handset gatewayForwarding, the return path and downstream access policy

Viss det godkjende omfanget ikkje seier kva for ei av dei tre, stopp og spør. Rooting av telefonen svarar ikkje på dette spørsmålet, og det endrar det som blir testa, ikkje observasjonspunktet.

Noter måla, dei tillatne kjeldeadressene, tidsvindauget og intensitetsgrensa samstundes. Tunnelen ber deg til dette omfanget; han gir ikkje lisens til å undersøkje alt han kan rute.

Trinn 2: vel kjelda som kan sjå den flata

Ein skannar som sit inne i VPN-en kan ikkje gjenskape ein uautentisert internettobservatør. Han har allereie ruter, påloggingsdata og løyve som observatøren utanfor manglar, så resultata skildrar visninga etter innslepp sjølv når målflata er den same. Den motsette feilen er like vanleg. Ein offentleg skan av VPN-porten seier nesten ingenting om ei privat teneste bak innlogginga, og å rapportere det som om han gjorde det, overdriv eksponeringa i éi retning og underdriv ho i den andre.

Stopp viss kjelda du kan skaffe ikkje samsvarer med flata. Ei vurdering køyrd frå ein peer inne i tunnelen bør ikkje presenterast som eit resultat før autentisering, og ein test som krev ei godkjend ekstern kjelde, bør ikkje flyttast lydlaust inn for å unngå papirarbeidet.

Trinn 3: stadfest ruta og returvegen gjennom telefonen

Når eininga vidaresender til eit anna subnett, treng skannaren ei tillaten rute og målet ein returveg som verkar. Stadfest begge i staden for å anta at eit ping-svar betyr at vegen er komplett.

ip route get 10.20.0.8
tcpdump -ni any host 10.20.0.8

Source NAT endrar kva den nedstraums tenesta ser. Viss telefonen omset adressa til skannaren, gjeld tilgangsreglane og loggane på målet for den omsette adressa, så ei teneste som ser ut til å godta deg, godtar kanskje telefonen og ikkje skannaren.

Følg òg med på overlapp med nettverket til skannaren sjølv. Viss telefonen rutar 192.168.1.0/24 og skannaren sit på eit LAN nummerert på same måten, treffer probane lokale einingar, og rapporten skildrar dei som målet. Kontroller ruta skannaren sjølv ville brukt, før du sender éi einaste pakke.

Skann mål-adressa og behald vertsnamnet applikasjonen treng for TLS-identitet og virtuell hosting. Å nå ein gateway beviser at gatewayen svarar; det testar ikkje tenesta bak han.

Trinn 4: handsam oppdaging som ein probe med antakingar

Vertsoppdaging er der vurderingsresultat oftast går gale. Lokal Ethernet-oppdaging kryssar ikkje ein ruta VPN, så probane som verkar på eit flatt LAN, kjem rett og slett ikkje fram. Blokkerte oppdagingsprobar får då ei tilgjengeleg, autorisert teneste til å sjå fråverande ut.

Bestem medvite om du vil hoppe over oppdaging og skanne dei kjende adressene direkte, og sei det i rapporten. Ein port som svarar, er ikkje bevis for at VPN-autentiseringa lukkast, og eit filtrert svar er ikkje bevis for at ingenting lyttar. Farten er ein del av same problemet. Ein telefon som strupar eller slepp pakkar under ein rask skan, produserer filtrerte tilstandar som høyrer til telefonen og ikkje tenesta, så senk samtidigheita og skann på nytt før du registrerer ein port som lukka.

Stoppbetingelsen her er tolking, ikkje teknikk: viss du ikkje kan seie kva ein tilstand betyr for denne vegen, høyrer resultatet heime i eit vedlegg og ikkje i funna.

Trinn 5: hald vindauget, og lukk det så

Ein telefon er ein dårleg server fordi han er laga for å sove. Batterioptimalisering, doze og Wi-Fi-straumstyring kan stanse appen midt i vurderinga, og ein gjentilkopling av tunnelen kan endre adressa målet brukar. Ei køyring som spenner over ein av desse hendingane, har eit ugyldig resultatvindauge.

Hald gatewayrolla til det minste omfanget den godkjende oppgåva tillèt, overvak tunnelen medan køyringa er aktiv, og logg start og slutt på kvart vindauge du rapporterer. Når vurderinga er over, fjern den midlertidige tilgangen via eigaren, behald kjelde- og ruteposten, og vern utdataa som kvar annan testartefakt.

Treng du eit repeterbart observasjonspunkt i staden for ein eingongssuksess, er det den leveransen det er verdt å argumentere for.referansen om vertsoppdaging forklarar kva probar som føreset eit lokalt segment, og det er detaljen som gjer eit tomt resultat til ei forsvarleg utsegn.

Relaterte artiklar