Прочетете журнала на VPN, преди да го изпратите: поле по поле

Отваряте заявка за поддръжка, прикачвате диагностичния експорт, който клиентът е създал, и чакате. Файлът вероятно не съдържа никаква история на сърфирането, и точно това го прави да изглежда безопасен. Той все пак съдържа кой сте, коя машина сте използвали, кои вътрешни адреси сте достигнали и кога, а понякога и частен ключ, копиран от клиент, който записва конфигурацията си. Преглеждането на файла, преди да го изпратите, отнема около пет минути и предотвратява трайно разкриване.

Отворете го и прочетете първите четиридесет реда

Започнете отгоре, където клиентите обикновено изсипват версия, платформа и конфигурация. Първите редове ви казват колко подробен е файлът, което определя колко от останалото трябва да ви интересува. Стандартният журнал и журналът за отстраняване на грешки са различни артефакти с различно излагане.

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

Проверете също размера и формата на файла, преди да прочетете каквото и да е от него. Текстов файл от два мегабайта с едно повтарящо се събитие е лесен за подрязване. Двоичен запис в същата папка е съвсем друг проблем и изисква различен разговор с този, който е поискал експорта.

В Windows еквивалентите са по една cmdlet, и първата си струва да се изпълни върху всеки файл, който не сте създали сами:

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

Полетата, които идентифицират човек

Потребителските имена се появяват на места, които хората не очакват: акаунтът, използван за удостоверяване, субектът на сертификата, пътят на профила в домашната папка и името на машината, което често кодира истинско име. Журнал, който редактира полето на акаунта и оставя пътя до дома непокътнат, не е редактирал нищо.

Последователността е по-важна от пълнотата, когато инженер по поддръжката трябва да проследи една сесия през файла. Заменяйте стойностите със стабилни етикети, вместо да ги изтривате, така че всяко появяване на един и същ потребител да се чете като същия потребител. Пълното изтриване на полето прекъсва нишката, която инженерът трябва, и не прави файла по-безопасен.

Времевата марка също е лични данни в съвкупност. Часовете, в които акаунт се е свързвал, взети за един месец, описват работно време и пътуване. Ако въпросът не се нуждае от целия диапазон, отрежете файла до прозореца около събитието.

Полетата, които идентифицират мрежа

Адресите на крайни точки, вътрешните маршрути и изтласканите опции описват формата на частна мрежа. Точно тази информация би искал нападател и тя обикновено присъства с много повече подробности, отколкото заявката изисква.

Търсете семейството адреси в употреба, не само това, което сте очаквали. Клиент с двоен стек може да запише крайна точка IPv6 и набор от маршрути IPv6, които никой не се е сетил да редактира, защото прегледът е търсил само точкови четворки.

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

Уникалният списък е смисълът. Той ви казва колко различни адреса споменава файлът, което обикновено е много по-малко, отколкото изглежда, докато превъртате. Той също ви дава контролен списък за редактиране и начин да докажете, че сте покрили всички. Десет адреса са работа за пет минути, а сто ви казват, че експортът е по-широк от въпроса.

Запазете топологията, ако на инженера му е нужна. Замяната на втория и третия октет при запазване на подсътните връзки отговаря на въпроса, без да публикува диапазона. Същият трик работи за префикси IPv6. Това, от което инженерът се нуждае, е формата на повредата, и формата оцелява при последователна замяна.

Тайните се крият във форми, не в етикети

Частният ключ не се нуждае от думата “password” наблизо. Той се появява като блок между маркерни редове, като дълъг низ base64 или като вграден дъмп на конфигурация. Токените се появяват като параметри на заявка, а идентификационните данни — вътре в URL адреси, които клиентът е записал дословно.

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

Вторият модел е този, който хората забравят. URL от вида схема, потребител, парола, хост е пълно удостоверение и клиентите записват такива URL адреси винаги, когато прокси или канал е настроен с вградено удостоверяване.

Никога не изпращайте оригиналния файл като доказателство, че не сте го редактирали. Ако оператор настоява за непроменен експорт, попитайте за какво му е нужен, изпратете го през проверения им канал за поддръжка и след това изтрийте местното си копие. Тази молба е законна; публичното поставяне не е.

Създайте редактираното копие и изпратете откъса

Работете върху копие, пазете оригинала на защитено място и редактирайте с повтаряща се команда, а не на ръка. Един преход по моделите на адресите улавя голяма част от него:

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

Крайният брой трябва да е нула. Ако не е, преходът на редактиране е пропуснал форма и трябва да погледнете тези редове, преди да изпратите каквото и да е. Прочетете редактирания файл веднъж и със собствените си очи; скриптът улавя модели, не контекст.

Изпратете най-малкия откъс, който все още показва повредата. Десет реда около грешката обикновено са достатъчни и се преглеждат много по-лесно от файл от два мегабайта. След това пазете съответствието между вашите етикети и реалните стойности на място, което контролирате, защото последващият въпрос ще се нуждае от него.

Документацията на OpenVPN за журналиране описва как нивата на подробност променят това, което се записва, което е полезен контекст за решаване колко от файла проблемът всъщност изисква.