Hvad en VPN-log kan og ikke kan bevise om browsing
Sessions-, resolver-, flow- og applikationsposter beviser forskellige hændelser. Vælg revisionsspørgsmålet og identitetssammenkoblingen, før du kalder det browserhistorik.
Før du vælger en logopsamler, skal du afgøre, hvilken hændelse revisionen skal fastslå. At spørge, hvilken VPN-session der kontaktede en destinationsadresse, er et andet spørgsmål end at spørge, hvilken person der åbnede en bestemt side. De to kræver forskellige poster, forskellige sammenkoblinger og forskellige niveauer af tillid. En forbindelseslog fra OpenVPN besvarer det første og kan ikke besvare det andet.
Navngiv hændelsen, før du vælger en opsamler
En sessionspost viser en accepteret identitet, et start- og sluttidspunkt og en adresse, som serveren tildelte efter sin egen politik. En resolverlog viser, at et navn blev forespurgt hos den resolver. En flowpost viser adresser, porte, protokol og tid, og en applikationslog viser den transaktion, som applikationen faktisk håndterede. Ingen af de fire erstatter en anden.
Hver af dem fastslår én hændelse og lader de andre stå åbne. At skrive spørgsmålet ned først forhindrer dig i at sammensætte en historie, som dataene ikke kan understøtte.
journalctl -u [email protected] --since today | grep -i 'peer info\|assigned' cat /etc/openvpn/server/openvpn-status.log | head -20 conntrack -L -p tcp --dport 443 2>/dev/null | head -20
Den første kommando viser sessionshændelser fra tjenesteloggen. Den anden udskriver den aktuelle klientliste med tildelte adresser, som er den mapping, en revisionssammenkobling afhænger af. Den tredje viser levende flowtilstand, kun nyttig så længe forbindelsen findes.
Et opslag er ikke et besøg
En browser opløser navne spekulativt, cacher svar og genbruger dem uden at spørge den overvågede resolver igen. Et navn i en resolverlog beviser derfor et opslag, ikke et besøg. DNS over HTTPS udvider det hul, fordi en browser, der er konfigureret til det, sender sine spørgsmål et sted, hvor din almindelige logger aldrig ser dem.
Destinationsadresser er ikke bedre i sig selv. En adresse kan være vært for mange ubeslægtede websteder, omvendt DNS er et gæt og ikke en rekonstruktion, og et værtsnavn, der er synligt under et TLS-håndtryk, er ikke anmodningsstien inde i den krypterede session.
Til præcise transaktioner har du brug for applikationens egne hændelsesposter eller et proxydesign, der eksplicit understøttes til logning. En CONNECT-tunnel giver en proxy destinationen og volumen, ikke sidestierne indeni. Administrativ adgang til netværket er ikke en licens til stille at erstatte applikationens tillidsmodel.
Sammenkobl identitet og tid, før du navngiver en person
En flowpost med en intern kildeadresse betyder intet, før adressen er sammenkoblet med en session på samme tid. Adresser genbruges, og den samme adresse kan have tilhørt en anden session en time tidligere. Statisk tildeling er en måde at holde forbindelsen på, ikke den eneste.
Oversættelsesgrænser svækker sammenkoblingen yderligere. Hvis flere enheder allerede delte én kildeadresse før dit observationspunkt, er det bedste, du kan identificere, den delte gateway-session og ikke en enkelt enhed. Et certifikat eller en konto, som flere personer bruger, har samme effekt.
Registrér tidszoner, urkilder, observationspunkter og hvert oversættelsesspring. Manglende poster kan betyde, at en flowpost er udløbet, at en sensor blev omgået, eller at en applikationslog var slukket. Fravær er ikke bevis for, at intet skete.
Definér derefter de minimale felter, de tilladte læsere og opbevaringsperioden for det angivne formål. Korrelation og fejlagtig tilskrivning er designspørgsmål og ikke en eftertanke, og metadata, der identificerer personer, fortjener samme beskyttelse som den identitetsmapping, de afhænger af.
Test revisionen med aktivitet, du kontrollerer
Generér tilladt trafik, hvis session og applikation du allerede kender, og kontrollér derefter, hvad hver post faktisk fangede. Udfør et opslag uden at indlæse siden, indlæs en side fra cachen, og åbn en forbindelse gennem en proxy, og se, hvilke hændelser der vises.
Rapportér den hændelse, som beviserne understøtter, og sig, hvad de ikke dækker. En beskeden post med et angivet omfang overlever en gennemgang; en ambitiøs browserhistorik sammensat af gæt gør ikke.