Vai VPN žurnāls var parādīt pārlūkošanas vēsturi? Ko pierāda pierādījumi
Sesijas žurnāls, risinātāja vaicājums un plūsmas ieraksts pierāda dažādas lietas. Izvēlieties jautājumu, savienojiet identitāti un laiku, un sakiet tikai to, kas tika parādīts.
Divi audita jautājumi izklausās līdzīgi un prasa dažāda veida pierādījumus. Uz jautājumu, kura sesija sazinājās ar šo adresi, var atbildēt no savienojumu un plūsmas ierakstiem. Uz jautājumu, kura persona atvēra šo lapu, parasti ne, vismaz ne no šiem ierakstiem. Kolektora izvēle pirms jautājuma izvēles ir ceļš, kā tīkla komanda beigās uzrāda resursdatora nosaukumu kā pārlūkošanas vēsturi.
Sāciet ar notikumu, kas auditam jāpierāda
Uzrakstiet jautājumu kā teikumu ar subjektu, izteicēju un laiku. Vien šī disciplīna atklāj plaisu starp sesijas ierakstu un lapas skatījumu. Sesijas žurnāls konstatē, ka identitāte tika pieņemta noteiktā intervālā, ar piešķirtu adresi saskaņā ar reģistrētu politiku, un tas nevar konstatēt, kuru lapu kāds lasīja, jo tas nekad nav redzējis pieprasījumu.
Nosauciet novērojumu pirms vākšanas projektēšanas. Lauks, kas nosaukts apmeklētās vietnes vārdā, bet patiesībā glabā atrisinātu nosaukumu, ir nākotnes kļūda, nevis ērtība. Lauku nosaukumi dzīvo ilgāk par cilvēkiem, kuri tos izvēlējās, tāpēc izvēlieties tādus, kas apraksta pierādījumu, nevis secinājumu.
Ko katrs ieraksts var un ko nevar pamatot
Gandrīz katrā audita projektā parādās četri ierakstu veidi, un katrs atbild uz citu jautājumu. Turiet tos atsevišķi gan ziņojumā, gan apstrādes plūsmā, jo to sajaukšana ir tas, kas aizstāvamu atradumu padara apkaunojošu.
| 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 |
Lasiet pēdējo kolonnu tikpat rūpīgi kā vidējo. Plūsmas ieraksts apraksta adreses un portus, un adreses apgrieztā meklēšana neatjauno nosaukumu, ko izmantoja pārlūks, jo viena adrese var mitināt daudzas nesaistītas vietnes. Risinātāja vaicājums pierāda, ka jautājums tika uzdots, nevis ka lapa tika parādīta. Arī TLS sarunu laikā redzamais resursdatora nosaukums nav šifrētais pieprasījuma ceļš.
Katrs no tiem ir īsts novērojums, un neviens nav tas novērojums, ko cilvēki pieņem. Pārlūks, kas uzstāj uz savu šifrēto risinātāju, atrodas ārpus uzraudzītās jomas, un analīze nevar atgūt to, ko žurnāls nekad nav redzējis. Šī plaisa pieder ziņojumam kā norādīta robeža, nevis kā zemsvītras piezīme.
Iepriekšēji vaicājumi un kešatmiņā saglabātas atbildes
Pārlūki atrisina nosaukumus iepriekš, dažkārt neko neielādējot. Tie arī atbild no kešatmiņas, nesūtot jaunu vaicājumu uz risinātāju, kuru jūs uzraugāt, kas nozīmē, ka vaicājuma neesamība nav apmeklējuma neesamība. Abas uzvedības salauž naivo vienādojumu starp DNS žurnālu un pārlūkošanas vēsturi.
DNS virs HTTPS pievieno otru robežu: pārlūks vai viesu programma ar savu risinātāju nekad neko nejautā organizācijas reģistrētājam. Precīzas transakcijas nāk tikai no pašas programmas notikumiem vai no starpniekservera, kura žurnālēšanu jūs skaidri atbalstāt. Vienkāršs HTTPS CONNECT tunelis atstāj starpniekserveri bez jebkāda skata uz iekšpusē esošajiem lapu ceļiem. Tīkla piederība nav atļauja klusi nomainīt programmas uzticēšanās modeli.
Adrese pieder sesijai, nevis personai
Plūsmas ieraksts ar adresi no tuneļa diapazona ir sākumpunkts, nevis atbilde. Savienojiet šo adresi un laika atzīmi ar tajā brīdī aktīvo sesijas piešķīrumu, jo šo adresi stundu vēlāk var piešķirt citai sesijai. Statiskā adresācija ir viens veids, kā saglabāt šo saikni, un ne vienīgais.
Kur tulkošanas solis saspiež vairākas ierīces vienā avota adresē virs sensora, savienošana var nosaukt tikai kopīgo vārtejas sesiju. Kopīgs konts vai vairāku cilvēku izmantots sertifikāts ierobežo attiecināšanu, lai cik pilnīgi izskatītos tīkla dati. Abi pieder ziņojumam kā robežas, nevis kā vēlāki nosacījumi.
Ierakstiet laika joslu, pulksteņa avotu, novērojuma punktu un katru tulkošanas robežu starp tiem. Neesamība ir pelnījusi tādu pašu rūpību kā klātbūtne, jo trūkstošs ieraksts var nozīmēt, ka plūsmas ieraksts ir beidzies, sensors nekad nav redzējis paketi vai programmas žurnāls bija izslēgts.
Projektējiet deklarētajam mērķim, tad pierādiet plūsmu
Kad jautājums ir fiksēts, definējiet, kuri lauki ir nepieciešami, kas tos drīkst lasīt un cik ilgi tie tiek glabāti. Vākt vairāk tāpēc, ka glabāšana ir lēta, rada atbildību, kas pārdzīvo izmeklēšanu. RFC 6973 privātuma modelis korelāciju, nepareizu attiecināšanu un nevajadzīgu vākšanu uzskata par projektēšanas problēmām, nevis vēlākām pārdomām.
Aizsargājiet kartējumu un ierakstus kā vienu objektu, jo katrs atsevišķi ir daudz mazāk jutīgs nekā pāris. Pēc tam validējiet projektu pret darbību, kuru jums ir atļauts ģenerēt un kuru jau saprotat, izmantojot mazāko vaicājumu, uz kuru ziņojums balstīsies. Plūsma, kas nespēj atveidot zināmu notikumu, neatveidos arī nezināmu. Ziņojiet par notikumu, ko atbalsta pierādījumi, ar vārdiem, ko pierādījumi pieļauj, un ļaujiet lasītājam pašam nonākt pie lielāka secinājuma.
Rakstiet robežas blakus atradumam: kas tika savienots, kas tulkots un kurš žurnāls klusēja. Atradums, kas norāda savas robežas, pārdzīvo pārbaudi, ko pārliecināts kopsavilkums nepārdzīvo. Tā ir atšķirība starp pierādījumu un stāstu par pierādījumu.