📚 네트워크 · 패킷 분석 › 02. 포트 · 프로토콜 분석 — 93편
이전 글: 92. Port + Protocol 분석 · 다음 글: 94. Port Scan
참고(리눅스 시스템 기초): 16. 프로세스와 네트워크 소켓 (ss -p) — 포트를 연 프로세스를 찾는 방법
1. 왜 알아야 하는가
관제 화면에 "목적지 포트 3306"이 보이면 보통 "MySQL 접속"이라고 읽습니다. 대부분은 맞습니다. 그러나 포트 번호는 서비스 이름표일 뿐, 실제로 어떤 프로그램이 어떤 프로토콜로 통신하는지를 보증하지 않습니다.
- 관리자가 SSH를 2222번, 관리 웹을 8443번처럼 비표준 포트로 옮긴 경우
- 악성코드가 방화벽을 통과하려고 허용된 포트(80, 443, 53) 를 쓰는 경우
- 하나의 포트 번호를 TCP와 UDP가 각각 다른 용도로 쓰는 경우
이런 상황에서 "포트 = 서비스"로 단정하면 탐지 누락과 오탐이 동시에 생깁니다. 이번 글에서는 포트와 서비스 이름이 연결되는 방식, 그리고 포트 번호 → 프로세스 → 응답 내용 순서로 서비스를 확정하는 방법을 정리합니다.
2. 핵심 개념
2-1. 포트-서비스 대응표는 어디에 있는가
| 출처 | 성격 | 관제에서의 의미 |
|---|---|---|
| IANA Service Name and Port Number Registry | 공식 등록부 | "이 번호는 원래 무엇을 위해 등록되었나" |
/etc/services (Linux) | 로컬 참조 파일, 일부만 수록 | ss, tcpdump 등이 번호를 이름으로 바꿔 보여줄 때 사용 |
| 보안 장비의 서비스/애플리케이션 객체 | 장비 벤더가 정의 | 방화벽 정책의 "HTTP", "SSH" 같은 이름 |
| 서버 설정 파일 | 실제 동작 기준 | sshd_config의 Port, nginx의 listen 등 |
/etc/services에 3306/tcp mysql이라고 적혀 있다는 것은 "그렇게 부르기로 했다"는 뜻입니다. 그 포트에 실제로 MySQL이 떠 있는지와는 무관합니다.
2-2. 포트와 서비스가 어긋나는 대표 유형
| 유형 | 예 | 성격 |
|---|---|---|
| 대체 포트 | HTTP를 8080·8000에, HTTPS를 8443에 | 운영상 흔함 |
| 포트 이전 | SSH를 22 → 2222 등으로 이동 | 자동화 스캔 회피 목적의 운영 설정 |
| 공유 포트 | 443/TCP(HTTPS)와 443/UDP(HTTP/3, QUIC) | 같은 번호, 다른 전송 계층 |
| 허용 포트 악용 | 443·53으로 HTTPS·DNS가 아닌 통신 | 탐지 우회 목적 (21편에서 다룸) |
| 등록 없는 포트 | 사내 애플리케이션이 임의 포트 사용 | 자산·서비스 대장으로만 확인 가능 |
2-3. 서비스 식별의 3단계 근거
| 단계 | 근거 | 확신도 | 확인 위치 |
|---|---|---|---|
| 1 | 포트 번호 | 추정 | 방화벽·IDS 로그 |
| 2 | 포트를 연 프로세스·설정 | 서버 측 확인 | ss -p, systemctl, 설정 파일 |
| 3 | 실제로 오간 데이터(프로토콜 형태) | 프로토콜 확인 | 응답 배너, 패킷, 프로토콜 인식 기능이 있는 IDS |
관제 보고서에서는 "3306 포트 접속 = MySQL"이 아니라 "목적지 3306/TCP 접속(일반적으로 MySQL 용도)" 처럼 근거 단계를 구분해 쓰는 것이 정확합니다.
3. 동작 원리
"포트 이름"이 화면에 표시되는 과정은 단순한 번호 변환입니다.
그림 1. 포트 번호는 출발점이고, 프로세스·프로토콜 확인으로 판정합니다
[패킷/소켓] dport = 3306
↓
[도구: ss, tcpdump, netstat 등]
↓ 숫자 옵션(-n)이 없으면 /etc/services 조회
[표시] ...:mysql
↓
※ 이 과정 어디에도 "실제로 MySQL이 응답하는지" 확인하는 단계는 없음반면 실제 서비스를 확인하는 흐름은 서버와 데이터를 봐야 합니다.
포트 번호 확인 (3306)
↓
서버에서 LISTEN 프로세스 확인 → ss -tlnp 'sport = :3306'
↓
프로세스 실행 파일·서비스 유닛 확인 → /proc/<PID>/exe, systemctl status
↓
응답 내용 확인 → HTTP 응답인지, DB 프로토콜인지, TLS인지
↓
결론: "3306/TCP에서 동작하는 것은 ○○ 프로세스의 ○○ 프로토콜"Suricata·Zeek 같은 네트워크 보안 도구는 포트가 아니라 패킷 내용으로 프로토콜을 판별하는 기능을 갖고 있습니다(Suricata의 app-layer 프로토콜 탐지, Zeek의 동적 프로토콜 탐지). 이런 도구의 로그에서 "포트 번호가 뜻하는 서비스"와 "탐지된 프로토콜"이 다르면 그 자체가 확인 대상이 됩니다(06. 방화벽 · IDS/IPS 분석 시리즈에서 다룸).
4. 실제 명령어 / 실습
실습 환경: 본인 소유 Linux VM (Rocky Linux 또는 Ubuntu). 인터페이스 이름은 ens33을 예시로 사용합니다. 이 실습은 VM 내부(127.0.0.1)에서만 진행합니다.
목표: "MySQL 포트(3306)"에 HTTP 서버를 띄워, 포트 이름과 실제 서비스가 다를 수 있음을 직접 확인합니다. (VM에 MySQL이 설치되어 3306을 쓰고 있다면 다른 등록 포트를 사용하세요.)
4-1. 포트 번호의 "이름" 확인
getent services 3306
grep -w '3306/tcp' /etc/services4-2. 3306번에 HTTP 서버 실행 (Python 기본 모듈)
# python3가 없으면: Rocky) sudo dnf install -y python3 / Ubuntu) sudo apt install -y python3
mkdir -p ~/porttest && cd ~/porttest
python3 -m http.server 3306 --bind 127.0.0.1다른 터미널에서 이어서 확인합니다.
4-3. 도구가 보여주는 "이름" vs 실제 프로세스
ss -tl # -n 없음: 포트가 이름(mysql)으로 표시될 수 있음
ss -tln # 숫자로 표시
sudo ss -tlnp 'sport = :3306' # 실제 포트를 연 프로세스📷 [실습 화면 삽입]
ss -tl에서:mysql로 표시되지만ss -tlnp에서는python3가 보이는 화면
4-4. 응답 내용으로 프로토콜 확인
curl -sI http://127.0.0.1:3306/4-5. 프로세스 실행 파일 확인
PID=$(sudo ss -tlnp 'sport = :3306' | grep -oP 'pid=\K[0-9]+' | head -1)
sudo ls -l /proc/$PID/exe
sudo cat /proc/$PID/cmdline | tr '\0' ' '; echo실습이 끝나면 첫 터미널에서 Ctrl+C로 서버를 종료합니다.
5. 결과 확인
형식 예시(값은 환경마다 다름):
$ getent services 3306
mysql 3306/tcp
$ ss -tl
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 5 127.0.0.1:mysql 0.0.0.0:*
$ sudo ss -tlnp 'sport = :3306'
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 5 127.0.0.1:3306 0.0.0.0:* users:(("python3",pid=2451,fd=3))
$ curl -sI http://127.0.0.1:3306/
HTTP/1.0 200 OK
Server: SimpleHTTP/0.6 Python/3.x.x| 확인 단계 | 결과 | 결론 |
|---|---|---|
| 포트 번호 | 3306 → mysql | 이름상으로는 MySQL |
| 프로세스 | python3 | MySQL 서버(mysqld 등)가 아님 |
| 응답 내용 | HTTP/1.0 200 OK | 실제 프로토콜은 HTTP |
-
ss -tl과ss -tln의 표시 차이를 확인했다 - 포트를 연 프로세스를
ss -p로 찾았다 - 응답 내용으로 실제 프로토콜(HTTP)을 확인했다
- 실습 후 테스트 서버를 종료했다
📷 [실습 화면 삽입]
curl -sI결과로 3306번에서 HTTP 응답이 오는 화면
6. 패킷 / 로그 분석
포트와 서비스가 어긋나는 상황을 로그에서 발견하는 방법입니다.
| 관찰 | 정상일 수 있는 경우 | 의심해야 하는 경우 |
|---|---|---|
| 8080·8443 등 대체 포트의 웹 트래픽 | 개발 서버, 관리 콘솔, 프록시 | 자산 대장에 없는 서버가 대체 포트로 외부와 통신 |
| 22가 아닌 포트의 SSH | 관리 정책에 따른 포트 이전 | 사용자 PC나 웹서버에서 새로 나타난 SSH 서비스 |
| 3306 등 DB 포트에서 HTTP 응답 | 테스트 환경 (위 실습 같은 경우) | 운영 서버에서 확인되지 않은 프로세스가 등록 포트를 점유 |
| IDS의 탐지 프로토콜과 포트 불일치 | 비표준 포트로 운영하는 정상 서비스 | 443에서 TLS가 아닌 데이터, 53에서 DNS가 아닌 데이터 |
ss에 이름으로 표시된 포트 | /etc/services 기반 표시일 뿐 | 이름만 보고 "정상 서비스"로 판단하는 것 자체가 위험 |
서버에서 확인할 때 유용한 명령은 다음과 같습니다.
sudo ss -tulnp # 전체 LISTEN 포트 + 프로세스
systemctl status <서비스명> # 서비스 유닛과 실행 파일
sudo lsof -i :3306 # lsof 설치 필요: Rocky) dnf install lsof / Ubuntu) apt install lsof프로세스와 연결을 함께 점검하는 방법은 44. 프로세스 네트워크 연결 점검에 정리되어 있습니다.
7. 보안관제 관점
| 로그·장비 | 알 수 있는 것 | 알 수 없는 것 |
|---|---|---|
| 방화벽(L3/L4) | 포트 번호, 허용/차단 | 실제 프로토콜 |
| 애플리케이션 인식 방화벽 | 벤더가 정의한 애플리케이션 이름 | 인식 룰 밖의 사내·신규 애플리케이션 |
| IDS (프로토콜 인식) | 페이로드 기반 프로토콜 | 암호화 이후의 내용 |
| 서버 로그·EDR | 프로세스·실행 파일 | 서버 밖 네트워크 구간 |
관제 시 원칙
- 보고서에는 근거 단계를 구분해 씁니다. ("3306/TCP 접속 확인, 서비스 종류는 서버 확인 필요")
- 자산·서비스 대장이 "이 서버의 이 포트는 무엇인가"의 기준이 됩니다. 대장에 없는 LISTEN 포트는 점검 대상입니다.
- 비표준 포트 자체는 위반이 아닙니다. 오탐을 줄이려면 조직의 정상 포트 목록(베이스라인)을 먼저 확보해야 합니다.
한계: 암호화된 통신은 페이로드로 프로토콜을 판별하기 어렵습니다(06. HTTPS와 TLS Handshake에서 다룸). 비표준 포트 서비스 식별과 위장 통신은 20편, 21편에서 더 깊게 다룹니다.
8. 핵심 정리
- 포트 번호와 서비스 이름의 대응은 IANA 등록과
/etc/services에 있는 관례이며, 실제 서비스를 보장하지 않습니다. ss,tcpdump등이 표시하는 서비스 이름은 번호를/etc/services로 바꾼 결과일 뿐입니다. 분석 시에는-n으로 숫자를 보는 습관이 안전합니다.- 서비스 확정은 포트 번호(추정) → 프로세스·설정(서버 확인) → 응답 내용(프로토콜 확인) 3단계로 합니다.
- 포트 번호와 IDS가 탐지한 프로토콜이 다르면 확인 대상입니다.
- 비표준 포트는 오탐이 많으므로 조직의 정상 포트 베이스라인과 함께 판단합니다.
