📚 네트워크 · 패킷 분석 › 04. 네트워크 장비 실습 — 200편
이전 글: 199. 네트워크 장비 로그 분석 · 다음 글: 201. 네트워크 스캔이란 무엇인가
1. 개념
SOC에서 네트워크 장비 이벤트를 분석한다는 것은 "이 이벤트가 실제 위협인가, 어디까지 영향을 주었는가"를 여러 장비의 증거로 판단하는 것입니다. 장비 하나의 로그는 사건의 한 조각일 뿐이므로, 트래픽이 지나간 장비들의 기록을 이어 붙여야 전체 그림이 보입니다.
이 글은 04 영역(장비 구성, 방화벽, NAT, IDS/IPS, 로그)을 하나의 분석 절차로 묶습니다. 각 장비가 답해 줄 수 있는 질문은 다음과 같습니다.
| 질문 | 답을 줄 장비·로그 | 관련 글 |
|---|---|---|
| 이 IP는 내부의 어느 단말인가? | DHCP 로그, 스위치 MAC 테이블, NAT 로그 | 161. MAC Address Table, 186. Firewall NAT 정책 |
| 트래픽은 어느 경로로 지나갔는가? | 구성도, 라우팅 테이블 | 160. 네트워크 장비 연결 구조, 175. Routing 경로 분석 |
| 통과했는가, 차단됐는가? | 방화벽 트래픽 로그 | 187. Firewall Log |
| 공격 패턴이 있었는가? | IDS/IPS Alert | 193. Snort, 194. Suricata |
| 얼마나 주고받았는가? | 흐름 기록(flow, NetFlow) | 191. Anomaly Detection |
| 장비 자체에 이상이 있었는가? | 장비 시스템·감사 로그 | 198. 네트워크 장비 장애와 보안 이벤트 |
2. 동작 원리
네트워크 장비 이벤트 분석의 일반적인 절차입니다.
① 이벤트 접수 (SIEM Alert, 외부 통보, 사용자 신고)
↓
② 범위 정하기: 관련 IP·포트·시간 범위 (앞뒤 여유 포함)
↓
③ 경로 재구성: 구성도로 출발지 → 목적지 경유 장비 목록 작성
↓
④ 장비별 증거 수집: 방화벽 판정 / NAT 변환 / IDS Alert / flow / 스위치·DHCP
↓ 연결 키: 시각 + 5-tuple, NAT 전후 주소, flow_id, MAC
⑤ 타임라인 작성: 모든 증거를 같은 시간 기준으로 정렬
↓
⑥ 판정: 정탐 / 오탐 / 추가 분석 필요, 영향 범위
↓
⑦ 대응·보고: 차단 요청, 담당 부서 전달, 에스컬레이션, 탐지 규칙 개선 제안④ 단계의 연결 키가 핵심입니다. 장비마다 기록하는 주소와 식별자가 다르므로, 어떤 키로 이어 붙일 수 있는지 알아야 합니다.
| 연결 키 | 이어 주는 로그 | 주의점 |
|---|---|---|
| 시각 + 5-tuple | 방화벽 ↔ IDS ↔ 서버 | 장비 간 시각 오차, NAT 전후 주소 차이 |
| NAT 변환 기록 | 공인 IP 로그 ↔ 내부 단말 로그 | PAT는 포트까지 일치해야 함 |
flow_id (Suricata) | 같은 흐름의 alert·http·dns·flow | 같은 센서 안에서만 유효 |
| MAC 주소 | DHCP ↔ 스위치 포트 ↔ 단말 | 라우터를 지나면 MAC이 바뀜 |
| 계정·호스트명 | VPN·인증 로그 ↔ 단말 | 공용 계정은 사용자 특정 불가 |
3. 주요 특징
장비별로 "무엇을 말해 주고, 무엇을 말해 주지 않는지"를 알고 증거를 해석해야 합니다.
| 장비 로그 | 말해 주는 것 | 말해 주지 않는 것 |
|---|---|---|
| 방화벽 허용 로그 | 연결이 정책상 허용됨 | 연결 안에서 무엇이 오갔는지 |
| 방화벽 차단 로그 | 해당 연결 시도가 막힘 | 다른 경로로 들어왔는지 |
| IDS Alert | 규칙과 일치하는 패턴이 보임 | 공격이 성공했는지 |
| 흐름 기록 | 통신량·지속 시간 | 내용 |
| 로그 없음 | (단독으로는 아무것도 증명하지 않음) | 트래픽 부재인지 수집 누락인지 |
그래서 판정은 여러 장비 증거의 일치 여부로 합니다. 예를 들어 "IDS Alert 있음 + 방화벽 허용 + 서버 응답 크기 큼"은 "IDS Alert 있음 + 방화벽 차단"보다 훨씬 높은 우선순위입니다.
4. 예시
분석 예시(가상 시나리오) — 아래는 절차를 보여 주기 위한 가상의 상황이며, 로그는 모두 형식 예시(값은 환경마다 다름)입니다.
상황: SIEM에 "DMZ 웹 서버 10.10.30.10으로 향하는 웹 공격 패턴" Alert가 표시됨.
[타임라인 — 형식 예시, 모두 KST 기준으로 정렬]
10:15:30 방화벽 DNAT 203.0.113.10:80 → 10.10.30.10:80, 출발지 198.51.100.7, 허용
10:15:31 IDS eve.json alert src 198.51.100.7 → dest 10.10.30.10:80, sid 1000100, action allowed
10:15:31 IDS 같은 flow_id의 http 이벤트: status 404
10:15:32~ 방화벽 같은 출발지에서 80 연결 120건 / 60초 (모두 허용)
10:16:40 IDS 같은 출발지 flow 이벤트들: bytes_toclient 작음, 대부분 404이 증거로 정리할 수 있는 판단은 다음과 같습니다.
- 트래픽은 방화벽을 통과해 서버까지 도달했습니다(허용 + DNAT).
- 응답이 대부분 404이고 응답 크기가 작아, 탐색·시도 단계일 가능성이 높고 성공 흔적은 이 증거만으로는 보이지 않습니다.
- 확정을 위해 웹 서버 접근 로그·애플리케이션 로그 확인이 필요하며, 출발지 차단 여부는 정책에 따라 결정합니다.
보고에는 확인한 사실, 추정, 확인하지 못한 부분(로그 공백 포함) 을 구분해 적습니다.
📷 [실습 화면 삽입 위치] 실습망에서 방화벽 로그·Suricata eve.json·웹 서버 접근 로그를 같은 출발지 IP로 검색해 시간순으로 나란히 정리한 타임라인 화면
5. 보안 관점
- 네트워크 장비 증거는 경계에서 무엇이 오갔는가를 보여 주지만, 호스트 내부에서 무엇이 실행됐는지는 보여 주지 않습니다. 호스트 로그·EDR과의 결합이 필요합니다.
- 공격자는 로그가 적게 남는 경로(동서 트래픽, 암호화, 허용된 서비스 포트)를 선호합니다. 증거가 없는 구간을 "안전"으로 보고하지 않습니다.
- 대응 조치(차단 등록, 격리)도 장비 설정 변경이므로, 변경 기록과 원복 계획을 함께 남깁니다.
- 분석에 사용한 원본 로그는 사건 종료까지 보존해 재검토가 가능하도록 합니다.
6. SOC 관점
관제자 분석 체크리스트
- 출발지·목적지는 NAT 전후 어느 쪽 주소인가? 내부 단말까지 특정했는가?
- 경유 장비 목록을 만들었고, 각 장비의 로그 존재 여부를 확인했는가?
- 각 장비의 판정(허용·차단·탐지)이 서로 모순되지 않는가? 모순된다면 구성 변경·우회 경로를 의심했는가?
- 사건 시각 장비 장애·재시작·드롭은 없었는가?
- 보고서에 사실·추정·미확인을 구분했는가?
판정 기준 (예)
Alert만 있음, 차단됨 → 낮음: 기록, 반복 시 출발지 차단 검토
Alert + 허용 + 응답 없음/오류 → 중간: 시도 단계, 서버 로그 확인
Alert + 허용 + 비정상 응답·대량 전송 → 높음: 즉시 에스컬레이션, 호스트 조사오탐 주의: 판정 기준은 조직의 자산 중요도와 정책에 따라 달라집니다. 탐지 장비 중심의 Alert 분석과 IOC 추출은 06 영역 298. Alert에서 IOC 추출·299. IDS Incident 분석에서 이어서 다룹니다. 다음 05 영역에서는 공격자가 네트워크를 탐색할 때 이 장비들에 어떤 흔적이 남는지를 다룹니다.
7. 핵심 정리
- 네트워크 장비 이벤트 분석은 여러 장비의 증거를 이어 붙여 위협 여부와 영향 범위를 판단하는 작업입니다.
- 절차는 접수 → 범위 → 경로 재구성 → 장비별 증거 → 타임라인 → 판정 → 대응·보고입니다.
- 시각+5-tuple, NAT 변환 기록,
flow_id, MAC 주소가 장비 로그를 잇는 연결 키입니다. - 각 장비 로그가 말해 주는 것과 말해 주지 않는 것을 구분하고, 로그 부재를 안전의 증거로 쓰지 않습니다.
- 보고서에는 확인한 사실, 추정, 미확인 부분을 나누어 적습니다.
