Läs din VPN-logg innan du skickar den: fält för fält

Du öppnar ett supportärende, bifogar diagnostiksexporten som klienten skapade och väntar. Filen innehåller förmodligen ingen webbläsarhistorik alls, och det är just det som får den att kännas säker. Den innehåller ändå vem du är, vilken maskin du använde, vilka interna adresser du nådde och när, och ibland en privat nyckel kopierad av en klient som loggar sin konfiguration. Att gå igenom filen innan du skickar den tar ungefär fem minuter och förhindrar ett permanent avslöjande.

Öppna den och läs de första fyrtio raderna

Börja högst upp, där klienter vanligtvis dumpar version, plattform och konfiguration. De första raderna berättar hur ordrik filen är, och det avgör hur mycket av resten du behöver bry dig om. En standardlogg och en felsökningslogg är olika artefakter med olika exponering.

head -n 40 vpn-support.log
sed -n '1,40p' vpn-support.log | grep -nE 'version|platform|config|option'

Kontrollera också filens storlek och form innan du läser något av den. En textfil på två megabyte med en upprepad händelse är lätt att korta av. En binär inspelning i samma mapp är ett helt annat problem, och det kräver ett annat samtal med den som bad om exporten.

I Windows är motsvarigheterna en cmdlet var, och den första är värd att köra på vilken fil som helst som du inte har skapat själv:

Get-Content .\vpn-support.txt -TotalCount 40
Get-Item .\vpn-support.txt | Select-Object Length,LastWriteTime

Fälten som identifierar en person

Användarnamn dyker upp på platser folk inte förväntar sig: kontot som används för autentisering, certifikatets subjekt, profilsökvägen under en hemkatalog och maskinnamnet som ofta kodar ett riktigt namn. En logg som redigerar kontofältet men lämnar hemsökvägen intakt har inte redigerat något.

Konsekvens är viktigare än fullständighet när en supporttekniker ska följa en session genom filen. Ersätt värden med stabila etiketter i stället för att ta bort dem, så att varje förekomst av samma användare fortfarande läses som samma användare. Att ta bort fältet helt bryter tråden teknikern behöver och gör inte filen säkrare.

En tidsstämpel är också personuppgifter i sin helhet. Tiderna då ett konto anslöt, tagna över en månad, beskriver arbetstider och resor. Om frågan inte behöver hela intervallet, klipp filen till fönstret runt händelsen.

Fälten som identifierar ett nätverk

Ändpunktsadresser, interna rutter och pushade alternativ beskriver formen av ett privat nätverk. Det är precis den information en angripare skulle vilja ha, och den finns vanligtvis med mycket mer detalj än ärendet behöver.

Leta efter adressfamiljen som används, inte bara den du förväntade dig. En dual-stack-klient kan logga en IPv6-ändpunkt och en uppsättning IPv6-rutter som ingen kom på att redigera, eftersom granskningen bara letade efter punktade fyrtal.

grep -nEo '([0-9]{1,3}\.){3}[0-9]{1,3}' vpn-support.log | sort -u | head -n 40
grep -nEo '([0-9a-fA-F]{0,4}:){2,7}[0-9a-fA-F]{0,4}' vpn-support.log | sort -u | head -n 20

Den unika listan är poängen. Den berättar hur många olika adresser filen nämner, och det är vanligtvis långt färre än det känns när man bläddrar. Den ger dig också en checklista att redigera efter och ett sätt att bevisa att du täckte dem alla. Tio adresser är ett arbete på fem minuter, och hundra säger att exporten är bredare än frågan.

Behåll topologin om teknikern behöver den. Att ersätta andra och tredje oktetten medan subnätrelationerna bevaras svarar på frågan utan att publicera intervallet. Samma trick fungerar för IPv6-prefix. Det teknikern behöver är felets form, och formen överlever en konsekvent ersättning.

Hemligheter gömmer sig i former, inte i etiketter

En privat nyckel behöver inte ordet “password” i närheten. Den visas som ett block mellan markörrader, som en lång base64-sträng eller som en inbäddad konfigurationsdump. Tokens visas som frågeparametrar, och inloggningsuppgifter visas i URL:er som en klient loggade ordagrant.

grep -nE 'BEGIN [A-Z ]*PRIVATE KEY|password|passwd|token|secret|psk|auth-user-pass' vpn-support.log
grep -nE 'https?://[^ ]*:[^ ]*@' vpn-support.log

Det andra mönstret är det folk glömmer. En URL av formen schema, användare, lösenord, värd är en fullständig inloggningsuppgift, och klienter loggar sådana URL:er varje gång en proxy eller ett flöde konfigureras med inbäddad autentisering.

Skicka aldrig originalfilen som bevis på att du inte har redigerat den. Om en operatör insisterar på en oförändrad export, fråga vad de behöver den till, skicka den via deras verifierade supportkanal och radera sedan din lokala kopia. Den begäran är legitim; en offentlig inklistring är det inte.

Bygg den redigerade kopian och skicka utdraget

Arbeta på en kopia, förvara originalet på en skyddad plats och redigera med ett kommando som kan upprepas i stället för för hand. En genomgång av adressmönstren fångar det mesta av det:

cp vpn-support.log vpn-support.original.log
sed -E 's/([0-9]{1,3}\.){3}[0-9]{1,3}/ADDR/g; s/[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+/USER@DOMAIN/g' \
  vpn-support.original.log > vpn-support.redacted.log
grep -cE 'PRIVATE KEY|password|token' vpn-support.redacted.log

Det slutliga antalet ska vara noll. Om det inte är det har redigeringsgenomgången missat en form, och du bör titta på de raderna innan du skickar något. Läs också den redigerade filen en gång med egna ögon; ett skript fångar mönster, inte sammanhang.

Skicka det minsta utdraget som fortfarande visar felet. Tio rader runt felet är vanligtvis nog, och de är mycket lättare att granska än en fil på två megabyte. Förvara sedan mappningen mellan dina etiketter och de verkliga värdena på en plats du kontrollerar, eftersom uppföljningsfrågan kommer att behöva den.

OpenVPN-dokumentationen om loggning beskriver hur detaljnivåer ändrar vad som registreras, vilket är en användbar kontext för att avgöra hur mycket av filen problemet faktiskt kräver.