Innan du väljer en loggsamlare måste du avgöra vilken händelse revisionen ska fastställa. Att fråga vilken VPN-session som kontaktade en måladress är en annan fråga än att fråga vilken person som öppnade en viss sida. Båda kräver olika poster, olika sammankopplingar och olika nivåer av tillit. En anslutningslogg från OpenVPN svarar på det första och kan inte svara på det andra.

Namnge händelsen innan du väljer en samlare

En sessionspost visar en accepterad identitet, en start- och sluttid och en adress som servern tilldelade enligt sin egen policy. En resolverlogg visar att ett namn efterfrågades hos den resolvern. En flödespost visar adresser, portar, protokoll och tid, och en applikationslogg visar den transaktion som applikationen faktiskt hanterade. Ingen av de fyra ersätter en annan.

Var och en av dem fastställer en händelse och lämnar de andra öppna. Att skriva ned frågan först hindrar dig från att sätta ihop en berättelse som uppgifterna inte kan stödja.

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

Det första kommandot visar sessionshändelser från tjänsteloggen. Det andra skriver ut den aktuella klientlistan med tilldelade adresser, vilket är den mappning som en revisionssammankoppling beror på. Det tredje visar levande flödestillstånd, användbart bara så länge anslutningen finns.

En sökning är inte ett besök

En webbläsare löser namn spekulativt, cachar svar och återanvänder dem utan att fråga den övervakade resolvern igen. Ett namn i en resolverlogg bevisar därför en sökning, inte ett besök. DNS över HTTPS vidgar den luckan, eftersom en webbläsare som är inställd för det skickar sina frågor dit din vanliga loggare aldrig ser dem.

Måladresser är inte bättre i sig själva. En adress kan vara värd för många orelaterade webbplatser, omvänd DNS är en gissning och inte en rekonstruktion, och ett värdnamn som syns under ett TLS-handslag är inte begärans väg inne i den krypterade sessionen.

För exakta transaktioner behöver du applikationens egna händelseposter eller en proxy-design som uttryckligen stöds för loggning. En CONNECT-tunnel ger en proxy målet och volymen, inte sidvägarna inuti. Administrativ åtkomst till nätverket är inte en licens att tyst ersätta applikationens förtroendemodell.

Koppla identitet och tid innan du namnger en person

En flödespost med en intern källadress betyder ingenting förrän adressen är kopplad till en session vid samma tidpunkt. Adresser återanvänds, och samma adress kan ha tillhört en annan session en timme tidigare. Statisk tilldelning är ett sätt att behålla kopplingen, inte det enda.

Översättningsgränser försvagar kopplingen ytterligare. Om flera enheter redan delade en källadress innan din observationspunkt, är det bästa du kan identifiera den delade gateway-sessionen och inte en enda enhet. Ett certifikat eller konto som flera personer använder har samma effekt.

Registrera tidszoner, klockkällor, observationspunkter och varje översättningssteg. Saknade poster kan betyda att en flödespost löpt ut, att en sensor kringgicks eller att en applikationslogg var avstängd. Frånvaro är inte bevis för att ingenting hände.

Definiera sedan minimifälten, de tillåtna läsarna och lagringsperioden för det angivna syftet. Korrelation och felaktig tillskrivning är designfrågor och inte en eftertanke, och metadata som identifierar personer förtjänar samma skydd som identitetsmappningen de beror på.

Testa revisionen med aktivitet du kontrollerar

Generera tillåten trafik där du redan känner till sessionen och applikationen, och kontrollera sedan vad varje post faktiskt fångade. Gör en sökning utan att ladda sidan, ladda en sida från cachen och öppna en anslutning via en proxy, och se vilka händelser som dyker upp.

Rapportera händelsen som bevisen stöder och säg vad de inte täcker. En anspråkslös post med ett angivet omfång överlever granskningen; en ambitiös webbläsarhistorik sammansatt av gissningar gör det inte.

Relaterade artiklar