06. Linux 로그의 시간 정보 이해

Linux 로그 경로 정리 · 06/50 · Part 1. Linux 로그 기본 구조

선행 학습 → 05. 로그 파일의 권한과 소유권
이번 글 → Linux 로그의 시간 정보 이해
이어서 → 07. 로그 메시지의 기본 구성

1. 들어가며

타임라인 분석(49편)의 정확도는 시간 정보의 정확도를 넘을 수 없습니다. 서버는 UTC, SIEM은 KST, 방화벽은 다른 NTP 서버를 쓰는 환경에서 시간대를 확인하지 않으면, 9시간 어긋난 로그를 "관련 없는 이벤트"로 버리게 됩니다.

핵심 요약

• 전통 syslog 형식(Sep 20 02:14:52)에는 연도와 시간대가 없다.
• journald는 이벤트를 UTC 기준 마이크로초로 저장하고, 출력 시 현지 시각으로 변환한다.
• 분석 전 반드시 서버 시간대 · NTP 동기화 상태를 기록한다.

2. 핵심 개념

용어	설명	예
timestamp	이벤트가 기록된 시각	Sep 20 02:14:52
timezone	시각의 기준 지역	Asia/Seoul (KST, +0900)
UTC	세계 표준시. 서버·SIEM의 공통 기준으로 권장	2026-09-19T17:14:52Z
local time	서버에 설정된 시간대로 표현한 시각	2026-09-20 02:14:52 KST
journal timestamp	__REALTIME_TIMESTAMP (epoch 마이크로초, UTC)	1789838092000000
RFC 5424 / ISO 8601	연도·시간대 포함 형식	2026-09-20T02:14:52.123+09:00

3. 로그 생성 구조

Event 발생 (커널 시계, UTC 기준 epoch)
    ↓
journald 저장: __REALTIME_TIMESTAMP (UTC, μs)
    ↓                                ↓
journalctl 출력 (TZ 적용)         rsyslog 파일 기록 (템플릿 따라)
 → 2026-09-20 02:14:52 KST          → RSYSLOG_TraditionalFileFormat: "Sep 20 02:14:52" (연도·TZ 없음)
                                     → RSYSLOG_FileFormat: "2026-09-20T02:14:52.123456+09:00"
auditd: msg=audit(1789838092.123:2046)  (epoch 초, UTC)

핵심: 원본이 epoch/UTC인 로그(journal, audit)는 변환 기준만 맞추면 정확하지만, 전통 syslog 텍스트는 기록 당시의 서버 시간대를 알아야 해석할 수 있습니다.

4. 실제 로그 경로

/etc/localtime                   → 서버 시간대 (심볼릭 링크)
/etc/chrony.conf (Rocky)         → NTP 서버 설정
/etc/chrony/chrony.conf (Ubuntu)
/etc/rsyslog.conf                → 파일 템플릿 (Traditional vs 고정밀)
/var/log/audit/audit.log         → epoch 타임스탬프

5. 명령어 실습

# 서버 시간대와 NTP 동기화 상태
timedatectl
ls -l /etc/localtime
chronyc tracking 2>/dev/null | head -5

# 같은 저널 이벤트를 KST / UTC 로 출력
journalctl -u sshd -n 3 -o short-iso
journalctl -u sshd -n 3 -o short-iso --utc

# journal 원시 타임스탬프 (μs)
journalctl -u sshd -n 1 -o verbose | grep -E '__REALTIME_TIMESTAMP|MESSAGE='

# audit epoch → 사람이 읽는 시각
ausearch -m USER_LOGIN -ts today -i | head -3      # -i 가 시간도 변환
date -d @1789838092                                # 수동 변환 (현재 TZ 기준)
TZ=UTC date -d @1789838092

6. 로그 예시

위 이미지는 Rocky Linux 9.8 실습 환경의 실제 실행 결과입니다.

아래는 같은 이벤트가 형식별로 어떻게 보이는지 설명하기 위한 예시 출력입니다.

[예시] secure (Traditional)  : Sep 20 02:14:52 web01 sshd[4101]: Accepted password for deploy ...
[예시] journalctl -o short-iso: 2026-09-20T02:14:52+0900 web01 sshd[4101]: Accepted password ...
[예시] journalctl --utc       : 2026-09-19T17:14:52+0000 web01 sshd[4101]: Accepted password ...
[예시] audit.log (raw)        : type=USER_LOGIN msg=audit(1789838092.000:2045): ...

7. 로그 필드 분석

형식	연도	시간대	정밀도	주의
Traditional syslog	없음	없음	초	연말·연초 로그, 다른 TZ 서버 병합 시 오류
journal	epoch	UTC 원본	μs	출력 시 --utc 여부 명시
audit	epoch	UTC 원본	ms	ausearch -i 변환은 실행 환경 TZ를 따름
Apache/Nginx access	있음	있음(+0900)	초	가장 해석이 쉬움

8. 보안관점

• 정상: NTP 동기화(System clock synchronized: yes), 모든 서버 동일 TZ 또는 UTC.
• 의심:
  • 시간이 역행하는 로그 구간 → 수동 시간 변경(date -s) 가능성. journal의 -- Boot 경계, audit의 TIME_INJOFFSET/time_adjtime 관련 이벤트 확인.
  • 서버 간 수 분 이상 차이 → NTP 장애. 타임라인 병합 시 보정값을 보고서에 명시.
  • 공격자는 파일 mtime을 touch로 위조할 수 있다(timestomping). 파일 시간은 로그 시간보다 약한 증거다.

9. SOC 관점

단계	시간 처리 원칙
수집	SIEM에서 원본 시간 필드와 수집 시각(@timestamp vs ingest time)을 구분
Triage	Alert 시간이 어떤 기준인지(UTC/KST) 먼저 확인
Investigation	모든 소스를 하나의 기준(권장 UTC 또는 KST 명시) 으로 정규화 후 병합
Report	"모든 시각은 KST(+09:00) 기준" 처럼 기준을 문서 첫머리에 명시

10. 실습 체크리스트

[ ] timedatectl 로 TZ / NTP 동기화 확인
[ ] 같은 이벤트를 KST / UTC 로 각각 출력
[ ] journal __REALTIME_TIMESTAMP 확인
[ ] audit epoch 수동 변환
[ ] Traditional syslog 의 연도·TZ 부재 문제 설명 가능
[ ] 보고서 시간 기준 명시 습관화

11. 핵심 정리

• 전통 syslog 타임스탬프에는 연도와 시간대가 없다.
• journal과 audit은 epoch(UTC) 기반이라 정규화가 쉽다.
• 분석 시작 전에 TZ와 NTP 상태를 기록한다.
• 병합 타임라인은 하나의 시간 기준으로 통일하고 보고서에 명시한다.
• 시간 역행·서버 간 편차는 그 자체로 조사 대상이다.

12. 다음 편 연결

구분	글
◀ 이전 글	05. 로그 파일의 권한과 소유권
▶ 다음 글	07. 로그 메시지의 기본 구성
시리즈	Linux 로그 경로 정리 전체 보기
선행 시리즈	리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 · Linux 시스템 보안 기초