엔드포인트 보안 이벤트와 Syslog: 로그 기반 위협 탐지의 출발점

1. 엔드포인트 보안 이벤트란

엔드포인트(Endpoint)는 네트워크에 연결된 최종 장치를 의미한다.

워크스테이션(클라이언트 장비), 서버, 노트북, 모바일 기기 등이 모두 엔드포인트에 해당하며, 공격자 입장에서는 네트워크 침투의 첫 번째 접점이 된다.

엔드포인트 보안 이벤트(Endpoint Security Event)는 이러한 장치에서 발생하는 보안 관련 활동 기록이다.

단순한 로그인 시도부터 악성코드 실행, 권한 상승, 파일 변조까지 엔드포인트에서 일어나는 모든 보안상 의미 있는 행위가 이벤트로 기록된다.

1️⃣ 엔드포인트 보안 이벤트의 분류

엔드포인트에서 발생하는 보안 이벤트는 크게 다음과 같이 분류된다.

분류	설명	예시
인증 이벤트	사용자 인증 시도 및 결과	로그인 성공/실패, SSH 접속 시도, sudo 사용
프로세스 이벤트	프로세스 생성·종료·변경	비정상 프로세스 실행, 권한 상승 시도
파일시스템 이벤트	파일/디렉토리 생성·수정·삭제	/etc/passwd 변조, 설정 파일 변경
네트워크 이벤트	네트워크 연결 및 트래픽 관련	비인가 포트 리스닝, 외부 C2 서버 통신
시스템 이벤트	OS 수준의 상태 변화	서비스 시작/중지, 커널 모듈 로드, 시간 변경
정책 위반 이벤트	보안 정책 또는 규칙 위반	SELinux 거부, AppArmor 차단, 방화벽 DROP

*C2 서버(Command and Control Server): 공격자가 침투에 성공한 시스템을 원격으로 제어하기 위해 운영하는 서버

2️⃣ 왜 엔드포인트 이벤트가 중요한가

네트워크 경계 보안(방화벽, IDS/IPS)만으로는 내부에서 발생하는 위협을 탐지할 수 없다.

공격자가 정상 경로로 내부에 진입한 이후의 행위 — 래터럴 무브먼트(Lateral Movement), 권한 상승(Privilege Escalation), 데이터 유출(Data Exfiltration) — 는 엔드포인트 레벨에서만 포착 가능하다.

엔드포인트 보안 이벤트 수집이 중요한 이유는 다음과 같다.

• 공격 타임라인 재구성: 침해 사고 발생 시 이벤트 로그를 통해 공격의 시간 순서를 추적할 수 있다.
• 이상 행위 탐지: 정상 행위의 베이스라인을 설정하고, 이를 벗어나는 이벤트를 식별한다.
• 컴플라이언스 충족: PCI-DSS, HIPAA, ISMS-P 등의 보안 인증 기준은 엔드포인트 로그 수집·보관을 요구한다.
• 포렌식 증거 확보: 법적 대응이 필요한 경우, 무결성이 보장된 로그가 디지털 증거로 사용된다.

2. Syslog 프로토콜

엔드포인트에서 발생하는 보안 이벤트를 체계적으로 수집하려면 표준화된 로그 전송 프로토콜이 필요하다.

Syslog는 이 목적에 가장 오래, 가장 널리 사용되어 온 프로토콜이다.

1️⃣ Syslog 아키텍처

Syslog 아키텍처는 세 가지 역할로 구성된다.

 

• Originator: 로그 메시지를 최초로 생성하는 주체다. 서버, 네트워크 장비, 애플리케이션 등이 해당한다.
• Relay: 메시지를 수신하여 다른 대상으로 전달하는 중계자다. 필터링, 집계, 포맷 변환 등의 처리를 수행할 수 있다.
• Collector: 최종적으로 메시지를 수신하여 저장·분석하는 주체다. SIEM 시스템이 대표적인 Collector다.

 

Relay는 필수가 아니며, Originator가 Collector에 직접 전송하는 구성도 가능하다.

그러나 대규모 인프라에서는 Relay를 통한 로그 집계가 네트워크 효율성과 관리 편의성 측면에서 유리하다.

 

모든 엔드포인트 내부에는 두 종류의 로그 생성 주체가 공존한다

애플리케이션 수준 — httpd, sshd, mysqld, 사용자 정의 앱 등이 syslog() 시스템 콜을 통해 로그를 생성한다. Facility는 각 애플리케이션의 성격에 따라 daemon, authpriv, local0-7 등으로 지정된다.

시스템 수준 — 커널(kern), cron, systemd, SELinux/AppArmor 등 OS 자체 구성요소가 생성하는 로그다. 커널 메시지는 /dev/kmsg를 통해 journald로 직접 전달되고, systemd 관리 하의 서비스 상태 변경(시작/중지/실패)도 journald가 자동으로 캡처한다.

 

 

 

두 경로 모두 엔드포인트 내부의 로컬 syslog 데몬(journald → rsyslog)에서 합류하여, 이후 동일한 전송 경로를 따라 중앙 Relay/Collector로 전달된다. 

 

2️⃣ 전송 프로토콜

Syslog 메시지의 전송 방식은 세 가지가 존재한다.

 

방식	포트	특징
UDP	514	비연결형, 전송 보장 없음, 가장 단순
TCP	514	연결형, 전송 순서 보장, 신뢰성 향상
TLS over TCP	6514	암호화 + 인증, RFC 5425 정의

전통적으로 syslog는 UDP/514를 사용해 왔다.

UDP는 빠르고 단순하지만, 패킷 유실 시 로그가 소실되며 평문 전송이므로 도청에 취약하다.

보안 이벤트처럼 무결성과 기밀성이 중요한 로그는 TLS 기반 전송(TCP/6514)을 사용하는 것이 원칙이다.

 

3. Syslog 메시지 구조

Syslog 메시지 포맷을 이해하는 것은 로그 분석의 기본이다. RFC 5424 기준의 메시지 구조를 분석한다.

1️⃣ RFC 5424 메시지 포맷

RFC 5424는 syslog 메시지를 다음과 같은 구조로 정의한다.

 

<PRI>VERSION TIMESTAMP HOSTNAME APP-NAME PROCID MSGID STRUCTURED-DATA MSG

 

실제 메시지 예시:

<34>1 2025-07-17T09:15:33.002Z webserver01 sshd 2847 - [auth user="admin" result="failed" src="192.168.1.100"] Failed password for admin from 192.168.1.100 port 52413 ssh2

 

 

2️⃣ PRI(Priority) 값의 구성

PRI는 Facility(발생 주체)와 Severity(심각도)를 하나의 숫자로 인코딩한다.

PRI = Facility × 8 + Severity

 

🔵 Facility 코드 (메시지 발생 주체)

코드Facility설명

0	kern	커널 메시지
1	user	사용자 수준 메시지
3	daemon	시스템 데몬
4	auth	인증/보안 메시지
10	authpriv	민감 인증 메시지
13	logaudit	감사(audit) 로그
16-23	local0-7	사용자 정의 용도

🔵 Severity 레벨 (심각도)

코드Severity의미

0	Emergency	시스템 사용 불가
1	Alert	즉시 조치 필요
2	Critical	치명적 상태
3	Error	오류 발생
4	Warning	경고 상태
5	Notice	정상이나 주의 필요
6	Informational	정보성 메시지
7	Debug	디버그 수준 메시지

위 예시에서 PRI 값 34를 역산하면: 34 ÷ 8 = 4 나머지 2 → Facility 4(auth), Severity 2(Critical).

인증 관련 치명적 이벤트라는 의미다.

3️⃣ Structured Data

RFC 5424에서 도입된 핵심 개선 사항이다.

RFC 3164의 MSG 필드가 자유 형식 텍스트였던 것과 달리, Structured Data는 키-값 쌍으로 메타데이터를 구조화하여 기계적 파싱을 가능하게 한다.

[sdID param1="value1" param2="value2"]

보안 이벤트에서 Structured Data를 활용하면 SIEM이 정규 표현식 없이도 필드를 직접 추출할 수 있어 파싱 정확도와 처리 속도가 향상된다.

 

4. Linux에서의 Syslog 구현

1️⃣ rsyslog vs syslog-ng vs journald

현대 Linux 시스템에서 syslog를 처리하는 주요 구현체는 세 가지다.

구현체	특징	기본 탑재
rsyslog	RFC 5424 지원, 고성능, 모듈 기반 아키텍처	RHEL/Rocky, Ubuntu (전통)
syslog-ng	유연한 필터링, 구조화된 설정 문법	SUSE, 일부 배포판
systemd-journald	바이너리 저널, 구조화된 필드, systemd 통합	systemd 기반 배포판 전체

현재 대부분의 배포판에서 systemd-journald가 1차 로그 수집기로 동작하며, rsyslog가 journald로부터 메시지를 수신하여 파일 기록 및 원격 전송을 담당하는 이중 구조로 운영된다.

 

journald는 바이너리 형식으로 저널을 저장하므로 journalctl 명령으로 직접 조회할 수 있고, rsyslog의 imjournal 모듈이 이 저널 데이터를 읽어 텍스트 로그 파일로 변환하거나 원격 서버로 전달한다.

2️⃣ rsyslog 설정: 보안 이벤트 수집

rsyslog의 설정 파일은 /etc/rsyslog.conf이며, 기본 문법은 selector action 구조다. selector는 facility.severity 형식으로 필터링 조건을 지정한다.

# /etc/rsyslog.conf 기본 보안 관련 설정

# 인증 관련 로그 → /var/log/secure (RHEL 계열)
authpriv.*                              /var/log/secure

# 모든 emergency 메시지 → 모든 로그인 사용자 터미널에 출력
*.emerg                                 :omusrmsg:*

# 커널 메시지 → /var/log/kern.log
kern.*                                  /var/log/kern.log

# crit 이상의 메시지만 별도 파일에 기록
*.crit                                  /var/log/critical.log

 

🔵 원격 전송 설정 (클라이언트 측)

원격 syslog 서버로 보안 이벤트를 전송하는 설정이다.

@ 하나는 UDP, @@ 두 개는 TCP다.

# UDP 전송 (@ 한 개)
authpriv.*    @192.168.10.50:514

# TCP 전송 (@@ 두 개)
authpriv.*    @@192.168.10.50:514

# TLS 전송 (RFC 5425)
# 별도의 모듈 로드 및 인증서 설정 필요
$DefaultNetstreamDriverCAFile /etc/pki/tls/certs/ca-bundle.crt
$ActionSendStreamDriver gtls
$ActionSendStreamDriverMode 1
$ActionSendStreamDriverAuthMode x509/name
authpriv.*    @@192.168.10.50:6514

 

🔵 원격 수신 설정 (서버 측)

# UDP 수신 활성화
module(load="imudp")
input(type="imudp" port="514")

# TCP 수신 활성화
module(load="imtcp")
input(type="imtcp" port="514")

# 원격에서 수신된 로그를 호스트별 디렉토리에 분류 저장
$template RemoteLogs,"/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log"
*.* ?RemoteLogs

 

$template을 사용하면 원격 호스트의 로그를 호스트명 기준으로 디렉토리를 분리하여 저장할 수 있다.

대규모 인프라에서 수백 대의 엔드포인트 로그를 수신할 때 필수적인 설정이다.

 

5. 보안 이벤트별 Syslog 로그 분석

실제 보안 이벤트가 syslog에 어떻게 기록되는지 주요 사례별로 확인한다.

1️⃣ SSH 브루트포스 공격 탐지

SSH 인증 실패는 authpriv facility로 기록된다.

Jul 17 09:15:33 webserver01 sshd[2847]: Failed password for admin from 192.168.1.100 port 52413 ssh2
Jul 17 09:15:35 webserver01 sshd[2849]: Failed password for admin from 192.168.1.100 port 52415 ssh2
Jul 17 09:15:36 webserver01 sshd[2851]: Failed password for invalid user test from 192.168.1.100 port 52417 ssh2
Jul 17 09:15:38 webserver01 sshd[2853]: Failed password for admin from 192.168.1.100 port 52419 ssh2

 

동일 IP에서 짧은 시간 내에 반복되는 Failed password 메시지는 브루트포스 공격의 전형적인 패턴이다.

invalid user 키워드가 포함된 경우 존재하지 않는 계정에 대한 접속 시도로, 공격자가 사용자명을 추측하고 있음을 나타낸다.

# 최근 1시간 내 SSH 실패 횟수를 IP별로 집계
grep "Failed password" /var/log/secure | \
  awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -10

# 예상 출력
    847 192.168.1.100
     23 10.0.0.55
      3 172.16.0.12

 

2️⃣ 권한 상승 시도

sudo 사용 기록은 보안 감사에서 핵심적으로 확인하는 이벤트다.

Jul 17 10:22:15 webserver01 sudo: jsmith : TTY=pts/0 ; PWD=/home/jsmith ; USER=root ; COMMAND=/bin/bash
Jul 17 10:25:03 webserver01 sudo: jsmith : command not allowed ; TTY=pts/0 ; PWD=/tmp ; USER=root ; COMMAND=/usr/sbin/useradd hacker

 

첫 번째 줄은 jsmith 사용자가 sudo /bin/bash로 루트 셸을 획득한 기록이다.

두 번째 줄은 useradd 명령 실행이 sudoers 정책에 의해 거부된 기록으로, command not allowed 키워드로 식별된다.

 

3️⃣ 커널 수준 보안 이벤트

SELinux 거부, 커널 모듈 로드, OOM Killer 발동 등은 kern facility로 기록된다.

Jul 17 11:00:45 webserver01 kernel: type=1400 audit(1752750045.123:456): avc:  denied  { read } for  pid=3821 comm="httpd" name="shadow" dev="sda1" ino=524292 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:shadow_t:s0 tclass=file

 

이 로그는 SELinux가 httpd 프로세스의 /etc/shadow 파일 읽기를 거부한 기록이다.

웹 서버가 패스워드 파일에 접근을 시도하는 것은 명백한 이상 행위이며, 웹 셸 설치 또는 Local File Inclusion(LFI) 공격의 징후일 수 있다.

 

6. Syslog 기반 보안 모니터링 구성

1️⃣ 중앙 집중식 로그 수집 아키텍처

엔드포인트 보안 이벤트를 효과적으로 모니터링하려면 로그를 중앙 서버로 집약하는 아키텍처가 필요하다.

이 구조에서 syslog는 수집·전송 계층을 담당하고, SIEM은 분석·탐지 계층을 담당한다.

 

이 아키텍처의 핵심 설계 원칙은 다음과 같다.

• 전송 구간 암호화: 엔드포인트와 중앙 서버 간 TLS(TCP/6514)를 사용하여 로그 데이터의 기밀성을 보장한다.
• 큐잉(Queueing): rsyslog의 디스크 큐를 활성화하여 네트워크 단절 시에도 로그가 유실되지 않도록 한다.
• 정규화(Normalization): Relay 단계에서 다양한 포맷의 로그를 통일된 형식으로 변환한다.
• 이중 저장: SIEM에는 실시간 분석용으로, 별도 스토리지에는 장기 보관용으로 동시에 전송한다.

2️⃣ 로그 무결성 보장

보안 이벤트 로그가 증거로서의 가치를 가지려면 무결성이 보장되어야 한다.

공격자가 시스템을 탈취한 뒤 로그를 삭제·변조하는 것은 포렌식 회피의 기본 수법이다.

로그 무결성을 보장하는 방법은 다음과 같다.

• 원격 전송 즉시 수행: 로그 생성 시점에 즉시 원격 서버로 전송하면, 로컬 로그가 삭제되어도 원격 사본이 보존된다.
• Write-Once 스토리지: 로그 저장소를 추가 전용(append-only)으로 구성하여 기존 로그의 수정·삭제를 물리적으로 차단한다.
• 로그 서명: 주기적으로 로그 파일의 해시 체인을 생성하여 변조 여부를 검증할 수 있도록 한다. rsyslog의 omhiredis나 별도의 해시 체인 도구를 활용한다.
• 접근 제어: 로그 파일에 대한 권한을 최소화하고, 로그 서버에는 관리자 외 접근을 차단한다.

7. Syslog 메시지 흐름

SSH 브루트포스 공격이 발생했을 때, 이벤트가 생성되어 최종적으로 알림이 발생하기까지의 전체 흐름은 다음과 같다.

 

전체 흐름을 정리하면 다음과 같다.

1. 공격자가 SSH 로그인을 시도한다.
2. sshd가 인증 실패를 판정하고 syslog() 시스템 콜로 로그를 생성한다. 이때 Facility는 authpriv(10), Severity는 해당 이벤트의 심각도에 따라 결정된다.
3. journald가 이 메시지를 수신하여 바이너리 저널에 기록한다.
4. 공격자가 반복 시도하면 동일한 패턴의 로그가 누적된다.
5. rsyslog의 imjournal 모듈이 저널 데이터를 읽어 설정된 규칙에 따라 필터링한다.
6. 필터를 통과한 메시지가 TLS로 암호화되어 SIEM 서버로 전송된다.
7. SIEM이 상관분석 규칙(동일 IP에서 N회 이상 인증 실패)을 적용하여 알림을 발생시킨다.

이벤트 생성부터 알림까지의 지연 시간은 일반적으로 수 초 이내다.

이 지연을 최소화하는 것이 실시간 위협 탐지의 핵심이며, rsyslog의 큐 설정과 SIEM의 인제스트 파이프라인 튜닝이 여기에 관여한다.

 

8. 주요 보안 로그 파일 레퍼런스

Linux 시스템에서 보안 이벤트를 모니터링할 때 확인해야 하는 핵심 로그 파일을 정리한다.

로그 파일	내용	관련 Facility
/var/log/secure (RHEL) / /var/log/auth.log (Debian)	인증 관련 이벤트 전체	authpriv
/var/log/messages (RHEL) / /var/log/syslog (Debian)	시스템 전반 메시지	다수
/var/log/kern.log	커널 메시지 (SELinux, 모듈 로드 등)	kern
/var/log/audit/audit.log	auditd 기반 상세 감사 로그	logaudit
/var/log/faillog	로그인 실패 기록 (바이너리)	—
/var/log/lastlog	마지막 로그인 기록 (바이너리)	—
/var/log/wtmp	로그인/로그아웃 이력 (바이너리)	—

faillog, lastlog, wtmp는 바이너리 파일로 syslog 경로를 거치지 않으며, 각각 faillog, lastlog, last 명령으로 조회한다.

이 파일들은 syslog와 상호보완적인 관계에 있으며, 침해 사고 조사 시 syslog 텍스트 로그와 교차 검증하는 데 활용한다.

 

9. 마무리: Syslog의 한계와 보완

Syslog는 40년 넘게 사용되어 온 검증된 프로토콜이지만, 현대적 보안 모니터링의 요구사항을 syslog만으로 충족하기에는 한계가 존재한다.

• 비구조화 메시지 문제: RFC 5424의 Structured Data가 도입되었으나, 대부분의 애플리케이션은 여전히 자유 형식 텍스트로 MSG를 생성한다. 파싱 정확도는 정규 표현식의 품질에 의존하게 된다.
• 엔드포인트 가시성의 한계: syslog는 애플리케이션이 명시적으로 syslog() 호출을 해야만 기록된다. 프로세스 내부 행위(메모리 조작, 시스템 콜 패턴)까지 관찰하려면 auditd, eBPF 기반 도구(Falco, Tetragon), 또는 EDR 에이전트가 필요하다.
• UDP 전송의 신뢰성: 레거시 장비 중 UDP/514만 지원하는 경우가 여전히 있으며, 이 경우 네트워크 혼잡 시 로그 유실 가능성이 존재한다.

그럼에도 syslog는 엔드포인트 보안 이벤트 수집의 기본 인프라로서의 위치가 견고하다. auditd가 커널 수준의 상세 감사 로그를 제공하고, EDR이 행위 기반 탐지를 수행하며, SIEM이 상관분석과 알림을 담당하는 — 이 모든 보안 모니터링 체계의 전송 계층에 syslog가 위치한다.