📚 네트워크 · 패킷 분석 › 02. 포트 · 프로토콜 분석 — 68편
이전 글: 67. SMTP · 다음 글: 69. IMAP
1. 개념
POP3(Post Office Protocol version 3)는 서버 메일함에 쌓인 메일을 클라이언트로 내려받는 프로토콜입니다(RFC 1939). 메일 포트 전체 구성은 82. 메일 프로토콜 SMTP·POP3·IMAP에서 다뤘고, 이 글은 POP3 대화 자체만 봅니다.
POP3의 설계 전제는 "메일은 서버에 잠시 머물고, 사용자의 PC가 가져간다"입니다. 그래서 폴더·검색·동기화 같은 기능이 없고 명령이 매우 단순합니다.
| 항목 | 값 |
|---|---|
| 전송 계층 | TCP |
| 기본 포트 | 110 (평문, STLS로 전환 가능), 995 (접속 즉시 TLS) |
| 표준 | RFC 1939(기본), RFC 2449(CAPA 확장), RFC 2595(STLS) |
| 응답 형식 | +OK 또는 -ERR + 설명 |
| 세션 특성 | 짧게 접속 → 내려받기 → 종료 |
2. 동작 원리
POP3 세션은 세 가지 상태를 차례로 거칩니다. 핵심은 DELE가 즉시 지우지 않고 표시만 하며, 실제 삭제는 QUIT 후 UPDATE 상태에서 일어난다는 점입니다.
클라이언트 192.168.10.50:50122 서버 192.168.10.30:110
│ ── TCP 연결 ───────────────────────────→ │
│ ←─ +OK POP3 ready (서버 배너) ─────────── │
↓ │
[AUTHORIZATION 상태] │
│ ── CAPA / STLS (TLS 전환, 선택) ────────→ │
│ ── USER alice / PASS ******** ─────────→ │ → 메일함 잠금(lock)
↓ +OK │
[TRANSACTION 상태] │
│ ── STAT, LIST, UIDL ───────────────────→ │ 메일 수·크기·고유 ID
│ ── RETR 1 ─────────────────────────────→ │ 메일 1 전체 전송
│ ── DELE 1 ─────────────────────────────→ │ "삭제 표시"만
│ ── QUIT ───────────────────────────────→ │
↓ ↓
[UPDATE 상태] 표시된 메일 실제 삭제 → 잠금 해제 → +OK → 연결 종료- 연결이 QUIT 없이 끊기면 UPDATE 상태에 들어가지 않으므로 삭제 표시는 취소됩니다.
- 인증에 성공하면 서버는 메일함을 잠가 같은 메일함에 대한 동시 세션을 막습니다.
3. 주요 특징
| 상태 | 명령 | 의미 |
|---|---|---|
| AUTHORIZATION | USER, PASS | 계정·비밀번호 전달 (평문) |
| AUTHORIZATION | APOP | 서버 배너의 값과 비밀번호로 만든 MD5 값 전달 (선택 기능) |
| AUTHORIZATION | CAPA, STLS | 지원 기능 조회, TLS 전환 |
| TRANSACTION | STAT | 메일 개수와 총 크기 |
| TRANSACTION | LIST, UIDL | 메일별 크기, 메일별 고유 ID |
| TRANSACTION | RETR n, TOP n k | 메일 전체, 헤더+본문 k줄 |
| TRANSACTION | DELE n, RSET, NOOP | 삭제 표시, 표시 취소, 연결 유지 |
| 공통 | QUIT | 종료 (TRANSACTION에서면 UPDATE로 이동) |
POP3와 IMAP의 차이를 관제 관점에서 보면 다음과 같습니다(IMAP은 69. IMAP).
| 비교 | POP3 | IMAP |
|---|---|---|
| 메일 위치 | 내려받은 뒤 서버에서 삭제하는 방식이 기본 | 서버에 유지 |
| 세션 길이 | 짧음, 주기적 재접속 | 길게 유지되는 경우 많음 |
| 트래픽 패턴 | 접속마다 새 메일 전체 다운로드 | 필요한 부분만 조회 |
| 흔적 | 서버에서 메일이 사라질 수 있음 | 서버에 메일과 플래그 남음 |
4. 예시
실습 예시 — 본인 소유 실습 메일 서버(Dovecot, 192.168.10.30)에 인증 없이 기능 목록만 조회합니다.
# 평문 110: 배너와 CAPA 확인 (접속 후 CAPA 입력 → QUIT)
nc -C 192.168.10.30 110
# 995: TLS로 접속 후 같은 확인
openssl s_client -connect 192.168.10.30:995 -quiet
# 서버: 리슨 포트와 프로세스 (Rocky/Ubuntu 공통)
sudo ss -tlnp | grep -E ':(110|995) 'CAPA 응답 형식 예시(값은 환경마다 다름):
+OK Dovecot ready.
CAPA
+OK
CAPA
TOP
UIDL
RESP-CODES
PIPELINING
AUTH-RESP-CODE
STLS
USER
SASL PLAIN
.여러 줄 응답은 . 한 줄로 끝납니다. 110에서 STLS가 없고 USER가 있다면 평문 비밀번호 전송이 가능한 상태입니다.
Dovecot 로그 형식 예시(값은 환경마다 다름, Rocky /var/log/maillog, Ubuntu /var/log/mail.log):
dovecot: pop3-login: Login: user=<alice>, method=PLAIN, rip=192.168.10.50, lip=192.168.10.30, mpid=2411, TLS
dovecot: pop3(alice): Disconnected: Logged out top=0/0, retr=12/348210, del=12/12, size=348210| 필드 | 의미 |
|---|---|
rip / lip | 원격(클라이언트) IP / 서버 IP |
TLS | 암호화 세션 여부 (없으면 평문 가능성) |
retr=12/348210 | 내려받은 메일 수 / 바이트 |
del=12/12 | 삭제한 메일 수 / 메일함 전체 수 |
📷 [실습 화면 삽입 위치] CAPA 응답에서 STLS·USER·SASL 줄을 확인한 화면
5. 보안 관점
- 평문 인증: 110에서 STLS 없이
USER/PASS를 보내면 패킷에 그대로 남습니다. 995만 허용하거나 평문 인증을 끄는 설정(Dovecot 2.3 기준disable_plaintext_auth, 버전에 따라 이름이 다를 수 있음)으로 막습니다. - 메일함 통째 반출: 탈취된 계정으로 POP3 접속하면
RETR반복만으로 메일함 전체를 가져갈 수 있습니다. 로그의retr값이 평소보다 크게 튀는지가 단서입니다. - 증거 소실: 다운로드 후 삭제가 기본 동작이라, 사고 후 서버에 원본이 없을 수 있습니다.
- 대입 공격: 110/995는 인터넷에 노출된 인증 창구이므로 계정 대입 대상이 됩니다.
6. SOC 관점
| 흔적 위치 | 확인할 수 있는 것 |
|---|---|
| 메일 서버 로그 | 로그인 성공·실패, 계정, 클라이언트 IP, TLS 여부, RETR·DELE 수량 |
| 방화벽 | 110/995 연결의 출발지 분포, 빈도 |
| IDS/NSM | 110 평문 구간의 USER/PASS, -ERR 응답 반복 |
관제자가 확인할 질문
- 이 계정의 평소 접속 IP·국가·주기와 비교해 새로운 출발지인가?
- 로그인 실패(
-ERR) 후 성공으로 이어졌는가? - 한 세션의
retr수량이 메일함 전체에 가까운가? 이후del까지 이어졌는가? - 조직 정책상 POP3를 쓰는 사용자인가?
오탐 주의: 새 PC나 새 메일 앱을 설정하면 첫 접속에서 메일함 전체를 내려받는 것이 정상입니다. 사용자의 기기 교체 이력과 출발지 IP를 함께 확인합니다.
7. 핵심 정리
- POP3는 TCP 110(STLS 전환 가능)과 995(접속 즉시 TLS)에서 메일을 내려받는 단순한 프로토콜입니다.
- 세션은 AUTHORIZATION → TRANSACTION → UPDATE 순서이며,
DELE는 표시만 하고 실제 삭제는 QUIT 이후입니다. - 응답은
+OK/-ERR, 여러 줄 응답은.한 줄로 끝납니다. - 메일이 서버에서 사라질 수 있어 사고 시 증거 확보가 어렵고, 탈취 계정의 대량 RETR은 메일 반출 흔적입니다.
- 관제에서는 로그인 출발지, TLS 여부, RETR·DELE 수량을 계정 단위로 봅니다.
