네트워크 보안 - TCP 심화 · IP Header · ICMP 완전 정리

Phase 2  |  Network Security

TCP 심화 · IP Header · ICMP 완전 정리

4-Way Handshake · Checksum · TCP Option · TTL · ICMP 메시지 유형까지

01 TCP 연결 종료 — 4-Way Handshake

TCP는 양방향 독립 채널이므로 각 방향을 따로 종료해야 한다. 이 때문에 연결 수립(3단계)보다 한 단계 많은 4단계가 필요하다.

[ 4-Way Handshake 흐름 ] Client Server │ │ │── FIN ──────────────────────►│ Client "이제 보낼 데이터 없음" │◄───────────────────── ACK ───│ Server "수신 확인, 아직 보낼 것 있음" │ │ (half-close 구간 — Server→Client 전송 가능) │◄────────────────────── FIN ───│ Server "나도 완료" │── ACK ──────────────────────►│ │ │ │ TIME_WAIT (2×MSL 대기) │ │ │ CLOSED CLOSED

TCP 상태 흐름

FIN_WAIT_1FIN 전송

→

FIN_WAIT_2ACK 수신

→

TIME_WAITFIN 수신 후 대기

→

CLOSED완전 종료

CLOSE_WAITFIN 수신 측

→

LAST_ACKFIN 전송 후

→

CLOSEDACK 수신

TIME_WAIT 존재 이유  |  마지막 ACK가 유실됐을 경우 상대가 FIN을 재전송할 수 있도록 2×MSL(Maximum Segment Lifetime) 동안 대기. 이 시간 동안 같은 포트로 새 연결을 맺으면 지연 패킷 충돌 가능.

02 TCP Checksum — 데이터 무결성 검증

수신 측에서 패킷이 전송 중 변조되거나 손상되었는지 검출하는 16bit 필드. 계산 범위에 Pseudo Header(IP 정보)까지 포함한다는 점이 특징이다.

1. Pseudo Header 구성 — 출발지 IP + 목적지 IP + Protocol(6) + TCP 전체 길이
2. TCP Header 필드 합산 (Checksum 필드는 0으로 치환)
3. TCP Data(Payload) 합산
4. 1~3 결과 전체 합산
5. 16bit 초과분(Carry) 처리 — 올림값을 LSB에 더함
6. 최종 합의 1의 보수(bitwise NOT) → Checksum 완성

수신 측 검증  |  수신 측에서 동일한 방법으로 합산 후 Checksum 포함 결과가 0xFFFF이면 무결. 다르면 패킷 폐기. 단, Checksum은 오류 탐지만 하며 수정은 불가.

03 TCP Option 필드

TCP Header 기본 20byte 이후 최대 40byte까지 추가 옵션을 붙일 수 있다. 주로 연결 초기(SYN) 단계에서 협상된다.

옵션	협상 시점	역할	핵심
MSS Maximum Segment Size	SYN 단계에서만	수신 가능한 최대 데이터 크기 협상. MTU − IP/TCP 헤더로 결정	일반적으로 1460 bytes (MTU 1500 기준)
Window Scale	SYN / SYN+ACK	Window Size 범위 확장. 기본 16bit(최대 65535)를 Scale 값으로 배수 확장	실제 Window = 기본 Window × 2Scale
Timestamp	매 세그먼트	RTT 측정 및 PAWS(Protection Against Wrapped Sequences) 처리	재전송 타이머 정밀화, 성능 최적화
NOP	필요 시마다	4byte 정렬을 위한 padding (0x01, 여러 번 사용 가능)	옵션 경계 맞춤
EOP	옵션 끝	옵션 필드 종료 표시 (0x00, 1회만 사용)	이후 필드는 무시

# Window Scale 계산 예시 기본 Window Size : 65535 bytes Scale Factor : 7 실제 Window = 65535 × 2^7 = 65535 × 128 = 8,388,480 bytes (~8MB) # 고속 네트워크(Gbps 환경)에서 Window Scale 없이는 대역폭을 다 못씀

04 UDP 분석

UDP 특징

• 비연결형 — 3-Way Handshake 없음
• Best-effort — 전달 보장 없음
• 순서 보장 없음 — 재조립은 앱 레벨 처리
• 헤더 8 bytes — 오버헤드 최소
• 빠른 속도가 신뢰성보다 중요한 경우 사용

UDP 사용 사례 vs 보안 위협

• DNS — 53/udp (질의/응답)
• DHCP — 67~68/udp
• VoIP / 스트리밍 — 실시간성 우선
• UDP Flood — 대량 UDP 패킷으로 자원 고갈
• DNS Amplification — 소스 IP 위조로 반사 공격

UDP Checksum  |  TCP Checksum과 동일한 방식으로 계산하지만 선택적(IPv4). IPv6에서는 필수. Checksum 필드가 0x0000이면 검증 생략을 의미한다.

05 TCP 데이터 분할 (Segmentation)

전송할 데이터가 MSS를 초과하면 TCP 계층에서 자동으로 분할(Segmentation)한다. 각 세그먼트는 Sequence Number로 순서를 추적한다.

# MSS = 1400 bytes, 전송 데이터 = 4200 bytes Segment 1 : SN=1, Data[0~1399] (1400 bytes) Segment 2 : SN=1401, Data[1400~2799] (1400 bytes) Segment 3 : SN=2801, Data[2800~4199] (1400 bytes) # 수신 측 ACK ACK=1401 # Seg1 수신 확인 ACK=2801 # Seg2 수신 확인 ACK=4201 # Seg3 수신 확인 → 전체 완료

IP Fragmentation과의 차이  |  TCP Segmentation은 L4(Transport)에서 분할, IP Fragmentation은 L3(Network)에서 MTU 초과 시 분할. MSS를 올바르게 설정하면 IP 단편화를 방지할 수 있다.

06 IP Header 구조 분석

기본 20 bytes, Options 포함 최대 60 bytes. 라우팅과 패킷 전달에 필요한 모든 정보를 담는다.

[ IPv4 Header — 기본 20 bytes ] 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ┌───────┬───────┬───────────────┬───────────────────────────────┐ │Version│ IHL │ TOS │ Total Length │ ├───────────────┴───────────────┼─────┬─────────────────────────┤ │ Identification │Flags│ Fragment Offset │ ├───────────────────────────────┼─────────────────────────────────┤ │ TTL │ Protocol │ Header Checksum │ ├───────────────────────────────────────────────────────────────┤ │ Source IP Address │ ├───────────────────────────────────────────────────────────────┤ │ Destination IP Address │ └───────────────────────────────────────────────────────────────┘

필드	크기	역할	보안 관점
Version	4 bits	IPv4(4) / IPv6(6) 구분	—
IHL	4 bits	Header 길이 (4byte 단위, 기본값=5)	비정상 값으로 파싱 오류 유발 가능
TTL	8 bits	라우터 통과마다 1 감소, 0이면 폐기	OS Fingerprinting, 루프 방지
Protocol	8 bits	6=TCP, 17=UDP, 1=ICMP	비정상 값으로 IDS 우회 시도
Flags	3 bits	DF(Don't Fragment), MF(More Fragments)	단편화 공격, Path MTU Discovery 우회
Fragment Offset	13 bits	단편화된 패킷의 원본 내 위치	단편화 중첩 공격으로 IDS 우회
Src / Dst IP	32 bits 각	송수신 IP 주소	IP Spoofing 주요 조작 대상

07 TTL (Time To Live) 분석

라우터를 한 홉(Hop) 거칠 때마다 TTL이 1씩 감소. 0이 되면 라우터가 패킷을 폐기하고 송신자에게 ICMP Time Exceeded를 보낸다.

OS별 TTL 초기값

Linux / macOS

64

Windows

128

TTL 활용 — OS Fingerprinting

• 수신 TTL로 경유 홉 수 역산
• 초기 TTL 추정 → OS 종류 파악
• nmap -O 옵션 기반 동작
• 방어: TTL 값 표준화 / 스크램블링

TTL 활용 — traceroute / tracert

• TTL=1부터 시작해 1씩 증가
• 각 라우터의 ICMP Time Exceeded 수집
• 경로 상 모든 홉 IP 확인 가능
• 방어: 중간 라우터 ICMP 응답 차단

# TTL로 홉 수 역산 예시 수신 패킷 TTL = 118 가장 가까운 초기값 = 128 (Windows 추정) 경유 홉 수 = 128 - 118 = 10 hops

08 ICMP (Internet Control Message Protocol)

IP 프로토콜의 오류 보고 및 네트워크 상태 알림용 프로토콜. L3에서 동작하며 별도 포트 없이 Protocol 필드 값 1로 식별된다.

TYPE 3

Destination Unreachable

목적지 도달 불가. Code 값으로 세부 원인 구분 (Net/Host/Port Unreachable 등)

TYPE 8 / 0

Echo Request / Reply

ping 테스트. Request(8) → Reply(0). 연결 확인 및 RTT 측정에 사용

TYPE 5

Redirect

더 좋은 경로 안내. 라우터가 송신자에게 최적 게이트웨이를 알려줌

TYPE 11

Time Exceeded

TTL 초과로 패킷 폐기. traceroute의 핵심 메커니즘

TYPE 4

Source Quench

혼잡 알림. 송신 속도를 줄이도록 요청 (현재는 거의 사용 안 함)

보안 위협  |  ICMP는 인증 없이 누구나 전송 가능. ICMP Flood(ping flood)로 대역폭 고갈, Smurf Attack(브로드캐스트 주소로 ping → 반사 트래픽 집중), ICMP Redirect로 트래픽 우회 등에 악용. 방화벽에서 불필요한 ICMP Type 차단 권장.

공격 유형	사용 ICMP Type	목적	대응
Ping Flood	Type 8 (Echo Request)	대역폭 고갈, 자원 소모	Rate Limit, 방화벽 차단
Smurf Attack	Type 8 → Broadcast	반사 트래픽으로 DDoS	Directed Broadcast 차단
ICMP Redirect 악용	Type 5	라우팅 테이블 조작 → MITM	Redirect 수신 비활성화
정보 수집	Type 3 Code 분석	방화벽 규칙 유추	ICMP 응답 최소화