📚 네트워크 · 패킷 분석 › 02. 포트 · 프로토콜 분석 — 59편
이전 글: 58. Listening Port · 다음 글: 60. TCP Connection과 Port
1. 개념
Established Connection은 TCP 3-Way Handshake가 끝나 양쪽이 데이터를 주고받을 수 있는 상태(ESTABLISHED)의 연결입니다. TCP 상태 전이 전체는 01. TCP/IP 구조 이해 영역 42. TCP 상태 전이 — LISTEN부터 TIME_WAIT까지에서 다뤘으므로, 이 글은 관제에서 ESTABLISHED 연결을 증거로 읽는 방법에 집중합니다.
ESTABLISHED가 증명하는 것과 증명하지 않는 것을 먼저 구분합니다.
| 증명하는 것 | 증명하지 않는 것 |
|---|---|
| 양쪽 IP가 실제로 패킷을 주고받았다 (출발지 위조로는 Handshake 완료가 어려움) | 인증에 성공했다 (로그인 실패도 연결은 ESTABLISHED) |
| 해당 포트에 실제로 응답하는 서비스가 있었다 | 데이터가 오갔다 (연결만 맺고 대기할 수도 있음) |
| 지금(또는 로그 시점) 연결이 살아 있다 | 그 연결이 정상 업무 목적이다 |
2. 동작 원리
호스트의 연결 목록에서 ESTABLISHED 한 줄은 로컬 쪽 4-tuple 절반 + 상대 쪽 절반입니다. 로컬 포트가 LISTEN 포트와 같은지로 방향을 가릅니다.
ss -tnp state established 출력 한 줄
↓
Local 192.168.10.20:22 ←→ Peer 192.168.10.30:51514
↓
로컬 포트 22가 이 호스트의 LISTEN 포트인가?
├─ 예 → 인바운드: 상대가 이 서버의 서비스에 접속함
└─ 아니오 (로컬 포트가 임시 포트) → 아웃바운드: 이 호스트가 상대에게 접속함
↓
Process 열로 어느 프로그램의 연결인지 확인 (sshd, curl, 알 수 없는 실행 파일 …)같은 연결을 네트워크 장비도 따로 기억합니다. Stateful 방화벽은 연결마다 세션 항목을 만들고, 일정 시간 패킷이 없으면 항목을 지웁니다(유휴 타임아웃). 이 때문에 호스트와 방화벽이 보는 상태가 어긋날 수 있습니다.
| 상황 | 호스트 상태 | 방화벽 세션 | 결과 |
|---|---|---|---|
| 오래 조용한 연결 (예: 유휴 SSH) | ESTABLISHED 유지 | 유휴 타임아웃으로 삭제 | 다음 패킷이 차단·RST, 연결 끊김 |
| 호스트가 비정상 종료 | 상대 쪽은 ESTABLISHED로 남기도 함 | 타임아웃까지 유지 | "유령" 연결 |
| Keepalive 사용 | 주기적 빈 패킷 | 세션 갱신 | 장시간 유지 가능 |
3. 주요 특징
- 한 서비스 포트에 여러 ESTABLISHED: 서버의 22번 포트에 ESTABLISHED가 여러 줄 있는 것은 정상입니다. 연결은 4-tuple로 구분되므로 Peer 쪽 IP·포트가 다르면 각각 별개의 연결입니다(60. TCP Connection과 Port).
- UDP에는 ESTABLISHED가 없습니다. 다만 Linux netfilter(conntrack) 같은 방화벽은 응답이 한 번 오간 UDP 흐름을 규칙상
ESTABLISHED로 분류합니다. 이것은 TCP 상태가 아니라 방화벽 내부 분류입니다(60. TCP Connection과 Port). - 지속 시간이 정보입니다. 웹 요청은 짧고, SSH·RDP·DB 커넥션 풀은 길며, 원격 제어형 악성코드의 연결은 길게 유지되거나 짧게 반복됩니다.
ESTABLISHED 목록을 관제용으로 읽을 때의 관찰 포인트입니다.
| 관찰 | 정상일 수 있는 경우 | 검토가 필요한 경우 |
|---|---|---|
| 서버가 외부로 아웃바운드 ESTABLISHED | 업데이트 저장소, API 연동, 로그 전송 | 웹서버·DB 서버가 알 수 없는 외부 IP의 고번호 포트와 연결 |
| 장시간 유지되는 외부 연결 | 메신저, 클라우드 동기화, VPN | 셸·스크립트 인터프리터 프로세스의 외부 연결 |
| 같은 서비스에 많은 ESTABLISHED | 사용량 증가, 커넥션 풀 | 평소 대비 급증, 한 출발지에서 다수 |
| Process가 임시 경로의 실행 파일 | 드묾 | /tmp, /dev/shm, 사용자 다운로드 폴더 |
4. 예시
실습 예시 — 본인 소유 VM에서 ESTABLISHED 연결을 방향과 프로세스로 나눠 봅니다.
# Linux (Rocky/Ubuntu 공통)
sudo ss -tnp state established # 전체 + 프로세스
sudo ss -tnp state established '( sport = :22 )' # 인바운드 SSH 세션
sudo ss -tnpo state established # -o: 타이머(keepalive 등) 표시출력 형식 예시(값은 환경마다 다름, 일부 열 생략):
Recv-Q Send-Q Local Address:Port Peer Address:Port Process
0 0 192.168.10.20:22 192.168.10.30:51514 users:(("sshd",pid=4120,...))
0 0 192.168.10.20:43980 198.51.100.25:443 users:(("dnf",pid=5012,...))첫 줄은 로컬 22가 LISTEN 포트이므로 인바운드, 둘째 줄은 로컬 임시 포트이므로 아웃바운드입니다.
# Windows (예시)
Get-NetTCPConnection -State Established |
Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, OwningProcess
Get-Process -Id <OwningProcess 값>5. 보안 관점
- ESTABLISHED는 위조가 어려운 증거입니다. SYN은 출발지를 위조할 수 있지만 Handshake를 끝내려면 SYN/ACK를 실제로 받아야 하므로, ESTABLISHED가 된 상대 IP는 실제 통신 주체일 가능성이 높습니다(단, 그 IP가 프록시·NAT·감염된 중간 시스템일 수는 있음).
- 공격 성공 여부의 분기점: 차단 로그만 있는 사건과 ESTABLISHED까지 간 사건은 대응 우선순위가 다릅니다. 연결이 성립했다면 그 뒤의 인증·데이터 전송 로그를 이어서 확인해야 합니다.
- C2 연결의 관찰 지점: 원격 제어 연결은 대개 아웃바운드 ESTABLISHED로 나타나며, 비정상 아웃바운드 분석은 90. 정상 포트로 위장한 통신 — 443을 쓰는 비정상 트래픽과 비정상 연결 점검에서 다룹니다.
6. SOC 관점
| 흔적 위치 | 확인할 수 있는 것 |
|---|---|
호스트 ss/netstat, EDR | 현재 연결, 방향, 프로세스 (시점 스냅숏) |
| 방화벽 세션 로그 | 연결 시작·종료 시각, 지속 시간, 방향별 바이트 |
| 서비스 로그 | 연결 이후의 인증 성공·실패, 요청 내용 |
| 패킷 캡처 | Handshake 완료 여부, 데이터 교환 여부 |
관제자가 확인할 질문
- 이 연결은 인바운드인가 아웃바운드인가? 어떤 프로세스의 연결인가?
- 연결 성립 후 인증·데이터 전송이 있었는가? 바이트 양은 얼마인가?
- 이 호스트의 역할(웹·DB·PC)에 비해 이 방향·목적지의 연결이 자연스러운가?
오탐 주의: ss·netstat은 조회 순간의 스냅숏이라 이미 끊긴 연결은 보이지 않습니다. 과거 연결은 방화벽 세션 로그나 EDR 네트워크 이벤트로 확인합니다. 로그인 실패도 연결은 ESTABLISHED이므로 "연결 성립 = 침입 성공"으로 해석하지 않습니다.
7. 핵심 정리
- ESTABLISHED는 Handshake가 끝나 데이터 교환이 가능한 상태로, 상대 IP가 실제 통신 주체였다는 강한 증거입니다.
- 로컬 포트가 LISTEN 포트면 인바운드, 임시 포트면 아웃바운드로 방향을 판단합니다.
- 연결 성립은 인증 성공이나 데이터 전송을 뜻하지 않으므로 서비스 로그로 이어서 확인합니다.
- 호스트와 방화벽은 연결 상태를 따로 관리해 유휴 타임아웃 등으로 어긋날 수 있습니다.
- 호스트 조회는 스냅숏이므로 과거 연결은 방화벽 세션 로그·EDR로 확인합니다.
