Videresendt VPN-port: hva besøkende og tilbyderen kan se

Å videresende en port gir fremmede en rute til en tjeneste gjennom tilbyderens offentlige adresse. Den ene endringen påvirker eksponering og gjenkjennbarhet samtidig, og ingen av dem publiserer navnet på den som driver tjenesten. Å holde de to fra hverandre unngår de motsatte feilene å behandle videresending som anonymitet og å behandle det som identifikasjon. Tre spørsmål skiller dem rent, og svarene kommer fra ulike bevis.

Tre objekter, tre forskjellige spørsmål

Hold den offentlige adressen atskilt fra applikasjonen som svarer bak den, og hold begge atskilt fra personen eller organisasjonen som driver saken. Hver har sitt eget publikum og sine egne bevis. Å blande dem gir konklusjoner som høres ryddige ut og er feil.

Gå gjennom dem i den rekkefølgen. Det første er et spørsmål om tilgjengelighet, det andre er et spørsmål om applikasjonsidentitet, og det tredje er et spørsmål om tilskrivning som de to første bare delvis belyser. Når noen spør om portvideresending er privat, spør hvilket av de tre de mener. Svarene er virkelig forskjellige, og en policy-side behandler vanligvis bare ett av dem.

Hva en besøkende kan koble på tvers av endepunkter

En besøkende kobler til endepunktet og ser det applikasjonen legitimt presenterer: 'vertsnavn', sertifikatnavn, innloggingsside, publisert innhold. Disse detaljene identifiserer tjenesten selv når dens vanlige tilgangsadresse er skjult bak tunnelen. To endepunkter som presenterer samme navngitte nettsted gir observatører et grunnlag for å koble dem. Ingenting i den atferden er en lekkasje, siden applikasjonen ble designet for å bli sett.

Samsvar mellom sertifikater, omdirigeringer og sideinnhold på tvers av to endepunkter er et sterkt signal om at de tilhører én tjeneste. Det forblir en uttalelse om tjenesten, ikke om et menneske, til en annen registrering kobler de to.

IETFs personvernveiledning beskriver hvordan vedvarende identifikatorer gjør det mulig å korrelere interaksjoner over tid. Korrelasjon er ikke tilskrivning, siden flere personer kan administrere én tjeneste og en adresse kan flytte mellom ubeslektede abonnenter. Den forskjellen er det som hindrer et korrelasjonsfunn i å bli en anklage.

Hva videresendingstilbyderen må vite

For å levere en innkommende forbindelse må tilbyderens system holde den aktive relasjonen mellom det offentlige inngangspunktet og den interne destinasjonen. Det driftsmessige faktum er forskjellig fra det en besøkende ser, og igjen forskjellig fra det tilbyderen velger å beholde. Hold de to spørsmålene atskilt når du leser en policy-side, fordi det ene er uunngåelig og det andre er en beslutning. En uttalelse om at ingen nettleserhistorikk lagres sier ingenting om mapping-historikk.

Om historiske mappinger, kontotilknytninger eller tilkoblingsregistreringer består, er et spørsmål for tilbyderens faktiske policy og implementering. Videresending beviser ikke at hver kategori logges. Spør spesifikt hvilke felt som overlever etter at mappingen er trukket tilbake, og hvor lenge.

Innkommende tilgjengelighet er også atskilt fra klientens utgående ruting, DNS og feilatferd. Å legge til en mapping beskriver ikke hvordan resten av klientens trafikk går ut.

Hvor lenge mappingen varer endrer eksponeringen

En mapping kan bestå i en økt, i en reservasjon eller under en tilbyderpolicy som endrer den. Verken permanent tildeling eller konstant rotasjon bør antas; les produktets dokumenterte atferd og noter det du observerer. To observasjoner med en ukes mellomrom forteller mer om 'rotasjon' enn noen markedssetning på produktsiden. Skriv det observerte intervallet ved siden av endepunktet i notatene dine, fordi intervallet er en del av eksponeringen.

Levetiden endrer hvilken korrelasjon som er mulig. Et stabilt endepunkt inviterer til langsiktig sporing av én tjeneste, mens et roterende gjør hver observasjon vanskeligere å koble til den forrige. Ingen av egenskapene er en garanti om tilbyderens registreringer, og ingen av dem erstatter beslutningen om hva tjenesten selv publiserer.

Publiser med vilje, og lukk deretter begge dører

Bekreft at tilbyderen tillater protokollen du trenger, at målets lytter er den du mente, og at verts- og applikasjonskontroller fortsatt begrenser tilgangen. Se før publisering hva tjenesten vil presentere for en fremmed. Disse to kommandoene viser sertifikatet og headerne en besøkende mottar.

openssl s_client -connect pub.example.net:443 -brief < /dev/null
curl -sSI https://pub.example.net/

Å publisere noe rettferdiggjør ikke å eksponere administrasjonssidene eller å droppe innloggingen til applikasjonen, og oversettelse gir ikke TLS til en tjeneste som aldri har hatt det. Hold den krypterte protokollen og dens serveridentitetskontroller på plass, uansett hvordan trafikken ankommer. Sjekk deretter svarheaderne, fordi en 'banner' eller 'feilsøkingsside' kan fortelle en fremmed mer enn tjenesten har til hensikt. Det de to kommandoene returnerer er samme visning som en observatør får.

Å avvikle tjenesten betyr to lukninger, ikke én: trekk mappingen tilbake gjennom eieren, og behandle deretter lytteren og rettigheten som separate punkter. Et bokmerket endepunkt som slutter å svare tilbakekaller ikke en legitimasjon og henter ikke tilbake allerede levert informasjon.