57. Destination Port
네트워크 · 패킷 분석
📚 네트워크 · 패킷 분석 › 02. 포트 · 프로토콜 분석 — 57편
이전 글: 56. Source Port · 다음 글: 58. Listening Port
1. 개념
Destination Port(목적지 포트, dport) 는 TCP·UDP 헤더의 2~3바이트에 있는 16비트 필드로, 패킷을 받을 프로세스를 가리킵니다. 헤더 위치와 요청·응답에서 방향이 바뀌는 원리는 56. Source Port에서 다뤘으므로, 이 글은 목적지 포트를 "연결을 시작한 쪽이 무엇을 원했는가" 로 읽는 방법에 집중합니다.
연결을 시작하는 패킷(TCP SYN, UDP 첫 요청)의 dport는 클라이언트가 고른 값이 아니라, 클라이언트가 이용하려는 서비스의 포트입니다. 그래서 세션 단위 로그에서 dport는 곧 "서비스 포트"가 됩니다.
| 관점 | dport가 알려 주는 것 | 한계 |
|---|---|---|
| 서비스 식별 | 22 → SSH, 443 → HTTPS를 기대했다는 뜻 | 실제로 그 프로토콜이 오갔는지는 보장하지 않음 |
| 의도 추정 | 관리 포트·DB 포트 등 어떤 자원에 접근하려 했는가 | 오입력·자동화 설정 오류도 같은 모양 |
| 정책 판단 | 방화벽 규칙과 비교해 허용 대상인가 | 허용 포트 위에서 다른 통신이 가능 |
| 분포 분석 | 한 출발지가 몇 개의 dport에 접근했는가 | 시간 범위를 정해야 의미가 생김 |
2. 동작 원리
목적지 호스트의 운영체제는 들어온 세그먼트를 (프로토콜, 목적지 IP, 목적지 포트) 로 찾아 해당 소켓에 넘깁니다. LISTEN 중인 소켓이 없거나 중간에서 막히면 응답 모양이 달라지고, 이 차이가 로그와 패킷에서 그대로 보입니다.
SYN (dport 22) 또는 UDP 요청 (dport 161) 도착
↓
[네트워크·호스트 방화벽] ── 차단(drop) → 응답 없음 (재전송만 반복)
│ └─ 차단(reject) → TCP RST 또는 ICMP 오류
↓ 허용
[OS 소켓 조회: proto + dst IP + dport]
├─ LISTEN 소켓 있음 → TCP: SYN/ACK / UDP: 서비스 응답(없을 수도 있음)
└─ LISTEN 소켓 없음 → TCP: RST/ACK
→ UDP: ICMP Destination Unreachable
(Type 3, Code 3 Port Unreachable)UDP는 서비스가 있어도 요청이 형식에 맞지 않으면 아무 응답을 하지 않을 수 있고, ICMP 오류는 OS가 초당 발생량을 제한하기도 합니다. 그래서 UDP dport는 "응답 없음 = 차단"으로 단정하기 어렵습니다. 응답 패킷 모양 자체는 03 영역 142. Port Scan Packet 분석에서 다룹니다.
3. 주요 특징
관제에서 dport는 개수와 분포로 볼 때 가장 많은 정보를 줍니다. 하나의 출발지를 기준으로 일정 시간 동안의 이벤트를 묶으면 다음처럼 모양이 갈립니다.
| 모양 | 목적지 IP 수 | 고유 dport 수 | 같은 dport 연결 수 | 먼저 떠올릴 해석 |
|---|---|---|---|---|
| 일반 클라이언트 | 적음 | 적음 (53, 443 등) | 보통 | 정상 이용 |
| 수직 스캔(Vertical) | 1개 | 많음 | 포트당 1~2회 | 한 호스트의 열린 포트 탐색 |
| 수평 스윕(Horizontal) | 많음 | 1~몇 개 | IP당 1~2회 | 특정 서비스(445, 3389 등)를 가진 호스트 찾기 |
| 반복 접속(Brute Force 형태) | 1개 | 1개 (22, 3389 등) | 매우 많음 | 인증 대입 시도, 또는 설정 오류 |
| 블록 스캔 | 많음 | 많음 | 적음 | 대역 전체 탐색 |
같은 수치라도 dport의 성격에 따라 무게가 다릅니다.
| dport 범주 | 예 | 해석 포인트 |
|---|---|---|
| 원격 관리 | 22, 3389, 5985/5986, 5900 | 외부 → 내부 접근 시도는 우선순위 높음 |
| 파일 공유·RPC | 445, 135, 139 | 내부 PC → PC 방향이면 확산 여부 확인 |
| DB·캐시 | 3306, 1433, 5432, 6379 | 앱 서버 외 출발지면 이상 |
| 임시 포트 범위 | 49152 이상 등 | 인바운드 dport라면 응답 패킷 방향 착오 가능성 먼저 확인 |
스캔 흔적의 심화 분석은 05 영역 242. Destination Port 분석, 226. 단일 IP에 대한 다중 Port 접근, 227. 다수 IP에 대한 Port 접근에서 다룹니다.
4. 예시
분석 방법 예시 — 방화벽 로그에서 출발지별 고유 dport 수를 세어 위 표의 모양을 구분합니다. 로그는 형식 예시(값은 환경마다 다름)이며 필드 이름은 장비마다 다릅니다.
src=203.0.113.45 sport=40112 dst=192.168.10.20 dport=21 proto=tcp action=deny
src=203.0.113.45 sport=40112 dst=192.168.10.20 dport=22 proto=tcp action=allow
src=203.0.113.45 sport=40112 dst=192.168.10.20 dport=3306 proto=tcp action=deny
src=198.51.100.7 sport=51022 dst=192.168.10.20 dport=22 proto=tcp action=allow
src=198.51.100.7 sport=51024 dst=192.168.10.20 dport=22 proto=tcp action=allow# 출발지별: 목적지 IP 수, 고유 dport 수, 전체 건수
awk '{for(i=1;i<=NF;i++){split($i,a,"="); v[a[1]]=a[2]}
k=v["src"]; n[k]++
if(!((k,v["dst"]) in sd)){sd[k,v["dst"]]=1; d[k]++}
if(!((k,v["dport"]) in sp)){sp[k,v["dport"]]=1; p[k]++}}
END{for(k in n) printf "%-15s dst=%d dports=%d total=%d\n",k,d[k],p[k],n[k]}' fw.log첫 출발지는 고유 dport가 많아 수직 스캔 모양, 두 번째는 22 하나에 반복되어 반복 접속 모양으로 1차 분류할 수 있습니다.
실습 예시 — 본인 소유 실습 VM에서 패킷 캡처로 같은 집계를 해 볼 수 있습니다(tshark는 Rocky wireshark-cli, Ubuntu tshark 패키지).
# 연결 시작 패킷(SYN)만 골라 출발지·목적지 포트별 건수
tshark -r lab.pcapng -Y 'tcp.flags.syn==1 && tcp.flags.ack==0' \
-T fields -e ip.src -e tcp.dstport | sort | uniq -c | sort -rn | head
# 호스트에서 지금 특정 dport로 나가고 있는 연결
ss -tn 'dport = :443'5. 보안 관점
- 방화벽 정책은 대부분 dport 중심입니다. "어느 출발지가 어느 목적지의 어떤 서비스(dport)에 접근할 수 있는가"가 규칙의 기본 단위이며, 출발지 포트는 임시 포트라 보통
any로 둡니다. 정책 설계 자체는 06 영역 261. Destination Port 정책에서 다룹니다. - dport는 연결을 시작하는 쪽이 정합니다. 따라서 "허용된 dport 위에서 다른 통신"이 가능합니다. 악성 코드가 외부 443으로 나가면서 HTTPS가 아닌 자체 프로토콜을 쓰는 경우가 대표적입니다(90. 정상 포트로 위장한 통신 — 443을 쓰는 비정상 트래픽).
- 아웃바운드 dport 제한은 탐지와 방어를 동시에 합니다. 일반 PC의 외부 25·445·23 연결을 막아 두면, 그 시도 자체가 경보가 됩니다.
- 드롭(응답 없음)과 리젝트(RST·ICMP 응답)는 스캔하는 쪽에 주는 정보량이 다릅니다. 외부 경계는 드롭이 일반적이고, 내부는 장애 진단 편의 때문에 리젝트를 쓰기도 합니다.
6. SOC 관점
| 흔적 위치 | dport로 확인할 수 있는 것 |
|---|---|
| 방화벽 세션·차단 로그 | Initiator가 원한 서비스, 허용·차단 결과 |
| IDS Alert | 룰이 기대한 서비스 포트와 실제 dport (96. IDS Alert의 Port) |
| NetFlow 등 흐름 기록 | 출발지별 고유 dport 수, 연결 빈도 |
| 서버 서비스 로그 | 그 dport의 서비스가 실제로 요청을 처리했는가(인증 로그 등) |
관제자가 확인할 질문
- 이 dport는 목적지 자산에서 실제로 제공 중인 서비스인가? 없는 서비스로의 접근이 반복되는가?
- 같은 출발지가 정해진 시간 안에 접근한 고유 dport 수와 목적지 수는 몇인가?
- 허용된 dport라면, 서비스 로그에 인증 실패·성공이 함께 남았는가?
오탐 주의: 인바운드 이벤트의 dport가 50000번대처럼 임시 포트 범위라면, 먼저 응답 패킷을 요청으로 잘못 읽은 것이 아닌지 확인합니다. 또 취약점 점검 서버·모니터링 시스템은 정상 업무로 여러 dport를 두드리므로 예외 목록과 대조합니다.
7. 핵심 정리
- Destination Port는 연결을 시작한 쪽이 이용하려는 서비스를 나타내며, 세션 로그에서는 서비스 포트로 읽습니다.
- 서비스가 없으면 TCP는 RST/ACK, UDP는 ICMP Port Unreachable(Type 3, Code 3)로 응답하고, 방화벽 드롭이면 응답이 없습니다.
- 출발지 하나의 고유 dport 수·목적지 수·반복 횟수로 수직 스캔, 수평 스윕, 반복 접속을 1차 구분합니다.
- 방화벽 정책은 dport 중심이지만, 허용된 dport 위에서 다른 프로토콜이 오갈 수 있습니다.
- 임시 포트 범위의 인바운드 dport는 방향 착오부터 의심합니다.
