📚 네트워크 · 패킷 분석 › 03. Wireshark 패킷 분석 — 114편
이전 글: 113. MAC Address 분석 · 다음 글: 115. IP 헤더 분석 — TTL·Flags·Fragment·Checksum 필드 읽는 법
참고(01. TCP/IP 네트워크 구조 이해): 31. Ethernet 프레임과 MAC 주소 · ARP 동작 원리 — ARP 요청·응답과 ARP 캐시의 개념은 이 글에서 다뤘습니다.
1. 왜 알아야 하는가
ARP는 "이 IP를 가진 장비의 MAC은 무엇인가?"를 묻고 답하는 프로토콜입니다. 같은 서브넷 안의 모든 IP 통신은 ARP로 얻은 IP ↔ MAC 매핑을 믿고 프레임을 보냅니다. 문제는 ARP에 인증 절차가 없다는 점입니다. 누군가 "게이트웨이 IP의 MAC은 나다"라고 응답하면, 그 응답을 받은 호스트는 그대로 ARP 캐시에 반영할 수 있습니다.
그래서 관제 관점에서 ARP 패킷 분석은 다음 질문에 답하는 작업입니다.
- 이 ARP 패킷은 요청인가, 응답인가?
- 응답이 주장하는 IP ↔ MAC 매핑이 평소와 같은가?
- 요청 없이 날아온 응답, 또는 Gratuitous ARP는 정상적인 이유로 설명되는가?
- 같은 IP를 서로 다른 MAC이 주장하고 있지는 않은가?
이 글은 ARP 스푸핑을 수행하는 방법이 아니라, 캡처된 ARP 패킷의 필드를 읽고 이상 징후를 탐지하는 방법만 다룹니다.
2. 핵심 개념
그림 1. ARP 필드와 Wireshark 필드명 — Sender IP와 Sender MAC의 짝이 분석의 핵심입니다
2-1. ARP 헤더와 Wireshark 필드명
Ethernet 위 IPv4용 ARP 패킷은 28바이트이며, Wireshark는 다음 필드로 분해합니다.
| 헤더 항목 | 크기 | Wireshark 필드 | 일반적인 값 / 의미 |
|---|---|---|---|
| Hardware type | 2 | arp.hw.type | 1 (Ethernet) |
| Protocol type | 2 | arp.proto.type | 0x0800 (IPv4) |
| Hardware size | 1 | arp.hw.size | 6 (MAC 길이) |
| Protocol size | 1 | arp.proto.size | 4 (IPv4 길이) |
| Opcode | 2 | arp.opcode | 1 = request, 2 = reply |
| Sender MAC | 6 | arp.src.hw_mac | "나의 MAC은 이것이다" |
| Sender IP | 4 | arp.src.proto_ipv4 | "나의 IP는 이것이다" |
| Target MAC | 6 | arp.dst.hw_mac | 요청에서는 보통 00:00:00:00:00:00 |
| Target IP | 4 | arp.dst.proto_ipv4 | "이 IP의 MAC을 알고 싶다" / 응답 대상 |
분석의 핵심은 Sender 필드 두 개입니다. ARP 패킷은 요청이든 응답이든 "Sender IP는 Sender MAC에 있다"는 주장을 담고 있고, 수신 측 OS는 이 주장을 ARP 캐시에 반영할 수 있습니다.
2-2. Ethernet 헤더와 ARP 헤더의 MAC은 다른 필드
112편에서 본 eth.src와 ARP의 arp.src.hw_mac은 서로 다른 위치에 기록된 값입니다. 일반적인 ARP 패킷에서는 두 값이 같습니다. 두 값이 다르다면 VRRP 같은 이중화 구성처럼 설명 가능한 경우인지, 아니면 조작된 패킷인지 확인할 대상입니다.
2-3. Wireshark가 붙여 주는 해석 필드
아래 필드는 패킷에 실제로 있는 값이 아니라, Wireshark가 패킷을 분석해 덧붙이는 판단 결과입니다.
| Wireshark 필드 | 붙는 조건 | Info 열 표시 예 |
|---|---|---|
arp.isgratuitous | Sender IP와 Target IP가 같은 ARP | Gratuitous ARP for 192.168.10.20 (Reply) |
arp.isannouncement | Sender IP = Target IP 인 요청 (ARP Announcement) | ARP Announcement for 192.168.10.20 |
arp.isprobe | Sender IP가 0.0.0.0 인 요청 (주소 충돌 사전 확인) | Who has 192.168.10.50? (ARP Probe) |
arp.duplicate-address-detected | 캡처 안에서 같은 IP를 다른 MAC이 주장 | 전문가 정보: Duplicate IP address configured |
arp.duplicate-address-frame | 위 경우, 이전 MAC이 보였던 프레임 번호 | Frame showing earlier use of IP address |
arp.packet-storm-detected | 짧은 시간에 ARP 요청이 기준 이상 발생 | 기본 비활성 (arp.detect_request_storms 설정) |
중복 IP 탐지는 기본 설정(arp.detect_duplicate_ips: TRUE)으로 켜져 있지만, 캡처 파일 안에서 본 것만 비교합니다. 캡처 시작 전부터 바뀌어 있던 매핑은 잡지 못합니다.
3. 동작 원리
정상적인 ARP 요청·응답과, 관제에서 주의 깊게 봐야 하는 흐름을 필드 기준으로 비교하면 다음과 같습니다.
[정상 요청·응답]
PC(192.168.10.20) GW(192.168.10.1)
│ opcode=1, src=00:0c:29:11:22:33/192.168.10.20 │
│ dst=00:00:00:00:00:00/192.168.10.1 (eth.dst = Broadcast) │
│ ─────────────────────────────────────────────────────────→ │
│ ←───────────────────────────────────────────────────────── │
│ opcode=2, src=00:0c:29:99:88:77/192.168.10.1 (유니캐스트) │
↓
ARP 캐시: 192.168.10.1 → 00:0c:29:99:88:77
[확인이 필요한 흐름]
다른 장비 ──→ opcode=2, src=00:50:56:aa:bb:cc/192.168.10.1 (요청 없이 도착)
↓
Wireshark: 192.168.10.1은 frame 2에서 00:0c:29:99:88:77 이었음
↓
arp.duplicate-address-detected + arp.duplicate-address-frame == 2두 번째 흐름이 곧바로 공격이라는 뜻은 아닙니다. 게이트웨이 장비 교체나 이중화 전환도 같은 모양을 만듭니다. 중요한 것은 "같은 IP를 주장하는 MAC이 바뀌었다"는 사실을 필드로 확정하고, 그 원인을 다른 증거로 설명할 수 있는지 확인하는 것입니다.
4. 실제 명령어 / 실습
실습 환경: 본인 소유 Linux VM (Rocky Linux 또는 Ubuntu). 인터페이스 이름은 ens33을 예시로 사용합니다. tshark 설치는 112편과 같습니다(Rocky: sudo dnf install -y wireshark-cli, Ubuntu: sudo apt install -y tshark).
실습은 정상 ARP 교환을 관찰하는 것까지만 합니다.
4-1. 기준값 기록
ip route show default # 게이트웨이 IP 확인
ip neigh show dev ens33 # 현재 IP ↔ MAC 매핑 (기준값)4-2. ARP만 캡처하기
# 터미널 1: ARP만 캡처 (Capture Filter)
sudo tshark -i ens33 -f "arp" -w /tmp/pcap08-arp.pcapng
# 터미널 2: 내 VM의 ARP 캐시를 비우고 게이트웨이와 통신 → ARP 요청 발생
sudo ip neigh flush dev ens33
ping -c 2 <게이트웨이 IP>
ip neigh show dev ens33 # 다시 채워진 매핑 확인ip neigh flush 는 내 VM의 ARP 캐시만 비우는 명령이며, 통신이 일어나면 곧바로 다시 채워집니다. 1~2분 정도 캡처하면 같은 서브넷의 다른 장비가 보내는 ARP도 함께 관찰되는 경우가 많습니다. 캡처는 Ctrl+C 로 종료합니다.
📷 [실습 화면 삽입]
ip neigh flush전후의ip neigh show결과와 tshark 캡처 화면
4-3. 필드 단위로 읽기
F=/tmp/pcap08-arp.pcapng
# (1) 요청/응답과 Sender·Target 필드
tshark -r $F -T fields -E header=y \
-e frame.number -e arp.opcode \
-e arp.src.hw_mac -e arp.src.proto_ipv4 \
-e arp.dst.hw_mac -e arp.dst.proto_ipv4
# (2) 응답이 주장하는 IP ↔ MAC 매핑 목록
tshark -r $F -Y "arp.opcode == 2" -T fields \
-e arp.src.proto_ipv4 -e arp.src.hw_mac | sort | uniq -c
# (3) Gratuitous / Announcement / Probe 구분
tshark -r $F -Y "arp.isgratuitous || arp.isprobe" -T fields \
-e frame.number -e arp.opcode -e arp.isgratuitous -e arp.isannouncement \
-e arp.isprobe -e _ws.col.Info
# (4) 중복 IP 탐지 결과
tshark -r $F -Y "arp.duplicate-address-detected" -T fields \
-e frame.number -e arp.src.proto_ipv4 -e arp.src.hw_mac -e arp.duplicate-address-frame
# (5) Ethernet 출발지와 ARP Sender MAC이 다른 패킷
tshark -r $F -Y "arp && !(eth.src == arp.src.hw_mac)" -T fields \
-e frame.number -e eth.src -e arp.src.hw_mac(5)번처럼 필드와 필드를 직접 비교하는 필터는 값이 아니라 패킷 안의 두 위치가 일치하는지를 검사합니다. 결과가 비어 있는 것이 일반적인 상태입니다. 필드 이름이나 연산자 지원 범위는 버전에 따라 차이가 있을 수 있으므로 tshark -v 로 사용 중인 버전을 함께 기록해 두세요.
📷 [실습 화면 삽입] Wireshark 상세 창에서 Address Resolution Protocol 트리를 펼친 화면(Opcode, Sender/Target 필드)
5. 결과 확인
아래는 형식 예시(값은 환경마다 다름) 입니다.
frame opcode src.hw_mac src.proto_ipv4 dst.hw_mac dst.proto_ipv4
1 1 00:0c:29:11:22:33 192.168.10.20 00:00:00:00:00:00 192.168.10.1
2 2 00:0c:29:99:88:77 192.168.10.1 00:0c:29:11:22:33 192.168.10.20
3 1 00:0c:29:11:22:33 192.168.10.20 00:00:00:00:00:00 192.168.10.20- 1번: 요청. Target MAC이 0으로 비어 있고 Target IP가 게이트웨이
- 2번: 응답. Sender 필드가 "192.168.10.1은 00:0c:29:99:88:77"이라고 주장
- 3번: Sender IP = Target IP 인 요청 →
arp.isgratuitous,arp.isannouncement가 True
중복 IP가 탐지된 경우 형식 예시:
frame src.proto_ipv4 src.hw_mac duplicate-address-frame
4 192.168.10.1 00:50:56:aa:bb:cc 2확인 체크리스트
-
arp.opcode값으로 요청(1)과 응답(2)을 구분했다 - 게이트웨이 IP에 대한 응답의
arp.src.hw_mac이 4-1에서 기록한 기준값과 같은지 확인했다 - 요청 패킷의
arp.dst.hw_mac이00:00:00:00:00:00인 것을 확인했다 - Gratuitous ARP·Announcement·Probe가 보였다면 필드 값으로 종류를 구분했다
-
arp.duplicate-address-detected결과가 없거나, 있다면 원인을 설명할 수 있다 -
eth.src와arp.src.hw_mac이 일치하는지 확인했다
6. 패킷 / 로그 분석
| 관찰 | 정상일 수 있는 경우 | 의심해야 하는 경우 |
|---|---|---|
Gratuitous ARP (arp.isgratuitous) | 인터페이스 활성화·IP 설정 직후, NIC 교체, VRRP 등 이중화 전환 | 게이트웨이 IP로 된 Gratuitous ARP가 처음 보는 MAC에서 반복 |
ARP Probe (arp.isprobe) | DHCP로 주소를 받은 장비의 주소 충돌 확인 | 짧은 시간에 여러 IP를 대상으로 Probe 반복 |
중복 IP (arp.duplicate-address-detected) | DHCP 재할당, VM 복제로 인한 설정 충돌, 장비 교체 | 게이트웨이·DNS 서버 IP를 두 MAC이 번갈아 주장 |
| 요청 없는 응답 | Gratuitous 응답 형태의 정상 공지 | 특정 호스트를 대상으로 같은 응답이 주기적으로 반복 |
| 한 MAC이 여러 IP를 주장 | 여러 IP를 가진 서버·라우터, Proxy ARP 설정 | 일반 PC MAC이 게이트웨이 IP와 다른 PC IP를 동시에 주장 |
| ARP 요청 급증 | 부팅 직후, 여러 내부 서버와 동시에 통신을 시작할 때 | 한 출발지가 서브넷 전체 IP를 순서대로 요청(스캔 가능성, 05. 네트워크 스캔 · 공격 징후 분석 시리즈에서 다룸) |
확인 명령 예시입니다.
# 게이트웨이 IP를 주장한 모든 MAC과 횟수
tshark -r $F -Y "arp.src.proto_ipv4 == 192.168.10.1" -T fields \
-e arp.src.hw_mac | sort | uniq -c
# 한 MAC이 주장한 IP가 여러 개인 경우
tshark -r $F -T fields -e arp.src.hw_mac -e arp.src.proto_ipv4 | sort -u \
| awk '{c[$1]++; ip[$1]=ip[$1]" "$2} END {for (m in c) if (c[m]>1) print m, ip[m]}'
# 출발지별 ARP 요청 수 (요청 급증 확인)
tshark -r $F -Y "arp.opcode == 1" -T fields -e arp.src.hw_mac | sort | uniq -c | sort -rn
# 시간과 함께 게이트웨이 매핑 변화 추적
tshark -r $F -Y "arp.src.proto_ipv4 == 192.168.10.1" -T fields \
-e frame.time -e arp.opcode -e arp.src.hw_mac두 번째 명령에서 Probe의 Sender IP 0.0.0.0 이 결과에 섞여 나올 수 있으므로, 결과를 읽을 때는 0.0.0.0 을 제외하고 판단합니다.
7. 보안관제 관점
흔적이 남는 곳
- ARP는 같은 브로드캐스트 도메인 안에서만 오가므로, 인터넷 경계의 방화벽이나 IDS 센서에는 보통 보이지 않습니다. 내부 스위치의 미러링 포트나 해당 서브넷의 호스트에서 캡처해야 관찰할 수 있습니다.
- 스위치의 DAI(Dynamic ARP Inspection)·포트 보안 로그, arpwatch 같은 ARP 감시 도구의 "MAC 변경" 알림, 호스트의 ARP 캐시(
ip neigh, Windowsarp -a)가 교차 확인 자료가 됩니다(장비 설정은 04. 네트워크 장비 실습 시리즈, 탐지 규칙은 06. 방화벽 · IDS/IPS 분석 시리즈에서 다룸). - DHCP 서버의 임대 기록으로 "그 시각 그 IP를 받아야 했던 MAC"을 확인하면 중복 IP의 원인을 좁힐 수 있습니다(48. DHCP DORA 과정 — IP를 받는 4단계 참고).
한계와 오탐 주의
arp.duplicate-address-detected는 캡처 파일 안의 비교 결과입니다. 캡처 전부터 매핑이 바뀌어 있었다면 탐지되지 않고, 반대로 정상적인 장비 교체도 탐지됩니다.- VRRP·HSRP 같은 게이트웨이 이중화, 클러스터 페일오버, 가상화 환경의 VM 이동은 정상적으로 Gratuitous ARP와 MAC 변경을 만듭니다. 네트워크 구성 정보를 모르면 오탐을 걸러낼 수 없습니다.
- ARP 패킷의 필드는 모두 보낸 쪽이 임의로 채울 수 있는 값이므로, "누가 보냈는가"는 스위치 포트 정보까지 확인해야 확정할 수 있습니다.
결론적으로 ARP 분석은 "게이트웨이 등 중요 IP의 MAC 매핑이 캡처 기간 동안 일관적이었는가"를 필드 값으로 확인하는 작업이고, 이상이 보이면 스위치·DHCP 로그로 원인을 확정합니다.
8. 핵심 정리
- ARP 분석의 기본은
arp.opcode(1 요청, 2 응답)와 Sender 필드(arp.src.hw_mac,arp.src.proto_ipv4)가 담은 IP ↔ MAC 주장을 읽는 것입니다. - 요청의 Target MAC은
00:00:00:00:00:00, 요청 프레임의eth.dst는 브로드캐스트인 것이 일반적입니다. arp.isgratuitous,arp.isannouncement,arp.isprobe는 Wireshark가 붙이는 판단 필드이며, Gratuitous ARP 자체는 정상 동작에서도 발생합니다.arp.duplicate-address-detected와arp.duplicate-address-frame으로 같은 IP를 다른 MAC이 주장한 지점을 찾을 수 있지만, 캡처 범위 안에서만 유효합니다.- 게이트웨이 IP의 MAC 변화는 최우선 확인 대상이며, 이중화·장비 교체 여부를 네트워크 구성과 DHCP·스위치 로그로 확인한 뒤 판단합니다.
