📚 네트워크 · 패킷 분석 › 02. 포트 · 프로토콜 분석 — 53편
이전 글: 52. TCP 기반 서비스와 UDP 기반 서비스 · 다음 글: 54. Registered Port
1. 개념
포트 번호 0~65535가 세 구간으로 나뉜다는 전체 그림은 51. 포트 번호 체계 — Well-known·Registered·임시 포트에서 다뤘습니다. 이 글은 그중 첫 구간인 Well-Known Port(0~1023) 만 좁혀서 봅니다.
IANA는 이 구간을 System Ports라고 부릅니다(RFC 6335). 인터넷 초기부터 쓰인 핵심 서비스가 이 구간에 모여 있어, 관제 로그에서 가장 자주 보이는 번호이기도 합니다.
| 항목 | 내용 |
|---|---|
| 범위 | 0 ~ 1023 |
| IANA 명칭 | System Ports (RFC 6335) |
| 할당 절차 | IETF Review 또는 IESG Approval — 표준화 과정을 거친 프로토콜 위주 |
| 포트 0 | 예약 번호. 정상 통신의 출발지·목적지로 쓰이지 않음 |
| 대표 서비스 | 20/21 FTP, 22 SSH, 23 Telnet, 25 SMTP, 53 DNS, 67/68 DHCP, 80 HTTP, 110 POP3, 123 NTP, 143 IMAP, 161/162 SNMP, 389 LDAP, 443 HTTPS, 445 SMB, 514 Syslog, 636 LDAPS, 993 IMAPS, 995 POP3S |
같은 번호라도 TCP와 UDP는 별개의 포트입니다. 예를 들어 53은 TCP·UDP 모두 DNS에 할당되어 있지만, 443/UDP는 HTTPS(TCP)와 다른 통신(QUIC)입니다(52. TCP 기반 서비스와 UDP 기반 서비스 참고).
2. 동작 원리
Well-Known Port의 특징은 "번호가 유명하다"는 것만이 아닙니다. 운영체제가 이 구간을 권한과 연결해 다룹니다.
서비스 프로그램이 bind(0.0.0.0:80) 요청
↓
[Linux 커널] 포트 < ip_unprivileged_port_start (기본 1024) 인가?
↓ 예
프로세스에 CAP_NET_BIND_SERVICE 권한이 있는가? (root는 기본 보유)
↓ 예 ↓ 아니오
LISTEN 성공 EACCES (Permission denied)
↓
일반적인 데몬: root로 포트를 연 뒤 권한이 낮은 계정으로 전환
(예: nginx master는 root, worker는 nginx/www-data 계정)- Linux는 1024 미만 포트를 Privileged Port로 취급합니다. 기준값은
net.ipv4.ip_unprivileged_port_start로 바꿀 수 있습니다. - Windows는 이런 구분이 없어, 일반 권한 프로그램도 낮은 번호 포트를 열 수 있습니다(방화벽 허용은 별도).
- 과거 rlogin/rsh 같은 r-계열 명령은 "출발지 포트가 1024 미만이면 root가 보낸 것"이라는 가정으로 상대를 신뢰했습니다. 누구나 자기 PC의 root가 될 수 있는 지금은 성립하지 않는 가정이며, 이 서비스들이 사라진 이유 중 하나입니다.
3. 주요 특징
관제에서 Well-Known Port를 볼 때 알아 둘 특징을 정리합니다.
| 특징 | 설명 | 관제에서의 의미 |
|---|---|---|
| 서버 쪽 포트 | 대부분 요청의 목적지 포트로 나타남 | dport가 0~1023이면 "어떤 서비스로의 접근인가"부터 판단 |
| 고정 출발지 포트 프로토콜 | DHCP(68→67), NTP(123↔123), NetBIOS Name(137↔137), IKE(500↔500) 등 | 출발지 포트가 낮다고 모두 이상한 것은 아님 |
| root 권한 흔적 | Linux에서 기본 설정이면 LISTEN에 권한 필요 | 알 수 없는 프로세스가 이 구간을 LISTEN → 권한 획득 여부 확인 |
| 번호 ≠ 프로토콜 | 등록은 "원래 용도"일 뿐 | 443에 TLS가 아닌 데이터도 흐를 수 있음 (93. 서비스와 포트 매핑 — 포트 번호만으로 서비스를 단정하면 안 되는 이유) |
| 스캔 우선순위 | 자동화 도구가 먼저 확인하는 번호 | 외부에서 이 구간 여러 포트로 시도 → 정찰 의심 |
평문 프로토콜과 암호화 대응 포트의 짝도 이 구간에 많습니다.
| 평문 | 암호화 대응 | 비고 |
|---|---|---|
| 80 HTTP | 443 HTTPS | 62. HTTPS와 TLS Handshake — 암호화된 통신에서 볼 수 있는 것에서 비교 |
| 23 Telnet | 22 SSH | 66. Telnet과 평문 프로토콜의 위험 |
| 110 POP3 / 143 IMAP | 995 POP3S / 993 IMAPS | 82. 메일 프로토콜 SMTP·POP3·IMAP |
| 389 LDAP | 636 LDAPS | 72. LDAP·Kerberos 포트 — 인증 인프라 트래픽 개요 |
| 21 FTP | 990 FTPS(암묵적), 22 SFTP | 65. SSH |
4. 예시
실습 예시 — 본인 소유 Linux VM에서 Well-Known 구간의 LISTEN 포트와 권한 기준을 확인합니다(Rocky/Ubuntu 공통).
# 권한이 필요한 포트의 기준값 (기본 1024)
sysctl net.ipv4.ip_unprivileged_port_start
# 1024 미만 포트에서 LISTEN 중인 TCP/UDP 소켓과 프로세스
sudo ss -tulnp '( sport < :1024 )'
# 번호의 등록 이름 확인 (로컬 /etc/services 기준)
getent services 123/udp
getent services 636/tcpss 출력 형식 예시(값은 환경마다 다름, 일부 열 생략):
Netid State Local Address:Port Process
udp UNCONN 0.0.0.0:68 users:(("dhclient",pid=812,...))
tcp LISTEN 0.0.0.0:22 users:(("sshd",pid=1034,...))
tcp LISTEN 0.0.0.0:80 users:(("nginx",pid=1502,...))일반 사용자로 낮은 번호 포트를 열려고 하면 거부되는 것도 확인할 수 있습니다.
# 일반 사용자 계정에서 실행 (예시: 권한 오류 발생)
python3 -m http.server 80
# PermissionError: [Errno 13] Permission denied5. 보안 관점
- 관심이 집중되는 구간: 원격 접속(22, 23), 파일 공유(21, 445), 디렉터리(389) 등 공격에 직접 쓰일 서비스가 모여 있어, 외부 노출 여부 자체가 점검 대상입니다(87. 내부망 필수 포트와 외부 노출 금지 포트).
- 평문 프로토콜의 잔존: 21, 23, 80, 110, 143, 389는 설정에 따라 계정 정보가 평문으로 오갑니다. 같은 서비스의 암호화 포트가 있는데도 평문 포트가 열려 있으면 개선 대상입니다.
- 권한 상승의 간접 증거: Linux 기본 설정에서 비인가 프로세스가 1024 미만 포트를 연다면, 해당 프로세스가 root 또는
CAP_NET_BIND_SERVICE를 가진 상태라는 뜻입니다. - "허용된 번호" 악용: 53, 80, 443은 방화벽에서 열려 있는 경우가 많아, 다른 통신을 숨기는 통로로 악용되기도 합니다(90. 정상 포트로 위장한 통신 — 443을 쓰는 비정상 트래픽).
6. SOC 관점
| 흔적 위치 | 확인할 수 있는 것 |
|---|---|
| 방화벽 로그 | 외부 → 내부 Well-Known 포트 접근 허용·차단 |
| IDS/IPS | 포트 기준 룰(예: 목적지 포트 23, 445)과 프로토콜 인식 결과 |
서버 ss/EDR | 낮은 번호 포트를 연 프로세스·실행 계정 |
| 자산 대장 | 서버별로 열려 있어야 하는 서비스 목록 |
관제자가 확인할 질문
- 이 목적지 포트의 서비스가 그 서버에서 실제로 운영 중인 서비스인가?
- 출발지 포트가 1024 미만이라면, 고정 출발지 포트를 쓰는 프로토콜(DHCP·NTP·IKE 등)인가?
- 낮은 번호 포트를 LISTEN하는 프로세스가 패키지로 설치된 정식 데몬인가?
오탐 주의: 포트 번호의 이름만 보고 서비스를 확정하지 않습니다. 대체 포트·포트 이전 같은 운영 설정도 흔하므로 프로세스와 실제 프로토콜로 확인합니다(89. 비표준 포트에서 동작하는 서비스 식별). 다수 Well-Known 포트로의 시도가 스캔인지 판단하는 방법은 05. 네트워크 스캔 징후 분석 영역 214. 특정 Port Scan에서 다룹니다.
7. 핵심 정리
- Well-Known Port는 0~1023, IANA 명칭은 System Ports이며 표준 절차를 거쳐 할당됩니다.
- Linux는 이 구간을 Privileged Port로 취급해 LISTEN에 root 또는
CAP_NET_BIND_SERVICE가 필요합니다(Windows는 구분 없음). - 대부분 목적지(서버) 포트로 보이지만 DHCP·NTP·IKE처럼 출발지도 고정된 프로토콜이 있습니다.
- 평문 서비스와 암호화 대응 포트의 짝이 많아, 평문 포트 노출 자체가 점검 포인트입니다.
- 번호는 원래 용도일 뿐이므로 프로세스·실제 프로토콜로 서비스를 확인합니다.
