📄 2026.01.23 (Day 62) - Splunk Forwarder 구성 및 Wazuh HIDS 환경 구축

1. 핵심 개념 정리

Splunk 분산 아키텍처

# 핵심 개념 설명 실무/보안 관점
1 Universal Forwarder 경량화된 로그 수집 및 전송 에이전트 각 시스템에 설치하여 중앙 집중식 로그 수집 구조 구축
2 Indexer 수집된 데이터를 인덱싱하고 검색 가능하게 저장 대용량 로그 데이터의 빠른 검색과 분석 지원
3 9997 포트 Forwarder -> Indexer 간 데이터 전송 전용 포트 방화벽 정책에서 해당 포트 허용 필수
4 inputs.conf Forwarder에서 수집할 로그 파일 및 인덱스 정의 로그 유형별 분리 저장으로 검색 효율성 향상
5 인덱스 분리 전략 waf(인증 로그), web(웹 로그), main(시스템) 분리 목적별 접근 제어 및 검색 성능 최적화

Wazuh HIDS 구성 요소

# 핵심 개념 설명 실무/보안 관점
6 Wazuh Manager OSSEC 기반 중앙 관리 서버 모든 에이전트 데이터를 수집하고 룰 엔진 구동
7 Agent 방식 대상 시스템에 에이전트 설치 후 실시간 모니터링 세밀한 호스트 레벨 보안 이벤트 탐지 가능
8 Agentless 방식 SSH로 원격 명령 실행 후 결과 비교 에이전트 설치 불가 환경에서도 모니터링 가능
9 Sysmon 연동 Windows 상세 활동 로그를 Wazuh로 통합 프로세스 생성, 네트워크 연결 등 고급 위협 탐지
10 local_rules.xml 커스텀 탐지 룰 정의 파일 조직 특화 보안 정책 및 위협 시나리오 구현

통합 모니터링 환경

# 핵심 개념 설명 실무/보안 관점
11 멀티 플랫폼 수집 Linux(auth.log, nginx), Windows(Event Log) 이기종 환경 통합 가시성 확보
12 프록시 우회 설정 로컬 주소에 프록시 미사용 설정 내부망 Splunk 접속 시 프록시 간섭 방지
13 호스트명 고유성 각 시스템별 고유 hostname 설정 필수 Wazuh에서 에이전트 식별 및 충돌 방지
14 IP 고정 설정 netplan으로 고정 IP 할당 안정적인 로그 수집 및 에이전트 통신 보장
15 통합 보안 체계 Splunk(로그 분석) + Wazuh(실시간 탐지) 사후 분석과 실시간 대응의 시너지 효과

2. 실습 내용 정리

실습 60-1: Ubuntu Forwarder 설치 및 로그 전송 설정

목표: Ubuntu 시스템의 주요 보안 로그를 Splunk 서버로 전송

실습 환경:

  • Splunk Server: 192.168.2.x (Indexer/Search Head)
  • Ubuntu Forwarder: 192.168.2.y
  • 수집 대상: /var/log/auth.log, /var/log/nginx/access.log, /var/log/ufw.log

실습 단계:

  1. Splunk Universal Forwarder 설치: dpkg -i splunkforwarder-8.2.0-e053ef3c985f-linux-2.6-amd64.deb
  2. SWID 태그 복사: swidtag 파일 /opt/splunkforwarder/etc/ 경로로 복사
  3. 부팅 시 자동 시작: /opt/splunkforwarder/bin/splunk enable boot-start
  4. Splunk 서버로 데이터 전송 설정: /opt/splunkforwarder/bin/splunk add forward-server 192.168.2.x:9997
  5. inputs.conf 수정: nano /opt/splunkforwarder/etc/system/local/inputs.conf

inputs.conf 설정 내용:

[default]

  • host = 192.168.2.x

[monitor:///var/log/auth.log]

  • disabled = false
  • index = waf
  • sourcetype = access_combined

[monitor:///var/log/nginx/access.log]

  • disabled = false
  • index = web
  • sourcetype = access_combined

[monitor:///var/log/ufw.log]

  • disabled = false
  • index = main
  • sourcetype = access_combined
  1. Forwarder 재시작: /opt/splunkforwarder/bin/splunk restart

확인 항목:

  • auth.log -> waf 인덱스 (인증 관련 보안 이벤트)
  • nginx/access.log -> web 인덱스 (웹 접근 로그)
  • ufw.log -> main 인덱스 (방화벽 로그)
  • 각 로그 파일의 라인 수 확인으로 수집 여부 검증

보안 인사이트:

  • 인덱스 분리를 통해 로그 유형별 접근 제어 및 검색 효율성 향상
  • auth.log 실시간 모니터링으로 SSH 무차별 대입 공격 조기 탐지
  • nginx access.log로 웹 공격 패턴 분석 및 이상 트래픽 식별

실습 60-2: Splunk 서버 리스닝 포트 활성화

목표: Splunk 서버에서 Forwarder 데이터 수신 준비

실습 단계:

  1. Splunk 서버에서 9997 포트 리스닝 활성화: /opt/splunk/bin/splunk enable listen 9997
  2. 관리자 인증 (Splunk username: admin)
  3. 리스닝 상태 확인: netstat -tuln | grep 9997

데이터 흐름:

  1. Ubuntu Forwarder에서 로그 파일 모니터링 시작
  2. 변경 사항 발생 시 즉시 데이터 수집
  3. 9997 포트를 통해 Splunk 서버로 전송

방화벽 설정:

  • Splunk 서버: 9997/tcp 인바운드 허용
  • Forwarder: 9997/tcp 아웃바운드 허용
  • 내부망에서만 통신하도록 소스 IP 제한 권장

실습 60-3: 로그 수집 검증 및 공격 시뮬레이션

목표: Forwarder 정상 수집 확인 및 Kali Linux에서 공격 시뮬레이션

실습 단계:

  1. 로그 파일 라인 수 확인 (수집 전): wc -l /var/log/ufw.log / nginx/access.log / auth.log
  2. 방화벽 활성화 및 SSH 포트 허용: ufw enable && ufw allow 22/tcp && reboot
  3. SSH 서버 설치 (없는 경우): apt install -y openssh-server
  4. Kali Linux에서 SSH 접속 실패 시도 (무차별 대입 시뮬레이션):
  5. 로그 파일 라인 수 재확인 (수집 후): wc -l /var/log/auth.log (“Failed password” 로그 증가 확인)

Splunk 검색 쿼리 (SSH 인증 실패 로그):

  • index=waf sourcetype=“access_combined” “Failed password” | rex “from (?<src_ip>\d+.\d+.\d+.\d+)” | stats count as fail_cnt by src_ip | sort - fail_cnt | head 20

발견 가능한 공격 패턴:

  • SSH 무차별 대입 공격: 동일 IP에서 다수 인증 실패
  • 포트 스캔: 짧은 시간 내 다수 포트 접근 시도
  • 웹 공격: SQL Injection, XSS, Directory Traversal 시도

탐지 기준 및 대응 방안:

  • 5분 내 동일 IP에서 10회 이상 인증 실패 -> 무차별 대입 공격
  • 404 에러 다발 발생 -> 디렉터리 스캔 의심
  • 임계치 초과 IP 자동 차단 (fail2ban 연동)
  • 실시간 알람 발송 (이메일, Slack)
  • 위협 인텔리전스 DB 조회

실습 60-4: Windows Forwarder 설치 및 프록시 설정

목표: Windows 10 시스템의 이벤트 로그를 Splunk로 전송하고 프록시 문제 해결

실습 환경:

  • Windows 10: DESKTOP-IRB3M7S
  • Splunk Server: 192.168.2.x
  • 수집 대상: Application, System, Security 이벤트 로그

실습 단계:

  1. Splunk Universal Forwarder 설치 (Windows용): 관리자 권한으로 설치 실행

  2. inputs.conf 수정 경로: C:\Program Files\SplunkUniversalForwarder\etc\system\local\inputs.conf

    [default]

    • host = DESKTOP-IRB3M7S

    [WinEventLog://Application]

    • disabled = 0 / index = main

    [WinEventLog://System]

    • disabled = 0 / index = main

    [WinEventLog://Security]

    • disabled = 0 / index = main / current_only = 0 / checkpointInterval = 5

  3. Forwarder 재시작: “C:\Program Files\SplunkUniversalForwarder\bin\splunk.exe” restart

  4. 프록시 설정 해제 (중요!):

    • inetcpl.cpl 실행 -> 연결 탭 -> LAN 설정
    • “로컬 주소에 대해 프록시 서버 사용 안 함” 체크

  5. Splunk Web UI 접속 테스트: http://192.168.2.x:8000

프록시 설정 문제 원인 및 해결:

문제 상황:

  • 기본 프록시 설정 시 로컬 IP(192.168.x.x)도 프록시 경유 시도
  • 내부망 Splunk 서버 접속 불가 발생

해결 방법:

  • “로컬 주소에 프록시 사용 안 함” 옵션 활성화
  • 내부 IP 대역(192.168.0.0/16)은 직접 연결
  • 외부 인터넷만 프록시 경유

Splunk 검색으로 Windows 호스트 확인:

  • index=* host=“DESKTOP-IRB3M7S” | stats count by source sourcetype
  • index=* host=“DESKTOP-IRB3M7S” source=“WinEventLog:Security” | head 20
  • index=* host=“DESKTOP-IRB3M7S” source=“WinEventLog:Security” | stats count by EventCode | sort - count

보안 인사이트:

  • Windows 이벤트 로그는 호스트 기반 침입 탐지의 핵심 데이터
  • EventCode 4625(로그온 실패), 4624(로그온 성공) 조합 분석으로 계정 탈취 탐지
  • current_only = 0 설정으로 과거 로그까지 수집하여 이력 분석 가능

실습 60-5: Wazuh 환경 구축

목표: Wazuh HIDS 서버 및 에이전트 설치로 호스트 기반 보안 모니터링 체계 구축

실습 환경:

  • Wazuh Server: 192.168.2.10 (Ubuntu 20.04)
  • Wazuh Agent1: 192.168.2.11 (Ubuntu 20.04, Agent 방식)
  • Wazuh Agent2: 192.168.2.12 (Ubuntu 20.04, Agentless 방식)
  • Wazuh Agent3: 192.168.2.13 (Windows 10, Agent 방식)

실습 단계:

  1. 모든 시스템 호스트명 변경 (중복 방지 필수!):

    • hostnamectl set-hostname wazuh-server (192.168.2.10)
    • hostnamectl set-hostname wazuh-agent1 (192.168.2.11)
    • hostnamectl set-hostname wazuh-agent2 (192.168.2.12)

  2. IP 고정 설정 (netplan): nano /etc/netplan/00-installer-config.yaml

    network: version: 2 / renderer: networkd ethernets: ens32: dhcp4: no addresses: [192.168.2.10/24] (각 시스템별로 IP 변경) gateway4: 192.168.2.2 nameservers: addresses: [8.8.8.8, 8.8.4.4]

  3. netplan 적용: netplan apply && reboot

  4. Wazuh 서버 설치 (wazuh-server에서):

  5. Wazuh 서비스 상태 확인:

    • systemctl status kibana / elasticsearch / filebeat / wazuh-manager

  6. Wazuh Agent 설치 (agent1에서):

    • systemctl daemon-reload
    • systemctl enable wazuh-agent && systemctl start wazuh-agent && systemctl status wazuh-agent

Agentless 방식 설정 (agent2 대상):

Wazuh 서버에서 실행:

  1. cd /var/ossec/agentless
  2. Agentless 호스트 등록: ./register_host.sh add wazuh@192.168.2.12 123456
  3. 등록된 호스트 확인: ./register_host.sh list
  4. ossec.conf에 모니터링 설정 추가: nano /var/ossec/etc/ossec.conf

설정 내용:

  • type: ssh_generic_diff / frequency: 10 / host: wazuh@192.168.2.12 / state: periodic_diff
  • arguments: tail -n 1 /etc/passwd (10초마다 마지막 줄 비교)
  • arguments: tail -n 1 /etc/shadow (10초마다 마지막 줄 비교)
  1. Wazuh Manager 재시작: systemctl restart wazuh-manager

Agentless 동작 방식:

  1. Wazuh 서버가 SSH로 agent2에 접속
  2. 지정된 명령어(tail -n 1 /etc/passwd) 실행
  3. 이전 실행 결과와 비교(diff)
  4. 변경 사항 발견 시 알람 발생

보안 인사이트:

  • Agent 방식: 실시간 파일 무결성 검증, 프로세스 모니터링
  • Agentless 방식: 레거시 시스템, 에이전트 설치 불가 환경 커버
  • /etc/passwd, /etc/shadow 변경 탐지로 계정 추가/변조 즉시 포착

3. Splunk vs Wazuh 비교

솔루션 특성 비교

항목 Splunk Wazuh 사용 시기/적용 방안
핵심 기능 로그 수집, 인덱싱, 빠른 검색 호스트 침입 탐지, 파일 무결성 점검 Splunk는 로그 분석, Wazuh는 실시간 위협 탐지
아키텍처 Forwarder -> Indexer -> Search Head Manager <- Agent/Agentless Splunk는 분산, Wazuh는 중앙 집중
분석 방식 SPL 쿼리 기반 사후 분석 룰 기반 실시간 이벤트 탐지 Splunk는 포렌식, Wazuh는 실시간 대응
라이선스 상용 (무료 500MB/일 제한) 오픈소스 (무료) 비용 고려 시 Wazuh 우선 검토

실전 활용 시나리오

시나리오 Splunk 활용 Wazuh 활용 통합 효과
SSH 무차별 대입 공격 auth.log에서 Failed password 패턴 검색 실시간 5716 룰로 즉시 탐지 Splunk로 공격 추이 분석 + Wazuh로 즉각 차단
웹 공격 탐지 nginx 로그에서 SQL Injection 패턴 검색 웹쉘 업로드 시 파일 무결성 알람 Splunk로 공격 유형 분류 + Wazuh로 피해 확산 방지
계정 탈취 분석 로그온 성공/실패 타임라인 재구성 /etc/passwd 변경 즉시 탐지 Splunk로 침투 경로 추적 + Wazuh로 권한 상승 차단
컴플라이언스 점검 접근 로그 장기 보관 및 감사 PCI-DSS, ISMS-P 룰셋 자동 점검 규제 준수 증빙 자동화

4. 심화 분석

프록시 우회 설정 상세 분석

구분 문제 상황 원인 분석 해결 방법 실무 적용
증상 Splunk Web UI 접속 불가 로컬 IP도 프록시 경유 시도 inetcpl.cpl -> 프록시 예외 설정 기업 환경에서 내부 서비스 접속 시 필수 설정
검증 브라우저 개발자 도구 확인 프록시 서버로 요청 전송 확인 “로컬 주소에 프록시 사용 안 함” 체크 네트워크 트러블슈팅 기본 절차
확장 Forwarder 데이터 미전송 9997 포트도 프록시 경유 시도 방화벽 룰에서 직접 연결 허용 모든 내부 IP 대역에 대해 프록시 예외 적용

inputs.conf 설정 전략

인덱스 분리 전략:

  • [monitor:///var/log/auth.log] -> index = waf (인증/접근 제어 관련)
  • [monitor:///var/log/nginx/access.log] -> index = web (웹 애플리케이션 로그)
  • [monitor:///var/log/ufw.log] -> index = main (시스템/방화벽 로그)

실무 적용 포인트:

  1. 인덱스별 접근 권한 분리 (RBAC)
  2. 검색 성능 향상 (필요한 인덱스만 조회)
  3. 데이터 보존 정책 차등 적용 (규제 준수)

5. 실무/보안 적용

보안 전문가 관점 - 탐지/대응 포인트

단계/유형 탐지 포인트 로그 예시 대응 방안
초기 침투 다수 인증 실패, 알려지지 않은 IP, 비정상 접속 시간 Failed password for admin from 203.x.x.x 해당 IP 즉시 차단, 계정 잠금 정책 적용, 위협 인텔리전스 조회
정찰 활동 404 에러 다발, 디렉터리 스캔, SQL Injection 시도 GET /../../../etc/passwd 404 WAF 정책 업데이트, 공격 IP 블랙리스트 등록, 취약점 긴급 패치
권한 상승 /etc/passwd 변경, sudo 사용 급증, 계정 추가 useradd hacker 변경사항 즉시 롤백, 침해 계정 격리, 포렌식 이미지 확보

Splunk 핵심 검색 쿼리

SSH 무차별 대입 공격 탐지:

  • index=waf sourcetype=“access_combined” “Failed password” | rex “from (?<src_ip>\d+.\d+.\d+.\d+)” | stats count as fail_cnt by src_ip | sort - fail_cnt | head 20

웹 공격 패턴 탐지:

  • index=web sourcetype=“access_combined” (“union select” OR “select * from” OR “etc/passwd” OR “script”) | stats count by clientip, uri | sort - count

404 에러 다발 (디렉터리 스캔 의심):

  • index=web sourcetype=“access_combined” status=404 | stats count as notfound_cnt by uri | sort - notfound_cnt | head 20

클라이언트 IP별 요청 수:

  • index=web sourcetype=“access_combined” | stats count as hits by clientip | sort - hits | head 20

Wazuh 룰셋 예시 (local_rules.xml)

SSH 인증 실패 탐지 (기본 룰 5716 확장):

  • rule id=“100001” level=“5”: if_sid=5716, srcip=1.1.1.1 -> SSH authentication failed from IP 1.1.1.1

Agentless로 /etc/passwd 변경 탐지:

  • rule id=“100002” level=“12”: if_sid=550, match=/etc/passwd -> User account file modified

6. 배운 점 및 인사이트

새로 알게 된 점

  • Forwarder 아키텍처의 효율성: Universal Forwarder를 통해 각 시스템에서 발생하는 로그를 중앙 Indexer로 집중시키는 분산 구조가 대규모 환경에서 얼마나 효과적인지 체감했다. 특히 경량 에이전트 방식이라 시스템 부하가 거의 없다는 점이 인상적이었다.

  • 프록시 설정의 함정: 기업 환경에서 흔히 설정된 프록시가 내부망 서비스 접속까지 방해할 수 있다는 점을 처음 알았다. “로컬 주소에 프록시 사용 안 함” 설정의 중요성을 실감했고, 보안 솔루션 구축 시 반드시 확인해야 할 체크리스트 항목이다.

  • 인덱스 분리 전략: 로그 유형별로 인덱스를 분리(waf, web, main)하면 검색 성능뿐만 아니라 접근 제어, 데이터 보존 정책까지 세밀하게 관리할 수 있다는 점을 배웠다.

  • Wazuh Agentless의 실용성: 에이전트 설치가 불가능한 레거시 시스템이나 임베디드 장비에서도 SSH를 통한 원격 명령 실행으로 보안 모니터링을 구현할 수 있다는 점이 매우 실용적이었다. /etc/passwd, /etc/shadow 같은 중요 파일의 변경을 10초마다 자동 점검하는 방식이 효과적이다.

  • 호스트명 고유성의 중요성: Wazuh에서 각 에이전트를 식별하는 기준이 호스트명이기 때문에, 중복 시 에이전트 충돌이 발생한다. 시스템 구축 초기에 네이밍 컨벤션을 확립하는 것이 중요하다.

이전 학습과의 연결고리

  • Splunk 기초와 연계: 이전에 배운 SPL 쿼리 문법(stats, sort, rex)을 실제 보안 로그 분석에 적용했다. 특히 정규표현식으로 IP 주소를 추출하는 rex 명령어가 실무에서 얼마나 유용한지 체감했다.

  • 웹 해킹 실습 확장: 이전에 학습한 SQL Injection, XSS 공격 기법을 직접 시뮬레이션하고, nginx access.log에서 해당 패턴을 Splunk로 탐지하는 전 과정을 경험했다.

  • 네트워크 보안 -> SIEM 전환: 이전에 학습한 방화벽(ufw), 네트워크 스캔(nmap) 개념이 Splunk로 수집되어 통합 분석되는 과정을 보면서, 개별 보안 도구들이 SIEM으로 통합되는 흐름을 이해하게 되었다.

실무 적용 아이디어

보안 전문가 관점:

  • 계층적 모니터링 체계: Splunk로 모든 로그를 수집/검색하고, Wazuh로 크리티컬 호스트(DB 서버, 도메인 컨트롤러)의 실시간 무결성을 점검하는 이중 방어 체계 구축. DMZ의 웹 서버는 Splunk로 트래픽 분석, 내부 서버는 Wazuh로 파일 무결성 점검하는 역할 분담이 효과적이다.

  • 자동화된 위협 대응: Splunk에서 탐지된 공격자 IP를 자동으로 방화벽 차단 목록에 추가하거나, Wazuh의 Active Response 기능과 연계하여 침해 계정을 즉시 잠금 처리하는 SOAR 파이프라인 구축이 가능하다.

  • 컴플라이언스 자동화: Wazuh의 PCI-DSS, ISMS-P 관련 기본 룰셋을 활용하면 정기 감사 시 필요한 증빙 자료를 수작업 없이 자동 생성할 수 있어 업무 효율이 크게 개선될 것이다.

침해사고 대응 관점:

  • 타임라인 재구성: Splunk의 transaction 명령어로 공격자의 전체 활동 흐름(초기 접근 -> 정찰 -> 권한 상승 -> 데이터 유출)을 시간 순서대로 재구성하여 침해 경로를 명확히 파악할 수 있다.

  • 포렌식 증거 확보: Wazuh의 Syscheck 기능으로 변경된 파일의 해시값과 변경 시점을 자동 기록하므로, 법적 대응 시 신뢰성 있는 디지털 증거로 활용 가능하다.

7. Quick Reference

Splunk Forwarder 명령어 모음

설치 및 초기 설정:

  • dpkg -i splunkforwarder-*.deb
  • /opt/splunkforwarder/bin/splunk enable boot-start

서버 연결:

  • /opt/splunkforwarder/bin/splunk add forward-server [서버IP]:9997

서비스 관리:

  • /opt/splunkforwarder/bin/splunk start / restart / status

설정 확인:

  • /opt/splunkforwarder/bin/splunk list forward-server
  • /opt/splunkforwarder/bin/splunk list monitor

Wazuh 관리 명령어

서비스 상태 확인:

  • systemctl status wazuh-manager / kibana / elasticsearch / filebeat

Agent 관리:

  • systemctl start wazuh-agent / enable wazuh-agent / status wazuh-agent

Agentless 호스트 관리:

  • cd /var/ossec/agentless
  • ./register_host.sh add [user@IP] [password]
  • ./register_host.sh list

핵심 Splunk 검색 쿼리

구분 쿼리 핵심 키워드 주요 내용 적용 방법
IP별 집계 index=web stats count by clientip sort -count stats, sort
패턴 탐지 index=web (“union select” OR “script”) OR, AND 공격 키워드 검색 SQL Injection, XSS 시도 탐지
IP 추출 rex “from (?<src_ip>\d+.\d+.\d+.\d+)” rex 정규식으로 IP 추출
404 분석 index=web status=404 stats count by uri stats 404 에러 URI 집계

프록시 설정 체크리스트

Windows 프록시 우회:

  • inetcpl.cpl 실행
  • 연결 탭 -> LAN 설정 클릭
  • “로컬 주소에 대해 프록시 서버 사용 안 함” 체크
  • 브라우저 재시작 후 192.168.x.x 접속 테스트

Linux 프록시 우회:

  • export no_proxy=“localhost,127.0.0.1,192.168.0.0/16”
  • .bashrc에 영구 저장 후 source ~/.bashrc 로 적용

Wazuh 초기 설정 체크리스트:

  • 모든 시스템 호스트명 고유하게 설정
  • IP 고정 설정 (netplan)
  • SSH 키 기반 인증 설정 (Agentless용)
  • 방화벽에서 Wazuh 포트 허용 (1514, 1515)

8. 트러블슈팅

문제 원인 해결 방법
Splunk Web UI 접속 불가 프록시 설정으로 로컬 주소도 프록시 경유 inetcpl.cpl -> “로컬 주소에 프록시 사용 안 함” 체크, 브라우저 캐시 삭제 후 재접속, 직접 IP:포트로 접속 시도
Forwarder 데이터 미수신 9997 포트 방화벽 차단 또는 리스닝 미활성화 ufw allow 9997/tcp, Splunk 서버에서 splunk enable listen 9997 실행, netstat -tuln
Wazuh Agent 연결 실패 호스트명 중복 또는 서버 IP 오타 hostnamectl 로 각 시스템 호스트명 고유성 확인, /var/ossec/etc/ossec.conf에서 서버 IP 검증, systemctl restart wazuh-agent 후 재연결
Agentless SSH 접속 실패 SSH 키 인증 미설정 또는 비밀번호 오류 ssh-keygen 후 ssh-copy-id wazuh@대상IP, register_host.sh에서 올바른 비밀번호 입력, 대상 시스템에서 SSH 서비스 실행 확인
Windows 이벤트 로그 미수집 SplunkForwarder 서비스 권한 부족 SplunkForwarder 서비스가 SYSTEM 계정으로 실행 중인지 확인, current_only = 0 설정으로 과거 로그도 수집, 이벤트 뷰어에서 해당 로그 접근 가능 여부 확인

Today’s Insight:

Splunk와 Wazuh를 통합 운영하면서 단일 SIEM의 한계를 넘어선 입체적 보안 모니터링의 가능성을 확인했다. Splunk는 방대한 로그를 빠르게 검색하고 공격 패턴을 분석하는 데 탁월하지만, 호스트 레벨의 미세한 변화를 실시간으로 포착하는 데는 Wazuh의 파일 무결성 점검이 더 효과적이었다. 특히 프록시 설정 같은 사소해 보이는 환경 요소가 실제로는 모니터링 체계의 가용성을 좌우할 수 있다는 점을 배웠다. 앞으로는 공격 시나리오별로 어느 도구가 더 적합한지 판단하는 감각을 키우고, 자동화된 위협 대응 파이프라인 구축으로 나아가야겠다. 로그 수집부터 탐지, 대응까지 전 과정을 직접 구축해본 경험은 SOC 분석가로서의 실무 감각을 키우는 데 큰 도움이 될 것이다.