049. SIEM·로그 수집 — 실전 시나리오 — 신규 서버 SIEM 편입부터 첫 Alert까지
SIEM · 보안관제 › A. SIEM 구조와 로그 수집 · 49/50편
학습 단계: 실전 시나리오·종합
실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Wazuh 4.x 올인원 / Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.
선행 학습
1. 개념
A영역의 내용을 하나의 작업으로 엮어 봅니다. 상황은 "신규 웹 서버 web02를 오늘 운영에 투입하니, 관제 대상으로 편입해 달라"는 요청입니다. 공격 재현이 아니라 편입 절차와 검증, 그리고 편입 직후 실제로 잡힌 이벤트를 판단하는 과정에 집중합니다.
편입 시나리오 타임라인(가상의 예시)
09:00 요청 접수: web02(Rocky 9, nginx, 192.168.56.23)
09:10 수집 인벤토리 작성: secure·audit·nginx access/error·방화벽 로그 (003편)
09:20 에이전트 등록 → Active (006편)
09:30 그룹 linux-rocky·web 적용 → Analyzing file 확인 (008·009편)
09:40 테스트 이벤트: 실패 로그인·sudo·웹 404 → 기대 룰 확인 (009·012·025편)
09:50 수집 상태 대시보드·히트맵에 web02 추가 확인 (045편)
10:05 nginx 로그 형식이 JSON → 기본 웹 룰 미매칭 발견 → 커스텀 룰 (012·024편)
11:30 첫 고위험 Alert: 외부 출발지 웹 스캔 + SSH 대입 시도
핵심: "에이전트 Active"가 아니라 "테스트 이벤트가 기대 룰로 나옴"이 편입 완료이 시나리오에서 가장 중요한 장면은 10:05입니다. 에이전트는 붙었고 로그도 들어왔지만, 로그 형식 차이로 웹 탐지가 안 되는 상태였습니다. 테스트 이벤트 검증이 없었다면 그대로 운영에 들어갔을 것입니다.
2. 왜 중요한가
- 편입 절차가 실제로 어떤 순서로 연결되는지 확인할 수 있습니다.
- "수집된다"와 "탐지된다"의 차이를 구체적으로 보여 줍니다.
- 면접에서 SIEM 편입 경험을 구조적으로 설명하는 틀이 됩니다.
3. 핵심 명령어 / 설정
| 시각 | 확인 | 결과 |
|---|---|---|
| 09:20 | agent_control | Active |
| 09:30 | Analyzing file | 4개 소스 등록 |
| 09:40 | 테스트 로그인 | 5716·5715 정상 |
| 09:40 | 테스트 웹 404 | 미매칭 → 조치 |
| 09:50 | 히트맵 | web02 행 채워짐 |
| 11:30 | 첫 고위험 | 스캔+대입 |
4. 실습 (실습 예시)
# 편입 검증 명령 모음 (실습 예시)
sudo /var/ossec/bin/agent_control -l | grep web02
ssh web02 "sudo grep 'Analyzing file' /var/ossec/logs/ossec.log | tail -4"
# 테스트 이벤트 후 기대 룰 확인
sudo jq -r 'select(.agent.name=="web02") | [.timestamp,.rule.id,.rule.description] | @tsv' /var/ossec/logs/alerts/alerts.json | tail -5
# JSON nginx 로그 디코딩 확인
ssh web02 "tail -n1 /var/log/nginx/access.json" | sudo /var/ossec/bin/wazuh-logtest -q 2>/dev/null | grep -E "name:|status|uri|id:"5. 정상 상태
web02 Active · 소스 4개 Analyzing
테스트: 5716(실패) · 5715(성공) · 5402(sudo) · 110xxx(JSON 웹 404 커스텀 룰)
히트맵: web02 모든 소스 수신모든 소스가 테스트 이벤트로 기대 룰을 만들고 수집 상태 대시보드에 나타나면 편입 완료로 판단합니다.
6. 이상 상태
11:30~11:42 web02
· 203.0.113.44 → 웹 404 1,820건(서로 다른 경로 1,700개)
· 같은 출발지 SSH 실패 96회(계정 41개)
· 성공 로그인: 없음- 편입 2시간 만에 외부 스캔·대입 시도 포착
- 서로 다른 경로 다수 → 디렉터리 스캔, 계정 다수 → spraying
- 성공 없음 → 시도 단계로 판단, 출발지 차단 요청
7. 로그 분석 (분석 방법)
첫 Alert 판단 흐름입니다(가상의 예시).
[고위험 Alert] web02 SSH 대입 + 웹 404 급증
↓
[집계] 출발지 Top · 경로 수 · 계정 수(042편)
↓
[성공 여부] 같은 출발지 Accepted·200 응답 확인 → 없음
↓
[판정] 정탐(공격 시도) · 침투 없음
↓
[조치] 출발지 차단 요청 · 노출 서비스 점검(SSH 외부 노출 여부)
↓
[편입 보고] 편입 결과 + 첫 탐지 내역| 판단 근거 | 결과 |
|---|---|
| 경로 1,700개 | 디렉터리 스캔 |
| 계정 41개 | spraying |
| 성공 없음 | 시도 단계 |
신규 서버가 외부에 노출되면 수 시간 안에 자동화된 스캔이 들어오는 일은 흔합니다. 편입 직후 이런 시도를 잡아낸 것 자체가 수집·디코딩·룰이 제대로 연결됐다는 증거이기도 합니다.
8. SOC 관제 포인트
- 편입 완료 기준을 "테스트 이벤트 기대 룰 확인"으로 둡니다.
- 편입 직후 첫 24시간은 해당 호스트 Alert를 집중 확인합니다.
- 편입 보고서에 소스별 검증 결과를 남깁니다.
9. 탐지 규칙
<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,siem_a,">
<rule id="110480" level="13">
<if_matched_group>authentication_failed</if_matched_group>
<if_group>web</if_group>
<same_source_ip />
<timeframe>1800</timeframe>
<description>동일 출발지 30분 내 웹 공격·스캔과 SSH 인증 실패 동시 발생(다중 서비스 공격)</description>
<mitre><id>T1595</id></mitre>
</rule>
</group>같은 출발지가 웹과 SSH를 함께 공격하는 패턴을 하나로 묶는 상관 예시입니다. 웹 로그와 인증 로그가 모두 srcip로 정규화되어 있어야 동작합니다(026편).
10. 대응 방법
- 초기 확인 — 편입 소스별 테스트 결과와 첫 Alert를 확인합니다.
- 범위 확인 — 출발지·대상 범위와 성공 이벤트 여부를 확인합니다.
- 증거 확보 — 편입 검증 기록과 Alert를 보존합니다.
- 차단/조치 — 출발지 차단과 노출 서비스 점검을 요청합니다.
- 재발 방지 — 편입 체크리스트와 첫 24시간 집중 감시를 운영합니다.
11. 핵심 정리
| 단계 | 완료 기준 |
|---|---|
| 등록 | Active |
| 수집 | Analyzing file |
| 탐지 | 테스트 → 기대 룰 |
| 운영 | 히트맵·첫 Alert 판단 |
| 면접 포인트 | "에이전트 Active는 시작일 뿐 — 테스트 이벤트가 기대 룰로 나와야 편입 완료" |
12. 다음 편 예고
다음 편 050. SIEM·로그 수집 — SIEM 구조와 로그 수집 종합 정리 에서는 A영역 50편을 수집·정규화·저장·운영 네 축으로 종합하고, 다음 B영역 「탐지 룰 엔지니어링」으로 이어지는 흐름을 정리합니다.
이전 편: 048. SIEM·로그 수집 — 수집·정규화 장애 대응 절차
📚 시리즈 전체 보기: SIEM · 보안관제
