16. /var/log/boot.log 분석

Linux 로그 경로 정리 · 16/50 · Part 2. RHEL / Rocky Linux 로그 경로

선행 학습 → 15. /var/log/maillog 분석
이번 글 → /var/log/boot.log 분석
이어서 → 17. Rocky Linux 로그 경로 종합 정리

1. 들어가며

침해사고에서 재부팅 시점은 중요한 기준점입니다. 휘발성 저널과 메모리 흔적이 사라지는 순간이고, 공격자가 심어둔 서비스·커널 모듈이 자동 실행되는 순간이기도 합니다.

핵심 요약

• /var/log/boot.log 는 local7 facility 규칙으로 만들어지는 부팅 중 콘솔 메시지 파일이다(RHEL 계열).
• 부팅 분석의 주 소스는 journalctl -b 와 journalctl --list-boots 다.
• 재부팅 시각은 last -x reboot, who -b, 저널 부팅 목록으로 교차 확인한다.

2. 핵심 개념

소스	무엇을 담나	특징
/var/log/boot.log	부팅 시 서비스 출력 (local7)	환경에 따라 비어 있거나 매우 짧음
journalctl -b [-N]	해당 부팅의 전체 로그	영구 저널일 때만 과거 부팅 조회 가능
journalctl --list-boots	부팅 목록 (ID, 시작~끝 시각)	비정상 종료 여부 추정
last -x reboot shutdown	wtmp 기반 재부팅/종료 기록	바이너리, 삭제·변조 가능
/var/log/dmesg / dmesg	커널 링 버퍼	현재 부팅 커널 메시지

3. 로그 생성 구조

전원/재부팅
   ↓
커널 부팅 ──▶ kmsg ──▶ journald (현재 부팅 ID 부여)
   ↓
systemd 기동 ──▶ unit 시작/실패 메시지 ──▶ journald
   │                                         ├─▶ /var/log/journal (영구 시)
   │                                         └─▶ rsyslog: local7.* ──▶ /var/log/boot.log
   └─ wtmp 에 reboot 레코드 ──▶ last -x

4. 실제 로그 경로

/var/log/boot.log            (Rocky: local7.* 규칙, 순환 파일 boot.log-YYYYMMDD)
/var/log/journal/<id>/       영구 저널 (없으면 과거 부팅 조회 불가)
/var/log/wtmp                reboot / shutdown 레코드
/etc/systemd/system/         부팅 시 자동 시작되는 사용자 정의 유닛 위치

5. 명령어 실습

# 부팅 목록과 현재 부팅 시각
journalctl --list-boots | tail -5
who -b
last -x reboot shutdown | head -5

# 직전 부팅에서 실패한 유닛
journalctl -b -1 -p err --no-pager | head -20       # 영구 저널일 때
systemctl --failed

# 부팅 시 자동 시작 유닛 중 최근 생성된 것
find /etc/systemd/system -name '*.service' -newermt '-7 days' -ls
systemctl list-unit-files --state=enabled --type=service | head -40

# boot.log (RHEL)
tail -20 /var/log/boot.log 2>/dev/null

6. 로그 예시

위 이미지는 Rocky Linux 9.8 실습 환경의 실제 실행 결과입니다. 컨테이너·클라우드 이미지처럼 부팅 경로가 다른 환경에서는 boot.log 가 비어 있을 수 있다는 점도 함께 확인합니다.

아래는 판단 설명용 예시 출력입니다.

[예시 출력: journalctl --list-boots]
 -2 7f1c...  Sun 2026-09-13 09:02:11 KST — Sat 2026-09-19 23:58:40 KST
 -1 a91e...  Sat 2026-09-19 23:59:31 KST — Sun 2026-09-20 02:31:07 KST
  0 c44b...  Sun 2026-09-20 02:31:58 KST — Sun 2026-09-20 09:10:02 KST

해석: 부팅 -1이 02:31:07에 끝나고 02:31:58에 재부팅 — 침해 시간대(02:13~02:30) 직후의 재부팅입니다. 변경관리 기록이 없다면 지속성 확인을 위한 공격자 재부팅 또는 흔적 제거 목적을 가설로 세웁니다.

7. 로그 필드 분석

항목	확인 질문
부팅 목록의 종료 시각	정상 종료(shutdown 레코드)가 있었나, 전원 차단인가?
부팅 직후 Started xxx.service	처음 보는 유닛이 자동 시작됐나?
-p err 결과	공격 도구가 의존성 문제로 실패한 흔적은 없나?
/etc/systemd/system 신규 파일	생성 시각이 침해 시간대와 겹치는가?

8. 보안관점

정상	의심
패치 공지 시간대의 재부팅	공지 없는 새벽 재부팅
부팅 목록 연속	저널 부팅 목록 중간 누락(저널 삭제)
알려진 유닛 자동 시작	무작위·정상 흉내 이름(syscheck, dbus-helper) 유닛
last -x 와 저널 시각 일치	두 소스 불일치 (wtmp 조작 가능성)

9. SOC 관점

• Detection: 에이전트 재연결 이벤트(Wazuh agent started)와 서버 재부팅 시각을 연결한다.
• Triage: 비정상 재부팅 Alert → 직전 부팅의 마지막 로그(journalctl -b -1 -n 50).
• Investigation: 재부팅 전 로그가 필요하면 영구 저널 여부가 결정적 — 휘발성이면 중앙 수집본을 본다.
• Response: 격리 시 재부팅하지 않는다(메모리·휘발성 저널 보존). 필요한 경우 수집 후 조치.

10. 실습 체크리스트

[ ] boot.log 와 journalctl -b 차이 설명
[ ] --list-boots / who -b / last -x 로 재부팅 시각 교차 확인
[ ] 직전 부팅 오류 조회
[ ] 최근 생성된 systemd 유닛 확인
[ ] 영구 저널 여부 확인
[ ] 사고 대응 중 재부팅 금지 이유 설명

11. 핵심 정리

• boot.log 는 local7 규칙 기반의 부팅 메시지로, 주 분석 소스는 저널이다.
• 재부팅 시각은 저널·wtmp·who -b 로 교차검증한다.
• 부팅 직후 자동 시작된 신규 유닛은 지속성 흔적이다.
• 과거 부팅 분석은 영구 저널 또는 중앙 수집본이 있어야 가능하다.
• 사고 대응 초기에는 증거 보존을 위해 재부팅을 피한다.

12. 다음 편 연결

구분	글
◀ 이전 글	15. /var/log/maillog 분석
▶ 다음 글	17. Rocky Linux 로그 경로 종합 정리
시리즈	Linux 로그 경로 정리 전체 보기
선행 시리즈	리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 · Linux 시스템 보안 기초