Ali lahko dnevnik VPN pokaže zgodovino brskanja? Kaj dokazuje dokaz
Dnevnik seje, poizvedba resolverja in zapis toka dokazujejo različne stvari. Izberite vprašanje, povežite identiteto in čas ter navedite le, kar je bilo prikazano.
Dve revizijski vprašanji zvenita podobno in zahtevata dokaze različnih vrst. Na vprašanje, katera seja je kontaktirala ta naslov, je mogoče odgovoriti iz zapisov povezav in tokov. Na vprašanje, katera oseba je odprla to stran, običajno ne, vsaj ne iz teh zapisov. Izbira zbiralnika pred izbiro vprašanja je način, kako omrežna ekipa na koncu predstavi ime gostitelja kot zgodovino brskanja.
Začnite z dogodkom, ki ga mora revizija ugotoviti
Vprašanje zapišite kot stavek s subjektom, glagolom in časom. Že ta disciplina razkrije vrzel med zapisom seje in prikazom strani. Dnevnik seje ugotavlja, da je bila identiteta sprejeta, za določen interval, z dodeljenim naslovom po zabeleženi politiki, in ne more ugotoviti, katero stran je kdo bral, ker nikoli ni videl zahteve.
Označite opažanje, preden zasnujete zbiranje. Polje, imenovano po obiskanem spletišču, ki v resnici shranjuje razrešeno ime, je prihodnja napaka in ne priročnost. Imena polj živijo dlje od ljudi, ki so jih izbrali, zato izbirajte imena, ki opisujejo dokaz, ne sklepa.
Kaj lahko posamezen zapis podpre in česa ne
Štiri vrste zapisov se pojavljajo skoraj v vsaki revizijski zasnovi in vsaka odgovarja na drugo vprašanje. Ohranite jih ločene v poročilu in v cevovodu, ker je njihovo mešanje način, kako obrambna ugotovitev postane nerodna.
| 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 |
Zadnji stolpec berite enako pozorno kot srednjega. Zapis toka opisuje naslove in vrata, povratno iskanje naslova pa ne rekonstruira imena, ki ga je uporabil brskalnik, ker lahko en naslov gosti veliko nepovezanih spletišč. Poizvedba resolverja dokazuje, da je bilo vprašanje postavljeno, ne da je bila stran prikazana. Ime gostitelja, vidno med pogajanjem TLS, prav tako ni šifrirana pot zahteve.
Vsako od tega je resnično opažanje in nobeno ni opažanje, ki ga ljudje predpostavljajo. Brskalnik, ki vztraja pri lastnem šifriranem resolverju, je zunaj nadzorovanega obsega in analiza ne more obnoviti tistega, česar beleženje ni nikoli videlo. Ta vrzel sodi v poročilo kot izrecna omejitev, ne kot opomba pod črto.
Špekulativna iskanja in odgovori iz predpomnilnika
Brskalniki razrešujejo imena vnaprej, včasih brez da bi kar koli naložili. Odgovarjajo tudi iz predpomnilnika, ne da bi poslali novo poizvedbo resolverju, ki ga spremljate, kar pomeni, da odsotnost poizvedbe ni odsotnost obiska. Obe vedenji lomita naivno enačbo med dnevnikom DNS in zgodovino brskanja.
DNS over HTTPS doda drugo mejo: brskalnik ali gostujoča aplikacija z lastnim resolverjem organizacijskega beležnika nikoli nič ne vpraša. Natančne transakcije prihajajo le iz dogodkov same aplikacije ali iz posrednika, katerega beleženje izrecno podpirate. Obični tunel HTTPS CONNECT posredniku ne da nobenega vpogleda v poti strani znotraj. Imeti omrežje ni dovoljenje, da tiho zamenjate model zaupanja aplikacije.
Naslov pripada seji, ne osebi
Zapis toka z naslovom iz obsega tunela je izhodišče in ne odgovor. Povežite ta naslov in časovni žig z dodelitvijo seje, ki je bila aktivna v tistem trenutku, ker je lahko naslov uro kasneje dodeljen drugi seji. Statično naslavljanje je eden od načinov, da to povezavo ohranite, ne edini.
Kjer korak prevajanja združi več naprav v en izvorni naslov pred senzorjem, lahko povezava poimenuje le skupno sejo prehoda. Skupni račun ali potrdilo, ki ga uporablja več ljudi, omejuje pripisovanje, ne glede na to, kako popolni so omrežni podatki. Oboje sodi v poročilo kot omejitev, ne kot pridržek za pozneje.
Zabeležite časovni pas, vir ure, točko opazovanja in vsako mejo prevajanja vmes. Odsotnost si zasluži enako skrbnost kot prisotnost, saj lahko manjkajoč zapis pomeni, da je vnos toka potekel, da senzor paketa ni nikoli videl ali da je bil dnevnik aplikacije izklopljen.
Načrtujte za navedeni namen, nato dokažite cevovod
Ko je vprašanje določeno, opredelite, katera polja so potrebna, kdo jih sme brati in kako dolgo se hranijo. Zbiranje več zato, ker je shranjevanje poceni, ustvari obveznost, ki preživi preiskavo. Model zasebnosti v RFC 6973 obravnava korelacijo, napačno pripisovanje in nepotrebno zbiranje kot načrtovalske težave, ne kot poznejšo misel.
Zaščitite preslikavo in zapise kot en predmet, ker je vsako samo veliko manj občutljivo od para. Nato preverite zasnovo na dejavnosti, ki jo smete ustvariti in jo že razumete, z najmanjšo poizvedbo, na kateri bo poročilo temeljilo. Cevovod, ki ne more poustvariti znanega dogodka, ne bo poustvaril niti neznanega. Poročajte o dogodku, ki ga dokazi podpirajo, z besedami, ki jih dokazi dovoljujejo, in pustite bralcu, da do večjega sklepa pride sam.
Zapišite omejitve ob ugotovitvi: kaj je bilo povezano, kaj prevedeno in kateri dnevnik je ostal tih. Ugotovitev, ki navaja lastne meje, prestane pregled, ki ga samozavesten povzetek ne prestane. To je razlika med dokazom in zgodbo o dokazu.