52. TCP 기반 서비스와 UDP 기반 서비스

📚 네트워크 · 패킷 분석 › 02. 포트 · 프로토콜 분석 — 52편
이전 글: 51. 포트 번호 체계 — Well-known·Registered·임시 포트 · 다음 글: 53. Well-Known Port
참고(01. TCP/IP 구조 이해): 40. TCP와 UDP 헤더 비교 — 신뢰성과 속도의 차이 — 헤더 구조와 신뢰성 차이는 이 글에서 다룸

1. 왜 알아야 하는가

같은 "포트 53"이라도 53/UDP와 53/TCP는 로그에서 다른 의미를 가집니다. 방화벽 정책도 프로토콜별로 따로 설정하며, 탐지 방법도 다릅니다.

• TCP 서비스는 연결 성립(3-Way Handshake) 여부로 "실제로 통신했는가"를 판단할 수 있습니다.
• UDP 서비스는 연결 과정이 없어 요청 한 번이 곧 통신입니다. 응답이 없으면 차단인지, 서비스가 없는지, 단순 유실인지 구분이 어렵습니다.

헤더 구조의 차이는 07. TCP와 UDP 헤더 비교에서 다뤘습니다. 이번 글은 "어떤 서비스가 왜 TCP 또는 UDP를 쓰는가, 그리고 그 차이가 관제에서 무엇을 바꾸는가" 에 집중합니다.

---

2. 핵심 개념

2-1. 주요 서비스별 전송 프로토콜

서비스	포트	전송 프로토콜	비고
HTTP	80	TCP
HTTPS	443	TCP (HTTP/3는 UDP 443, QUIC)	같은 443이라도 TCP·UDP가 다른 통신
SSH	22	TCP	SSH 구조 이해
DNS	53	UDP 기본, TCP 병행	큰 응답·존 전송 등은 TCP
DHCP	67(서버) / 68(클라이언트)	UDP	브로드캐스트 사용 (09편에서 다룸)
NTP	123	UDP	17편에서 다룸
SNMP	161(질의) / 162(Trap)	UDP	16편에서 다룸
Syslog	514	UDP 전통적, TCP도 사용	원격 Syslog
TFTP	69	UDP	인증 없는 파일 전송
SMB	445	TCP	14편에서 다룸
RDP	3389	TCP (UDP도 병행 가능)	15편에서 다룸
SMTP / IMAP / POP3	25 / 143 / 110	TCP	13편에서 다룸

2-2. 서비스가 UDP를 선택하는 이유

이유	해당 서비스	설명
짧은 요청·응답	DNS, NTP, SNMP	연결 준비 비용 없이 패킷 한 쌍으로 끝남
브로드캐스트 필요	DHCP	IP가 없는 상태에서 "누구든 응답해 달라"는 요청은 연결 기반으로 불가
지연 민감	음성·영상, QUIC	재전송을 기다리는 것보다 다음 데이터가 중요하거나, 신뢰성을 상위 계층에서 직접 구현
단방향 전송	Syslog(UDP), SNMP Trap	보내고 끝. 수신 확인이 필요 없다고 본 설계

2-3. 관제에서 달라지는 점

항목	TCP 서비스	UDP 서비스
"통신 성공" 증거	SYN → SYN/ACK → ACK 성립	요청과 응답 패킷이 모두 존재
닫힌 포트의 반응	RST 응답	ICMP Port Unreachable (또는 무응답)
방화벽 상태 추적	플래그로 연결 시작·종료 판단	플래그가 없어 타임아웃으로 세션 관리
출발지 IP 위조	Handshake가 필요해 데이터 통신은 어려움	요청 한 번으로 응답이 생겨 위조·반사에 악용되기 쉬움
ss LISTEN 표시	LISTEN	UNCONN (연결 없는 대기 소켓)

---

3. 동작 원리

DNS를 예로 들면 같은 서비스가 상황에 따라 UDP와 TCP를 오갑니다.

그림 1. 서비스별로 주로 쓰는 전송 계층 — 같은 포트 번호라도 TCP/UDP는 별개입니다

[클라이언트]                                   [DNS 서버 :53]
    │ ① UDP 질의 (A? example.com)                  │
    │ ─────────────────────────────────────────→   │
    │ ② UDP 응답                                   │
    │ ←─────────────────────────────────────────   │
    │     ↓ 응답이 UDP로 담기에 크면                 │
    │     ↓ 서버가 응답에 TC(잘림) 비트를 설정       │
    │ ③ 클라이언트가 TCP로 같은 질의 재시도          │
    │ ── SYN → SYN/ACK → ACK ──────────────────→   │
    │ ④ TCP 질의·응답 → 연결 종료                   │

UDP의 "닫힌 포트" 반응도 TCP와 다릅니다.

[클라이언트] ── UDP → 192.168.10.20:9999 (아무 서비스 없음)
                         ↓
[서버 커널]  대기 소켓 없음 → ICMP Type 3 Code 3 (Port Unreachable) 회신
                         ↓
[클라이언트] "connection refused" 오류로 인식
             (방화벽이 ICMP를 막거나 조용히 버리면 → 무응답 = 판단 불가)

ICMP 메시지 형식은 06. ICMP와 ping을 참고하세요.

---

4. 실제 명령어 / 실습

실습 환경: 본인 소유 Linux VM (Rocky Linux 또는 Ubuntu). 인터페이스 이름은 ens33을 예시로 사용합니다.

도구 설치:

# Rocky Linux
sudo dnf install -y bind-utils tcpdump
# Ubuntu
sudo apt install -y dnsutils tcpdump

4-1. TCP/UDP 대기 소켓 구분

sudo ss -tlnp     # TCP LISTEN
sudo ss -ulnp     # UDP 대기 소켓 (상태가 UNCONN으로 표시)

4-2. 같은 DNS 질의를 UDP와 TCP로 비교

터미널 1에서 캡처를 시작합니다.

sudo tcpdump -ni ens33 port 53

터미널 2에서 질의합니다. (dig는 기본적으로 UDP를 사용합니다.)

dig example.com A
dig +tcp example.com A

📷 [실습 화면 삽입] tcpdump에서 첫 질의는 UDP 한 쌍, +tcp 질의는 SYN부터 시작하는 TCP 흐름으로 보이는 화면

4-3. 닫힌 UDP 포트의 반응 확인 (로컬)

# 터미널 1
sudo tcpdump -ni lo icmp
# 터미널 2: 서비스가 없는 로컬 UDP 포트로 DNS 질의
dig @127.0.0.1 -p 9999 example.com +tries=1 +time=2

4-4. UDP 서비스 동작 확인 예 (NTP)

chronyc sources          # chrony가 사용 중인 NTP 서버 (Rocky 기본, Ubuntu는 버전에 따라 chrony 또는 systemd-timesyncd)
sudo ss -uanp | grep -E ':123\b'

---

5. 결과 확인

형식 예시(값은 환경마다 다름):

$ sudo ss -ulnp
State   Recv-Q Send-Q  Local Address:Port   Peer Address:Port  Process
UNCONN  0      0       127.0.0.1:323        0.0.0.0:*          users:(("chronyd",pid=812,fd=5))

# tcpdump (UDP 질의)
IP 192.168.10.20.51377 > 192.168.10.1.53: 2210+ A? example.com. (29)
IP 192.168.10.1.53 > 192.168.10.20.51377: 2210 1/0/1 A 203.0.113.10 (56)

# tcpdump (TCP 질의) — 첫 패킷이 SYN
IP 192.168.10.20.42818 > 192.168.10.1.53: Flags [S], seq ...

# 닫힌 UDP 포트
;; communications error to 127.0.0.1#9999: connection refused
IP 127.0.0.1 > 127.0.0.1: ICMP 127.0.0.1 udp port 9999 unreachable, length ...

확인 항목	기대 결과
ss -u 상태	UNCONN (UDP는 LISTEN 상태가 없음)
dig 기본 질의	UDP 패킷 2개(질의·응답)로 끝남
dig +tcp	3-Way Handshake 후 질의·응답, 종료
닫힌 UDP 포트	ICMP Port Unreachable 회신

• TCP LISTEN과 UDP UNCONN 소켓을 구분했다
• 같은 DNS 질의가 UDP·TCP로 다르게 보이는 것을 확인했다
• 닫힌 UDP 포트에서 ICMP Port Unreachable을 확인했다
• 내 VM의 UDP 서비스(chronyd 등)를 프로세스까지 확인했다

📷 [실습 화면 삽입] lo 인터페이스에서 ICMP port unreachable이 캡처된 화면

---

6. 패킷 / 로그 분석

방화벽 로그에서는 프로토콜 필드(PROTO=TCP / PROTO=UDP)를 먼저 확인합니다. Linux netfilter LOG 형식 예시(값은 환경마다 다름):

IN=ens33 OUT= SRC=198.51.100.23 DST=192.168.10.20 LEN=76 ... PROTO=UDP SPT=40211 DPT=123 LEN=56
IN=ens33 OUT= SRC=198.51.100.23 DST=192.168.10.20 LEN=60 ... PROTO=TCP SPT=40212 DPT=445 WINDOW=64240 SYN

firewalld 환경(Rocky 기본)에서 차단 패킷을 로그로 남기려면 sudo firewall-cmd --set-log-denied=all 을 사용하고, 커널 로그는 sudo journalctl -k | grep 'DPT=' 로 확인합니다(실습 후 --set-log-denied=off로 되돌림).

관찰	정상일 수 있는 경우	의심해야 하는 경우
53/TCP 트래픽	큰 DNS 응답, 내부 DNS 서버 간 존 전송	일반 PC가 외부로 53/TCP 대량 통신, 허가되지 않은 존 전송 요청
외부 → 내부 UDP 요청에 대한 큰 응답	공개 DNS·NTP 서버 운영	요청보다 훨씬 큰 응답이 특정 외부 IP로 반복 (반사·증폭 악용 가능성)
443/UDP 트래픽	브라우저의 HTTP/3(QUIC)	QUIC을 정책상 막은 조직인데 특정 단말만 지속 사용
다수 UDP 포트로 요청 + ICMP Unreachable 다수	네트워크 점검	UDP 포트 스캔 (05. 네트워크 스캔 · 공격 징후 분석 시리즈에서 다룸)
514/UDP로 외부 전송	승인된 외부 로그 수집 서버	목적지가 로그 서버 목록에 없음

---

7. 보안관제 관점

로그·장비	TCP 서비스	UDP 서비스
방화벽 세션 로그	연결 성립·종료 시각, 종료 사유	타임아웃 기반 세션, 종료 시각이 부정확할 수 있음
IDS	흐름 재조립 후 내용 검사	패킷 단위 검사 비중이 큼
서버 로그	서비스 로그에 접속 기록이 남는 경우 많음	서비스가 요청을 기록하지 않는 경우가 많음 (DNS 질의 로그는 기본 꺼짐인 경우가 많음)

한계와 오탐 주의

• UDP는 요청만 보고 "통신 성공"이라고 단정할 수 없습니다. 반드시 응답 패킷의 존재를 확인합니다.
• UDP는 출발지 IP 위조가 상대적으로 쉽습니다. UDP 로그의 출발지 IP를 곧바로 "실제 공격자"로 보고하면 안 됩니다.
• 방화벽이 ICMP를 차단하면 닫힌 UDP 포트도 "무응답"으로 보여, 열림·닫힘·필터링 구분이 어렵습니다.
• DNS 악용 탐지는 08. DNS 악용 유형, 증폭 공격 탐지 기준은 05. 네트워크 스캔 · 공격 징후 분석 시리즈에서 다룹니다.

---

8. 핵심 정리

• 주요 서비스는 신뢰성이 필요하면 TCP, 짧은 요청·브로드캐스트·지연 민감 통신이면 UDP를 씁니다. DNS·RDP·HTTPS(HTTP/3)처럼 둘 다 쓰는 서비스도 있습니다.
• TCP는 Handshake 성립으로 통신 성공을 판단하고, UDP는 요청·응답 쌍의 존재로 판단합니다.
• 닫힌 포트의 반응은 TCP가 RST, UDP가 ICMP Port Unreachable(또는 무응답)입니다.
• ss에서 UDP 대기 소켓은 LISTEN이 아니라 UNCONN으로 표시됩니다.
• UDP는 출발지 위조·반사에 악용되기 쉬우므로, UDP 로그의 출발지 IP는 신중하게 해석합니다.

다음 글: 04. HTTP 요청·응답 구조