사라지는 것부터 모은다

한 줄 요약

증거는 사라지는 속도가 빠른 것부터 모은다. 모으는 차례와 모으지 않기로 한 선을 문서가 아니라 코드로 굳혀야 다음 사람이 같은 것을 다시 할 수 있다.

왜 이게 필요했나

장애 현장에 들어가면 손이 먼저 로그 파일로 간다. 로그는 눈에 보이고, 열면 바로 읽히고, 복사하기 쉽다. 그런데 로그를 내려받는 10분 동안 프로세스 목록이 바뀌고, 열려 있던 연결이 닫히고, 커널 통계가 갱신되고, 임시 파일이 지워진다. 로그는 내일도 그 자리에 있지만 그것들은 지금뿐이다.

그 10분의 차이가 나중에 결론을 가른다. "그때 그 프로세스가 떠 있었나요" 라는 질문에 답할 수 없으면 가설 하나를 배제하지 못하고, 배제하지 못한 가설은 조사 범위를 넓힌 채로 남는다.

어떻게 동작하나

이 문제는 오래전에 정리됐다. [RFC 3227 "Guidelines for Evidence Collection and Archiving"](https://www.rfc-editor.org/rfc/rfc3227.html) 의 2.1 절은 "휘발성이 높은 것에서 낮은 것으로 나아가라" 고 적고, 전형적인 시스템의 예시 차례를 일곱 묶음으로 준다.

1  레지스터, 캐시2  라우팅 테이블, ARP 캐시, 프로세스 표, 커널 통계, 메모리3  임시 파일 시스템4  디스크5  그 시스템과 관련된 원격 로깅·모니터링 자료6  물리 구성, 네트워크 토폴로지7  보관 매체

이 차례가 주는 것은 우선순위만이 아니다. 판단의 근거를 준다. 왜 프로세스 목록을 먼저 떴느냐는 질문에 "감" 이 아니라 "2번 묶음이고 디스크는 4번" 이라고 답할 수 있다. 그래서 수집 계획은 항목마다 등급을 적은 파일로 만들어 두고, 수집기는 그 파일의 차례를 정렬하지 않고 그대로 따른다. 정렬하는 순간 판단이 코드 안으로 숨는다.

같은 RFC 의 2.2 절은 피해야 할 것도 적는다. 시스템을 재시작하거나 종료하지 말 것, 증거가 될 프로그램을 신뢰하지 말 것, 자료를 바꾸는 도구를 쓰지 말 것 같은 것들이다.

모았다는 것을 어떻게 증명하나

모으는 것만으로는 부족하다. 몇 주 뒤에 "이 파일이 그날 그 서버에서 나온 것이 맞느냐" 는 질문이 온다. 그래서 수집물마다 세 가지를 함께 적는다.

• 언제 — 수집 시각. 항목마다 따로 적는다. 묶음 전체의 시각 하나로는 차례를 증명하지 못한다.
• 누가 — 수집자. 나중에 물어볼 사람이 있어야 한다.
• 무엇으로 — 실제로 실행한 명령. "로그를 받았다" 가 아니라 그 명령이다.

그 위에 내용 지문을 얹는다. 파일마다 sha256 을 계산해 매니페스트에 적으면, 나중에 같은 계산을 다시 해서 한 글자라도 바뀌었는지 알 수 있다. 여기서 한 걸음 더 나가야 하는 이유가 있다 — 파일 해시를 매니페스트에 적어 두기만 하면, 매니페스트를 고쳐 버리면 그만이다. 그래서 매니페스트 자체의 해시를 따로 파일로 남긴다. 이것이 봉인이다.

봉인은 위조를 막지 못한다. 매니페스트와 봉인 파일을 둘 다 고칠 수 있는 사람은 얼마든지 있다. 봉인이 막는 것은 모르는 사이에 바뀌는 것이다 — 누가 편집기로 열어 저장했거나, 복사 중에 잘렸거나, 압축이 깨진 것. 실제로 이런 사고가 악의적 위조보다 훨씬 자주 난다.

현장에서 만나는 모습

첫째, 다 모으려 들면 고객 자료를 통째로 들고 나오게 된다. 결제 서버의 운영 데이터베이스에는 이름·이메일·전화번호가 들어 있다. 그것을 덤프해서 노트북에 넣는 순간, 우리는 조사하는 사람이 아니라 새로운 위험이 된다. 그래서 수집 계획에는 모으지 않기로 한 항목과 그 이유도 같은 파일에 적는다.

중요한 것은 조용히 빼는 것이 아니라 뺐다는 사실을 기록에 남기는 것이다. 매니페스트에 "이 항목은 제외했고 이유는 이것" 이라고 남아 있으면, 나중에 그 자료가 필요해졌을 때 무엇을 요청해야 하는지 곧바로 알 수 있다. 조용히 빼면 아무도 그것이 있었다는 것을 모른다.

둘째, 수집 명령이 자료를 바꾸는 경우가 있다. 로그 파일을 열어 편집기가 잠금 파일을 만들거나, 데이터베이스에 접속해 통계를 갱신하게 만드는 것들이다. 읽기 전용으로 여는 방법이 있으면 그것을 쓰고, 없으면 무엇을 바꿨는지 적어 둔다.

셋째, 시각은 표준 표기로 적는다. 서버 시간대와 우리 노트북의 시간대가 다르면 나중에 타임라인을 맞출 때 한 시간이 통째로 어긋난다. [RFC 3339](https://www.rfc-editor.org/rfc/rfc3339.html) 표기로 UTC 를 적고, 서버의 시간대 설정도 따로 수집 항목에 넣는다.

넷째, 검증기를 함께 남긴다. 봉인 값만 남기면 다음 사람이 손으로 해시를 계산해 비교해야 한다. 검증기를 함께 두면 한 줄로 끝나고, 무엇보다 무엇이 깨졌는지 이름을 대 준다. "봉인이 깨졌습니다" 만 나오는 검증기는 그 자리에 사람을 세워 둔다.

실무에서 진짜 중요한 것

• 사라지는 순서대로 모은다. 차례를 계획 파일에 적고 수집기는 그 차례를 그대로 따른다.
• 언제·누가·무엇으로를 항목마다 적는다. 묶음 하나에 한 번이 아니다.
• 매니페스트도 봉인한다. 파일 해시만으로는 매니페스트를 고치면 끝이다.
• 빼기로 한 것을 기록에 남긴다. 조용히 빼면 아무도 그것이 있었다는 것을 모른다.

다음 실습에서 할 것

(가상) 서진화학의 결제 서버 한 대를 손에 쥔다. 휘발성이 높은 것은 실습 파드의 /proc 에서 진짜로 읽고, 디스크에 남은 것들은 만들어 둔 자리에서 읽는다. RFC 3227 의 등급을 항목마다 매겨 수집 계획을 만들고, 그 차례대로 모으는 수집기를 만들고, 수집 시각과 수집자와 명령과 sha256 을 매니페스트에 적고, 매니페스트를 봉인한다. 그다음 봉인이 깨졌는지 검증하는 도구를 만든다 — 채점기는 여러분의 묶음에서 파일 하나를 몰래 고친 뒤 여러분의 검증기가 그 이름을 대는지 본다. 마지막으로 고객 개인정보가 든 항목에 선을 긋고, 뺐다는 사실이 기록에 남는지 확인한다.