[도서] 인프라보안 - 14장: ESM 구축과 보안 로그 중앙화

syslog만으로는 부족한 이유, Universal Forwarder가 등장하는 지점

이 챕터를 읽으면서 가장 먼저 눈에 들어온 건 syslog 방식과 Universal Forwarder 방식을 대비해서 설명하는 부분이었다. 방화벽이나 IDS 로그는 syslog로 514번 포트를 통해 어떻게든 Splunk 서버로 밀어 넣을 수 있다. 근데 문제는 로그를 보내는 측에서 소스 타입이나 인덱스를 전혀 지정하지 않고 그냥 내보내버린다는 거다. 결국 중앙 서버 쪽에서 몽땅 뭉쳐서 받을 수밖에 없는 구조가 된다.

그런데 Universal Forwarder를 쓰면 얘기가 달라진다. 로그를 내보내는 에이전트 쪽에서 어떤 인덱스로, 어떤 sourcetype으로 분류해서 보낼지 직접 정의할 수 있다. 중앙 Splunk 서버는 약속한 대로 받아서 적절한 인덱스에 딱 분배해준다. 방화벽이나 IDS처럼 에이전트를 설치하기 어려운 장비는 syslog로 처리하고, OS가 있는 서버나 PC는 Universal Forwarder를 쓰는 것이 맞는 구조라는 걸 이 챕터에서 명확하게 정리해준다.

inputs.conf 하나로 수집 대상을 정의하는 방식

리눅스에 Universal Forwarder를 설치하고 나서 핵심 작업은 결국 /opt/splunkforwarder/etc/system/local/inputs.conf를 편집하는 것이다. 형태는 단순하다.

[monitor:///var/log/auth.log]
disabled = false
index = linux
sourcetype = linux_audit

이처럼 모니터링할 파일 경로를 지정하고, 인덱스명과 sourcetype만 넣어주면 된다. sourcetype을 'linux_audit'처럼 Splunk가 기본 제공하는 타입으로 지정하면 나중에 파싱할 때 훨씬 편하게 작업할 수 있다. 브로 IDS의 http 트랜잭션 로그를 추가할 때도 같은 문법으로 블록 하나만 덧붙이면 끝이다. 설정 자체는 단순한데, 이 단순함이 여러 서버에 에이전트를 배포할 때 재현성을 높여준다는 점에서 꽤 실용적이다.

그리고 중앙 서버 쪽에서는 [Settings] → [Forwarding and receiving] → [Configure receiving]에서 9997번 포트를 열어줘야 포워더에서 들어오는 데이터를 받을 수 있다. pfSense ACL도 함께 열어줘야 하는데, VLAN마다 Splunk 서버의 TCP 포트로 접근하는 룰을 만들어야 해서 VLAN 구성이 촘촘할수록 이 작업이 적지 않게 반복된다.

윈도우 이벤트 로그, 수집보다 활성화가 먼저다

윈도우 쪽 설정을 읽으면서 사실 이 부분이 제일 중요하다고 느꼈다. 윈도우에 Universal Forwarder를 설치하고 inputs.conf에서 [WinEventLog://Security]를 잡아줘도, 정작 윈도우 자체의 감사 정책이 비활성화 상태면 로그가 하나도 안 쌓인다.

서버를 새로 설치하면 로컬 보안 정책 편집기(secpol.msc)에서 Audit Policy 항목이 전부 'No auditing'으로 되어 있다. 로그인 감사, 계정 관리 감사, 프로세스 추적 감사 등이 모두 꺼진 상태라는 얘기다. 이걸 활성화하지 않으면 나중에 보안 사고가 터져도 그 서버에서 무슨 일이 있었는지 추적할 방법이 없어진다. 책에서도 이 점을 꽤 강하게 짚는다. 서버를 설치하자마자 맨 처음 해야 할 작업이 이벤트 로그 활성화라는 것.

활성화하고 나서 Splunk에서 검색할 때는 index=windows source="WinEventLog:Security"로 시작하는 게 기본이다. sourcetype을 WinEventLog:Security로 지정하면 Splunk가 Account_Domain, Account_Name, EventCode 같은 필드를 왼쪽 패널에 미리 파싱해서 보여준다. 여기서 EventCode를 클릭하면 코드별 발생 건수 통계가 바로 나오고, 4689가 가장 많이 발생했다거나 4702가 몇 건이었다는 식으로 즉석 분류가 된다. 단순한 키워드 검색에서 조금만 더 나아가면 대시보드 소재가 되는 통계를 꽤 쉽게 뽑아낼 수 있다는 걸 여기서 확인했다.

그리고 로그가 안 들어올 때 트러블슈팅 포인트로 책이 언급하는 것 중 한 가지가 시간 동기화 문제였는데, VM 환경에서 Suspend 후 Resume하면 시간이 틀어지면서 로그가 제대로 조회되지 않는 경우가 생긴다. 이런 경우에는 Windows Time 서비스를 자동으로 설정하거나 NTP를 강제 동기화해서 해결한다. 별거 아닌 것 같지만 시간이 안 맞으면 로그 분석 자체가 의미를 잃으니까 실제 환경에서는 생각보다 중요한 포인트다.