gyumin.log

ICMP

🌿 자라는 중

목차

네트워크가 이상할 때 누구나 제일 먼저 치는 명령이 ping이다. 그 ping이 쓰는 프로토콜이 ICMP다.

  • ICMP (Internet Control Message Protocol): IP 통신 중 생긴 오류를 보고하고 네트워크 상태를 진단하는 3계층 프로토콜. RFC 792 표준
  • Echo Request / Echo Reply: “살아 있나요?” / “네, 잘 있어요” - ping의 정체
  • Type / Code: ICMP 메시지의 종류(무슨 일인가)와 세부 원인(왜인가)을 나타내는 번호
  • TTL (Time To Live): 패킷이 거칠 수 있는 라우터 수. 0이 되면 폐기되고 ICMP가 그 사실을 알려준다

IP는 일반 우편이다

IP는 Best Effort(최선형) 프로토콜이다. “최선을 다하지만 보장은 없다”는 뜻인데, 정확히 세 가지가 없다.

없는 것의미
신뢰성패킷이 사라지거나 순서가 바뀌어도 모른다
보장성목적지에 도착한다는 보장이 없다
연결성보내기 전에 미리 연결을 맺지 않는다

일반 우편과 똑같다. 우체통에 넣으면 끝 - 도착했는지, 중간에 사라졌는지 보낸 사람은 알 길이 없다. 그래서 우체국에는 반송 통지서가 있다. “수취인 불명으로 반송합니다”, “주소지에 도달할 수 없습니다” 같은 통지가 오면, 적어도 왜 안 갔는지는 알 수 있다.

ICMP가 정확히 이 반송 통지서다. IP가 말없이 버린 패킷에 대해 “목적지에 못 갔어요(Destination Unreachable)”, “너무 오래 돌아다녀서 폐기했어요(Time Exceeded)“라고 발신자에게 알려준다.

한 가지 재미있는 점 - ICMP는 자기 혼자 돌아다니지 못하고 IP 패킷 안에 실려서(인캡슐레이션) 전달된다. 반송 통지서도 결국 우편으로 배달되는 것과 같다.

ping의 동작 - Echo Request와 Echo Reply 내 컴퓨터가 Echo Request(Type 8)를 보내고 목적지 서버가 Echo Reply(Type 0)로 응답하는 그림 내 컴퓨터 ping 192.168.1.22 목적지 서버 192.168.1.22 Echo Request (Type 8) "살아 있나요?" Echo Reply (Type 0) "네, 잘 있어요" 윈도우에서 ping 한 번이면 이 왕복을 4회 반복한다 (Request 4개 + Reply 4개 = 8패킷)

메시지 구조 - Type과 Code

ICMP 헤더는 딱 4바이트다: Type(1) + Code(1) + Checksum(2). 반송 통지서로 치면 Type이 통지 종류(“반송”인지 “안부 회신”인지), Code가 세부 사유(“수취인 불명”인지 “주소 없음”인지)다.

ICMP 메시지는 IP 패킷에 실려 간다 IP 헤더 뒤에 ICMP의 Type, Code, Checksum, 데이터가 이어지는 구조 IP 패킷 IP 헤더 Type 1바이트 Code 1바이트 Checksum 2바이트 데이터 선택 ICMP 헤더는 4바이트 - 색칠된 부분이 ICMP 메시지, 우편(IP)에 실려 배달된다

외워둘 Type 값 - 시험과 실무 양쪽에서 계속 만난다.

Type의미언제 오는가
8Echo Requestping 요청
0Echo Replyping 응답
3Destination Unreachable목적지 도달 불가 (Code 0=네트워크, 1=호스트, 3=포트)
11Time ExceededTTL이 0이 되어 패킷 폐기
5Redirect“그 길 말고 이 길이 더 빨라요” 경로 재안내

외우는 요령: 물어볼 때 8, 답할 때 0. ping 결과에서 항상 이 쌍으로 움직인다.

traceroute의 트릭

목적지까지 어떤 라우터들을 거치는지 보여주는 traceroute(윈도우는 tracert)는 사실 TTL 만료를 일부러 일으키는 영리한 도구다.

  1. TTL=1로 패킷을 보낸다 → 첫 번째 라우터에서 TTL이 0이 되어 폐기 → 그 라우터가 **Time Exceeded(Type 11)**를 보내온다 → 첫 번째 경유지의 IP를 알아냈다
  2. TTL=2로 보낸다 → 두 번째 라우터가 자수한다
  3. 목적지에 닿을 때까지 TTL을 하나씩 늘려가며 반복

오류 보고 메시지를 역이용해 지도를 그리는 셈이다.

한 걸음 더: 실무에서

  • ping 안 됨 ≠ 서버 다운. 방화벽이 ICMP만 차단해 둔 경우가 흔하다. ping은 안 되는데 웹은 잘 열리는 서버가 실제로 많다 - 장애 진단 때 ping 하나만 보고 판단하면 안 되는 이유
  • TTL 값으로 상대 OS를 추측할 수 있다. ping 응답의 TTL 초기값이 128이면 윈도우, 64면 리눅스, 255면 네트워크 장비(라우터·스위치)일 가능성이 높다
  • ping의 기본 데이터 크기는 32바이트(윈도우 기준)이고, Reply도 같은 크기로 돌아온다. 와이어샤크로 잡으면 프레임 전체는 74바이트

보안에서 ICMP - 진단 도구가 무기가 될 때

편리한 진단 도구는 공격자에게도 편리하다. 보안기사에 단골로 나오는 ICMP 악용 공격들:

  • Ping of Death: 규격보다 큰 ICMP 패킷을 조각내 보내, 수신 측이 재조립하다 버퍼가 넘쳐 다운되게 하는 공격
  • Smurf: 출발지 IP를 피해자로 위조한 Echo Request를 브로드캐스트로 뿌리는 공격. 네트워크의 모든 호스트가 피해자에게 일제히 Reply를 보내 마비시킨다
  • ICMP Flooding (Ping Flood): Echo Request를 대량으로 퍼부어 자원을 소진시키는 DoS
  • ICMP Redirect 공격: 가짜 Redirect(Type 5)로 “이 길이 더 빨라요”라고 속여 트래픽을 공격자 쪽으로 우회시키는 중간자 공격
  • ICMP Tunneling: ICMP 데이터 영역에 몰래 데이터를 실어 방화벽을 우회하는 은닉 채널

방화벽에서 ICMP를 막아두는 곳이 많은 이유가 바로 이것들이다. 진단 편의와 보안 사이의 트레이드오프인 셈.

정처기·보안기사 포인트

정처기: 네트워크 기초 파트에서 가볍게 나온다.

  • ICMP는 3계층(네트워크 계층) 프로토콜, RFC 792
  • “ping이 사용하는 프로토콜은?” → ICMP
  • IP 패킷에 캡슐화되어 전송된다

보안기사: 네트워크 보안 과목의 단골. 이쪽이 훨씬 깊게 나온다.

  • Type 값 암기: 8(Request) / 0(Reply) / 3(Unreachable) / 11(Time Exceeded) / 5(Redirect)
  • traceroute가 TTL 만료(Type 11)를 이용하는 원리
  • 위의 ICMP 악용 공격 5종 - 특히 Smurf의 동작 원리(브로드캐스트 + 출발지 위조)는 필기·실기 모두 출제

한 줄: ICMP는 L3 오류 보고 프로토콜, ping은 8/0, traceroute는 11, 공격은 Smurf·PoD·Flooding·Redirect.

연결되는 것들

한 줄 요약: IP는 보장 없는 일반 우편이고, ICMP는 그 우편망의 반송 통지서다 - 못 간 이유를 알려주고(오류 보고), 안부를 확인하고(ping), 통지서를 역이용해 지도까지 그린다(traceroute).