Kan en VPN-logg visa webbläsarhistorik? Vad bevisningen visar
En sessionslogg, en resolverfråga och en flödespost bevisar olika saker. Välj frågan, koppla identitet och tid och ange bara det som visades.
Två granskningsfrågor låter lika och kräver olika slags bevis. Vilken session som kontaktade den här adressen går att svara på utifrån anslutnings- och flödesposter. Vilken person som öppnade den här sidan går oftast inte, åtminstone inte utifrån de posterna. Att välja insamlare innan man väljer fråga är hur ett nätverksteam till slut presenterar ett värdnamn som webbläsarhistorik.
Börja med händelsen som granskningen ska fastställa
Skriv frågan som en mening med subjekt, verb och tid. Bara den disciplinen blottlägger gapet mellan en sessionspost och en sidvisning. En sessionslogg fastställer att en identitet accepterades, under ett intervall, med en tilldelad adress enligt en registrerad policy, och den kan inte fastställa vilken sida någon läste eftersom den aldrig såg begäran.
Märk observationen innan du designar insamlingen. Ett fält som är uppkallat efter en besökt webbplats men som i själva verket lagrar ett uppslaget namn är ett framtida fel och inte en bekvämlighet. Fältnamn lever längre än människorna som valde dem, så välj namn som beskriver beviset och inte slutsatsen.
Vad varje post kan och inte kan styrka
Fyra posttyper förekommer i nästan varje granskningsdesign, och var och en svarar på en annan fråga. Håll dem åtskilda i rapporten såväl som i kedjan, eftersom sammanblandning är hur ett försvarbart fynd blir pinsamt.
| The question being asked | Record that can answer it | What that record proves | What still needs a join |
|---|---|---|---|
| Was this address contacted? | Flow record | The connection five-tuple and when it was seen | Which session held the address at that moment |
| Which account held that address? | Session log | Which identity authenticated and the tunnel address it received | Which device or person used that account |
| Was this name looked up? | Resolver query | That this resolver was asked for this name | Whether a page was fetched, and by whom |
| Was this page viewed? | Proxy or application transaction | The request and identity recorded inside that application's scope | Traffic outside that application's visibility |
| Who was the person? | None of the four on its own | An account in use, at best | A named human, whenever accounts are shared |
Läs den sista kolumnen lika noga som den mellersta. En flödespost beskriver adresser och portar, och en omvänd uppslagning av en adress återskapar inte namnet en webbläsare använde, eftersom en adress kan vara värd för många orelaterade webbplatser. En resolverfråga bevisar att en fråga ställdes, inte att en sida visades. Ett värdnamn som syns under en TLS-förhandling är inte heller den krypterade begärans väg.
Var och en av dessa är en verklig observation, och ingen av dem är den observation folk antar. En webbläsare som insisterar på sin egen krypterade resolver ligger utanför det övervakade området, och analysen kan inte återvinna det loggningen aldrig såg. Det gapet hör hemma i rapporten som en uttalad begränsning, inte som en fotnot.
Spekulativa uppslag och cachade svar
Webbläsare slår upp namn i förväg, ibland utan att ladda något alls. De svarar också från cachen utan att skicka en ny fråga till resolvern du övervakar, vilket betyder att avsaknaden av en fråga inte är avsaknaden av ett besök. Båda beteendena bryter den naiva ekvationen mellan en DNS-logg och webbläsarhistorik.
DNS over HTTPS lägger till en andra gräns: en webbläsare eller gästapplikation med egen resolver frågar aldrig organisationens loggare om något. Exakta transaktioner kommer bara från applikationens egna händelser eller från en proxy vars loggning du uttryckligen stöder. En vanlig HTTPS CONNECT-tunnel ger proxyn ingen inblick i sidvägarna inuti. Att äga nätet är inte tillstånd att i tysthet byta ut applikationens förtroendemodell.
Adressen tillhör en session, inte en person
En flödespost med en adress i tunnelintervallet är en utgångspunkt, inte ett svar. Koppla den adressen och tidsstämpeln till den sessionstilldelning som var aktiv i det ögonblicket, eftersom adressen kan tilldelas en annan session en timme senare. Statisk adressering är ett sätt att behålla den kopplingen, inte det enda.
Där ett översättningssteg slår samman flera enheter till en enda källadress uppströms sensorn kan kopplingen bara namnge den delade gateway-sessionen. Ett delat konto eller ett certifikat som används av flera personer begränsar tillskrivningen hur fullständiga nätverksdata än ser ut. Båda hör hemma i rapporten som begränsningar, inte som förbehåll för senare.
Registrera tidszonen, klockkällan, observationspunkten och varje översättningsgräns däremellan. Frånvaro förtjänar samma omsorg som närvaro, eftersom en saknad post kan betyda att en flödespost löpt ut, att en sensor aldrig såg paketet eller att en applikationslogg var avstängd.
Designa för det angivna syftet och bevisa sedan kedjan
När frågan är fastställd, definiera vilka fält som behövs, vem som får läsa dem och hur länge de sparas. Att samla mer eftersom lagring är billigt skapar en belastning som överlever utredningen. Integritetsmodellen i RFC 6973 ramar in korrelation, feltillskrivning och onödig insamling som designproblem och inte som eftertanke.
Skydda mappningen och posterna som ett objekt, eftersom var och en för sig är långt mindre känslig än paret. Validera sedan designen mot aktivitet du får skapa och redan förstår, med den minsta fråga som rapporten kommer att vila på. En kedja som inte kan återskapa en känd händelse återskapar inte heller en okänd. Rapportera händelsen som bevisningen stöder, med de ord bevisningen tillåter, och låt läsaren nå den större slutsatsen själv.
Skriv begränsningarna bredvid fyndet: vad som kopplades, vad som översattes och vilken logg som förblev tyst. Ett fynd som anger sina egna gränser tål en granskning som en självsäker sammanfattning inte tål. Det är skillnaden mellan bevis och en berättelse om bevis.