WIKI SECURITY의 오픈소스(OSS) Wazuh 기반 통합 보안 모니터링 구축 및 검증 사례
1. 통합 로그관리, 로그 수집만으로 충분할까?
기업의 정보시스템은 Windows·Linux 서버뿐 아니라 네트워크 스위치, 방화벽, VPN, IDS/IPS 등 다양한 장비로 구성되어 있다.
보안사고나 시스템 장애가 발생했을 때 원인을 정확하게 파악하려면 여러 시스템에서 생성되는 로그를 통합적으로 수집하고 분석할 수 있어야 한다.
오픈소스(OSS) 기반 보안 플랫폼인 Wazuh는 서버에 설치한 Agent뿐 아니라 Syslog를 이용해서도 네트워크 및 보안장비의 로그를 수집할 수 있다.
그러나 실제 구축 과정에서는 로그를 수집하는 것만으로 해결되지 않는 문제가 발생할 수 있다.
“수집된 로그가 어느 장비에서 발생했는지 정확하게 식별하고 분석할 수 있는가?”
WIKI SECURITY는 Wazuh 4.14.x 기반의 통합 로그관리 환경을 직접 구축하고 검증하는 과정에서 이러한 문제를 확인했다.
특히 다음 두 가지 기술적 과제에 중점을 두었다.
– Agent 설치가 불가능한 네트워크·보안장비의 Syslog를 Wazuh에서 장비별로 식별하는 방법
– Windows 이벤트가 NXLog 및 Syslog 서버를 거쳐 전달되어도 원본 Event ID를 Wazuh에서 식별하는 방법
이번 글에서는 실제 테스트 과정에서 발생한 문제와 이를 해결하기 위해 적용한 아키텍처 및 기술적 검증 결과를 소개한다.
2. 첫 번째 시도: Wazuh Manager에 Syslog 직접 연동
2.1 초기 아키텍처 구성
Wazuh는 Agent 설치가 불가능한 네트워크 스위치, 방화벽 등의 장비로부터 Syslog를 직접 수신할 수 있다.
WIKI SECURITY는 먼저 Netgear GS716T 네트워크 스위치에서 발생하는 로그를 Wazuh Manager로 직접 전달하는 방식으로 테스트했다.
구성 A – Wazuh Manager 직접 Syslog 수집
이 방식은 별도의 로그 수집 서버가 필요하지 않고, Wazuh Manager에서 직접 Syslog 메시지를 수신하므로 구성이 비교적 간단하다는 장점이 있다.
실제 테스트에서도 네트워크 스위치의 로그가 Wazuh Manager로 정상적으로 전달되는 것을 확인했다.
그러나 수집된 로그를 시스템별로 구분하고 분석하는 과정에서 운영상의 제약이 확인되었다.
2.2 원본 시스템 식별 문제
일반적으로 Wazuh Agent가 설치된 시스템은 agent.id, agent.name 등의 식별정보를 통해 구분할 수 있다.
반면 Syslog로 직접 연결된 네트워크 장비는 Wazuh Agent가 설치되어 있지 않기 때문에 개별 Agent 식별정보가 생성되지 않는다.
실제 테스트에서 확인한 로그 식별정보는 다음과 같다.
| 항목 | 확인 결과 |
|---|---|
| 로그 발생 시스템 | Netgear GS716T |
| Syslog 송신 IP | 192.168.20.1 |
| agent.id | 000 |
| agent.name | Wazuh Manager 호스트명 |
| location | 192.168.20.1 |
| 로그 수집 | 정상 |
이러한 구조에서는 여러 Syslog 장비의 이벤트가 동일한 Manager 식별정보로 기록될 수 있다.
따라서 agent.id 또는 agent.name만으로 시스템별 이벤트를 집계하면 서로 다른 장비의 로그가 하나의 시스템에 속한 것처럼 표시될 수 있다.
물론 location에 기록된 송신 IP나 Syslog 메시지의 호스트 정보를 이용하면 원본 장비를 식별할 수 있다.
그러나 Agent 기반 시스템과 Syslog 기반 시스템의 식별 방식이 서로 달라, 통합 대시보드나 장비별 이벤트 분석에 활용하기 위해서는 별도의 식별 기준을 적용해야 한다.
WIKI SECURITY는 이 문제를 개선하기 위해 Wazuh Manager 앞단에 별도의 Syslog 수집 서버를 배치하는 방식으로 아키텍처를 변경했다.
3. 개선된 아키텍처: rsyslog 중계 서버 기반 로그 수집
3.1 Syslog 수집 계층 분리
개선된 구조에서는 네트워크·보안장비가 Wazuh Manager로 직접 로그를 전송하지 않고, 중간의 rsyslog 서버로 전달하도록 구성했다.
rsyslog 서버는 송신 시스템별로 로그파일을 분리하여 저장하고, 서버에 설치된 Wazuh Agent가 해당 로그파일을 수집하여 Wazuh Manager로 전달한다.
구성 B – rsyslog 중계 서버 기반 통합 로그 수집
주요 처리 흐름은 다음과 같다.
(1) 대상 시스템에서 Syslog(테스트 기준 UDP/514)를 이용하여 rsyslog 서버로 로그 전송
(2) rsyslog 서버에서 송신 시스템별 로그파일 자동 생성
(3) Wazuh Agent의 Logcollector가 시스템별 로그파일 수집
(4) Wazuh Agent가 TCP/1514를 통해 Wazuh Manager로 로그 전달
(5) Wazuh Manager에서 Decoder 및 Rule을 이용한 로그 분석
(6) 탐지 알림을 Wazuh Indexer에 전달하여 Dashboard에서 검색·분석
여기서 Wazuh Manager가 수신한 모든 원본 로그가 기본적으로 Indexer에 저장되는 것은 아니다. 전체 이벤트의 검색이 필요한 경우에는 Archives 기록 및 인덱싱 기능을 추가로 구성해야 한다.
3.2 시스템별 로그파일 자동 분리
이번 개선에서 가장 중요한 기능은 rsyslog의 동적 파일 생성 기능을 이용하여 원본 시스템별 로그를 분리하는 것이다.
WIKI SECURITY는 송신 IP 및 호스트 정보를 활용하여 다음과 같이 로그파일을 자동 생성하도록 구성했다.
/var/log/remote/
192.168.20.1_192.168.20.1.log
192.168.1.20_192.168.1.20.log첫 번째 파일은 Netgear 네트워크 스위치, 두 번째 파일은 Windows 시스템에서 전달된 로그가 저장된 파일이다.
이러한 방식으로 하나의 중계 서버에서 여러 시스템의 로그를 수집하더라도 파일별로 구분하여 관리할 수 있다.
또한 Wazuh Agent가 로그파일을 읽어 Manager로 전달하면, Wazuh에서 location 필드를 통해 해당 로그파일의 경로를 확인할 수 있다.
다만 agent.id와 agent.name은 여전히 중계 서버에 설치된 Wazuh Agent의 식별정보를 나타낸다.
따라서 중계 서버를 도입하여 개별 장비별 Agent ID를 생성하는 것이 아니라, 장비별 로그파일 경로를 확보하고 원본 시스템 식별에 활용하는 구조다.
향후 시스템별 통합 분석을 구현할 때는 해당 경로와 장비 정보를 별도의 공통 식별 필드로 정규화할 수 있다.
3.3 직접 연동과 중계 서버 방식 비교
| 비교 항목 | 직접 Syslog 연동 | rsyslog 중계 연동 |
|---|---|---|
| 로그 수집 | Manager에서 직접 수신 | 중계 서버에서 수신 |
| 구성 복잡도 | 비교적 단순 | 별도 서버 구성 필요 |
| Agent 식별정보 | Manager 기준 | 중계 Agent 기준 |
| 원본 장비 식별 | 송신 IP 및 헤더 활용 | 장비별 파일 경로·IP·헤더 활용 |
| 로그파일 분리 | 별도 구성 필요 | 수집 단계에서 구현 |
| 원본 로그 별도 저장 | 추가 구성 필요 | 중계 서버에서 가능 |
| 로그 형식 처리 | 별도 처리 구성 필요 | 중계 서버에서 사전처리 가능 |
| 운영 구조 | Manager 중심 | 수집과 분석 계층 분리 |
이번 테스트에서는 중계 서버 방식으로 아키텍처를 변경함으로써 원본 시스템별 로그파일 관리와 로그 형식 처리를 수행할 수 있는 구조를 확보했다.
특히 여러 장비의 로그를 통합하는 환경에서는 수집 계층을 별도로 구성함으로써 장비별 로그 관리 정책을 적용하기가 용이하다.
다만 중계 서버의 장애 가능성, 로그 저장 용량, 접근 통제 및 보관 정책 등은 실제 구축 시 함께 검토해야 한다.
4. Windows Event ID를 Syslog에서도 정확하게 식별할 수 있을까?
4.1 Windows 이벤트 수집 과정의 문제
Windows 운영체제는 로그온 실패, 사용자 계정 생성, 서비스 설치 등 다양한 이벤트를 Event ID와 함께 기록한다.
대표적인 보안 관련 이벤트는 다음과 같다.
| Event ID | 주요 내용 |
|---|---|
| 4625 | 로그온 실패 |
| 4720 | 사용자 계정 생성 |
| 4728 | 보안 그룹에 구성원 추가 |
| 7045 | 서비스 설치 |
이번 테스트에서는 Windows 11에 NXLog Community Edition을 설치하고, Windows Event Log를 Syslog로 변환하여 rsyslog 서버로 전송했다.
이 과정에서 Windows 이벤트가 Syslog 형식으로 변환되더라도 원본 Event ID와 주요 이벤트 정보를 Wazuh에서 정확하게 식별할 수 있어야 한다는 과제가 있었다.
4.2 NXLog의 Snare 형식 활용
WIKI SECURITY는 Windows 이벤트를 Snare 호환 형식으로 변환하는 NXLog의 to_syslog_snare() 기능을 활용했다.
Snare 형식에는 Windows 원본 Event ID, 호스트명, 이벤트 소스 등 분석에 필요한 정보를 포함할 수 있다.
그런데 실제 테스트에서는 NXLog가 생성한 Snare 메시지가 rsyslog를 통과하면서 필드 구분자가 변경되는 문제가 확인되었다.
Snare 형식은 TAB 문자를 필드 구분자로 사용할 수 있으나, rsyslog는 기본 설정에 따라 TAB 등의 제어문자를 다른 문자열로 변환할 수 있다.
이렇게 필드 구분자가 변경되면 Wazuh의 Snare Decoder가 메시지를 예상한 형식으로 인식하지 못할 수 있다.
4.3 rsyslog의 메시지 형식 처리 개선
WIKI SECURITY는 Windows에서 발생한 원본 이벤트와 NXLog가 변환한 Syslog 메시지, rsyslog에 저장된 로그 및 Wazuh Decoder의 분석 결과를 비교했다.
이 과정에서 TAB 문자 처리 문제를 확인하고, rsyslog의 제어문자 처리 설정을 조정하여 Snare 형식의 필드 구분자가 유지되도록 개선했다.
이후 wazuh-logtest를 이용하여 Decoder와 Rule 매칭 결과를 검증했다.
즉, 로그가 정상적으로 전달되는지만 확인한 것이 아니라 Windows 이벤트의 주요 식별정보가 수집과 변환 과정을 거쳐 최종 분석 단계까지 유지되는지 검증했다는 점이 중요하다.
4.4 Wazuh 분석 결과
실제 Windows 11 테스트 이벤트를 이용한 검증에서 다음과 같은 결과를 확인했다.
| 검증 항목 | 확인 결과 |
|---|---|
| Windows 시스템 | DESKTOP-JJ59TT7 |
| NXLog 이벤트 변환 | Snare 호환 형식 |
| Wazuh Decoder | windows-snare |
| 원본 Windows Event ID | 256 |
| Wazuh Rule ID | 18101 |
| 이벤트 식별 | 정상 확인 |
이번 테스트를 통해 NXLog와 rsyslog를 거쳐 전달된 Windows 이벤트의 원본 Event ID가 Wazuh에서 식별되는 것을 확인했다.
다만 이 결과가 Windows의 모든 이벤트 유형과 탐지 규칙에 동일하게 적용된다는 것을 의미하지는 않는다.
실제 보안관제에 활용하려면 로그 수집 대상, 이벤트 형식, Decoder 및 Rule 매칭 결과를 이벤트 유형별로 추가 검증해야 한다.
5. 이번 기술 검증의 주요 성과
이번 PoC에서는 Wazuh 기반 통합 로그관리 환경의 주요 기술적 문제를 확인하고 개선 방법을 검증했다.
| 주요 검증 항목 | 결과 |
|---|---|
| Netgear 네트워크 스위치 Syslog 수집 | 확인 |
| 직접 연동 시 장비 식별 특성 | 확인 |
| rsyslog 기반 통합 로그 수신 | 확인 |
| 시스템별 로그파일 자동 생성 | 확인 |
| Wazuh Agent를 통한 로그 전달 | 확인 |
| Windows NXLog 로그 수집 | 확인 |
| Windows Event ID 추출 | 확인 |
| Snare Decoder 및 Rule 매칭 | 시험 이벤트에서 확인 |
| 다중 시스템 간 보안 상관분석 | 후속 검증 대상 |
이번 테스트는 단순한 Wazuh 설치나 로그 연동이 아니라, 이기종 시스템의 로그를 수집하고 원본 시스템과 주요 이벤트 정보를 분석에 활용할 수 있도록 아키텍처를 개선한 사례다.
이러한 결과는 향후 시스템별 이벤트 관리, 이상징후 탐지, 통합 대시보드 및 시스템 간 상관분석으로 확장하기 위한 기술적 기반이 된다.
6. 통합 로그 수집에서 보안 모니터링 체계로
통합 로그 수집은 보안관리 체계 구축의 출발점이다.
실제 운영 환경에서는 수집한 로그를 분석하고 보안상 중요한 이벤트를 식별하는 체계가 함께 마련되어야 한다.
예를 들어 네트워크 장비의 설정 변경, Windows 계정 변경, Linux 시스템의 비정상적인 접근 시도 등을 통합적으로 모니터링할 수 있다.
이를 위해서는 다음과 같은 추가 기능을 검토할 수 있다.
– 시스템별 통합 모니터링: 장비 식별정보의 정규화와 이벤트 현황 관리
– 이상징후 탐지: 시스템·장비별 Decoder 및 Rule 구성
– 이벤트 상관분석: IP, 사용자, 발생 시간 등을 이용한 시스템 간 이벤트 연계
– 통합 대시보드: 주요 이벤트, 장비별 현황 및 로그 수집 상태 시각화
– 운영 자동화: 주요 이벤트 알림과 정기 점검 및 대응 절차 자동화
이러한 기능은 로그 수집만으로 자동 완성되는 것은 아니며, 데이터 정규화와 탐지 정책 및 운영 절차에 대한 추가 설계가 필요하다.
7. WIKI SECURITY의 오픈소스(OSS) 기반 보안관리 지원
WIKI SECURITY는 정보보안 컨설팅과 기술적 보안진단 경험을 바탕으로, 오픈소스(OSS)를 활용한 보안관리 시스템의 구축 및 운영 방안을 지속적으로 연구하고 검증하고 있다.
이번 사례 역시 공개된 소프트웨어를 단순히 설치하는 데 그치지 않고, 실제 연동 과정에서 발생하는 문제를 분석하고 해결 방법을 검증하는 데 중점을 두었다.
고객사마다 운영체제와 네트워크·보안장비의 종류가 다르고, 기존 IT 관리 환경과 보안 요구사항도 서로 다르다.
따라서 효과적인 보안관리 체계를 구축하려면 고객사의 실제 환경에 맞는 아키텍처 설계와 연동 검증이 필요하다.
WIKI SECURITY는 다음과 같은 영역에서 고객사의 보안관리 환경 구축을 지원할 수 있다.
| 지원 분야 | 주요 내용 |
|---|---|
| 보안관리 환경 분석 | 로그 수집 대상 및 기존 시스템 환경 분석 |
| 통합 로그 수집 체계 | Wazuh, rsyslog 등 오픈소스(OSS) 기반 아키텍처 설계 |
| 이기종 시스템 연동 | Windows, Linux, 네트워크 및 보안장비 로그 통합 |
| 보안 이벤트 분석 | Decoder, Rule 및 시스템별 이벤트 식별 체계 구성 |
| 통합 보안 모니터링 | 주요 이상징후 탐지, 대시보드 및 알림 체계 구축 |
| 기술지원 및 운영 개선 | 로그 수집 품질 검증, 탐지 규칙 개선, 운영 절차 수립 |
특히 전담 보안 인력이 충분하지 않거나 보안관리 시스템 도입에 따른 비용 부담이 있는 중소·중견기업에서도 활용 가능한 구축 및 운영 방안을 함께 검토할 수 있다.
마치며
오픈소스(OSS)는 다양한 기술을 유연하게 조합하여 기업의 환경에 맞는 보안관리 시스템을 구성할 수 있다는 장점이 있다.
그러나 오픈소스를 설치하는 것과 실제 운영에 활용할 수 있는 보안관리 체계를 구축하는 것은 다른 문제다.
이번 사례에서도 Wazuh를 이용한 로그 수집 자체는 구현할 수 있었지만, 원본 장비 식별과 Windows 이벤트의 정확한 분석을 위해서는 각 구성요소의 동작 방식을 이해하고 문제를 해결하는 과정이 필요했다.
WIKI SECURITY는 이러한 실제 구축·검증 경험을 바탕으로 고객사의 환경에 적합한 오픈소스(OSS) 기반 통합 로그관리 및 보안 모니터링 체계 구축을 지원하고자 한다.
Wazuh 기반 통합 로그관리 또는 보안 모니터링 환경의 구축을 검토하고 있다면 WIKI SECURITY와 함께 적용 가능성을 검토할 수 있다.