📚 네트워크 · 패킷 분석 › 01. TCP/IP 구조 이해 — 35편
이전 글: 34. ICMP와 ping — 오류 보고 프로토콜 읽는 법 · 다음 글: 36. TTL과 네트워크 경로
1. 개념
ping은 ICMP Echo Request(Type 8)를 보내고 Echo Reply(Type 0)를 받아 상대가 IP 수준에서 응답하는지, 왕복에 얼마나 걸리는지를 측정하는 진단 도구입니다. ICMP 자체의 Type/Code 체계는 34. ICMP와 ping — 오류 보고 프로토콜 읽는 법에서 다뤘으므로, 이 글은 ping이라는 프로그램이 내부적으로 무엇을 하는지에 집중합니다.
ping이 알려주는 것과 알려주지 않는 것을 먼저 구분해 두면 오해가 줄어듭니다.
| ping이 알려주는 것 | ping이 알려주지 않는 것 |
|---|---|
| 대상 IP가 Echo에 응답하는지 | 특정 서비스(포트)가 살아 있는지 |
| 왕복 시간(RTT)과 그 변동 | 응답이 없는 이유 (다운인지, 차단인지) |
| 손실률 | 경로상 어느 구간이 느린지 (37편 traceroute의 역할) |
| 응답 패킷의 TTL (36편) | 응답한 장비가 정말 그 IP의 주인인지 |
2. 동작 원리
Linux ping 기준으로 한 번의 요청-응답 과정은 다음과 같습니다.
[ping 프로세스]
│ ① Identifier(식별자) 결정, Sequence = 1
│ ② 페이로드 앞부분에 "보낸 시각" 기록, 나머지는 채움 데이터 (기본 56바이트)
│ ③ ICMP 체크섬 계산 → IP 헤더(Protocol 1)를 붙여 전송
↓
Echo Request (id=X, seq=1) ─────────────→ [대상 호스트 커널]
│ 같은 id, seq, 페이로드를 그대로 담아
│ Type만 0으로 바꿔 응답
Echo Reply (id=X, seq=1) ←─────────────────┘
│
│ ④ 받은 패킷의 id가 내 것인지 확인 (다른 ping 프로세스 응답과 구분)
│ ⑤ 현재 시각 − 페이로드에 적힌 보낸 시각 = RTT
│ ⑥ 한 줄 출력: 바이트 수, icmp_seq, ttl, time
↓
1초 대기 후 seq = 2로 반복 ... (-c 횟수 도달 또는 Ctrl+C)
↓
⑦ 통계 출력: 전송 수, 수신 수, 손실률, RTT 최소/평균/최대/편차- 응답은 대상의 커널이 만듭니다. 대상에 별도 프로그램이 필요 없고, 커널 설정이나 방화벽이 Echo를 무시하면 응답이 없습니다.
- Identifier는 여러 ping이 동시에 실행될 때 서로의 응답을 구분하는 값이고, Sequence는 몇 번째 요청인지 나타냅니다. seq에 빈 번호가 생기면 그 요청 또는 응답이 유실된 것입니다.
- 일반 사용자가 ping을 쓸 수 있는 방법은 배포판마다 다릅니다(파일 capability
cap_net_raw부여, 또는 커널의 비특권 ICMP 소켓 허용 설정net.ipv4.ping_group_range).
3. 주요 특징
Linux(iputils)와 Windows의 기본 동작은 다릅니다. 로그나 패킷에서 ping 흔적을 볼 때 이 차이가 출발지 OS를 짐작하는 단서가 되기도 합니다.
| 항목 | Linux (iputils ping) | Windows ping |
|---|---|---|
| 기본 횟수 | 중지할 때까지 계속 | 4회 |
| 횟수 지정 | -c 5 | -n 5 |
| 기본 데이터 크기 | 56바이트 (ICMP 포함 64) | 32바이트 |
| 크기 지정 | -s 1000 | -l 1000 |
| 간격 | 기본 1초, -i로 변경 (매우 짧은 간격은 root 필요) | 약 1초 |
| 응답 대기 시간 | -W 초 | -w 밀리초 |
| TTL 지정 | -t 값 | -i 값 |
| DF 비트 | -M do | -f |
출력에서 자주 보는 메시지와 해석입니다.
| 출력 | 의미 | 먼저 볼 것 |
|---|---|---|
64 bytes from ... time=0.4 ms | 정상 응답 | RTT 수준과 변동 |
| 아무 출력 없이 통계에서 100% loss | 응답이 오지 않음 | 방화벽 drop, 대상 다운, 경로 문제 모두 가능 |
From 192.168.10.10 ... Destination Host Unreachable | 같은 대역에서 ARP 응답이 없음(From이 자기 IP = 자기 호스트가 보고) | 대상 전원·IP 설정 |
From <라우터> ... Destination Net Unreachable | 라우터가 경로를 모름 | 라우팅 설정 |
Time to live exceeded | 중간에서 TTL 소진 | 라우팅 루프, 너무 작은 TTL (36편) |
(DUP!) | 같은 seq에 응답이 두 번 | 브로드캐스트 ping, 중복 IP, 네트워크 이상 |
Linux ping의 종료 코드는 응답을 받으면 0, 응답을 하나도 받지 못하면 1, 그 밖의 오류는 2인 것이 일반적이라 스크립트의 가용성 점검에 쓰입니다.
4. 예시
실습 예시 — 본인 소유 VM(192.168.10.10 → 192.168.10.20)에서 실행합니다. ping은 Rocky(iputils)와 Ubuntu(iputils-ping) 모두 기본 설치되어 있는 경우가 많습니다.
# 5회 전송, 응답 대기 2초
ping -c 5 -W 2 192.168.10.20
# 1000바이트 데이터로 3회 (IP 패킷 1028바이트)
ping -c 3 -s 1000 192.168.10.20
# 종료 코드 확인 (0이면 응답 있음)
ping -c 1 -W 1 192.168.10.20 > /dev/null; echo $?출력 형식 예시(값은 환경마다 다름):
PING 192.168.10.20 (192.168.10.20) 56(84) bytes of data.
64 bytes from 192.168.10.20: icmp_seq=1 ttl=64 time=0.412 ms
64 bytes from 192.168.10.20: icmp_seq=2 ttl=64 time=0.388 ms
64 bytes from 192.168.10.20: icmp_seq=4 ttl=64 time=0.401 ms
64 bytes from 192.168.10.20: icmp_seq=5 ttl=64 time=0.395 ms
--- 192.168.10.20 ping statistics ---
5 packets transmitted, 4 received, 20% packet loss, time 4052ms
rtt min/avg/max/mdev = 0.388/0.399/0.412/0.009 ms| 출력 요소 | 읽는 법 |
|---|---|
56(84) bytes | 데이터 56 + ICMP 헤더 8 + IP 헤더 20 = 84 |
64 bytes from | 받은 ICMP 메시지 크기 (헤더 8 + 데이터 56) |
icmp_seq=3 누락 | 3번 요청 또는 응답이 유실됨 → 통계의 20% loss |
ttl=64 | 응답 패킷의 남은 TTL (해석은 36편) |
mdev | RTT 편차. 클수록 지연이 들쭉날쭉함 |
패킷 수준에서 id·seq·페이로드를 확인하는 방법은 03. Wireshark 패킷 분석 영역 118. Ping Packet 분석에서 다룹니다.
5. 보안 관점
- 응답 없음 ≠ 호스트 없음. 많은 서버와 방화벽이 외부 Echo를 차단합니다. 반대로 공격자도 ping 무응답만으로 판단하지 않고 다른 방법으로 존재를 확인하는 경우가 많습니다.
- ping은 정찰의 가장 기본 형태입니다. 한 출발지가 대역의 여러 IP로 Echo Request를 짧은 간격으로 보내는 패턴을 ping sweep이라 하며, 05. 네트워크 스캔 징후 분석 영역 206. Ping Scan에서 다룹니다.
- 페이로드는 비워 두는 약속이 없습니다. 표준 ping은 고정 패턴을 채우지만, Echo 페이로드에 임의 데이터를 담을 수 있어 ICMP 터널링에 쓰일 수 있습니다. 기본 크기(Linux 56, Windows 32)에서 벗어난 크기나 매번 바뀌는 내용은 확인 대상입니다.
- 커널의 Echo 응답 여부는
net.ipv4.icmp_echo_ignore_all, firewalld의icmp-block등으로 조절하며 설정 조회는 34. ICMP와 ping — 오류 보고 프로토콜 읽는 법에 정리했습니다.
6. SOC 관점
| 흔적 위치 | 확인할 수 있는 것 |
|---|---|
| 방화벽 로그 | ICMP Type 8 허용·차단, 출발지·목적지, 횟수 |
| IDS/IPS | ICMP sweep, 대용량 ICMP, 비표준 페이로드 관련 시그니처 |
| 패킷 캡처 | id·seq 연속성, 페이로드 크기와 내용, 간격 |
| 모니터링 시스템(NMS) | 정기 ping 가용성 점검 기록 |
관제자가 확인할 질문
- 출발지가 모니터링 서버·로드밸런서처럼 정기적으로 ping을 보내는 자산인가?
- 한 대상에 대한 연속 ping인가, 여러 대상에 대한 순차 ping인가?
- 요청 간격이 1초 전후의 사람·기본값 패턴인가, 매우 촘촘한 자동화 패턴인가?
- 페이로드 크기와 내용이 OS 기본값과 일치하는가?
오탐 주의: 장애 대응 중인 운영자의 연속 ping, NMS·헬스체크, 네트워크 장비의 IP SLA 같은 기능은 정상적으로 대량의 Echo를 만듭니다. 출발지 자산 확인이 판단의 출발점입니다.
7. 핵심 정리
- ping은 Echo Request에 id·seq·보낸 시각을 담아 보내고, 같은 id·seq의 Echo Reply로 RTT와 손실을 계산합니다.
- Echo Reply는 대상의 커널이 만들기 때문에, 서비스 상태가 아니라 IP 수준 응답 여부만 알려줍니다.
- Linux(기본 56바이트, 무한 반복)와 Windows(기본 32바이트, 4회)는 기본값이 달라 흔적 해석의 단서가 됩니다.
- 무응답은 다운·차단·경로 문제를 구분하지 못하며,
Destination Host Unreachable은 대개 ARP 실패를 뜻합니다. - 대역 순차 ping과 비표준 페이로드는 확인 대상이지만, NMS·헬스체크 같은 정상 출발지를 먼저 걸러냅니다.
