Прочитајте го вашиот 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 за логирање опишува како нивоата на деталност менуваат што се запишува, што е корисен контекст за одлучување колку од датотеката проблемот навистина бара.