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