Przeczytaj dziennik VPN, zanim go wyślesz: pole po polu

Otwierasz zgłoszenie do wsparcia, dołączasz eksport diagnostyczny utworzony przez klienta i czekasz. Plik prawdopodobnie nie zawiera żadnej historii przeglądania, i właśnie to sprawia, że wydaje się bezpieczny. Nadal zawiera informacje, kim jesteś, jakiej maszyny użyłeś, jakie adresy wewnętrzne i kiedy osiągnąłeś, a czasem klucz prywatny skopiowany przez klienta, który zapisuje swoją konfigurację. Przejrzenie pliku przed wysłaniem zajmuje około pięciu minut i zapobiega trwałemu ujawnieniu.

Otwórz go i przeczytaj pierwsze czterdzieści linii

Zacznij od góry, gdzie klienci zwykle wysypują wersję, platformę i konfigurację. Pierwsze linie mówią, jak szczegółowy jest plik, co określa, ile z reszty musisz brać pod uwagę. Dziennik domyślny i dziennik debugowania to różne artefakty o różnej ekspozycji.

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

Sprawdź też rozmiar i kształt pliku, zanim cokolwiek z niego przeczytasz. Dwumegabajtowy plik tekstowy z jednym powtarzającym się zdarzeniem łatwo przyciąć. Zapis binarny w tym samym folderze to zupełnie inny problem i wymaga innej rozmowy z osobą, która poprosiła o eksport.

W systemie Windows odpowiedniki to po jednym cmdlecie, a pierwszy warto uruchomić na każdym pliku, którego sam nie utworzyłeś:

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

Pola, które identyfikują osobę

Nazwy użytkowników pojawiają się w miejscach, których ludzie się nie spodziewają: konto używane do uwierzytelniania, podmiot certyfikatu, ścieżka profilu w katalogu domowym i nazwa maszyny, która często koduje prawdziwe imię. Dziennik, który redaguje pole konta i pozostawia ścieżkę domową nietkniętą, nie zredagował niczego.

Spójność jest ważniejsza niż kompletność, gdy inżynier wsparcia musi prześledzić jedną sesję przez plik. Zastąp wartości stabilnymi etykietami zamiast je usuwać, aby każde wystąpienie tego samego użytkownika nadal czytało się jako ten sam użytkownik. Usunięcie pola całkowicie przerywa wątek, którego inżynier potrzebuje, i nie czyni pliku bezpieczniejszym.

Znacznik czasu jest także danymi osobowymi w ujęciu zbiorczym. Godziny, w których konto się łączyło, wzięte z miesiąca, opisują godziny pracy i podróże. Jeśli pytanie nie wymaga całego zakresu, przytnij plik do okna wokół zdarzenia.

Pola, które identyfikują sieć

Adresy punktów końcowych, trasy wewnętrzne i wypychane opcje opisują kształt sieci prywatnej. To dokładnie informacja, którą chciałby mieć atakujący, i zwykle występuje znacznie bardziej szczegółowo, niż potrzebuje zgłoszenie.

Szukaj używanej rodziny adresów, nie tylko tej, której oczekiwałeś. Klient z podwójnym stosem może zapisać punkt końcowy IPv6 i zestaw tras IPv6, o których redagowaniu nikt nie pomyślał, ponieważ przegląd szukał tylko czwórek z kropkami.

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

Unikalna lista jest sednem. Mówi, ile różnych adresów wymienia plik, i zwykle jest ich znacznie mniej, niż się wydaje podczas przewijania. Daje też listę kontrolną do redagowania i sposób na udowodnienie, że objąłeś wszystkie. Dziesięć adresów to praca na pięć minut, a sto mówi, że eksport jest szerszy niż pytanie.

Zachowaj topologię, jeśli inżynier jej potrzebuje. Zastąpienie drugiego i trzeciego oktetu przy zachowaniu relacji podsieci odpowiada na pytanie bez publikowania zakresu. Ta sama sztuczka działa dla prefiksów IPv6. Inżynier potrzebuje kształtu awarii, a kształt przetrwa spójne podstawienie.

Sekrety ukrywają się w kształtach, nie w etykietach

Klucz prywatny nie potrzebuje w pobliżu słowa “password”. Pojawia się jako blok między liniami znaczników, jako długi ciąg base64 lub jako wbudowany zrzut konfiguracji. Tokeny pojawiają się jako parametry zapytania, a poświadczenia pojawiają się wewnątrz adresów URL, które klient zapisał dosłownie.

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

Drugi wzorzec to ten, o którym ludzie zapominają. Adres URL w postaci schemat, użytkownik, hasło, host to pełne poświadczenie, a klienci zapisują takie adresy za każdym razem, gdy serwer proxy lub kanał jest skonfigurowany z wbudowanym uwierzytelnianiem.

Nigdy nie wysyłaj oryginalnego pliku jako dowodu, że go nie edytowałeś. Jeśli operator nalega na niezmieniony eksport, zapytaj, do czego go potrzebuje, wyślij go jego zweryfikowanym kanałem wsparcia, a następnie usuń swoją lokalną kopię. Ta prośba jest uzasadniona; publiczne wklejenie nie.

Zbuduj zredagowaną kopię i wyślij fragment

Pracuj na kopii, przechowuj oryginał w chronionym miejscu i redaguj powtarzalnym poleceniem, a nie ręcznie. Jedno przejście po wzorcach adresów wychwytuje większość:

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

Ostateczna liczba powinna wynosić zero. Jeśli nie, przebieg redagowania pominął jakiś kształt i powinieneś spojrzeć na te linie przed wysłaniem czegokolwiek. Przeczytaj też zredagowany plik raz własnymi oczami; skrypt wychwytuje wzorce, nie kontekst.

Wyślij najmniejszy fragment, który nadal pokazuje awarię. Dziesięć linii wokół błędu zwykle wystarcza, i są one znacznie łatwiejsze do przejrzenia niż dwumegabajtowy plik. Potem przechowuj mapowanie między etykietami a rzeczywistymi wartościami w miejscu, które kontrolujesz, ponieważ kolejne pytanie będzie go potrzebować.

Dokumentacja OpenVPN dotycząca logowania opisuje, jak poziomy szczegółowości zmieniają to, co jest zapisywane, co jest przydatnym kontekstem do decyzji, ile pliku problem naprawdę wymaga.