Vidarebefordrad VPN-port: vad besökare och leverantören kan se

Att vidarebefordra en port ger främlingar en väg till en tjänst via leverantörens offentliga adress. Den enda ändringen påverkar exponering och igenkännbarhet samtidigt, och ingen av dem publicerar namnet på den som driver tjänsten. Att hålla de två åtskilda undviker de motsatta felen att behandla vidarebefordran som anonymitet och att behandla den som identifiering. Tre frågor skiljer dem rent, och svaren kommer från olika bevis.

Tre objekt, tre olika frågor

Håll den offentliga adressen åtskild från applikationen som svarar bakom den, och håll båda åtskilda från personen eller organisationen som driver saken. Var och en har sin egen publik och sina egna bevis. Att blanda dem ger slutsatser som låter prydliga och är felaktiga.

Gå igenom dem i den ordningen. Den första är en fråga om nåbarhet, den andra är en fråga om applikationens identitet, och den tredje är en fråga om tillskrivning som de två första bara delvis belyser. När någon frågar om portvidarebefordran är privat, fråga vilken av de tre de menar. Svaren skiljer sig verkligen, och en policysida behandlar vanligtvis bara en av dem.

Vad en besökare kan koppla mellan slutpunkter

En besökare ansluter till slutpunkten och ser vad applikationen legitimt presenterar: 'ett värdnamn', ett certifikatnamn, en inloggningssida, publicerat innehåll. Dessa detaljer identifierar tjänsten även när dess vanliga åtkomstadress är dold bakom tunneln. Två slutpunkter som presenterar samma namngivna webbplats ger observatörer en grund för att koppla dem. Inget i det beteendet är ett läckage, eftersom applikationen designades för att synas.

Överensstämmande certifikat, omdirigeringar och sidinnehåll mellan två slutpunkter är en stark signal om att de tillhör en och samma tjänst. Det förblir ett påstående om tjänsten, inte om en människa, tills någon annan post kopplar samman de två.

IETF:s riktlinjer för integritet beskriver hur beständiga identifierare gör det möjligt att korrelera interaktioner över tid. Korrelation är inte tillskrivning, eftersom flera personer kan administrera en enda tjänst och en adress kan flytta mellan orelaterade abonnenter. Den skillnaden är det som hindrar ett korrelationsfynd från att bli en anklagelse.

Vad vidarebefordransleverantören måste veta

För att leverera en inkommande anslutning måste leverantörens system hålla den aktiva relationen mellan den offentliga ingångspunkten och den interna destinationen. Det driftfaktumet skiljer sig från vad en besökare ser, och återigen från vad leverantören väljer att behålla. Håll de två frågorna åtskilda när du läser en policysida, eftersom den ena är oundviklig och den andra är ett beslut. Ett påstående att ingen webbhistorik sparas säger ingenting om mappningshistorik.

Om historiska mappningar, kontokopplingar eller anslutningsposter består är en fråga för leverantörens faktiska policy och implementering. Vidarebefordran bevisar inte att varje kategori loggas. Fråga specifikt vilka fält som överlever efter att mappningen dragits tillbaka, och hur länge.

Inkommande nåbarhet är också åtskild från klientens utgående routning, DNS och beteende vid fel. Att lägga till en mappning beskriver inte hur resten av klientens trafik tar sig ut.

Hur länge mappningen varar förändrar exponeringen

En mappning kan bestå under en session, under en reservation eller enligt en leverantörspolicy som ändrar den. Varken permanent tilldelning eller konstant rotation bör antas; läs produktens dokumenterade beteende och anteckna det du observerar. Två observationer med en veckas mellanrum säger mer om 'rotation' än någon marknadsföringsmening på produktsidan. Skriv det observerade intervallet bredvid slutpunkten i dina anteckningar, eftersom intervallet är en del av exponeringen.

Livslängden förändrar vilken korrelation som är möjlig. En stabil slutpunkt bjuder in till långsiktig spårning av en tjänst, medan en roterande gör varje observation svårare att koppla till den föregående. Ingen av egenskaperna är en garanti om leverantörens poster, och ingen av dem ersätter beslutet om vad tjänsten själv publicerar.

Publicera medvetet och stäng sedan båda dörrarna

Bekräfta att leverantören tillåter protokollet du behöver, att målets lyssnare är den du menade, och att värd- och applikationskontroller fortfarande begränsar åtkomsten. Titta före publicering på vad tjänsten kommer att presentera för en främling. Dessa två kommandon visar certifikatet och de huvuden en besökare får.

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

Att publicera något berättigar inte att exponera dess administrationssidor eller att släppa applikationens inloggning, och översättning ger inte TLS till en tjänst som aldrig har haft det. Håll det krypterade protokollet och dess serveridentitetskontroller på plats, oavsett hur trafiken anländer. Kontrollera sedan svarshuvudena, eftersom en 'banner' eller 'felsökningssida' kan berätta mer för en främling än tjänsten avser. Det de två kommandona returnerar är samma vy som en observatör får.

Att avveckla tjänsten innebär två stängningar, inte en: dra tillbaka mappningen via dess ägare och hantera sedan lyssnaren och rättigheten som separata poster. En bokmärkt slutpunkt som slutar svara återkallar inte en autentiseringsuppgift och hämtar inte tillbaka redan levererad information.