92. Port + Protocol 분석

목록 보기

92/300

📚 네트워크 · 패킷 분석 › 02. 포트 · 프로토콜 분석 — 92편
이전 글: 91. IP + Port 분석 · 다음 글: 93. 서비스와 포트 매핑 — 포트 번호만으로 서비스를 단정하면 안 되는 이유

1. 개념

로그에 "443"이라고만 적혀 있으면 정보가 부족합니다. 443/TCP인지 443/UDP인지에 따라 전혀 다른 통신이고, 443/TCP 위에서 실제로 TLS가 오갔는지는 또 다른 문제입니다. Port + Protocol 분석은 포트 번호를 다음 세 층의 "프로토콜"과 묶어서 읽는 방법입니다.

층	무엇을 가리키는가	어디에 적혀 있는가	로그 표기 예
L3 프로토콜 번호	IP 다음에 오는 헤더 종류	IPv4 Protocol 필드, IPv6 Next Header	`proto=6`, `proto=tcp`, `PROTO=UDP`
L4 포트 번호	그 전송 계층 안의 프로세스	TCP·UDP 헤더	`dport=443`
L7 애플리케이션 프로토콜	실제로 오간 대화 형식	페이로드 내용	`app_proto=tls`, `service=dns`

포트 번호와 서비스 이름의 대응이 실제 서비스를 보장하지 않는다는 점은 93. 서비스와 포트 매핑 — 포트 번호만으로 서비스를 단정하면 안 되는 이유에서 다룹니다. 이 글은 전송 계층 프로토콜과 포트의 조합, 그리고 로그가 이 조합을 어떻게 적는지에 집중합니다.

2. 동작 원리

포트 번호 공간은 전송 계층 프로토콜마다 따로 있습니다. 운영체제는 IP 헤더의 프로토콜 번호로 먼저 TCP·UDP를 가른 뒤, 그 안에서 포트를 찾습니다.

IP 패킷 수신
    ↓ Protocol 필드 확인
    ├─ 6  (TCP)  → TCP 포트 공간에서 dport 조회 → 예: 53/tcp 소켓
    ├─ 17 (UDP)  → UDP 포트 공간에서 dport 조회 → 예: 53/udp 소켓
    ├─ 1  (ICMP) → 포트 없음, Type·Code로 구분
    ├─ 47 (GRE), 50 (ESP) → 포트 없음, 터널·암호화 페이로드
    └─ 그 외 번호 → 해당 프로토콜 처리기 (없으면 폐기 또는 ICMP 오류)

그래서 53/tcp와 53/udp는 서로 다른 소켓이며, 하나만 열려 있을 수도 있습니다. IANA도 포트를 "번호/전송 프로토콜" 쌍으로 등록합니다(같은 번호를 TCP·UDP 모두에 등록해 두는 경우가 많을 뿐입니다).

자주 쓰는 IP 프로토콜 번호입니다.

번호	프로토콜	포트 개념	관제 메모
1	ICMP	없음 (Type·Code)	로그에 포트 칸이 비거나 0으로 찍힐 수 있음
6	TCP	있음	연결 상태(Flag)까지 확인 가능
17	UDP	있음	연결 개념 없음, 응답 없음이 흔함
47	GRE	없음	터널 — 안쪽 패킷을 따로 봐야 함
50	ESP	없음	IPsec 암호화, 내용 확인 불가
58	ICMPv6	없음	IPv6의 이웃 탐색도 여기에 포함

3. 주요 특징

같은 번호라도 전송 프로토콜에 따라 정상과 이상의 기준이 달라지는 대표 조합입니다.

조합	일반적인 의미	관제 해석 포인트
53/udp	일반 DNS 질의·응답	기본값, 대량이면 터널링·증폭 여부
53/tcp	큰 응답(TC 비트 이후 재질의), 영역 전송(AXFR)	외부로의 AXFR 요청·허용은 정보 노출
443/tcp	HTTPS(TLS over TCP)	기본값
443/udp	QUIC(HTTP/3)	방화벽·프록시에서 가시성이 다를 수 있음
389/tcp	LDAP	내부 인증 트래픽
389/udp	CLDAP	외부 노출 시 반사·증폭 악용 사례
3389/tcp · 3389/udp	RDP (UDP는 전송 성능용)	둘 중 하나만 막으면 정책이 반쪽
500/udp · 4500/udp	IKE, IPsec NAT-T	ESP(50)와 함께 VPN 흐름을 이룸

로그와 탐지 도구는 이 세 층을 서로 다른 필드에 적습니다.

도구·로그	L3 프로토콜	L4 포트	L7 추정
iptables LOG	`PROTO=TCP`	`SPT=` `DPT=`	없음
Suricata `eve.json`	`proto`	`src_port`, `dest_port`	`app_proto`
Zeek `conn.log`	`proto`	`id.orig_p`, `id.resp_p`	`service`
Wireshark	`ip.proto`	`tcp.port`, `udp.port`	Protocol 열(해석기 결과)

Suricata app_proto나 Zeek service는 포트 번호가 아니라 내용을 보고 판단한 값이라서, 포트와 비교하면 "포트는 443인데 내용은 TLS가 아님" 같은 불일치를 찾을 수 있습니다. 불일치의 판정 방법은 89. 비표준 포트에서 동작하는 서비스 식별을 참고합니다.

4. 예시

실습 예시 — 본인 소유 실습 VM에서 같은 번호의 TCP·UDP 소켓을 구분해 봅니다(Rocky/Ubuntu 공통).

# 53번의 TCP·UDP 소켓을 각각 확인
sudo ss -tlnp 'sport = :53'
sudo ss -ulnp 'sport = :53'

# 서비스 이름 DB에서 번호/프로토콜 쌍 확인
grep -wE '^(domain|https|ldap|ms-wbt-server)' /etc/services

/etc/services 내용 형식 예시(값은 배포판마다 다름):

domain          53/tcp
domain          53/udp
https           443/tcp
https           443/udp

분석 방법 예시 — Suricata eve.json에서 포트와 app_proto가 기대와 다른 흐름을 고릅니다. 레코드는 형식 예시(값은 환경마다 다름)이며, jq가 필요합니다.

# dest_port 443인데 app_proto가 tls가 아닌 flow 이벤트
jq -c 'select(.event_type=="flow" and .dest_port==443 and .proto=="TCP"
             and .app_proto!="tls")
       | {src_ip, dest_ip, dest_port, proto, app_proto}' eve.json

{"src_ip":"192.168.10.31","dest_ip":"203.0.113.80","dest_port":443,"proto":"TCP","app_proto":"failed"}

app_proto가 failed(식별 실패)이거나 다른 프로토콜로 나오면, 해당 흐름의 패킷을 직접 확인할 후보가 됩니다. 연결이 너무 짧아 판단할 데이터가 없는 경우에도 식별 실패가 나올 수 있으므로 바이트 수를 함께 봅니다.

📷 [실습 화면 삽입 위치] Wireshark에서 udp.port == 443로 QUIC 패킷을, tcp.port == 443로 TLS 패킷을 각각 필터링해 Protocol 열이 다르게 표시된 화면

5. 보안 관점

방화벽 규칙은 포트와 프로토콜을 함께 지정해야 합니다. "443 허용"을 TCP로만 적으면 QUIC(443/udp)은 차단되고, 반대로 "any 프로토콜 443"으로 적으면 의도하지 않은 UDP까지 열립니다.
포트가 없는 프로토콜은 포트 기반 규칙을 빠져나갈 수 있습니다. ICMP·GRE·ESP는 프로토콜 번호로 따로 다뤄야 하며, ICMP는 데이터 영역에 임의 내용을 실을 수 있어 터널링에 악용되기도 합니다.
QUIC은 가시성 문제를 만듭니다. TLS 검사(복호화) 장비나 프록시가 443/tcp만 처리하면, 브라우저가 443/udp로 우회해 검사 범위 밖으로 나갈 수 있습니다. 조직에 따라 QUIC을 막아 TCP로 되돌리는 정책을 쓰기도 합니다.
DNS 53/tcp의 외부 허용은 영역 전송(AXFR)을 통한 내부 호스트 목록 노출로 이어질 수 있으므로, 영역 전송 허용 대상을 보조 DNS 서버로 제한합니다.

6. SOC 관점

흔적 위치	Port + Protocol로 확인할 것
방화벽 로그	proto 필드(번호 또는 이름), 포트 없는 프로토콜의 허용 여부
IDS/NSM (Suricata, Zeek)	`proto`와 `app_proto`/`service`의 조합, 식별 실패 흐름
패킷 캡처	`ip.proto` 값과 해석기가 붙인 Protocol 열
호스트 `ss`	같은 번호의 TCP·UDP 소켓이 각각 열려 있는가

관제자가 확인할 질문

이 이벤트의 포트는 어느 전송 프로토콜의 포트인가? 로그에 proto가 숫자로 찍혀 있다면 6·17·1 중 무엇인가?
포트가 기대하는 L7 프로토콜과, 탐지 도구가 내용으로 판단한 L7 프로토콜이 일치하는가?
포트가 없는 프로토콜(ICMP, GRE, ESP)의 흐름이 업무상 필요한 구간에서만 나타나는가?

오탐 주의: 같은 번호가 TCP·UDP 모두에 등록되어 있다고 해서 두 프로토콜이 다 쓰이는 것은 아닙니다(예: 443/udp는 QUIC을 쓰는 클라이언트에서만). 또 app_proto 식별 실패는 짧은 연결·비대칭 캡처에서도 흔하므로, 식별 실패 하나만으로 위장 통신이라 판단하지 않습니다.