295. IDS Alert의 Source/Destination 분석

Ids Soc ip 네트워크 패킷 분석 로그분석 방화벽 · IDS 기초 보안관제

네트워크 · 패킷 분석

목록 보기

295/300

📚 네트워크 · 패킷 분석 › 06. 방화벽 · IDS 기초 — 295편
이전 글: 294. 비정상 Network Traffic 탐지 · 다음 글: 296. Alert와 Firewall Log 연계

1. 개념

IDS Alert의 Source(출발지) 와 Destination(목적지) 은 Alert를 만든 패킷의 보낸 쪽과 받는 쪽입니다. 여기서 흔한 오해가 생깁니다. Alert의 출발지가 항상 공격자이고, 목적지가 항상 피해자인 것은 아닙니다. 스캔 맥락의 출발지·목적지 IP 분석은 05 영역 240. Source IP 분석, 241. Destination IP 분석에서 다뤘으므로, 이 글은 Alert 필드의 주소를 해석할 때의 함정에 집중합니다.

규칙이 보는 패킷	Alert의 src	Alert의 dest	공격자·대상
요청(`to_server`) — 공격 요청 탐지	클라이언트	서버	src = 공격 시도자, dest = 대상
응답(`to_client`) — 서버 응답 탐지	서버	클라이언트	src = 대상 서버, dest = 시도자
내부 → 외부 — 악성 통신 탐지	내부 호스트	외부 서버	src = 감염 의심 호스트, dest = 악성 인프라

2. 동작 원리

Alert의 주소가 실제 사람·장비를 가리키기까지는 여러 층이 끼어 있습니다.

실제 공격자
   ↓ (VPN·프록시·감염 PC 경유 가능)
공인 IP 203.0.113.95  ← Alert의 src로 보이는 주소 (실제 공격자의 위치와 다를 수 있음)
   ↓
[CDN / 로드 밸런서 / 리버스 프록시] ← 이 뒤에 센서가 있으면 src가 프록시 IP로 바뀜
   ↓
[방화벽 NAT] 공인 198.51.100.10 → 사설 192.168.20.10
   ↓
센서 위치에 따라 dest가 공인 주소 또는 사설 주소로 기록
   ↓
웹 서버 192.168.20.10

상황	Alert에 보이는 값	실제 값을 찾는 곳
프록시·로드 밸런서 뒤의 센서	src = 프록시 IP	HTTP `X-Forwarded-For` 헤더, 프록시 로그
방화벽 NAT 전/후 센서	공인 또는 사설 dest	방화벽 NAT 로그·세션 로그
내부 사용자의 외부 통신(출발지 NAT 후 센서)	src = 방화벽 공인 IP	방화벽 세션 로그의 변환 전 주소
응답 방향 규칙	src = 서버	규칙의 `flow`·`target` 확인

Suricata는 규칙에 target:dest_ip 또는 target:src_ip가 있으면 EVE Alert에 source·target 정보를 추가해 공격 대상 쪽을 명시합니다. 또한 설정에 따라 Alert에 X-Forwarded-For 값을 함께 기록할 수 있습니다(xff 옵션, 기록 위치와 방식은 버전·설정별로 확인).

3. 주요 특징

UDP·ICMP·TCP SYN의 출발지는 위조될 수 있습니다. 연결이 성립하지 않은(3-way handshake가 끝나지 않은) 트래픽의 src는 신뢰도가 낮습니다. 반면 flow:established 조건이 있는 규칙의 Alert는 양방향 통신이 있었으므로 출발지 위조 가능성이 낮습니다.
공유 IP가 많습니다. 클라우드·CDN·통신사 NAT 주소는 여러 사용자가 함께 씁니다. 평판이 나쁜 IP라도 지금 그 주소의 사용자가 같은 공격자라는 보장은 없습니다.
내부 IP는 시간에 따라 주인이 바뀝니다. DHCP 환경에서는 Alert 시각 기준의 임대 기록으로 호스트를 특정해야 합니다.

4. 예시

응답 방향 규칙의 Alert에서 주소를 해석하는 형식 예시입니다(값은 환경마다 다름, Suricata EVE 일부 필드).

# 형식 예시 — 서버 응답에서 일치한 Alert (target 표시 포함)
{"timestamp":"2026-09-30T15:40:02.114200+0900","event_type":"alert",
 "src_ip":"192.168.20.10","src_port":80,"dest_ip":"203.0.113.95","dest_port":50712,
 "alert":{"signature_id":1001901,"signature":"LOCAL server returned directory listing to external client",
          "source":{"ip":"203.0.113.95","port":50712},"target":{"ip":"192.168.20.10","port":80}},
 "http":{"xff":"198.51.100.7"}}

분석 방법

src_ip가 내부 서버이지만, 포트 80이 출발지이므로 서버의 응답입니다. alert.target도 서버를 대상으로 표시합니다.
시도한 쪽은 dest_ip 203.0.113.95입니다. 다만 xff 값이 있으므로 이 주소는 중간 프록시일 수 있고, 원 요청자는 198.51.100.7일 가능성이 있습니다. X-Forwarded-For는 클라이언트가 임의로 넣을 수도 있으므로 신뢰하는 프록시가 추가한 값인지 확인합니다.
차단·IOC 등록 대상을 정할 때 이 구분이 중요합니다. 서버 IP를 차단 목록에 넣는 실수를 막아야 합니다.

5. 보안 관점

출발지를 잘못 해석하면 엉뚱한 대상을 차단하거나, 내부 피해 호스트를 공격자로 오인합니다.
공격자는 공유 인프라(클라우드, 프록시, 감염 PC)를 거쳐 실제 위치를 숨깁니다. IP 하나로 행위자를 단정하지 않습니다.
위조 가능한 출발지를 기준으로 자동 차단하면, 공격자가 정상 IP를 위조해 서비스 차단을 유도할 수 있습니다.

6. SOC 관점

관제자가 Alert의 주소를 해석할 때 질문

이 규칙은 요청을 봤는가, 응답을 봤는가? 공격 방향은 어느 쪽인가?
센서 위치 기준으로 주소는 NAT 전인가 후인가? 프록시 뒤인가?
내부 IP라면 Alert 시각 기준 어떤 호스트·사용자였는가(DHCP·자산 대장)?
외부 IP의 평판·소유 조직·공유 인프라 여부는?

Alert의 src / dest
   ↓ 규칙 flow·target → 공격 방향 확정
   ↓ 센서 위치·NAT·프록시 → 실제 주소 복원
   ↓ 내부: 자산·DHCP 기록 → 호스트·담당자
   ↓ 외부: 평판·소유 조직·공유 여부
결과: 공격 시도자 / 대상 자산 / 신뢰도 기록

오탐 주의: 외부 IP의 나쁜 평판은 과거 기록일 뿐입니다. 공유 IP라면 평판만으로 공격자로 판단하지 않습니다. 주소 복원에 필요한 방화벽 로그 연계는 296. Alert와 Firewall Log 연계에서 이어집니다.

7. 핵심 정리

Alert의 src·dest는 패킷의 보낸 쪽·받는 쪽이며, 응답 방향 규칙에서는 src가 대상 서버입니다.
규칙의 flow 조건과 Suricata target 표시로 공격 방향을 먼저 확정합니다.
NAT·프록시·로드 밸런서 때문에 Alert의 주소가 실제 주소와 다를 수 있어 방화벽·프록시 로그로 복원합니다.
연결이 성립하지 않은 트래픽의 출발지는 위조 가능성이 있고, 공유 IP는 행위자를 특정하지 못합니다.
내부 IP는 Alert 시각 기준의 DHCP·자산 기록으로 실제 호스트를 확인합니다.

changseop lee

코드에 숨겨진 위협을 읽고 AI로 보안의 미래를 설계합니다. 프론트엔드 개발 경험을 자산 삼아 더 견고하고 지능적인 보안 운영 시스템을 구축해 나가는 과정을 기록합니다