Прочитайте журнал 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 по журналированию описывает, как уровни подробности меняют то, что записывается, и это полезный контекст для решения, сколько файла проблема действительно требует.