Hva en VPN-logg kan og ikke kan bevise om nettsurfing

Før du velger en loggsamler, må du avgjøre hvilken hendelse revisjonen skal fastslå. Å spørre hvilken VPN-økt som kontaktet en måladresse er et annet spørsmål enn å spørre hvilken person som åpnet en bestemt side. Begge krever ulike poster, ulike sammenkoblinger og ulike nivåer av tillit. En tilkoblingslogg fra OpenVPN svarer på det første og kan ikke svare på det andre.

Navngi hendelsen før du velger en samler

En øktpost viser en akseptert identitet, et start- og sluttidspunkt og en adresse som serveren tildelte etter sin egen policy. En resolverlogg viser at et navn ble spurt hos den resolveren. En flytpost viser adresser, porter, protokoll og tid, og en applikasjonslogg viser transaksjonen som applikasjonen faktisk håndterte. Ingen av de fire erstatter en annen.

Hver av dem fastslår én hendelse og lar de andre stå åpne. Å skrive ned spørsmålet først hindrer deg i å sette sammen en historie som dataene ikke kan stø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 kommandoen viser økthendelser fra tjenesteloggen. Den andre skriver ut den gjeldende klientlisten med tildelte adresser, som er mappingen en revisjonssammenkobling avhenger av. Den tredje viser levende flyttilstand, bare nyttig så lenge tilkoblingen finnes.

Et oppslag er ikke et besøk

En nettleser løser navn spekulativt, bufrer svar og gjenbruker dem uten å spørre den overvåkede resolveren igjen. Et navn i en resolverlogg beviser derfor et oppslag, ikke et besøk. DNS over HTTPS utvider dette gapet, fordi en nettleser som er konfigurert for det, sender spørsmålene sine dit din vanlige logger aldri ser dem.

Måladresser er ikke bedre i seg selv. Én adresse kan være vert for mange ubeslektede nettsteder, omvendt DNS er en gjetning og ikke en rekonstruksjon, og et vertsnavn som er synlig under en TLS-håndtrykk, er ikke forespørselsstien inne i den krypterte økten.

For nøyaktige transaksjoner trenger du applikasjonens egne hendelsesposter eller et proxy-design som eksplisitt støttes for logging. En CONNECT-tunnel gir en proxy målet og volumet, ikke sidestiene inni. Administrativ tilgang til nettverket er ikke en lisens til stille å erstatte applikasjonens tillitsmodell.

Koble identitet og tid før du navngir en person

En flytpost med en intern kildeadresse betyr ingenting før adressen er koblet til en økt på samme tid. Adresser gjenbrukes, og samme adresse kan ha tilhørt en annen økt en time tidligere. Statisk tildeling er én måte å holde sammenkoblingen på, ikke den eneste.

Oversettelsesgrenser svekker sammenkoblingen ytterligere. Hvis flere enheter allerede delte én kildeadresse før observasjonspunktet ditt, er det beste du kan identifisere den delte gateway-økten og ikke én enhet. Et sertifikat eller en konto som flere personer bruker, har samme effekt.

Registrer tidssoner, klokkekilder, observasjonspunkter og hvert oversettelsessteg. Manglende poster kan bety at en flytpost er utløpt, at en sensor ble omgått, eller at en applikasjonslogg var slått av. Fravær er ikke bevis for at ingenting skjedde.

Deretter definerer du minimumsfeltene, de tillatte leserne og oppbevaringsperioden for det angitte formålet. Korrelasjon og feilattribusjon er designspørsmål og ikke en ettertanke, og metadata som identifiserer personer fortjener samme beskyttelse som identitetsmappingen de avhenger av.

Test revisjonen med aktivitet du kontrollerer

Generer tillatt trafikk der du allerede kjenner økten og applikasjonen, og kontroller deretter hva hver post faktisk fanget. Gjør et oppslag uten å laste siden, last en side fra bufferen og åpne en tilkobling gjennom en proxy, og se hvilke hendelser som dukker opp.

Rapporter hendelsen bevisene støtter, og si hva de ikke dekker. En beskjeden post med et angitt omfang overlever gjennomgangen; en ambisiøs nettleserhistorikk satt sammen av gjetninger gjør det ikke.