Kan ein VPN-logg visa nettlesarhistorikk? Kva prova faktisk viser
Ein sesjonslogg, eit resolveroppslag og ei flytoppføring provar ulike ting. Vel spørsmålet, kople identitet og tid, og opplys berre det som vart vist.
To revisjonsspørsmål høyrest like ut og krev ulike slag prov. Kva sesjon som kontakta denne adressa, kan svarast ut frå tilkoplings- og flytoppføringar. Kva person som opna denne sida, kan vanlegvis ikkje svarast, i det minste ikkje ut frå desse oppføringane. Å velje innsamlar før ein vel spørsmål, er korleis eit nettverksteam til slutt presenterer eit vertsnamn som nettlesarhistorikk.
Start med hendinga revisjonen skal fastslå
Skriv spørsmålet som ei setning med subjekt, verb og tid. Berre denne disiplinen avdekkjer gapet mellom ei sesjonsoppføring og ei sidevising. Ein sesjonslogg fastslår at ein identitet vart godteken, for eit intervall, med ei tildelt adresse under ein registrert policy, og han kan ikkje fastslå kva side nokon las, fordi han aldri så førespurnaden.
Merk observasjonen før du designar innsamlinga. Eit felt som er kalla opp etter ein besøkt nettstad, men som faktisk lagrar eit oppslått namn, er ein framtidig feil og ikkje ein bekvemmelegheit. Feltnamn lever lenger enn menneska som valde dei, så vel namn som skildrar provet og ikkje konklusjonen.
Kva kvar oppføring kan og ikkje kan underbyggje
Fire oppføringstypar finst i nesten kvart revisjonsdesign, og kvar av dei svarar på eit ulikt spørsmål. Hald dei åtskilde i rapporten så vel som i kjeda, fordi samanblanding er korleis eit forsvarleg funn blir pinleg.
| 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 midtre. Ei flytoppføring skildrar adresser og portar, og eit omvendt oppslag av ei adresse gjev ikkje att namnet ein nettlesar brukte, fordi éi adresse kan huse mange ikkje-relaterte nettstader. Eit resolveroppslag provar at eit spørsmål vart stilt, ikkje at ei side vart vist. Eit vertsnamn som er synleg under ei TLS-forhandling, er heller ikkje den krypterte førespurnadsstien.
Kvar av desse er ein reell observasjon, og ingen av dei er observasjonen folk føreset. Ein nettlesar som held på sin eigen krypterte resolver, ligg utanfor det overvaka omfanget, og analysen kan ikkje gjenskape det loggføringa aldri såg. Det gapet høyrer heime i rapporten som ei uttalt avgrensing, ikkje som ei fotnote.
Spekulative oppslag og svar frå mellomlageret
Nettlesarar slår opp namn på førehand, stundom utan å laste noko som helst. Dei svarar også frå mellomlageret utan å sende ein ny førespurnad til resolveren du overvakar, noko som tyder at fråvær av førespurnad ikkje er fråvær av besøk. Begge åtferdene bryt den naive likninga mellom ein DNS-logg og nettlesarhistorikk.
DNS over HTTPS legg til ei ny grense: ein nettlesar eller gjesteprogram med eigen resolver spør aldri loggaren til organisasjonen om noko. Nøyaktige transaksjonar kjem berre frå hendingane til programmet sjølv eller frå ein proxy der du uttrykkeleg støttar loggføringa. Ein vanleg HTTPS CONNECT-tunnel gjev proxyen ingen innsikt i sidebanane inni han. Å eige nettet er ikkje løyve til å byte ut tillitsmodellen til programmet i det stille.
Adressa høyrer til ein sesjon, ikkje ein person
Ei flytoppføring med ei adresse frå tunnelområdet er eit utgangspunkt, ikkje eit svar. Kople den adressa og tidsstempla til sesjonstildelinga som var aktiv i det augeblikket, fordi adressa kan tildelast ein annan sesjon ein time seinare. Statisk adressering er éin måte å halde på den koplinga, ikkje den einaste.
Der eit omsetjingstrinn slår saman fleire einingar til éi kjeldeadresse oppstraums sensoren, kan koplinga berre namngje den delte gateway-sesjonen. Ein delt konto eller eit sertifikat som fleire personar brukar, avgrensar tilskrivinga uansett kor fullstendige nettverksdataa ser ut. Begge høyrer heime i rapporten som avgrensingar, ikkje som atterhald for seinare.
Registrer tidssona, klokkekjelda, observasjonspunktet og kvar omsetjingsgrense imellom. Fråvær fortener same omsut som tilstadevere, sidan ei manglande oppføring kan tyde at ei flytoppføring er gått ut, at ein sensor aldri såg pakken, eller at ein programlogg var slått av.
Design for det oppgjevne føremålet, og prov deretter kjeda
Når spørsmålet er fastsett, definer kva felt som trengst, kven som kan lese dei, og kor lenge dei blir tekne vare på. Å samle meir fordi lagring er billeg, skaper ei byrde som varer lenger enn granskinga. Personvernmodellen i RFC 6973 rammar inn korrelasjon, feiltilskriving og unødvendig innsamling som designproblem og ikkje som ettertankar.
Vern koplinga og oppføringane som eitt objekt, fordi kvar av dei åleine er langt mindre sensitive enn paret. Stadfest deretter designet mot aktivitet du har løyve til å skape og allereie forstår, med den minste førespurnaden rapporten vil byggje på. Ei kjeda som ikkje kan gjenskape ei kjend hending, vil heller ikkje gjenskape ei ukjend. Rapporter hendinga prova underbyggjer, med dei orda prova tillèt, og la lesaren trekkje den større konklusjonen utan hjelp.
Skriv avgrensingane ved sida av funnet: kva som vart kopia, kva som vart omsett, og kva logg som vart taus. Eit funn som oppgjev sine eigne grenser, toler ein gjennomgang som eit sjølvsikkert samandrag ikkje toler. Det er skilnaden mellom prov og ei forteljing om prov.