Kan en VPN-logg vise nettleserhistorikk? Hva bevisene faktisk viser
En sesjonslogg, et resolveroppslag og en flytoppføring beviser ulike ting. Velg spørsmålet, koble identitet og tid, og oppgi bare det som ble vist.
To revisjonsspørsmål høres like ut og krever ulike typer bevis. Hvilken sesjon som kontaktet denne adressen, kan besvares ut fra tilkoblings- og flytoppføringer. Hvilken person som åpnet denne siden, kan vanligvis ikke besvares, i det minste ikke ut fra disse oppføringene. Å velge innsamler før man velger spørsmål, er hvordan et nettverksteam ender med å presentere et vertsnavn som nettleserhistorikk.
Start med hendelsen revisjonen skal fastslå
Skriv spørsmålet som en setning med subjekt, verb og tid. Bare den disiplinen avdekker gapet mellom en sesjonsoppføring og en sidevisning. En sesjonslogg fastslår at en identitet ble godtatt, for et intervall, med en tildelt adresse under en registrert policy, og den kan ikke fastslå hvilken side noen leste, fordi den aldri så forespørselen.
Merk observasjonen før du designer innsamlingen. Et felt som er oppkalt etter et besøkt nettsted, men som faktisk lagrer et oppslått navn, er en fremtidig feil og ikke en bekvemmelighet. Feltnavn lever lenger enn menneskene som valgte dem, så velg navn som beskriver beviset og ikke konklusjonen.
Hva hver oppføring kan og ikke kan underbygge
Fire oppføringstyper finnes i nesten ethvert revisjonsdesign, og hver av dem svarer på et ulikt spørsmål. Hold dem atskilt i rapporten så vel som i kjeden, fordi sammenblanding er hvordan et forsvarlig funn blir pinlig.
| 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 |
Les den siste kolonnen like nøye som den midterste. En flytoppføring beskriver adresser og porter, og et omvendt oppslag av en adresse gjenoppretter ikke navnet en nettleser brukte, fordi én adresse kan være vert for mange urelaterte nettsteder. Et resolveroppslag beviser at et spørsmål ble stilt, ikke at en side ble vist. Et vertsnavn som er synlig under en TLS-forhandling, er heller ikke den krypterte forespørselsstien.
Hver av disse er en reell observasjon, og ingen av dem er observasjonen folk antar. En nettleser som insisterer på sin egen krypterte resolver, ligger utenfor det overvåkede omfanget, og analysen kan ikke gjenopprette det loggingen aldri så. Det gapet hører hjemme i rapporten som en uttalt begrensning, ikke som en fotnote.
Spekulative oppslag og bufrede svar
Nettlesere slår opp navn på forhånd, noen ganger uten å laste noe i det hele tatt. De svarer også fra hurtigbufferen uten å sende en ny spørring til resolveren du overvåker, noe som betyr at fravær av spørring ikke er fravær av besøk. Begge atferdene bryter den naive ligningen mellom en DNS-logg og nettleserhistorikk.
DNS over HTTPS legger til en ny grense: en nettleser eller gjesteapplikasjon med sin egen resolver spør aldri organisasjonens logger om noe. Nøyaktige transaksjoner kommer bare fra applikasjonens egne hendelser eller fra en proxy der du uttrykkelig støtter loggingen. En vanlig HTTPS CONNECT-tunnel gir proxyen ingen innsikt i sidestiene inni den. Å eie nettet er ikke tillatelse til å bytte ut applikasjonens tillitsmodell i det stille.
Adressen tilhører en sesjon, ikke en person
En flytoppføring med en adresse fra tunnelområdet er et utgangspunkt, ikke et svar. Koble den adressen og tidsstempelet til sesjonstildelingen som var aktiv i det øyeblikket, fordi adressen kan tildeles en annen sesjon en time senere. Statisk adressering er én måte å holde på den koblingen, ikke den eneste.
Der et oversettelsestrinn slår sammen flere enheter til én kildeadresse oppstrøms for sensoren, kan koblingen bare navngi den delte gateway-sesjonen. En delt konto eller et sertifikat som brukes av flere personer, begrenser tilskrivningen uansett hvor fullstendig nettverksdataene ser ut. Begge hører hjemme i rapporten som begrensninger, ikke som forbehold for senere.
Registrer tidssonen, klokkekilden, observasjonspunktet og hver oversettelsesgrense imellom. Fravær fortjener samme omhu som tilstedeværelse, siden en manglende oppføring kan bety at en flytoppføring er utløpt, at en sensor aldri så pakken, eller at en applikasjonslogg var slått av.
Design for det angitte formålet, og bevis deretter kjeden
Når spørsmålet er fastsatt, definer hvilke felt som trengs, hvem som kan lese dem, og hvor lenge de oppbevares. Å samle mer fordi lagring er billig, skaper en byrde som varer lenger enn undersøkelsen. Personvernmodellen i RFC 6973 rammer inn korrelasjon, feiltilskrivning og unødvendig innsamling som designproblemer og ikke som ettertanker.
Vern koblingen og oppføringene som ett objekt, fordi hver av dem alene er langt mindre sensitiv enn paret. Valider deretter designet mot aktivitet du har lov til å generere og allerede forstår, ved hjelp av den minste spørringen rapporten vil bygge på. En kjede som ikke kan gjenskape en kjent hendelse, vil heller ikke gjenskape en ukjent. Rapporter hendelsen bevisene underbygger, med de ordene bevisene tillater, og la leseren trekke den større konklusjonen uten hjelp.
Skriv begrensningene ved siden av funnet: hva som ble koblet, hva som ble oversatt, og hvilken logg som forble taus. Et funn som angir sine egne grenser, tåler en gjennomgang som et selvsikkert sammendrag ikke tåler. Det er forskjellen mellom bevis og en historie om bevis.