📚 네트워크 · 패킷 분석 › 01. TCP/IP 구조 이해 — 04편
이전 글: 03. LAN과 WAN · 다음 글: 05. 네트워크 인터페이스와 NIC
1. 개념
네트워크 통신에서 Client(클라이언트) 는 서비스를 먼저 요청하는 쪽, Server(서버) 는 요청을 기다렸다가 응답하는 쪽입니다. 이는 장비의 종류가 아니라 통신 안에서의 역할을 가리키는 말입니다.
| 구분 | Client | Server |
|---|---|---|
| 통신 시작 | 먼저 연결·요청을 보냄 (능동) | 요청이 오기를 기다림 (수동, Listen) |
| 포트 | 보통 OS가 고른 임시 포트(Ephemeral Port) | 서비스별로 정해진 포트 (예: 22, 80, 443) |
| 대표 예 | 웹 브라우저, SSH 클라이언트, 메일 앱 | 웹서버, SSH 데몬, 메일 서버, DNS 서버 |
| 필요한 것 | 서버의 주소(IP 또는 도메인)와 포트 | 열려 있는 포트와 요청을 처리할 프로세스 |
같은 장비도 상황에 따라 역할이 바뀝니다. 웹서버는 사용자에게는 Server이지만, 데이터베이스에 질의할 때는 DB 서버에 대한 Client가 됩니다.
2. 동작 원리
Client-Server 통신은 요청(Request) → 응답(Response) 구조로 진행됩니다. TCP를 쓰는 서비스라면 요청 전에 연결 수립 과정이 먼저 일어납니다.
[Client 192.168.10.25] [Server 192.168.10.80]
임시 포트 51514 포트 80에서 LISTEN 중
│ │
│ ── ① 연결 요청 (TCP SYN) ──────────────────────→ │
│ ←───────────────── ② 연결 수락 (SYN/ACK) ────── │
│ ── ③ 연결 확인 (ACK) ─────────────────────────→ │
│ ── ④ 요청: GET /index.html ───────────────────→ │
│ ←─────────────────── ⑤ 응답: 200 OK + 본문 ──── │
│ ── ⑥ 연결 종료 ────────────────────────────────→ │- 서버는 미리 포트를 열고(Listen) 기다립니다.
- 클라이언트는 OS가 골라 준 임시 포트에서 서버의 서비스 포트로 접속합니다.
- 응답은 요청이 왔던 주소·포트로 되돌아갑니다.
①~③의 연결 수립은 41. TCP 3-Way Handshake — 연결이 성립했다는 증거에서, 포트 번호 체계는 51. 포트 번호 체계 — Well-known·Registered·임시 포트(02 영역)에서 다룹니다.
3. 주요 특징
① 모든 통신이 Client-Server 구조인 것은 아닙니다.
| 모델 | 구조 | 예 |
|---|---|---|
| Client-Server | 중앙 서버가 여러 클라이언트에 서비스 제공 | 웹, 메일, DNS, 파일 서버 |
| P2P(Peer-to-Peer) | 참여자가 서로 클라이언트이자 서버 | 토렌트, 일부 메신저의 파일 전송 |
| 브로드캐스트·멀티캐스트형 | 한쪽이 여러 대상에게 알림 | DHCP Discover, mDNS, 라우팅 프로토콜 |
② 서버는 "열린 포트"로 식별됩니다. 서버 프로그램이 특정 포트를 Listen 상태로 두지 않으면 외부 요청을 받을 수 없습니다. 반대로 말하면 Listen 포트 목록 = 그 호스트가 제공하는 서비스 목록 = 공격받을 수 있는 입구입니다.
③ 연결의 방향성이 있습니다. "A가 B에 접속했다"와 "B가 A에 접속했다"는 전혀 다른 사건입니다. 방화벽 정책도 대부분 이 방향(인바운드/아웃바운드)을 기준으로 작성됩니다.
4. 예시
호스트가 어떤 역할로 통신하고 있는지는 ss 명령으로 확인합니다.
실습 예시 — Rocky Linux / Ubuntu 공통 (ss는 iproute2에 포함)
# 예시(값은 환경마다 다름)
sudo ss -tlnp # Server 역할: LISTEN 중인 TCP 포트와 프로세스
ss -tn # 현재 맺어진 TCP 연결(Client·Server 양쪽 모두)# 출력 형식 예시(값은 환경마다 다름)
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=812,fd=6))
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=701,fd=3))
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 0 192.168.10.80:80 192.168.10.25:51514 ← 원격이 임시 포트 → 이 호스트가 Server
ESTAB 0 0 192.168.10.80:48822 192.168.10.90:3306 ← 로컬이 임시 포트 → 이 호스트가 Client같은 웹서버 안에서 80번 포트로는 Server 역할을, DB(3306)에 대해서는 Client 역할을 하고 있음을 읽을 수 있습니다. Windows에서는 netstat -ano로 비슷한 정보를 볼 수 있습니다. Listen 포트와 Established 연결의 자세한 해석은 02 영역 57. Destination Port, 58. Listening Port에서 다룹니다.
5. 보안 관점
- 서버 측 위험: 열려 있는 포트는 누구나 접속을 시도할 수 있는 입구입니다. 불필요한 서비스는 끄고, 필요한 서비스는 접근 가능한 출발지를 제한해야 합니다.
- 클라이언트 측 위험: 사용자가 악성 사이트에 접속하거나 악성 파일을 받는 것도 "클라이언트가 먼저 요청한" 통신입니다. 방화벽이 아웃바운드를 대부분 허용하는 환경이라면 이 경로가 주요 침투 경로가 됩니다.
- 역할이 뒤집히는 경우: 평소 요청만 받던 서버가 외부로 먼저 접속을 시작하는 것은, 정상 업무(업데이트, API 호출)일 수도 있지만 원격 제어 채널(리버스 셸, C2 통신)의 징후일 수도 있습니다. 판단은 반드시 평소 패턴과 비교해야 합니다.
6. SOC 관점
로그를 읽을 때 가장 먼저 확정할 것은 "누가 먼저 연결을 시작했는가" 입니다.
| 로그/데이터 | 방향 판단 근거 |
|---|---|
| 방화벽 세션 로그 | 세션을 처음 만든 쪽이 src, 인바운드/아웃바운드 구분 필드 |
| IDS Alert | src/dst와 함께 TCP 플래그·흐름 방향(to_server, to_client) |
| 패킷 캡처 | SYN(플래그만 SYN)을 보낸 쪽이 Client |
| 웹서버 접근 로그 | 접속한 Client의 IP가 기록됨 |
관제자가 확인할 질문은 다음과 같습니다.
- 출발지 포트가 임시 포트이고 목적지 포트가 서비스 포트인가? (일반적인 Client → Server 모양인가?)
- 이 서버가 평소에도 외부로 먼저 연결하는가? 목적지와 포트는 업무상 설명되는가?
- 응답 방향 패킷만 보고 출발지를 착각하고 있지는 않은가?
⚠️ 오탐 주의: 일부 로그는 응답 패킷 기준으로 src/dst를 기록하거나, 장비마다 방향 필드 정의가 다릅니다. 포트 번호만으로 방향을 단정하지 말고, 세션 시작 기록(SYN)을 기준으로 확인해야 합니다.
7. 핵심 정리
- Client는 먼저 요청하는 쪽, Server는 포트를 열고 기다리는 쪽이며, 이는 장비가 아닌 역할의 구분입니다.
- 클라이언트는 임시 포트에서, 서버는 서비스 포트에서 통신하는 것이 일반적입니다.
- 서버의 Listen 포트 목록은 곧 외부에 노출된 입구 목록입니다.
- 서버가 외부로 먼저 연결을 시작하는 것은 평소 패턴과 비교해 확인할 대상입니다.
- 관제 분석의 출발점은 "누가 먼저 연결을 시작했는가"를 확정하는 것입니다.
