037. SIEM·로그 수집 — 수집 파이프라인 장애와 백프레셔

changseop lee·7일 전

SIEM · 보안관제 › A. SIEM 구조와 로그 수집 · 37/50편
학습 단계: 저장·파이프라인
실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Wazuh 4.x 올인원 / Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

1. 개념

파이프라인 뒤쪽이 느려지면 앞쪽에 이벤트가 쌓입니다. 이를 백프레셔(backpressure)라고 하며, 버퍼가 가득 차면 결국 이벤트가 버려집니다. 공격으로 로그가 폭증할 때 가장 중요한 로그가 사라질 수 있다는 뜻입니다.

단계별 버퍼와 드롭 지점
 [agent]    client_buffer(queue_size, events_per_second)
             → 가득 차면 에이전트 측 이벤트 유실(버퍼 경고 기본 룰 202~204 계열, 버전 확인)
 [manager]  analysisd 큐
             → wazuh-analysisd.state 의 events_dropped 증가
 [filebeat] 내부 큐 → 인덱서 응답 지연 시 대기
 [indexer]  디스크 워터마크 초과 → 쓰기 차단(read_only)

예: 스캔 공격으로 web01 로그 폭증
 agent 초당 전송 상한(events_per_second) 도달 → 버퍼 누적 → 포화 → 유실

핵심: 공격 순간이 로그가 가장 많은 순간 — 드롭 지표를 상시 본다

에이전트의 events_per_second는 매니저 보호를 위한 상한입니다. 너무 낮으면 폭증 시 유실이 생기고, 너무 높으면 매니저가 과부하됩니다. 실측 EPS를 기준으로 조정합니다.

2. 왜 중요한가

  • 유실된 이벤트는 다시 복구하기 어렵습니다.
  • 폭증 순간은 공격이 진행 중일 가능성이 높은 시점입니다.
  • 단계별 지표를 알아야 병목 위치를 정확히 조정할 수 있습니다.

3. 핵심 명령어 / 설정

지점지표정상
에이전트버퍼 경고 Alert없음
analysisdevents_dropped0
filebeat큐·재시도 로그재시도 드묾
indexer디스크 사용률·쓰기 거부워터마크 미만

4. 실습 (실습 예시)

# 단계별 드롭·적체 지표 (실습 예시)
sudo grep -E "^(events_received|events_dropped|event_queue_usage)" /var/ossec/var/run/wazuh-analysisd.state 2>/dev/null
sudo jq -r 'select(.rule.id|test("^20[234]$")) | [.timestamp,.agent.name,.rule.description] | @tsv' /var/ossec/logs/alerts/alerts.json | tail -3
curl -sk -u 'admin:<비밀번호>' "https://localhost:9200/_cat/allocation?v&h=node,disk.percent"

5. 정상 상태

events_dropped='0'
버퍼 경고 Alert 없음
disk.percent 41

분석 엔진 드롭이 0이고, 에이전트 버퍼 경고가 없으며, 인덱서 디스크가 워터마크 아래인 상태가 정상입니다.

6. 이상 상태

03:20 web01 "Agent event queue is full. Events may be lost."
events_dropped='18234'
같은 시각: 웹 스캔 Alert 급증(31101 × 9,000)
  • 스캔 공격으로 로그 폭증 → 에이전트 버퍼 포화 → 유실
  • 유실 구간에 다른 중요 이벤트(로그인·실행)가 섞였을 수 있음
  • 유실 시간대는 호스트 로컬 로그로 보완 조사 필요

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

백프레셔 분석 흐름입니다(가상의 예시).

[드롭 신호] 버퍼 경고 · events_dropped 증가
   ↓
[시점·호스트] 폭증 원인(공격·장애·설정 변경)
   ↓
[유실 범위] 해당 시간대 호스트 로컬 로그와 대조
   ↓
[조정] events_per_second · 매니저 자원 · 노이즈 필터(046편)
   ↓
[재발 감시] 폭증 시뮬레이션 후 드롭 0 확인
원인조치
공격성 폭증노이즈 필터·출발지 차단
상한 과소events_per_second 상향
매니저 자원 부족증설·분산

유실 구간의 판단은 "탐지 못함"이 아니라 "볼 수 없었음"으로 기록하고, 로컬 로그로 메운 결과를 함께 남겨야 사고 보고서가 정확해집니다.

8. SOC 관제 포인트

  • 드롭 지표(버퍼 경고·events_dropped)를 실시간 감시합니다.
  • 폭증 Alert와 드롭이 겹치면 우선순위를 높입니다.
  • 유실 구간을 사고 보고에 명시하고 보완 조사 결과를 남깁니다.

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,siem_a,">
  <rule id="110360" level="12">
      <if_sid>203</if_sid>
      <description>에이전트 이벤트 큐 포화(로그 유실 발생 가능)</description>
    </rule>
</group>

에이전트 버퍼 포화를 알리는 기본 룰(203, 버전별 ID 확인 필요)을 상위로 두고 레벨을 높여 즉시 확인하도록 하는 예시입니다.

10. 대응 방법

  1. 초기 확인 — 드롭 지표와 발생 시점·호스트를 확인합니다.
  2. 범위 확인 — 폭증 원인과 유실 가능 범위를 확인합니다.
  3. 증거 확보 — 지표와 해당 시간대 로컬 로그를 보존합니다.
  4. 차단/조치 — 버퍼 상한·노이즈 필터·자원을 조정합니다.
  5. 재발 방지 — 드롭 지표 상시 감시와 폭증 대비를 운영합니다.

11. 핵심 정리

지점지표
에이전트버퍼 포화 경고
매니저events_dropped
인덱서디스크 워터마크
원칙유실은 볼 수 없었음으로 기록
면접 포인트"공격 순간이 로그가 가장 많은 순간 — 버퍼가 차면 가장 중요한 로그부터 사라질 수 있다"

12. 다음 편 예고

다음 편 038. SIEM·로그 수집 — 로그 전송 보안 — TLS와 인증 에서는 에이전트↔매니저, 매니저↔인덱서, syslog 전송 구간의 암호화·인증 상태를 점검하고 평문 전송·인증서 만료 위험을 다룹니다.


이전 편: 036. SIEM·로그 수집 — Logstash 필터 — grok·mutate·date
📚 시리즈 전체 보기: SIEM · 보안관제

profile
코드에 숨겨진 위협을 읽고 AI로 보안의 미래를 설계합니다. 프론트엔드 개발 경험을 자산 삼아 더 견고하고 지능적인 보안 운영 시스템을 구축해 나가는 과정을 기록합니다

0개의 댓글