📚 네트워크 · 패킷 분석 › 03. Wireshark 패킷 분석 — 148편
이전 글: 147. 외부 비정상 통신 분석 · 다음 글: 149. Packet에서 IOC 추출
1. 왜 알아야 하는가
"실제로 어떤 패킷이 오갔는가?"라는 질문의 답은 결국 pcap 파일입니다. 그런데 그 답이 설득력을 가지려면 한 가지가 더 증명되어야 합니다.
"이 파일은 수집된 이후 아무도 바꾸지 않았다."
분석 중 실수로 저장 버튼을 누르거나, 필요한 부분만 잘라 원본 이름으로 덮어쓰거나, 여러 사람이 파일을 주고받는 과정에서 어떤 버전이 원본인지 모르게 되는 일은 흔히 일어날 수 있습니다. 이렇게 되면 분석 내용이 맞더라도 근거로서의 신뢰성이 떨어집니다.
이 글은 수집 직후 해시를 기록하고, 원본을 읽기 전용으로 보존하며, 가공은 사본에서만 하는 기본 절차를 정리합니다.
2. 핵심 개념
2-1. 해시(Hash)의 역할
해시 함수는 파일 내용으로부터 고정 길이 값을 계산합니다. 1바이트만 바뀌어도 완전히 다른 값이 나오므로, 수집 시점의 해시와 현재 해시가 같으면 내용이 바뀌지 않았다고 판단할 수 있습니다.
| 알고리즘 | 출력 길이 | 증거 무결성 용도 |
|---|---|---|
| MD5 | 128비트 | 충돌 공격이 알려져 있어 단독 사용 비권장 (기존 시스템 호환용으로 병기하는 경우는 있음) |
| SHA-1 | 160비트 | 충돌 공격이 알려져 있어 단독 사용 비권장 |
| SHA-256 | 256비트 | 일반적으로 권장 |
해시는 내용이 바뀌지 않았다는 것을 보여 줄 뿐, 파일이 원래부터 정확하게 수집되었다는 것까지 보장하지는 않습니다. 수집 단계의 누락(드롭)은 capinfos나 캡처 도구의 통계로 따로 기록합니다.
2-2. 원본과 작업 사본
| 구분 | 원본(Original) | 작업 사본(Working Copy) |
|---|---|---|
| 목적 | 증거 보존 | 분석·가공 |
| 권한 | 읽기 전용 | 읽기·쓰기 |
| 변경 | 금지 | 자르기·병합·주석 모두 가능 |
| 해시 | 수집 직후 1회 기록, 이후 검증만 | 가공 결과물마다 새로 기록 |
Wireshark는 파일을 여는 것만으로 내용을 바꾸지 않지만, 패킷 주석을 달고 저장하면 파일이 바뀝니다. 그래서 분석은 항상 사본으로 합니다.
2-3. 증거 관리 기록(Chain of Custody) 기초
증거가 "누구 손을 거쳐 어떻게 이동했는지"를 기록하는 문서입니다. 법적 절차가 필요한 수준이 아니더라도, 관제 보고서의 신뢰성을 높이는 습관입니다.
| 항목 | 예시 |
|---|---|
| 증거 식별 | 파일명, 크기, SHA-256 |
| 수집 정보 | 수집 일시(UTC), 수집 위치(센서/인터페이스), 캡처 필터, 수집자 |
| 보관 위치 | 저장 경로, 접근 권한 |
| 인계 이력 | 일시, 인계자 → 인수자, 전달 방법, 인수 시 해시 재검증 결과 |
| 가공 이력 | 사본에서 수행한 작업(시간대 추출, 병합)과 결과물 해시 |
3. 동작 원리
수집부터 보고까지 해시가 등장하는 지점입니다.
그림 1. 수집부터 보고까지 원본 무결성을 유지하는 절차
[수집] tcpdump / dumpcap → capture.pcap
↓
[즉시 기록] sha256sum → capture.pcap.sha256 / capinfos 요약 저장
↓
[원본 보존] chmod 444 (+ 필요시 chattr +i), 증거 보관 디렉터리로 이동
↓
[사본 생성] cp → work/capture.pcap → 해시 비교(원본과 동일해야 함)
↓
[가공] editcap(시간대 추출) / mergecap(병합) → 결과물 해시 새로 기록
↓
[인계·보고] 수신 측에서 sha256sum -c 로 재검증 → 보고서에 해시 명시핵심은 해시를 계산하는 시점이 빠를수록 증명할 수 있는 구간이 길어진다는 것입니다. 수집 후 여러 날이 지나서 계산한 해시는 그 사이의 변경 여부를 증명하지 못합니다.
4. 실제 명령어 / 실습
실습 환경: 본인 소유 Linux VM (Rocky Linux 또는 Ubuntu). 인터페이스는 ens33을 예시로 사용합니다. sha256sum은 coreutils에 기본 포함, capinfos·editcap·mergecap은 Rocky wireshark-cli, Ubuntu wireshark-common 패키지에 포함됩니다.
4-1. 수집 직후 해시·요약 기록
sudo mkdir -p /evidence/case01 && cd /evidence/case01
sudo tcpdump -i ens33 -nn -c 500 -Z root -w capture.pcap 'not port 22'
# -Z root: 권한 하향(2편) 때문에 root 소유 디렉터리에 쓰지 못하는 경우를 피하기 위한 실습용 설정
sudo sh -c 'sha256sum capture.pcap > capture.pcap.sha256'
sudo sh -c 'capinfos capture.pcap > capture.capinfos.txt'
sudo sh -c 'capinfos -H capture.pcap >> capture.capinfos.txt' # 파일 해시 (종류는 버전에 따라 다름)4-2. 원본 읽기 전용 처리
sudo chmod 444 capture.pcap capture.pcap.sha256
sudo chattr +i capture.pcap # 변경·삭제 방지 (root 필요, 파일시스템 지원 필요)
lsattr capture.pcap # 'i' 속성 확인chattr +i가 걸린 파일은 root도 속성을 해제(chattr -i)하기 전까지 수정·삭제할 수 없습니다. 다만 root가 해제할 수 있으므로 완전한 보호가 아니라 실수 방지 장치입니다. 조직 차원에서는 별도 저장소, 접근 통제, 백업이 함께 필요합니다.
4-3. 사본 생성과 검증
mkdir -p ~/work && cp /evidence/case01/capture.pcap ~/work/
cd ~/work
sha256sum capture.pcap # 원본 해시와 비교
cd /evidence/case01 && sha256sum -c capture.pcap.sha256 # 원본 검증: OK 확인📷 [실습 화면 삽입]
sha256sum -c결과capture.pcap: OK와lsattr의i속성 표시
4-4. 변조 탐지 실험 (사본에서만)
cd ~/work
cp capture.pcap tamper.pcap
printf 'X' | dd of=tamper.pcap bs=1 seek=100 conv=notrunc 2>/dev/null # 1바이트 변경
sha256sum capture.pcap tamper.pcap1바이트 변경만으로 해시가 완전히 달라지는 것을 확인합니다.
4-5. 사본 가공: editcap / mergecap (간단히)
# 시간 구간 추출 (시각 형식: "YYYY-MM-DD HH:MM:SS")
editcap -A "2026-09-26 10:00:00" -B "2026-09-26 10:05:00" capture.pcap slice.pcap
# 1~100번 패킷만 남기기 (-r: 지정 범위를 '유지')
editcap -r capture.pcap first100.pcap 1-100
# 여러 파일 병합 (기본: 패킷 시각 순서로 정렬 병합)
mergecap -w merged.pcapng ring.pcap0 ring.pcap1
sha256sum slice.pcap first100.pcap merged.pcapng > derived.sha256editcap은 -r 없이 번호를 주면 해당 패킷을 제거합니다. 헷갈리기 쉬운 옵션이므로 결과를 capinfos로 꼭 확인합니다. mergecap의 기본 출력 형식은 pcapng입니다.
📷 [실습 화면 삽입]
capinfos slice.pcap으로 추출 결과의 시작·종료 시각이 지정 구간 안에 있는지 확인한 화면
5. 결과 확인
형식 예시(값은 환경마다 다름):
$ sha256sum -c capture.pcap.sha256
capture.pcap: OK
$ sha256sum capture.pcap tamper.pcap
3f1a...(64자리 16진수)...9c2e capture.pcap
b77d...(64자리 16진수)...014a tamper.pcap
$ lsattr capture.pcap
----i---------e------- capture.pcap- 수집 직후 SHA-256 해시와 capinfos 요약을 파일로 저장했다
- 원본을 읽기 전용(
chmod 444, 필요시chattr +i)으로 처리했다 - 분석은 사본에서 하고, 사본 해시가 원본과 같음을 확인했다
- 1바이트 변경 시 해시가 달라지는 것을 확인했다
- editcap/mergecap 결과물의 해시를 별도로 기록했다
- 수집·인계·가공 이력을 표로 남겼다
6. 패킷 / 로그 분석
해시 검증 결과와 파일 메타데이터를 해석하는 기준입니다.
| 관찰 | 정상일 수 있는 경우 | 의심해야 하는 경우 |
|---|---|---|
sha256sum -c 실패(FAILED) | 사본에 주석을 저장함, 전송 중 손상(재전송으로 해결) | 원본 보관 위치의 파일 해시가 바뀜 → 접근 기록 확인 |
| capinfos 캡처 기간이 요청 구간보다 짧음 | 링 버퍼 덮어쓰기, 캡처 중단 | 기록과 다른 구간만 전달됨 |
| 파일 형식이 기록(pcap)과 다름(pcapng) | 분석 중 "다른 이름으로 저장" 결과물 | 원본이라고 전달된 파일이 가공본 |
| 패킷 수가 기록보다 적음 | editcap/필터 추출본 | 가공 이력에 없는 삭제 |
| 원본 파일 수정 시각(mtime) 변경 | 복사 시 속성 미보존 | 원본 경로 파일의 mtime 변경 |
stat /evidence/case01/capture.pcap # 크기, 수정 시각, 권한 확인
capinfos -c -a -e capture.pcap # 패킷 수, 첫·마지막 패킷 시각만 확인파일 시스템 시각(mtime)은 쉽게 바뀔 수 있으므로 보조 정보로만 사용하고, 판단의 기준은 해시로 둡니다.
7. 보안관제 관점
- 관제에서 pcap은 IDS 경보 검증, 침해 사고 대응팀 인계, 고객사 보고의 근거가 됩니다. 인계할 때 파일과 해시를 함께 전달하고, 받는 쪽이 재검증하도록 하는 것이 기본입니다.
- 흔적이 남는 곳: 증거 디렉터리 접근은 파일 권한과 감사 로그(auditd를 설정한 경우)로 추적할 수 있습니다. 증거 파일 접근에 대한 감사 정책은 조직 규정에 따릅니다.
- 한계: 해시는 수집 이후의 무결성만 보여 줍니다. 캡처 누락, 캡처 호스트의 시각 오차, 캡처 필터로 인한 제외는 별도로 기록해야 합니다. 시각 신뢰성은 17. NTP와 로그 시간 동기화를 참고하세요.
- 주의: pcap에는 개인정보나 인증 정보가 포함될 수 있으므로 보관 기간·접근 권한·폐기 절차도 증거 관리의 일부입니다. 공유가 필요할 때는 필요한 구간만 잘라 전달합니다.
- 법적 증거 요건, 포렌식 도구 체계는 이 시리즈 범위를 벗어나며, 관제 보고 절차는 「07. 네트워크 보안관제 통합 분석」 시리즈에서 다룹니다.
8. 핵심 정리
- pcap의 신뢰성은 "수집 이후 바뀌지 않았다"는 증명에서 나오며, 그 수단이 SHA-256 해시입니다.
- 해시는 수집 직후 계산하고, capinfos 요약(기간·패킷 수)과 함께 기록합니다.
- 원본은 읽기 전용으로 보존하고, 분석·가공은 사본에서만 합니다.
- editcap(구간 추출,
-r로 유지 범위 지정)·mergecap(병합) 결과물은 새 해시와 가공 이력을 남깁니다. - 수집·인계·가공 이력을 남기는 증거 관리 기록은 보고서의 근거를 뒷받침합니다.
다음 글: 07. Ethernet 프레임 필드 분석
