📚 네트워크 · 패킷 분석 › 01. TCP/IP 구조 이해 — 36편
이전 글: 35. Ping의 동작 원리 · 다음 글: 37. Traceroute의 동작 원리
1. 개념
TTL(Time To Live)은 IPv4 헤더의 8비트 필드로, 패킷이 최대 몇 개의 라우터를 거칠 수 있는지를 제한합니다. 이름은 "시간"이지만 RFC 791의 원래 설계와 달리, 실제로는 라우터를 한 번 지날 때마다 1씩 줄어드는 홉(Hop) 카운터로 동작합니다. IPv6에서는 이름 자체가 Hop Limit으로 바뀌었습니다.
라우팅의 전체 흐름(라우터를 지날 때 바뀌는 값과 유지되는 값)은 17. 게이트웨이와 라우팅 기초 — 다른 네트워크로 패킷은 어떻게 가는가에서 다뤘습니다. 이 글은 그중 TTL 하나로 경로에 대해 무엇을 알 수 있는지에 집중합니다.
| 항목 | IPv4 | IPv6 |
|---|---|---|
| 필드 이름 | TTL | Hop Limit |
| 크기 | 8비트 (0~255) | 8비트 (0~255) |
| 감소 주체 | 패킷을 전달하는 라우터 | 패킷을 전달하는 라우터 |
| 0이 되면 | 폐기 + ICMP Time Exceeded(Type 11) | 폐기 + ICMPv6 Time Exceeded(Type 3) |
2. 동작 원리
TTL이 존재하는 가장 큰 이유는 라우팅 루프 방지입니다. 설정 오류로 두 라우터가 서로에게 패킷을 넘기는 상황이 생겨도, TTL이 없으면 패킷이 영원히 돌며 대역폭을 소모합니다.
[PC 192.168.10.20] 초기 TTL 64로 전송
│
↓ (같은 대역 안 스위치 통과: 변화 없음 — 스위치는 IP를 보지 않음)
[라우터 R1] TTL 64 → 63, 헤더 체크섬 재계산 후 전달
↓
[라우터 R2] TTL 63 → 62
↓
[라우터 R3] TTL 62 → 61
↓
[서버 203.0.113.10] 도착 시 TTL = 61 → "3홉을 지나 왔다"
※ 루프 상황
[R2] ⇄ [R3] 사이를 계속 왕복 → 매번 1씩 감소 → 0이 되는 라우터가
패킷을 버리고 출발지로 ICMP Time Exceeded(11/0) 전송- 감소는 라우터(L3 전달 장비)만 합니다. 스위치, 허브, 브리지는 TTL을 바꾸지 않습니다.
- TTL이 바뀌면 IPv4 헤더 체크섬도 매 홉마다 다시 계산됩니다.
- 출발지가 TTL을 일부러 작게 설정하면 원하는 홉에서 패킷을 멈추게 할 수 있고, 이것이 37. Traceroute의 동작 원리의 원리입니다.
3. 주요 특징
출발지가 처음 넣는 초기 TTL은 OS와 장비마다 기본값이 있습니다. 일반적으로 알려진 값은 다음과 같으며, 설정으로 바꿀 수 있으므로 "추정 근거"로만 씁니다.
| 출발지 유형 | 흔한 초기 TTL | 확인·변경 위치 |
|---|---|---|
| Linux, macOS, 다수의 Unix 계열 | 64 | Linux: net.ipv4.ip_default_ttl |
| Windows | 128 | 레지스트리 DefaultTTL |
| 많은 네트워크 장비(라우터 등) | 255 | 장비 설정 |
수신 측에서 본 TTL을 가장 가까운 위쪽 초기값에서 빼면 대략적인 홉 수를 추정할 수 있습니다.
| 수신 TTL | 추정 초기값 | 추정 홉 수 | 해석 예 |
|---|---|---|---|
| 64 | 64 | 0 | 같은 대역의 Linux 계열 |
| 57 | 64 | 7 | 7개 라우터를 지난 Linux 계열 |
| 128 | 128 | 0 | 같은 대역의 Windows |
| 116 | 128 | 12 | 12홉 떨어진 Windows 계열 |
| 245 | 255 | 10 | 네트워크 장비 또는 TTL을 크게 설정한 출발지 |
| 1 | 판단 불가 | — | 멀티캐스트·일부 라우팅 프로토콜처럼 "같은 링크만" 의도한 패킷일 수 있음 |
이 추정은 응답 경로 기준이라는 점에 주의합니다. ping 응답의 TTL은 상대가 나에게 보낸 패킷의 값이므로, 가는 길과 오는 길이 다른(비대칭) 경로라면 두 방향의 홉 수가 다를 수 있습니다.
4. 예시
실습 예시 — 본인 소유 Linux VM에서 TTL 값을 확인합니다(Rocky/Ubuntu 공통).
# 내 호스트의 기본 초기 TTL
sysctl net.ipv4.ip_default_ttl
# 같은 대역 대상의 응답 TTL
ping -c 2 192.168.10.30
# 게이트웨이 너머 대상의 응답 TTL
ping -c 2 203.0.113.10
# TTL을 1로 제한해 첫 라우터에서 멈추게 하기 → Time Exceeded 수신
ping -c 1 -t 1 203.0.113.10
# 수신 패킷의 TTL 확인 (-v: TTL 등 IP 헤더 표시)
sudo tcpdump -nn -v -i ens33 icmp출력 형식 예시(값은 환경마다 다름, 203.0.113.10은 문서용 예시 주소):
64 bytes from 192.168.10.30: icmp_seq=1 ttl=128 time=0.51 ms
64 bytes from 203.0.113.10: icmp_seq=1 ttl=54 time=8.21 ms
From 192.168.10.1 icmp_seq=1 Time to live exceeded| 줄 | 해석 |
|---|---|
ttl=128 (같은 대역) | 라우터를 거치지 않았으므로 초기값 그대로 → Windows 계열일 가능성 |
ttl=54 (외부) | 64에서 10을 뺀 값 → 약 10홉, Linux 계열일 가능성 |
From 192.168.10.1 ... Time to live exceeded | 첫 라우터(게이트웨이)가 TTL 1 → 0이 되어 폐기하고 보고 |
TTL 필드를 Wireshark에서 보는 방법(ip.ttl)은 03. Wireshark 패킷 분석 영역 115. IP 헤더 분석 — TTL·Flags·Fragment·Checksum 필드 읽는 법에서 다룹니다.
5. 보안 관점
TTL은 출발지가 마음대로 정할 수 있는 값이지만, 한 연결 안에서는 대체로 일정해야 한다는 점이 분석의 근거가 됩니다.
- 세션 중간에 TTL이 튀는 패킷: 같은 출발지 IP·포트에서 오는데 한 패킷만 TTL이 크게 다르면, 경로상의 다른 장비가 끼워 넣은(주입된) 패킷일 수 있습니다. 세션 중간 RST의 TTL 비교는 45. TCP 연결 종료 — FIN과 RST의 차이와 연결됩니다.
- 출발지 위조 흔적: 여러 IP에서 온다고 표시되는데 TTL 분포가 이상하게 똑같다면, 실제로는 한 곳에서 위조해 보낸 트래픽일 가능성을 검토할 수 있습니다.
- TTL을 이용한 회피: IDS 센서까지는 도달하지만 목적지에는 도달하지 못할 만큼 작은 TTL로 패킷을 섞어 보내 IDS와 목적지가 다른 내용을 보게 만드는 기법이 알려져 있습니다. IDS는 이런 패킷을 정규화하거나 경고하는 기능으로 대응합니다.
- TTL 255 확인(GTSM, RFC 5082): 일부 라우팅 프로토콜은 "바로 옆 장비가 보냈다면 TTL이 255여야 한다"는 점을 이용해 원격 위조 패킷을 거릅니다.
6. SOC 관점
| 흔적 위치 | 확인할 수 있는 것 |
|---|---|
| 패킷 캡처 | 패킷별 TTL, 세션 내 TTL 일관성 |
| IDS/IPS | TTL 관련 이상 이벤트, 시그니처의 ttl 조건 (06. 방화벽 · IDS 기초 영역에서 다룸) |
| 라우터·방화벽 | TTL 만료로 폐기된 패킷 통계, ICMP Time Exceeded 발생량 |
| 방화벽 로그 | 장비에 따라 TTL을 기록하지 않는 경우가 많음 |
관제자가 확인할 질문
- 이 출발지의 평소 TTL은 얼마였고, 지금 값은 그 범위 안인가?
- 같은 세션의 다른 패킷과 TTL이 같은가?
- ICMP Time Exceeded가 갑자기 많아졌다면 라우팅 루프나 경로 변경이 있었는가?
오탐 주의: 경로 변경, 로드밸런싱으로 인한 다중 경로, NAT 장비나 프록시가 새 패킷을 만드는 구조에서는 TTL이 정상적으로 바뀝니다. TTL 기반 OS 추정은 설정 변경·중간 장비 영향이 있어 보조 근거로만 사용합니다.
7. 핵심 정리
- TTL(IPv6는 Hop Limit)은 라우터를 지날 때마다 1씩 줄고, 0이 되면 폐기되며 ICMP Time Exceeded가 출발지로 돌아갑니다.
- TTL의 주목적은 라우팅 루프로 패킷이 무한히 도는 것을 막는 것입니다.
- 흔한 초기값(Linux 64, Windows 128, 네트워크 장비 255)과 수신 TTL로 홉 수와 출발지 유형을 대략 추정할 수 있습니다.
- 한 세션 안에서 TTL은 대체로 일정하므로, 튀는 TTL은 주입·위조 패킷을 의심하는 단서가 됩니다.
- 경로 변경·NAT·프록시로 TTL이 바뀔 수 있어 TTL 판단은 다른 증거와 함께 사용합니다.
