📚 네트워크 · 패킷 분석 › 05. 네트워크 스캔 징후 분석 — 247편
이전 글: 246. IOC 추출 · 다음 글: 248. 네트워크 정찰 Incident 분석
1. 개념
Incident Timeline(사건 타임라인) 은 여러 장비와 시스템에 흩어진 이벤트를 하나의 시간 기준으로 정렬한 기록입니다. 타임라인이 있어야 "무엇이 먼저였는가", "어느 단계에서 탐지되었는가", "어디서 멈췄는가"를 설명할 수 있습니다. IDS Alert가 출발점인 사건의 분석 절차는 299. IDS Incident 분석에서 다뤘고, 이 글은 정찰 사건의 타임라인을 만드는 방법 자체에 집중합니다. 다음 글(248. 네트워크 정찰 Incident 분석)은 같은 가상 시나리오로 사건 분석을 이어갑니다.
| 타임라인이 답하는 질문 | 필요한 열 |
|---|---|
| 언제 처음 접촉했는가 | 시각(통일 기준) |
| 어떤 장비가 무엇을 보았는가 | 출처, 원본 위치 |
| 누가 무엇을 대상으로 했는가 | 주체 → 대상(IP·포트·계정) |
| 어느 단계인가 | 단계 분류(정찰·시도·성공·확산) |
| 무엇이 근거인가 | 사실(관찰)과 추정(해석) 분리 |
2. 동작 원리
타임라인 작성 순서입니다.
[1] 출처 목록화 방화벽, IDS, 서버 인증 로그, HIDS, 웹 로그, DHCP, 패킷
↓
[2] 수집·보존 조사 기간 로그 추출, 원본 해시 기록
↓
[3] 시간 정규화 모든 시각을 한 기준(KST 또는 UTC)으로 변환, 원본 표기 병기
↓ 장비 간 시계 오차 확인(같은 연결이 두 장비에 찍힌 시각 비교)
[4] 정렬·병합 시각 순 정렬, 같은 사건의 중복 행 병합
↓
[5] 해석 열 추가 단계 분류, 추정은 별도 열
↓
[6] 공백 표시 로그가 없는 구간·장비를 명시
↓
[7] 검증 다른 분석가가 원본 위치로 재확인 가능해야 함시계 오차를 확인하는 간단한 방법은 같은 연결을 두 장비에서 찾는 것입니다. 방화벽의 세션 시작 시각과 IDS flow 시작 시각이 3초 차이라면, 이 두 장비의 이벤트 순서는 3초 이내에서는 확신할 수 없습니다. NTP 동기화 상태는 평소 점검 항목입니다.
3. 주요 특징
- 사실과 추정 분리: "DB 계정 탈취 시도"는 추정이고, "3306 연결 후 서버 로그에 인증 실패 12건"은 사실입니다. 타임라인의 내용 열에는 사실만 쓰고, 해석은 판단 열에 씁니다.
- 공백도 기록: "02:30~03:00 방화벽 로그 없음(수집 장애)"처럼 로그가 없는 구간을 적어야, 그 구간에 아무 일도 없었다고 오해하지 않습니다.
- 주체 식별: 내부 IP는 DHCP 임대 기록으로 그 시각의 단말과 사용자를 확인합니다. IP는 시간이 지나면 다른 단말에 할당될 수 있습니다.
- 단위 통일: 스캔처럼 수천 건인 이벤트는 행 하나로 요약하고(기간, 건수, 범위), 원본 조회 조건을 남깁니다.
| 흔한 실수 | 결과 | 예방 |
|---|---|---|
| 시간대 혼용(UTC와 KST) | 9시간 어긋난 순서 | 변환 후 원본 표기 병기 |
| 추정을 사실처럼 기록 | 잘못된 결론 전파 | 판단 열 분리 |
| 요약 행에 조회 조건 누락 | 재현 불가 | 원본 위치·검색 조건 기록 |
| 로그 공백 미표시 | "아무 일 없음"으로 오해 | 공백 행 삽입 |
4. 예시
⚠️ 아래는 설명을 위한 가상 시나리오이며, 모든 로그와 값은 형식 예시입니다(값은 환경마다 다름).
가상 시나리오 — 내부 업무 단말 대역의 한 IP에서 서버 대역으로 새벽에 스캔 Alert가 발생했습니다. 관련 로그를 모아 KST 기준 타임라인을 작성합니다.
# 형식 예시 — 가상 시나리오 타임라인 (KST, 원본 UTC 장비는 변환)
시각 출처(원본 위치) 주체 → 대상 내용(사실) 판단(추정)
01:58:10 DHCP 192.168.30.45 = PC-FIN-017 임대 갱신 주체 식별
02:03~02:19 FW(내부 구간) 192.168.30.45 → 192.168.20.0/24 차단 4,120건, 고유 포트 1,000, 호스트 38 정찰
02:04:31 IDS(sid 1001502) 192.168.30.45 → 192.168.20.0/24 내부 SYN 스캔 임계치 Alert 탐지 시점
02:19:55 FW 192.168.30.45 → 192.168.20.30:3306 허용 세션 12건, 각 2~3초 시도
02:20:02 DB 서버 로그 192.168.30.45 → 192.168.20.30 인증 실패 12건, 성공 없음 시도(실패)
02:21~02:45 FW — 로그 수집 장애(원인: 수집기 재시작) 공백
02:46:30 FW 192.168.30.45 → 192.168.20.50:445 허용 세션 3건 시도?
02:46:31 파일 서버 보안 로그 192.168.30.45 → 192.168.20.50 로그온 실패 기록 3건 시도(실패)실습 예시 — 본인 소유 실습 환경에서 서로 다른 로그를 시각 기준으로 병합하는 방어 측 방법입니다. 각 로그를 시각<TAB>출처<TAB>내용 형식의 파일로 변환한 뒤 정렬합니다.
# UTC 시각을 KST로 변환 (GNU date)
TZ=Asia/Seoul date -d "2026-09-29T17:04:31Z" "+%F %T" # 결과: 2026-09-30 02:04:31
# 변환된 파일 병합·정렬
sort -t$'\t' -k1,1 fw.tsv ids.tsv db.tsv > timeline.tsv5. 보안 관점
- 타임라인은 보고서와 대응 요청의 근거입니다. 각 행이 원본으로 되돌아갈 수 있어야 법적·감사 요구에도 대응할 수 있습니다.
- 증거 원본은 수정하지 않고 사본으로 작업합니다. 추출 파일의 해시를 기록해 두면 이후 무결성을 설명할 수 있습니다.
- 로그 공백 구간은 탐지·수집 개선 과제로 연결합니다. 위 시나리오의 수집기 재시작 공백은 사건과 별개로 개선 대상입니다.
6. SOC 관점
관제자가 확인할 질문
- 모든 행이 같은 시간 기준인가? 장비 간 시계 오차는 확인했는가?
- 내부 IP의 그 시각 사용자·단말을 DHCP·자산 기록으로 확인했는가?
- 내용 열에 추정이 섞이지 않았는가?
- 로그 공백 구간과 장비를 표시했는가?
- 첫 Alert보다 앞선 흔적(방화벽 차단의 시작 시각)을 반영했는가?
출처 목록 → 수집·해시 → 시간 정규화 → 정렬·병합
↓
해석 열(단계·추정) → 공백 표시 → 동료 검증 → 분석·보고에 사용 (248편)오탐 주의: 타임라인은 처음 세운 가설에 맞춰 이벤트를 고르기 쉽습니다. 가설과 맞지 않는 이벤트(예: 같은 시간대 다른 출발지의 활동)도 삭제하지 말고 별도 표시해 두면 판단 수정에 도움이 됩니다.
7. 핵심 정리
- 사건 타임라인은 여러 장비의 이벤트를 하나의 시간 기준으로 정렬한 기록입니다.
- 출처 목록화, 수집·해시, 시간 정규화, 정렬·병합, 해석, 공백 표시, 검증 순으로 작성합니다.
- 같은 연결을 두 장비에서 비교해 시계 오차를 확인하고, 원본 시간 표기를 병기합니다.
- 내용 열에는 사실만, 해석은 판단 열에 분리해 기록합니다.
- 로그 공백과 내부 IP의 당시 사용자까지 기록해야 타임라인을 검증할 수 있습니다.
