Collect in order of volatility, then seal it

한국어 원문으로 표시합니다.

목표

RFC 3227 의 휘발성 차례대로 증거를 모으는 계획을 파일로 굳히고, 그 차례를 그대로 따르는 수집기를 만든다. 수집 시각·수집자·명령·sha256 을 매니페스트에 적고 매니페스트를 봉인한 뒤, 봉인이 깨졌는지 검증하는 도구를 만들고, 고객 개인정보가 든 항목에 선을 긋는다.

왜 중요한가

현장에 들어가면 손이 먼저 로그로 간다. 로그를 내려받는 10분 동안 프로세스 목록이 바뀌고 연결이 닫히고 임시 파일이 지워진다. 로그는 내일도 그 자리에 있지만 그것들은 지금뿐이고, 사라진 뒤에는 "그때 그 프로세스가 떠 있었나요" 라는 질문에 답할 수 없다. RFC 3227 의 2.1 절은 휘발성이 높은 것에서 낮은 것으로 나아가라고 적고 일곱 묶음의 예시 차례를 준다. 이 차례가 주는 것은 우선순위만이 아니라 판단의 근거다 — 왜 그것을 먼저 떴느냐는 질문에 감이 아니라 등급으로 답할 수 있다. 모으는 것만으로는 부족하다. 몇 주 뒤에 "이 파일이 그날 그 서버에서 나온 것이 맞느냐" 는 질문이 온다. 항목마다 언제·누가·무엇으로 모았는지와 내용 지문을 적고, 매니페스트 자체도 봉인한다. 파일 해시만 적어 두면 매니페스트를 고쳐 버리면 그만이기 때문이다. 반대로 다 모으려 들면 고객 개인정보를 통째로 들고 나오게 된다. 선을 긋되 조용히 빼지 말고, 뺐다는 사실과 이유를 기록에 남긴다. 채점기는 여러분이 적어 낸 문구를 믿지 않는다. 자기 계획과 자기 범위 파일로 여러분의 수집기를 실제로 돌려 차례와 시각과 해시를 대조하고, 만들어진 묶음에서 파일 하나를 몰래 고쳐 여러분의 검증기가 그 이름을 대는지 본다.

단계

/root/evidence/gen_scene.py 를 만들어 실행해 /root/evidence/host/ 를 만드세요. 설정 2개, 로그 2개, 중앙 로그 사본 1개, 임시 파일 6개, 운영 DB(customer 120행·charge 360행)가 들어갑니다.
/root/evidence/plan.json 에 항목 여덟 개를 휘발성이 높은 것부터 차례대로 적으세요. 항목마다 id·volatility_class·command·why 를 적습니다.
/root/evidence/collect.py 를 만들어 계획의 차례 그대로 모으고 매니페스트를 남기게 하세요.
항목마다 sha256 과 바이트 수를, 매니페스트에는 수집자를 적게 하세요. --collector 를 더합니다.
매니페스트 자체를 봉인해 MANIFEST.sha256 을 남기게 하세요.
/root/evidence/verify.py 를 만들어 봉인이 깨졌는지 검증하고, 깨진 파일의 이름을 찍게 하세요.
/root/evidence/scope.json 에 모으지 않기로 한 항목과 이유를 적고, --scope 를 더해 제외한 항목이 기록에는 남게 하세요.
진짜 묶음을 /root/evidence/bundle/ 에 만들고 검증한 뒤 /root/evidence/evidence_report.md 에 네 절로 적으세요.

참고

수집할 항목 여덟 개는 이것입니다.

id	무엇인가	어디서 읽나
`proc_table`	지금 떠 있는 프로세스 목록	이 파드의 프로세스 표
`net_state`	라우팅 표와 열린 연결	`/proc/net/route`, `/proc/net/tcp`
`kernel_stats`	커널 통계와 메모리	`/proc/stat`, `/proc/meminfo`
`tmp_files`	임시 파일 시스템에 남은 것	`host/tmp`
`app_logs`	애플리케이션 로그	`host/var/log`
`app_db`	운영 데이터베이스	`host/var/lib/app.db`
`remote_logs`	중앙 로그 서버에서 받은 사본	`host/remote`
`host_config`	설정과 물리 구성	`host/etc`

실행 계약: python3 /root/evidence/collect.py --plan <계획> --out <묶음 디렉터리> [--collector <이름>] [--scope <범위 파일>] 은 한 줄 요약을 표준출력에 내고 종료 코드 0 으로 끝납니다. 계획이나 범위 파일을 읽을 수 없으면 3 입니다.
검증 계약: python3 /root/evidence/verify.py --bundle <묶음 디렉터리> 는 온전하면 0, 깨졌으면 0 이 아닌 값으로 끝나고 깨진 파일 이름이 든 줄을 표준출력에 냅니다.
계획 파일: {"items": [{"id": …, "volatility_class": 1..7, "command": "셸 명령", "why": "왜 이 자리인가"}]}. 항목의 차례가 곧 수집 차례입니다. 수집기는 정렬하지 않습니다.
매니페스트: <묶음>/manifest.json 에 {"created_at", "collector", "items": [...]} 를 씁니다. 항목마다 id·order(1부터)·volatility_class·command·collected_at·status 를 적고, 모은 항목에는 file·exit_code·sha256·bytes 를, 제외한 항목에는 reason 을 적습니다.
수집물 파일 이름은 <id>.txt 이고 명령의 표준출력을 그대로 담습니다.
봉인: <묶음>/MANIFEST.sha256 에 <manifest.json 의 sha256> manifest.json 한 줄을 씁니다.
범위 파일: {"policy": …, "excluded": [{"id": …, "reason": …}]}. 제외한 항목은 파일을 만들지 않고 매니페스트에 status excluded 와 reason 으로 남깁니다.
시각은 RFC 3339 의 UTC 표기로 적습니다. 항목마다 따로 적어야 차례가 증명됩니다.
흔한 실수: 계획을 등급으로 다시 정렬하기(판단이 코드 안으로 숨습니다), 묶음 전체에 시각 하나만 적기, 파일 해시만 적고 매니페스트를 봉인하지 않기, 제외한 항목을 조용히 빼기.
항목 여덟 개의 구성과 app_db 를 제외 대상으로 삼는 것은 이 실습의 가정입니다. RFC 3227 은 묶음의 차례를 정할 뿐 어떤 항목을 뺄지는 정해 주지 않습니다.
참고 문서: RFC 3227의 2.1 절이 휘발성 차례를, 2.2 절이 피해야 할 것을 적습니다. NIST SP 800-86이 같은 주제를 더 넓게 다루고, 파이썬 hashlib 문서와 RFC 3339가 이 실습에서 쓰는 도구입니다.

현장을 손에 쥐기

/root/evidence/gen_scene.py 를 만들어 실행해 /root/evidence/host/ 를 만드세요. etc 2개, var/log 2개, remote 1개, tmp 6개, var/lib/app.db(customer 120행·charge 360행)가 들어갑니다.

실습 파드에서 진짜 고객 서버를 만질 수는 없으니 디스크 쪽만 만들어 둡니다. 휘발성이 높은 것은 흉내 낼 필요가 없습니다 — 이 파드의 /proc 이 진짜이기 때문입니다. 만든 뒤 tree 로 한 번 훑어보세요.

휘발성 차례로 계획 세우기

/root/evidence/plan.json 에 항목 여덟 개를 휘발성이 높은 것부터 차례대로 적으세요. 항목마다 id, RFC 3227 의 volatility_class(1..7), 실제로 돌릴 command, 왜 그 자리인지 적은 why 를 넣습니다.

RFC 3227 2.1 절의 일곱 묶음을 그대로 등급으로 씁니다. 프로세스 표와 커널 통계와 라우팅 표가 같은 묶음이고, 임시 파일 시스템이 그다음, 디스크가 그다음, 원격 로깅 자료가 그다음, 물리 구성이 그다음입니다. command 는 실제로 돌려 무언가를 내놓아야 합니다.

계획대로 모으기

/root/evidence/collect.py 를 만들어 계획의 차례 그대로 모으고 <묶음>/manifest.json 을 남기게 하세요. 항목마다 id·order·volatility_class·command·collected_at·file·exit_code·status 를 적습니다.

계획을 등급으로 다시 정렬하지 마세요 — 정렬하는 순간 판단이 코드 안으로 숨습니다. 명령은 bash 로 돌리고 표준출력을 <id>.txt 에 그대로 담습니다. 시각은 항목마다 따로 적어야 차례가 증명됩니다.

언제·누가·무엇으로를 적기

--collector <이름> 을 더하고, 모은 항목마다 sha256 과 bytes 를, 매니페스트에는 collector 를 적게 하세요.

몇 주 뒤에 '이 파일이 그날 그 서버에서 나온 것이 맞느냐' 는 질문이 옵니다. 그때 답할 수 있는 것은 수집 시각과 수집자와 실제로 실행한 명령, 그리고 내용 지문입니다. sha256 은 파일을 통째로 읽어 계산하세요.

매니페스트도 봉인하기

매니페스트를 다 쓴 뒤 그 파일의 sha256 을 계산해 <묶음>/MANIFEST.sha256 에 <해시> manifest.json 한 줄로 남기게 하세요.

파일 해시를 매니페스트에 적어 두기만 하면 매니페스트를 고쳐 버리면 그만입니다. 봉인은 위조를 막지 못하지만 모르는 사이에 바뀌는 것을 잡아냅니다 — 편집기로 열어 저장했거나 복사 중에 잘린 경우가 실제로 훨씬 자주 납니다.

깨진 것의 이름을 대기

/root/evidence/verify.py 를 만드세요. --bundle <묶음> 으로 봉인과 파일 해시를 견주어 온전하면 0, 깨졌으면 0 이 아닌 값으로 끝나고, 깨진 파일의 이름이 든 줄을 표준출력에 냅니다.

'봉인이 깨졌습니다' 만 찍는 검증기는 그 자리에 사람을 세워 둡니다. 무엇이 깨졌는지 이름을 대야 다음 행동이 생깁니다. 매니페스트가 바뀐 경우와 수집물 파일이 바뀐 경우를 모두 잡고, 제외된 항목은 파일이 없는 것이 정상입니다.

모으지 않기로 한 것을 기록에 남기기

/root/evidence/scope.json 에 policy 와 excluded 를 적어 app_db 를 제외하고, collect.py 에 --scope <파일> 을 더하세요. 제외한 항목은 파일을 만들지 않고 매니페스트에 status excluded 와 reason 으로 남습니다.

결제 서버의 운영 DB 에는 이름과 이메일과 전화번호가 들어 있습니다. 그것을 덤프해 들고 나오는 순간 우리는 조사하는 사람이 아니라 새로운 위험이 됩니다. 중요한 것은 조용히 빼지 않는 것입니다 — 뺐다는 사실이 기록에 남아야 나중에 무엇을 요청할지 알 수 있습니다.

묶음을 만들고 보고하기

진짜 묶음을 /root/evidence/bundle/ 에 만들고(계획과 범위를 모두 주어) verify.py 로 검증한 뒤, /root/evidence/evidence_report.md 에 ## 무엇을 어떤 차례로 모았나 ## 무엇을 모으지 않았나 ## 봉인과 검증 ## 남은 위험 네 절로 적으세요.

보고서는 손으로 쓰지 말고 매니페스트에서 만들어 내세요. 항목 이름과 등급, 제외한 항목과 이유, 봉인 값과 검증 명령이 모두 들어가야 다음 사람이 그대로 다시 검증할 수 있습니다.