Kva ein VPN-logg kan og ikkje kan prova om nettsurfing

Før du vel ein loggsamlar, må du avgjere kva hending revisjonen skal slå fast. Å spørje kva VPN-økt som kontakta ei måladresse er eit anna spørsmål enn å spørje kven person som opna ei bestemt side. Begge krev ulike postar, ulike samankoplingar og ulike nivå av tillit. Ein tilkoplingslogg frå OpenVPN svarar på det første og kan ikkje svare på det andre.

Namngje hendinga før du vel ein samlar

Ein øktpost viser ein godkjend identitet, eit start- og sluttidspunkt og ei adresse som tenaren tildelte etter si eiga policy. Ein resolverlogg viser at eit namn vart spurt hjå den resolveren. Ein flytpost viser adresser, portar, protokoll og tid, og ein applikasjonslogg viser transaksjonen som applikasjonen faktisk handsama. Ingen av dei fire erstattar ein annan.

Kvar av dei slår fast éi hending og lèt dei andre stå opne. Å skrive ned spørsmålet først hindrar deg i å setje saman ei historie som dataa ikkje 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 økthendingar frå tenesteloggen. Den andre skriv ut den gjeldande klientlista med tildelte adresser, som er mappinga ei revisjonssamankopling er avhengig av. Den tredje viser levande flyttilstand, berre nyttig så lenge tilkoplinga finst.

Eit oppslag er ikkje eit besøk

Ein nettlesar løyser namn spekulativt, bufrer svar og brukar dei om att utan å spørje den overvaka resolveren igjen. Eit namn i ein resolverlogg provar derfor eit oppslag, ikkje eit besøk. DNS over HTTPS vidar ut dette gapet, fordi ein nettlesar som er sett opp for det, sender spørsmåla sine dit din vanlege loggar aldri ser dei.

Måladresser er ikkje betre i seg sjølve. Éi adresse kan vere vert for mange uslekta nettstader, omvend DNS er ei gissing og ikkje ein rekonstruksjon, og eit vertsnamn som er synleg under eit TLS-handtrykk, er ikkje førespurnadsstien inne i den krypterte økta.

For nøyaktige transaksjonar treng du applikasjonen sine eigne hendingspostar eller eit proxy-design som er eksplisitt støtta for logging. Ein CONNECT-tunnel gjev ein proxy målet og volumet, ikkje sidestiene inni. Administrativ tilgang til nettverket er ikkje ein lisens til stille å erstatte tillitsmodellen til applikasjonen.

Kople identitet og tid før du namngjev ein person

Ein flytpost med ei intern kjeldadresse tyder ingenting før adressa er kopla til ei økt på same tid. Adresser vert brukte om att, og same adresse kan ha høyrt til ei anna økt ein time tidlegare. Statisk tildeling er éin måte å halde samankoplinga på, ikkje den einaste.

Omsetjingsgrenser svekkjer samankoplinga ytterlegare. Om fleire einingar allereie delte éi kjeldadresse før observasjonspunktet ditt, er det beste du kan identifisere den delte gateway-økta og ikkje éi eining. Eit sertifikat eller ein konto som fleire personar brukar, har same effekt.

Registrer tidssoner, klokkekjelder, observasjonspunkt og kvart omsetjingssteg. Manglande postar kan tyde på at ein flytpost er utlopen, at ein sensor vart omgått, eller at ein applikasjonslogg var slått av. Fråvær er ikkje prov på at ingenting skjedde.

Deretter definerer du minimumsfelta, dei tillatne lesarane og oppbevaringsperioden for det oppgjevne føremålet. Korrelasjon og feilattribusjon er designspørsmål og ikkje ein ettertanke, og metadata som identifiserer personar fortener same vern som identitetsmappinga dei er avhengige av.

Test revisjonen med aktivitet du kontrollerer

Generer tillaten trafikk der du allereie kjenner økta og applikasjonen, og kontroller deretter kva kvar post faktisk fanga. Gjer eit oppslag utan å laste sida, last ei side frå bufferen og opne ei tilkopling gjennom ein proxy, og sjå kva hendingar som dukkar opp.

Rapporter hendinga prova støttar, og sei kva dei ikkje dekkjer. Ein beskjeden post med eit oppgjeve omfang overlever gjennomgangen; ein ambisiøs nettlesarhistorikk sett saman av gissingar gjer det ikkje.