049. SIEM·로그 수집 — 실전 시나리오 — 신규 서버 SIEM 편입부터 첫 Alert까지

Об этом предложении

SIEM · 보안관제 › A. SIEM 구조와 로그 수집 · 49/50편 학습 단계: 실전 시나리오·종합 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Wazuh 4.x 올인원 / Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」 이며, IP·계정·호스트명은 가상의 값입니다. 선행 학습 048. SIEM·로그 수집 — 수집·정규화 장애 대응 절차 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 · 보안관제