046. Linux 서버 보안 — 설정 변경 이벤트의 SIEM·ELK 연계

ELK Linux 서버 보안 SIEM Soc 리눅스 보안관제 시스템 보안 · 취약점 시스템보안

시스템 보안 · 취약점

목록 보기

46/150

시스템 보안 · 취약점 › A. Linux 서버 보안 설정 · 46/50편 (전체 046/450)
학습 단계: 5단계 · SOC 관제 연계
실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

1. 개념

지금까지 만든 로그원은 서로 다른 파일·형식에 흩어져 있습니다. SIEM 연계의 목적은 이를 같은 필드 이름으로 정규화해 한 곳에서 검색하는 것입니다.

[Linux 서버]                         [수집·처리]                 [저장·분석]
/var/log/audit/audit.log  ─┐
/var/log/secure, auth.log ─┼─→ Wazuh agent ──→ Wazuh manager ──→ (Wazuh) indexer / Elasticsearch
FIM · SCA · 점검 로그      ─┘      (디코딩·룰 매칭)      alerts.json      ↓
                                                                  Kibana / Wazuh 대시보드
또는
/var/log/* ──→ Filebeat ──→ Logstash (grok·kv 파싱) ──→ Elasticsearch ──→ Kibana

어느 경로든 핵심은 같습니다. "누가(user) · 어디서(host, src ip) · 무엇을(action, file) · 결과(result)" 필드가 일관되게 채워져야 합니다.

2. 왜 중요한가

서버 한 대의 로그로는 "이 변경이 다른 서버에서도 일어났는가?"에 답할 수 없습니다. 중앙 수집이 있어야 범위 확인이 가능합니다.
로컬 로그는 지워질 수 있지만, 이미 SIEM에 저장된 사본은 남습니다(029편).
필드가 정규화되어 있어야 서로 다른 로그원(auditd의 auid, sudo의 사용자명)을 같은 사용자로 묶어 볼 수 있습니다.

3. 핵심 명령어 / 설정

로그원	Wazuh 주요 필드(예시)	의미
auditd	`data.audit.key`, `data.audit.auid`, `data.audit.exe`, `data.audit.session`	감사 키·행위자·실행 파일·세션
sudo	`data.srcuser`, `data.dstuser`, `data.command`	실행 사용자·대상 사용자·명령
sshd	`data.srcip`, `data.dstuser`	출발지 IP·로그인 계정
FIM	`syscheck.path`, `syscheck.event`, `syscheck.sha256_after`	파일·이벤트 종류·해시
SCA	`data.sca.check.title`, `data.sca.check.result`	점검 항목·결과
공통	`agent.name`, `rule.id`, `rule.level`, `rule.groups`, `timestamp`	호스트·룰·심각도·시각

필드명은 디코더·버전에 따라 다를 수 있으므로, 실제 Alert 문서 하나를 열어 필드 목록을 먼저 확인하는 습관이 중요합니다.

4. 실습 (실습 예시)

# Kibana(KQL) 검색 예시 — 인덱스: wazuh-alerts-*

# 1) 특정 서버의 하드닝 관련 Alert (037·039편 그룹)
agent.name : "rocky9-web01" and rule.groups : "hardening_drift"

# 2) 계정·권한·인증 설정 변경(030편 키)
data.audit.key : ("identity" or "priv_conf" or "auth_conf" or "sshd_config")

# 3) 같은 행위자(auid 1002)의 모든 Alert
data.audit.auid : "1002" or data.srcuser : "devops"

# 4) 핵심 파일 FIM 변경
syscheck.path : (/etc/ssh/* or /etc/sudoers* or /etc/passwd)

# 5) 레벨 10 이상, 최근 24시간, 호스트별 집계 → 시각화(Bar, Terms: agent.name)
rule.level >= 10

Logstash 경로를 쓰는 경우 sudo 로그는 다음처럼 파싱할 수 있습니다(분석 방법 예시).

filter {
  if [program] == "sudo" {
    grok { match => { "message" => "%{USER:sudo.user} : TTY=%{DATA:sudo.tty} ; PWD=%{DATA:sudo.pwd} ; USER=%{USER:sudo.runas} ; COMMAND=%{GREEDYDATA:sudo.command}" } }
  }
}

5. 정상 상태

설정 변경 대시보드의 정상 패턴은 업무 시간대에 소수의 변경이 관리 계정으로 발생하는 모습입니다.

[설정 변경 대시보드 — 최근 7일]
시간대 분포   : 09~18시 집중
변경 주체 Top : admin1(관리자) 32건, root(패키지 업데이트) 15건
변경 대상 Top : /etc/httpd/conf.d/ 9건, /etc/ssh/sshd_config.d/ 1건(CHG-2026-0915)
하드닝 FAIL   : 0건

6. 이상 상태

[설정 변경 대시보드 — 10월 1일]
시간대 분포   : 02~04시 급증
변경 주체 Top : devops 27건 (평소 0~2건)
변경 대상 Top : sshd_config.d, sudoers.d, profile.d, systemd/system, hosts, rsyslog.d
하드닝 FAIL   : rocky9-web01 5건 / 03:30 이후 rocky9-web01 수신 없음

평소 기준선(시간대·주체·대상)과 비교했을 때 세 축이 모두 벗어나고, 마지막에 수신이 끊긴 형태입니다. 대시보드는 이런 "평소와 다름"을 한눈에 보이게 하는 것이 목적입니다.

7. 로그 분석 (분석 방법)

SIEM에서 같은 행위자 기준으로 정렬한 결과 예시입니다(가상의 예시 — 검색 결과 요약).

timestamp            agent         rule.id  level  description
02:10:44  rocky9-web01  5715     3     sshd: authentication success (devops from 192.168.56.77)
02:11:30  rocky9-web01  5402     3     Successful sudo to ROOT executed (devops)
02:13:00  rocky9-web01  100160   10    키 인증 전용 정책 서버에서 password 인증 성공 ...
02:14:09  rocky9-web01  100110   12    UID 0 계정 생성 탐지
02:16:00  rocky9-web01  100360   8     계정/권한/인증 설정 변경: priv_conf
03:30:01  rocky9-web01  100240   12    SELinux Enforcing 해제(setenforce 0)
03:30:43  rocky9-web01  100440   11    보안 서비스 중지: unit=wazuh-agent
03:30:45  (manager)     -        -     agent disconnected: rocky9-web01

개별 Alert의 레벨은 제각각이지만, 같은 출발지·같은 계정으로 묶으면 침해 흐름 하나로 읽힙니다.

8. SOC 관제 포인트

설정 변경 대시보드는 시간대·주체·대상·하드닝 FAIL·수신 공백 다섯 패널을 기본으로 구성합니다.
필드 정규화 표(로그원별 사용자·호스트·대상 필드)를 문서로 유지합니다.
저장된 검색(Saved Search)으로 038편의 세션 추적 쿼리를 바로 실행할 수 있게 해 둡니다.

9. 탐지 규칙

SIEM 측에서는 단일 이벤트 룰 위에 집계 기반 탐지를 추가합니다(개념 예시).

조건: 동일 agent.name 에서 1시간 내
      rule.groups:"hardening_drift" 3건 이상
      AND 변경 주체가 평소 변경 주체 목록에 없음
결과: 우선순위 High Incident 생성, 담당자 알림

Wazuh 룰의 frequency/timeframe(037편 100430)은 에이전트 단위 상관에 적합하고, 여러 서버를 가로지르는 상관(같은 계정이 여러 서버에서 변경)은 SIEM 검색·알림 기능으로 구현하는 것이 일반적입니다.

10. 대응 방법

초기 확인 — 대시보드에서 기준선을 벗어난 축(시간·주체·대상)과 관련 Alert를 확인합니다.
범위 확인 — 같은 주체·출발지 IP로 전체 서버를 검색해 영향 범위를 확인합니다.
증거 확보 — 검색 결과(쿼리·시간 범위 포함)를 내보내 증거로 보관합니다.
차단/조치 — 범위 확인 결과에 따라 계정·IP 차단, 서버 격리를 진행합니다.
재발 방지 — 필드 정규화 문서, 기본 대시보드, 집계 탐지 조건을 운영 표준으로 유지합니다.

11. 핵심 정리

구분	핵심 내용
수집 경로	Wazuh agent→manager→indexer 또는 Filebeat→Logstash→Elasticsearch
정규화 핵심	누가 · 어디서 · 무엇을 · 결과 필드 일관성
검색	KQL: data.audit.key, syscheck.path, data.sca.check.result 등
대시보드	시간대 · 주체 · 대상 · 하드닝 FAIL · 수신 공백
면접 포인트	"개별 Alert 레벨보다 같은 행위자로 묶었을 때의 흐름"