![[AWS] Wazuh SIEM 구축 해보기](data:image/webp;base64,UklGRk4AAABXRUJQVlA4IEIAAADQAQCdASoQAAgABUB8JbACdAERFVJWAAD+7owD8ROMYBmFmE9FUIAj1Eykn6XwfHx9SQ3gav6RDKgkqQJHR+DivgA=)
![[AWS] Wazuh SIEM 구축 해보기](https://images.unsplash.com/photo-1644325349124-d1756b79dd42?ixlib=rb-4.1.0&q=85&fm=jpg&crop=entropy&cs=srgb&w=1600&fit=max&auto=format)
근두운 팀프로젝트 과정 중 AWS SecOps 인프라에서 발생하는 모든 보안 이벤트를 수집하여 상관 분석을 도와주는 Wazuh SIEM 구축 과정을 정리해 보려고 한다.
Wazuh SIEM 을 선택하게 된 이유부터 Wazuh 구축에 필요한 EC2, VPC, Security Group, IAM Role 생성 그리고, Wazuh Agent 로그를 수집해 Dashboard 에서 확인하는 과정을 소개할 예정이다.
Wazuh SIEM 선택 이유
우선 AWS 에서 활용할 수 있는 SIEM 후보를 비교해보았다.
구분 | Wazuh | ELK 스택 | AWS OpenSearch |
운영 형태 | 자체 구축 중심 | 자체 구축 또는 Elastic Cloud | AWS 관리형 |
Agent 기반 수집 | Wazuh Agent 제공 | Elastic Agent 제공 | 별도 수집기 구성 필요 |
커스텀 룰 | XML 기반 커스텀 룰 | Elastic Security 탐지 규칙 | Sigma・커스텀 룰 지원 |
자동 대응 | Active Response | 커넥터・워크플로 기능 | AWS 서비스 및 외부 시스템 연동 |
운영 복잡도 | 중간 | 중간 ~ 높음 | 상대적으로 낮음 |
비용 | 소프트웨어 무료,
AWS 인프라 비용만 발생 | 배포・기능에 따라 다름 | 사용량 기반 관리형 비용 |
세 가지 SIEM 후보 중, Wazuh 를 선택하게 되었고 그 이유는 다음과 같다.
- 제한된 예산에서 운영하는 팀 프로젝트 환경
- 직접 커스텀 탐지룰을 작성하여 룰 설계 경험 확장
- 자동대응 및 SOAR 와의 연동
추가로, Wazuh 는 오픈소스 기반 SIEM/XDR 플랫폼으로 SIEM 기능에 더해 XDR 의 기능도 하고 있어, Agent 를 통해 엔드포인트의 활동(로그, 프로세스, 파일)을 행위 기반으로 탐지할 수 있다.
이러한 특징들을 고려하여 우리 프로젝트에서는 Wazuh SIEM 을 선택하였다.
Wazuh 이해하기
Wazuh 는 Agent, Server(Manager), Indexer, Dashboard 로 구성되어 있다.
각 구성요소가 하는 역할은 다음 표와 같다.
구분 | 역할 |
Agent | EC2 인스턴스와 같은 엔드포인트에 설치되어 로그, 파일, 프로세스, 설정, 취약점 정보를 수집 |
Server | 디코더와 탐지룰을 통해 Agent 또는 외부 로그 소스로부터의 이벤트를 수신・분석하여 Alert 생성 |
Indexer | OpenSearch 기반, 탐지 결과와 보안 이벤트를 저장・검색 |
Dashboard | Alert 와 보안 데이터를 시각화하여 웹 UI 제공 |
기본적인 흐름은 Agent 가 엔드포인트 로그를 Server 로 전달하게 되면 Server 는 디코더를 통해 로그의 필드를 분류하고 이를 탐지룰과 매칭하여 Alert 를 생성, 관리자는 이를 Dashboard 에서 확인할 수 있게 된다.
서버의 행위를 자세히 보면 다음 예시처럼 동작한다.
예시
아래와 같은 Access Log 가 있으면,
192.168.0.10 - - [16/Aug/2026:14:36:00 +0900] "GET /index.html HTTP/1.1" 200 1234
디코더가 해당 로그에서 필드를 추출하여 분류하는 것이다.
name: 'web-accesslog' id: '200' protocol: 'GET' srcip: '192.168.0.10' url: '/index.html'
그리고, 디코더가 추출한 필드를 룰엔진이 탐지룰과 매칭하여 Alert 를 생성하게 된다.
Dashboard 에서 Alert 를 확인하는 과정은 Wazuh 구축을 마치고 직접 확인해보자!
Wazuh 구축을 위한 사전 준비
해당 과정은 AWS Console 에서 진행하며,
AdministratorAccess 권한을 가진 IAM User 를 사용
🔥 실습 편의를 위해 해당 권한을 사용, 실제 환경에서는 최소 권한 정책을 사용해야 함!이번 실습에서 구성할 네트워크 환경은 다음과 같다.
flowchart TD
it(("Internet"))
ig("Internet Gateway")
subgraph VPC["VPC"]
subgraph PS["Public Subnet"]
direction TB
PS1{"Security Group"}
PS2["EC2: wazuh\n(Server, Indexer, Dashboard)"]
end
end
it --- ig
ig --- PS1
PS1 --- PS2Step 1. VPC 생성
먼저 해당 실습을 진행할 VPC 를 생성한다. (default VPC 가 있지만, 실습 후 지울거기 때문에 새로 만들어주자)
콘솔에 접속해서, 현재 설정되어 있는 region 을 확인해주자, 우리는 서울 리전(ap-northeast-2)을 사용할 것이다.
VPC 생성
주요 설정
- VPC Only - 네트워크 구성 과정을 별도로 하기 위해 VPC 만 생성
- IPv4 CIDR - 10.20.0.0/16 (10.20.0.0 ~ 10.20.255.255)
생성 후, VPC 설정에서 다음 기능을 활성화 해준다.
- DNS resolution - 도메인 네임을 IP 주소로 변환할 수 있게 해줌
- DNS hostnames - Public IP 가 할당된 EC2 에 AWS DNS 호스트 이름을 제공
이러면 VPC 설정은 끝이다!
Step 2. Subnet 생성
이제 EC2 를 위치시킬 Subnet 을 생성한다.
Subnet 생성
Step 1. 에서 생성한 VPC 를 연결해주고, Subnet 설정 진행
주요 설정
- Availability Zone - 물리적인 가용 영역 설정 - ap-northeast-2a
- IPv4 CIDR - 10.20.10.0/24 - VPC 내부에서 논리적으로 분리
Subnet 생성도 끝!
Step 3. Internet Gateway 생성
VPC 와 인터넷 구간의 연결을 위한 IGW 를 생성한다.
Internet Gateway 생성
이름만 입력 후 생성, 생성된 IGW 를 보면 Detached 상태일텐데, Attach to VPC 옵션을 통해 우리가 생성했던 VPC 에 Attach 해준다.
IGW 생성 완료!
Step 4. Route Table 생성
생성한 Subnet 이 Internet Gateway 를 통해 외부 통신이 가능하도록 Route Table 생성한다.
Step 1. 에서 생성한 VPC 를 연결해주고 생성
Public Subnet 과 인터넷 사이의 연결 통로를 만들어주기 위해 경로를 추가
- Destination - 0.0.0.0/0
- Target - 생성한 Internet Gateway
VPC 내부 주소가 아닌 모든 IPv4 트래픽을 Internet Gateway 로 보내줌
경로 추가 후, Subnet associations 를 통해 Route Table 과 Subnet 을 연결
다음 조건이 만족되어, Subnet 이 Public Subnet 기능을 하게 됨
IGW 가 VPC 에 연결
Route Table 의 0.0.0.0/0 Route 가 IGW 에 추가
Route Table 을 Subnet 에 연결
Step 5. Security Group 생성
Step 1. ~ 4. 과정을 통해 다음과 같은 네트워크 구성이 완성되었다.
다만 현재 상태는 인터넷의 트래픽이 Public Subnet 으로 갈 수 있는 길만 생겼을 뿐, 실제 접근은 불가능
이러한 접근을 가능하게 하고, 제한하는 것이 바로 Security Group 이다. (방화벽이라고 생각하면 편함)
Security Group 을 생성하기 전, 특징을 조금 살펴보자!
- Security Group 은 화이트리스트 기반으로, Allow 할 정책을 추가하는 방식으로 사용
- Stateful 방식으로, 허용된 요청에 대한 응답 트래픽은 반대 방향의 규칙 없이 자동으로 허용
Security Group 생성
이름과, 설명, VPC 연결을 먼저 해주고, 사용할 Inbound 규칙을 설정해주자
첫 번째로, Wazuh Dashboard 에 접속하기 위한 규칙을 생성
내 공인 IP 가 443/TCP 에 인바운드 하는 것을 허용
두 번째로, Wazuh Agent 이벤트를 수집하고, Agent 를 등록하기 위한 규칙 생성
내 PC 에 Agent 설치 후, 테스트를 할 예정이므로 내 공인 IP 가 1514/TCP(Agent 로그 전송 포트), 1515/TCP(Agent 등록 포트) 에 인바운드 하는 것을 허용
⚠️ Agent 등록을 더 이상 받지 않는 환경에서는 등록 완료 후 1515/TCP 포트는 미사용 포트로 닫는 것을 권장→ Inbound 규칙 분리, 해당과정은 실습용 이라서 1514-1515 묶어서 진행
Outbound 규칙은 기본 설정으로 생성!
이제 Security Group 규칙을 통해, 내 PC 에서 Public Subnet 접근이 가능해짐!
Step 6. IAM Role 생성
이번 실습에서는 EC2 인스턴스에 접근하기 위해 SSM 의 Session Manager 를 이용할 것이다.
Key Pair 를 통해 SSH 로 세션을 연결할 수도 있지만, SecOps 인프라를 구축하는 만큼 비교적 안전한 SSM 방식을 채택하였다.
SSM Session Manager 는 SSH / 22번 포트를 외부에 열지 않아도 되고, Key Pair 를 배포하지 않고도, 인스턴스 접근이 가능하다.
SSM 접속 조건을 보면 다음과 같다.
- 접속할 EC2 에 Public IP 할당 필요 - EC2 생성 시 진행
- Internet Gateway 경로 설정 - Step 3 에서 완료
- Outbound 443/TCP 허용 - Step 5 에서 완료
- EC2 가 SSM 권한을 가져야 함 - 해당 Step 에서 진행
- EC2 에 SSM Agent 가 있어야 함
AWS 공식문서에 따르면, SSM Agent 는 일부 AMI 에 사전 설치되어 있다고 한다.
우리는 나중에 EC2 생성 시 SSM Agent 가 생성되어 있는 AMI 를 사용할 것이다.
IAM Role 생성
주요 설정
- Type - AWS Service - EC2 가 사용할 정책이니 이를 선택
- Use case - EC2
이 설정은 다음과 같은 신뢰 정책을 생성해준다.
{ "Version": "2010-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
해석 하면, EC2 가 해당 Role 의 권한을 AssumeRole 을 통해 임시로 받아서 사용할 수 있게 해주는 것이다.
권한 정책 연결
해당 IAM Role 이 가지는 권한을 연결해준다. 즉, EC2 가 가지는 권한을 설정해주는 과정
우리는 AmazonSSMManagedInstanceCore 를 사용해서 EC2 가 SSM Session Manager 통신을 가능하게 해준다.
이때, EC2 인스턴스 세션을 얻어야 하는 IAM User 또는 Role 은 ssm:StartSession 권한이 필요하다.
이제 해당 IAM Role 을 EC2 에 연결해줘야 함! - Instance Profile 이 담당
Step 7. EC2 생성 for Wazuh
이제 Wazuh 를 설치할 서버인 EC2 인스턴스를 생성한다. - 여기서부터는 비용 발생! 💰💰💰
EC2 생성하기 전, Wazuh 의 하드웨어 요구사항을 파악해보자!
- OS - Amazon Linux 2, Amazon Linux 2023, Ubuntu 16.04, 18.04, 20.04, 22.04, 24.04 등
- 하드웨어 요구 사항
구분 | Minimum(RAM / CPU) | Recommended(RAM / CPU) |
All-in-one
(agent 1 ~ 25) | 8 GiB / 4 vCPU | 8 GiB / 4 vCPU |
Indexer | 4 GB / 2 Core | 16 GB / 8 Core |
Server | 2 GB / 2 Core | 4 GB / 8 Core |
Dashboard | 4 GB / 2 Core | 8 GB / 4 Core |
거의 웬만한 Linux OS 에서는 Wazuh 를 지원해주고 있다.
EC2 생성
AWS 는 EC2 생성 시 AMI 를 제공해줘서, 쉽게 OS 설치가 가능하다!
- Amazon Linux 2023 - latest - x86_64 선택 - 앞서 언급했던 SSM Agent 가 사전 설치되어 있다.
- 만약 SSM Agent 가 없거나, 실행 중인 상태가 아니라고 하면 EC2 생성단계 중 User data 설정 시, SSM Agent 를 실행하는 스크립트를 넣어주면 된다.
#!/bin/bash # SSM Agent 를 즉시 실행하고, 재부팅 후에도 자동으로 시작 systemctl enable --now amazon-ssm-agent
1. 인스턴스 타입 설정
Wazuh 공식 홈페이지에서 단일노드 구성 시 4 vCPU / 8 GiB (CPU / RAM) 를 권장하니, 이에 맞춰서 선택하자!
실습 목적이니 t3.xlarge 를 선택
⚠️ CPU 크레딧을 사용하는 버스터블 인스턴스 타입, 로그가 지속해서 유입되는 운영환경에서는 성능 예측이 쉬운 M 계열이 더 적합!
🕵️♂️ 프로젝트 규모에 따라서, 인스턴스 자원을 잘 선택하자!
고민해볼만한 인스턴스 타입
구분 | t3.xlarge(버스터블) | m5.xlarge | m6i.xlarge | m7i.xlarge |
CPU 코어 | 4 Core | 4 Core | 4 Core | 4 Core |
RAM | 16 GiB | 16 GiB | 16 GiB | 16 GiB |
네트워크 | 최대 5Gbps | 최대 10Gbps | 최대 12.5Gbps | 최대 12.5Gbps |
EBS 대역폭 | 최대 2.78Gbps | 최대 4.75Gbps | 최대 10Gbps | 최대 10Gbps |
시간당 비용 | $0.2080 | $0.2360 | $0.2360 | $0.2478 |
💰 비용은 서울 리전・Linux・On-Demand・2026년 8월 확인 기준
Amazon Web Services, Inc.EC2 온디맨드 인스턴스 요금
EC2 온디맨드 인스턴스 요금
AWS 클라우드 솔루션으로 업계를 혁신하세요. 해당 산업에 적합한 AWS 제품을 사용하는 고객의 검증된 아키텍처, 규정 준수 가이드 및 성공 사례에 액세스할 수 있습니다. 산업에 맞는 AWS 솔루션을 살펴보세요.
2. Key Pair 와 네트워크 설정
우리는 SSM 을 사용한다 했으니, Key Pair 는 설정해주지 않을 것이다.
네트워크 설정은 우리가 앞 단계에서 만들었던 VPC, Subnet, Security Group 을 선택해주면 된다.
3. 스토리지 설정
주요 설정
- Volume size - 100 GiB - Wazuh 공식 All-in-one 기준 최대 25개의 Agent 와 90일 보관에 권장되는 용량을 50GB, 구성요소와 로그 증가 여유를 고려해 100GiB 할당
- Volume type - gp3 - AWS 범용 SSD EBS 볼륨
- IOPS - 3000 IOPS - 초당 읽기쓰기 작업 횟수(default)
- Delete on termination - 활성화 - EC2 삭제 시 Root EBS 도 함께 삭제(비활성화 하면, EC2 삭제해도 볼륨이 남아있어 비용이 발생할 수 있으니 주의하자)
- Encrypted - 활성화 - EBS 에 저장되는 Wazuh 데이터와 로그를 암호화
- KMS Key - aws/ebs - AWS 관리형 키 사용
- Throughput - 125 MiB/s - 대역폭(default)
4. Advanced details 설정
- IAM instance Profile 설정
- Instance profile 을 통해 step 6. 에서 생성한 IAM Role 을 연결
- Termination 설정
- Termination protection - Disable
- Stop protection - Disable
- Shutdown behavior - Stop
- Stop - Hibernate behavior - Disable
실습 목적이니, 삭제 방지 기능은 비활성화 해준다.
- Instance Metadata 설정
- Metadata accessible - Enabled
- Metadata version - V2 Only(token required) - IMDSv2 사용(SSRF 취약점 방지)
- Metadata response hop limit - 1
- Allow tags in metadata - Disable
여기까지 설정을 하면 EC2 생성 과정이 끝난다.
Step 8. Wazuh 설치하기
이제 Wazuh 설치를 할 준비가 모두 끝났으니, 설치를 진행해보자
먼저 SSM 을 통해 EC2 세션을 획득한다.
# AWS CLI, SSM Plugin, ssm:StartSession 권한이 있는 자격증명 선행 필요 aws ssm start-session --target "Instance ID" --region ap-northeast-2
세션을 얻었으면, 먼저 패키지를 업데이트 하고 설치에 필요한 패키지를 설치한다.
# dnf 패키지 매니저는 upgrade 하나로 패키지 목록 갱신과 패키지 설치를 한 번에 진행 sudo dnf upgrade --refresh -y && sudo dnf install -y tar gzip
Wazuh 설치 파일을 보관할 디렉터리 생성
sudo install -d -m 700 /opt/wazuh-install
Wazuh 공식 홈페이지에서 설치 도우미를 지정한 디렉터리에 다운로드
sudo curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh -o /opt/wazuh-instal/wazuh-install.sh
설치 도우미를 실행하여 Wazuh All-in-one 방식으로 설치(5 ~ 10분 소요)
sudo bash /opt/wazuh-install/wazuh-install.sh -a
설치가 완료되면, 다음과 같은 메시지 출력
Wazuh Dashboard 에 로그인할 수 있는 계정과 패스워드를 생성해주고, 접속 주소(url)도 알려준다.
실제로 Wazuh 서비스가 정상적으로 실행이되었는지 세션에서 먼저 점검해보자!
systemctl status wazuh-indexer systemctl status wazuh-manager systemctl status wazuh-dashboard
결과가 active(running) 이라면, 서비스가 정상적으로 동작하고 있음을 확인할 수 있다.
그러면 이제 Dashboard 에 접속해서 확인!
Step 9. Agent 설치
내 PC 에 Wazuh Agent 를 설치해서 실제로 Dashboard 에 어떻게 기록되는지를 확인 해볼 것이다.
(희생양이 된 나의 맥북…??)
Agent 설치 방법은 Wazuh 공식 문서에도 잘 정리되어 있고, Dashboard 의
Deploy new agent 기능으로 쉽게 설치하고자하는 환경에서의 설치 방법과 명령어를 제공해준다.
이미지 처럼 환경을 입력하게 되면,
그대로 복사 붙여넣기만 하면 되게끔 만들어 준다.(좋은 녀석)
위 명령어를 실행시켜 주면, Agent 설치와 Wazuh 서버에 Agent 등록이 완료가 된다.
서버에서 Agent 등록 여부를 확인해보면,
# 등록된 모든 에이전트와 현재 연결상태 출력 sudo /var/ossec/bin/agent_control -l
정상적으로 등록된 것을 볼 수 있다.(Dashboard 에서도 확인 가능)
Dashboard 에서 Threat Hunting - Events 를 보면, 탐지룰에 매칭된 Alert 를 확인할 수 있음
아래는 Wazuh Server 의 기본 탐지룰 중 하나이다.
<!-- 0020-syslog_rules.xml syslog, sudo 명령을 탐지하는 그룹 password 입력 실패 3회 시 탐지 --> <group name="syslog,sudo,"> <rule id="5404" level="10"> <if_sid>5401</if_sid> <match>3 incorrect password attempts</match> <description>Three failed attempts to run sudo</description> <mitre> <id>T1548.003</id> </mitre> <group>pci_dss_10.2.4,pci_dss_10.2.5,gpg13_7.8,gdpr_IV_35.7.d,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AC.7,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group> </rule> </group>
위 탐지룰에 매칭되기 위해 macbook 터미널에서 일부러 sudo 권한 실행에 대한 패스워드 검증을 틀려보자
아래 이미지 처럼
rule.id = 5404 에 매핑되어 탐지된 것을 확인할 수 있다.
마무리
AWS 리소스를 활용하여 Wazuh SIEM 을 설치하고, 로컬에 Agent 설치까지 완료하였다.
Agent 가 엔드포인트에서 발생하는 행위를 Server 에 정의된 탐지룰에 매핑하여 Alert 를 생성, 이를 Indexer 가 검색 가능한 형태로 저장해주고, Dashboard 에서 시각화해서 보여주는 과정을 경험하며, Wazuh 의 동작 방식과 함께 보안 관제의 기본 흐름을 이해할 수 있었다.
다음번에는 AWS Native 로그를 연동해서 Dashboard 로 확인하는 과정을 실습해 볼 것이다.
