📚 네트워크 · 패킷 분석 › 01. TCP/IP 구조 이해 — 32편
이전 글: 31. Ethernet 프레임과 MAC 주소 · ARP 동작 원리 · 다음 글: 33. ARP Cache
1. 개념
ARP(Address Resolution Protocol)는 같은 네트워크 안에서 IP 주소에 대응하는 MAC 주소를 알아내는 프로토콜입니다. ARP가 왜 필요한지와 전체 역할은 31. Ethernet 프레임과 MAC 주소 · ARP 동작 원리에서 다뤘고, 이 글은 실제로 오가는 두 메시지인 Request(요청)와 Reply(응답)의 모양에 집중합니다.
| 구분 | Opcode | 한 문장 의미 | 이더넷 목적지 MAC |
|---|---|---|---|
| ARP Request | 1 | "이 IP를 가진 장비는 MAC을 알려 달라" | 보통 브로드캐스트 ff:ff:ff:ff:ff:ff |
| ARP Reply | 2 | "그 IP는 나이고, 내 MAC은 이것이다" | 보통 요청자에게 유니캐스트 |
ARP 메시지는 IP 패킷이 아니라 이더넷 프레임에 직접 실립니다(EtherType 0x0806). 따라서 라우터를 넘어가지 않고, IP 주소 기반 방화벽 규칙의 대상이 되지 않는 경우가 많습니다.
2. 동작 원리
PC 192.168.10.20이 게이트웨이 192.168.10.1로 패킷을 보내야 하는데 MAC을 모르는 상황입니다(MAC 값은 예시).
PC (192.168.10.20, MAC 02:00:00:00:00:20)
│
│ ① ARP Request (Opcode 1)
│ Ethernet dst = ff:ff:ff:ff:ff:ff (브로드캐스트)
│ Sender = 192.168.10.20 / 02:00:00:00:00:20
│ Target = 192.168.10.1 / 00:00:00:00:00:00 (모름)
↓
[스위치] 같은 VLAN의 모든 포트로 전달
│
├→ 다른 호스트들: Target IP가 자기 것이 아니므로 응답하지 않음
└→ 게이트웨이 (192.168.10.1, MAC 02:00:00:00:00:01)
│ (요청자의 IP-MAC을 자기 캐시에 기록할 수 있음)
│
│ ② ARP Reply (Opcode 2)
│ Ethernet dst = 02:00:00:00:00:20 (유니캐스트)
│ Sender = 192.168.10.1 / 02:00:00:00:00:01
│ Target = 192.168.10.20 / 02:00:00:00:00:20
↓
PC: 캐시에 192.168.10.1 → 02:00:00:00:00:01 저장 후 원래 IP 패킷 전송- Request의 Target MAC은 0으로 채워져 있습니다. 모르는 값을 묻는 것이기 때문입니다.
- Reply에서는 Sender와 Target의 역할이 뒤바뀝니다. Reply의 Sender 필드가 "정답"입니다.
- 이미 캐시에 있는 항목을 재확인할 때는 브로드캐스트가 아니라 유니캐스트 Request를 보내기도 합니다(Linux의 이웃 항목 확인 과정 등). 캐시 상태 변화는 33. ARP Cache에서 다룹니다.
3. 주요 특징
ARP 메시지(IPv4 over Ethernet 기준)는 28바이트이며 필드는 다음과 같습니다.
| 필드 | 값 (IPv4/이더넷) | Request | Reply |
|---|---|---|---|
| Hardware Type | 1 (Ethernet) | 1 | 1 |
| Protocol Type | 0x0800 (IPv4) | 0x0800 | 0x0800 |
| Hardware / Protocol Size | 6 / 4 | 6 / 4 | 6 / 4 |
| Opcode | 1 또는 2 | 1 | 2 |
| Sender MAC / IP | 보내는 장비 | 요청자 | 응답자(정답) |
| Target MAC / IP | 받는 장비 | 0 / 찾는 IP | 요청자 |
같은 Request 형식이지만 목적이 다른 변형도 있습니다.
| 변형 | 구별 방법 | 용도 |
|---|---|---|
| Gratuitous ARP | Sender IP = Target IP (자기 IP를 스스로 알림) | IP 변경·장애 조치(HA, VRRP 등) 후 주변 캐시 갱신 |
| ARP Probe (RFC 5227) | Sender IP = 0.0.0.0 | IP를 쓰기 전에 중복 사용자가 있는지 확인 |
| ARP Announcement (RFC 5227) | Probe 후 Sender IP = Target IP로 알림 | "이제 이 IP를 쓰겠다"는 선언 |
| 요청 없는 Reply | 해당 Request 없이 Opcode 2만 도착 | 일부 장비의 알림 방식이기도 하지만 스푸핑에서도 쓰임 |
4. 예시
실습 예시 — 본인 소유 VM에서 ARP Request/Reply를 관찰합니다. 인터페이스 ens33은 예시입니다.
# arping 설치
# Rocky Linux (iputils에 포함되어 대개 기본 설치)
sudo dnf install -y iputils tcpdump
# Ubuntu (iputils 계열 arping)
sudo apt install -y iputils-arping tcpdump
# [터미널 1] ARP만 캡처, -e로 이더넷 MAC도 표시
sudo tcpdump -nn -e -i ens33 arp
# [터미널 2] 게이트웨이 IP에 ARP Request 3회
sudo arping -I ens33 -c 3 192.168.10.1Ubuntu의 arping 패키지는 iputils와 다른 구현이라 옵션이 다를 수 있으므로 arping --help로 확인합니다.
tcpdump 출력 형식 예시(값은 환경마다 다름):
02:00:00:00:00:20 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.10.1 tell 192.168.10.20, length 28
02:00:00:00:00:01 > 02:00:00:00:00:20, ethertype ARP (0x0806), length 60: Reply 192.168.10.1 is-at 02:00:00:00:00:01, length 28| 출력 요소 | 읽는 법 |
|---|---|
> ff:ff:ff:ff:ff:ff | 브로드캐스트 Request |
who-has A tell B | "A의 MAC은? B에게 알려 달라" (Opcode 1) |
A is-at M | "A의 MAC은 M" (Opcode 2) |
length 42 / length 60 | 이더넷 헤더 14 + ARP 28 = 42. 최소 프레임 크기를 맞추려고 패딩되어 60으로 보이기도 함 |
Wireshark에서는 arp.opcode == 1(Request), arp.opcode == 2(Reply), arp.isgratuitous(Gratuitous) 필터로 구분하며, 필드 단위 분석은 03. Wireshark 패킷 분석 영역 114. ARP 패킷 필드 분석 — opcode와 Sender·Target 필드로 IP-MAC 매핑 검증하기에서 다룹니다.
5. 보안 관점
ARP에는 인증이 없습니다. 받은 Reply가 진짜 해당 IP의 주인이 보낸 것인지 확인할 방법이 프로토콜 안에 없고, 많은 OS가 조건에 따라 요청하지 않은 Reply나 Gratuitous ARP로도 캐시를 갱신합니다. 이 점을 이용해 게이트웨이 IP에 자기 MAC을 대응시키는 것이 ARP 스푸핑(ARP Cache Poisoning)의 원리입니다.
패킷에서 보이는 전형적인 흔적은 다음과 같습니다.
- 게이트웨이 IP에 대한 Reply가 Request 없이 반복적으로 도착함
- 같은 IP에 대해 서로 다른 MAC을 담은 Reply가 번갈아 나타남
- 한 MAC이 여러 IP의 주인이라고 Reply함 (라우터·프록시 ARP가 아닌데도)
대응은 스위치의 DAI(Dynamic ARP Inspection), 포트 보안, 중요 장비 정적 항목 등이며, 장비 측 설정은 04. 네트워크 장비 실습 영역에서 다룹니다.
6. SOC 관점
| 흔적 위치 | 확인할 수 있는 것 |
|---|---|
| 내부망 패킷 캡처 | Request/Reply 짝, 요청 없는 Reply, 같은 IP의 MAC 변경 |
| 스위치 로그 | DAI 위반, 포트 보안 위반, MAC 이동(flapping) 이벤트 (장비마다 형식 다름) |
| IDS | ARP 관련 이상 탐지 기능(구성에 따라 다름). 대부분 내부 센서 위치가 필요 |
| 호스트 | ARP 캐시 변화 (33편) |
관제자가 확인할 질문
- 해당 Reply를 보낸 MAC은 자산 목록의 어떤 장비인가?
- 같은 시각에 게이트웨이 IP의 MAC이 바뀐 호스트가 여러 대인가?
- 직전에 HA 절체, 장비 교체, IP 변경 작업이 있었는가?
오탐 주의: 방화벽·라우터 이중화(VRRP 등)의 절체, 가상화 환경의 VM 이동, 서버 NIC 교체는 정상적으로 Gratuitous ARP와 MAC 변경을 만듭니다. 또한 ARP는 브로드캐스트 도메인 밖으로 나가지 않으므로 센서가 그 VLAN을 보고 있지 않으면 흔적 자체가 수집되지 않습니다.
7. 핵심 정리
- ARP Request(Opcode 1)는 보통 브로드캐스트로, Target MAC을 0으로 비운 채 "이 IP의 MAC은?"을 묻습니다.
- ARP Reply(Opcode 2)는 보통 유니캐스트로, Sender 필드에 정답(IP-MAC)을 담아 돌려줍니다.
- Gratuitous ARP(Sender IP = Target IP)와 ARP Probe(Sender IP 0.0.0.0)는 같은 형식의 다른 용도입니다.
- ARP에는 인증이 없어, 요청 없는 Reply와 같은 IP의 MAC 변경이 스푸핑의 대표적인 흔적입니다.
- 이중화 절체·VM 이동 같은 정상 변경을 먼저 확인하고, 내부망 센서 위치의 한계를 고려합니다.
