53. Well-Known Port

About this offer

📚 네트워크 · 패킷 분석 › 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/tcp ss 출력 형식 예시(값은 환경마다 다름, 일부 열 생략): 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 denied 5. 보안 관점 관심이 집중되는 구간 : 원격 접속(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처럼 출발지도 고정된 프로토콜이 있습니다. 평문 서비스와 암호화 대응 포트의 짝이 많아, 평문 포트 노출 자체가 점검 포인트입니다. 번호는 원래 용도일 뿐이므로 프로세스·실제 프로토콜로 서비스를 확인합니다.