보내기 전에 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개인을 식별하는 항목
사용자 이름은 인증에 쓰는 계정, 인증서 주체, 홈 디렉터리 아래의 프로필 경로, 실제 이름을 부호화하는 경우가 많은 기기 이름 등 사람들이 예상하지 못한 곳에 나타납니다. 계정 항목만 지우고 홈 경로를 그대로 둔 로그는 아무것도 지우지 않은 것입니다.
| Field | What it identifies | Practical treatment |
|---|---|---|
| Account or username | A person, and often an employer | Replace consistently, keep the mapping |
| Certificate subject and CN | Device or user identity | Keep the structure, replace the value |
| Home directory path | A login name, sometimes a full name | Replace the segment, not the whole path |
| Machine or hostname | A person or a physical location | Replace with a stable pseudonym |
지원 엔지니어가 파일 전체에서 한 세션을 따라가야 할 때는 완전성보다 일관성이 더 중요합니다. 값을 삭제하는 대신 안정적인 라벨로 바꾸세요, 같은 사용자의 모든 출현이 여전히 같은 사용자로 읽히도록 말입니다. 항목을 완전히 삭제하면 엔지니어에게 필요한 실마리가 끊어지고 파일이 더 안전해지지도 않습니다.
타임스탬프도 종합하면 개인 데이터입니다. 한 계정이 접속한 시각을 한 달치 모으면 근무 시간과 이동을 드러냅니다. 질문이 전체 범위를 필요로 하지 않으면 파일을 사건 주변의 기간으로 잘라내세요.
네트워크를 식별하는 항목
엔드포인트 주소, 내부 경로, 밀어 넣은 옵션은 사설 네트워크의 형태를 설명합니다. 공격자가 갖고 싶어 할 바로 그 정보이며, 보통 티켓이 필요한 것보다 훨씬 자세히 들어 있습니다.
사용 중인 주소 체계를, 예상한 것만이 아니라 찾으세요. 듀얼 스택 클라이언트는 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 로깅 문서는 상세도 수준이 기록되는 내용을 어떻게 바꾸는지 설명하며, 문제가 파일의 어느 정도를 실제로 요구하는지 판단하는 데 유용한 맥락입니다.