Videresendt VPN-port: hvad besøgende og udbyderen kan se

At videresende en port giver fremmede en rute til en tjeneste gennem udbyderens offentlige adresse. Den ene ændring påvirker eksponering og genkendelighed på samme tid, og ingen af dem offentliggør navnet på den, der driver tjenesten. At holde de to adskilt undgår de modsatte fejl at behandle 'videresendelse' som anonymitet og at behandle det som identifikation. Tre spørgsmål adskiller dem rent, og svarene kommer fra forskellige beviser.

Tre objekter, tre forskellige spørgsmål

Hold den offentlige adresse adskilt fra den applikation, der svarer bag den, og hold begge adskilt fra den person eller organisation, der driver sagen. Hver har sit eget publikum og sine egne beviser. At blande dem giver konklusioner, der lyder ryddelige og er forkerte.

Gå gennem dem i den rækkefølge. Det første er et spørgsmål om tilgængelighed, det andet er et spørgsmål om applikationsidentitet, og det tredje er et spørgsmål om tilskrivning, som de to første kun delvist oplyser. Når nogen spørger, om portvideresendelse er privat, så spørg, hvilket af de tre de mener. Svarene er virkelig forskellige, og en politikside behandler normalt kun et af dem.

Hvad en besøgende kan koble på tværs af endepunkter

En besøgende forbinder til endepunktet og ser, hvad applikationen legitimt præsenterer: et 'værtsnavn', et certifikatnavn, en login-side, offentliggjort indhold. Disse detaljer identificerer tjenesten, selv når dens sædvanlige adgangsadresse er skjult bag tunnelen. To endepunkter, der præsenterer det samme navngivne websted, giver observatører et grundlag for at koble dem. Intet i den adfærd er en lækage, da applikationen blev designet til at blive set.

At matche certifikater, omdirigeringer og sideindhold på tværs af to endepunkter er et stærkt signal om, at de tilhører én tjeneste. Det forbliver en udtalelse om tjenesten, ikke om et menneske, indtil en anden registrering forbinder de to.

IETF's vejledning om privatliv beskriver, hvordan vedvarende identifikatorer gør det muligt at korrelere interaktioner over tid. Korrelation er ikke tilskrivning, da flere personer kan administrere én tjeneste, og en adresse kan flytte mellem ubeslægtede abonnenter. Den forskel er det, der forhindrer et korrelationsfund i at blive en anklage.

Hvad videresendelsesudbyderen skal vide

For at levere en indgående forbindelse skal udbyderens system holde den aktive relation mellem det offentlige indgangspunkt og den interne destination. Den driftsmæssige kendsgerning er forskellig fra det, en besøgende ser, og igen forskellig fra det, udbyderen vælger at beholde. Hold de to spørgsmål adskilt, når du læser en politikside, fordi det ene er uundgåeligt, og det andet er en beslutning. En udtalelse om, at der ikke gemmes browserhistorik, siger intet om mapping-historik.

Om historiske mappinger, kontotilknytninger eller forbindelsesregistreringer består, er et spørgsmål for udbyderens faktiske politik og implementering. Videresendelse beviser ikke, at hver kategori logges. Spørg specifikt, hvilke felter der overlever, efter mappingen er trukket tilbage, og hvor længe.

Indgående tilgængelighed er også adskilt fra klientens udgående routing, DNS og fejlopførsel. At tilføje en mapping beskriver ikke, hvordan resten af klientens trafik forlader.

Hvor længe mappingen varer, ændrer eksponeringen

En mapping kan bestå i en session, i en reservation eller under en udbyderpolitik, der ændrer den. Hverken permanent tildeling eller konstant rotation bør antages; læs produktets dokumenterede adfærd, og notér det, du observerer. To observationer med en uges mellemrum fortæller mere om 'rotation' end nogen marketingsætning på produktsiden. Skriv det observerede interval ved siden af endepunktet i dine noter, fordi intervallet er en del af eksponeringen.

Levetiden ændrer, hvilken korrelation der er mulig. Et stabilt endepunkt inviterer til langsigtet sporing af én tjeneste, mens et roterende gør hver observation sværere at forbinde med den sidste. Ingen af egenskaberne er en garanti om udbyderens registreringer, og ingen af dem erstatter beslutningen om, hvad tjenesten selv offentliggør.

Udgiv med vilje, og luk derefter begge døre

Bekræft, at udbyderen tillader den protokol, du har brug for, at målets lytter er den, du mente, og at værts- og applikationskontroller stadig begrænser adgangen. Se før publicering, hvad tjenesten vil præsentere for en fremmed. Disse to kommandoer viser certifikatet og de headere, en besøgende modtager.

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

At offentliggøre noget retfærdiggør ikke at blotlægge dets administrationssider eller droppe applikationens login, og oversættelse giver ikke TLS til en tjeneste, der aldrig har haft det. Hold den krypterede protokol og dens serveridentitetskontroller på plads, uanset hvordan trafikken ankommer. Kontroller derefter svarheaderne, fordi et 'banner' eller en fejlretningsside kan fortælle en fremmed mere, end tjenesten har til hensigt. Det, de to kommandoer returnerer, er samme billede, som en observatør får.

At nedlægge tjenesten betyder to lukninger, ikke én: træk mappingen tilbage gennem dens ejer, og tag derefter lytteren og rettigheden som separate punkter. Et bogmærket endepunkt, der holder op med at svare, tilbagekalder ikke en legitimation og henter ikke allerede leveret information tilbage.