Cosa può e non può dimostrare un registro VPN sulla navigazione

Prima di scegliere un raccoglitore di registri, decidete quale evento l'audit deve stabilire. Chiedere quale sessione VPN ha contattato un indirizzo di destinazione è una domanda diversa dal chiedere quale persona ha aperto una pagina specifica. Entrambe richiedono registri diversi, giunzioni diverse e livelli di fiducia diversi. Un registro di connessione OpenVPN risponde alla prima e non può rispondere alla seconda.

Nominate l'evento prima di scegliere un raccoglitore

Un registro di sessione mostra un'identità accettata, un orario di inizio e di fine e un indirizzo che il server ha assegnato secondo la propria politica. Il registro di un resolver mostra che un nome è stato interrogato presso quel resolver. Un registro di flusso mostra indirizzi, porte, protocollo e orario, e un registro applicativo mostra la transazione che quell'applicazione ha effettivamente gestito. Nessuno dei quattro sostituisce un altro.

Ognuno di essi stabilisce un evento e lascia aperti gli altri. Scrivere prima la domanda vi impedisce di montare una storia che i dati non possono sostenere.

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

Il primo comando mostra gli eventi di sessione dal giornale del servizio. Il secondo stampa l'elenco attuale dei client con gli indirizzi assegnati, che è la mappatura da cui dipende una giunzione di audit. Il terzo mostra lo stato di flusso in tempo reale, utile solo finché la connessione esiste.

Una ricerca non è una visita

Un browser risolve i nomi in modo speculativo, memorizza le risposte nella cache e le riutilizza senza interrogare di nuovo il resolver monitorato. Un nome nel registro di un resolver dimostra quindi una ricerca, non una visita. DNS su HTTPS allarga questo divario, perché un browser configurato per farlo invia le sue domande dove il vostro registratore abituale non le vede mai.

Gli indirizzi di destinazione non sono migliori da soli. Un indirizzo può ospitare molti siti non correlati, il DNS inverso è una congettura e non una ricostruzione, e un nome host visibile durante un handshake TLS non è il percorso della richiesta dentro la sessione cifrata.

Per transazioni esatte servono i registri degli eventi dell'applicazione stessa o una progettazione proxy supportata esplicitamente per la registrazione. Un tunnel CONNECT dà al proxy la destinazione e il volume, non i percorsi delle pagine al suo interno. L'accesso amministrativo alla rete non è una licenza per sostituire in silenzio il modello di fiducia dell'applicazione.

Unite identità e tempo prima di nominare una persona

Un registro di flusso con un indirizzo sorgente interno non significa nulla finché quell'indirizzo non è unito a una sessione nello stesso momento. Gli indirizzi vengono riutilizzati, e lo stesso indirizzo può essere appartenuto a una sessione diversa un'ora prima. L'assegnazione statica è un modo per mantenere l'associazione, non l'unico.

I confini di traduzione indeboliscono ulteriormente la giunzione. Se più dispositivi condividevano già un indirizzo sorgente prima del vostro punto di osservazione, il meglio che potete identificare è la sessione del gateway condiviso e non un singolo dispositivo. Un certificato o un account usati da più persone hanno lo stesso effetto.

Registrate i fusi orari, le sorgenti di orologio, i punti di osservazione e ogni salto di traduzione. I registri mancanti possono significare che una voce di flusso è scaduta, che un sensore è stato aggirato o che un registro applicativo era spento. L'assenza non è prova che non sia successo nulla.

Poi definite i campi minimi, i lettori consentiti e il periodo di conservazione per lo scopo dichiarato. La correlazione e l'attribuzione errata sono questioni di progettazione e non un pensiero successivo, e i metadati che identificano le persone meritano la stessa protezione della mappatura d'identità da cui dipendono.

Provate l'audit con attività che controllate

Generate traffico consentito di cui conoscete già sessione e applicazione, poi verificate cosa ha effettivamente catturato ogni registro. Fate una ricerca senza caricare la pagina, caricate una pagina dalla cache e aprite una connessione attraverso un proxy, e osservate quali eventi compaiono.

Riferite l'evento che le prove sostengono e dite cosa non copre. Un registro modesto con un ambito dichiarato supera la revisione; una cronologia di navigazione ambiziosa messa insieme con congetture no.