ARP Spoofing 실습과 패킷 흐름 분석

ARP Spoofing 상황을 공격 실행이 아니라 패킷 흐름 분석과 방어 관점으로 정리했습니다. ARP cache, tcpdump, Wireshark 필터, Dynamic ARP Inspection 대응을 다룹니다.

ARP Spoofing 실습과 패킷 흐름 분석

ARP Spoofing 공격 절차를 따라 하는 글이 아니라, 격리된 허가 랩에서 이미 캡처된 ARP 변조 상황을 어떻게 읽고 방어할지 정리한 분석 가이드다. 설명의 핵심은 "정상 상태에서는 클라이언트의 외부 통신이 게이트웨이 MAC으로 가고, ARP 변조 이후에는 게이트웨이 IP가 다른 MAC으로 보인다"는 패킷 흐름 차이다. 여기서는 공격 실행 명령 대신 확인, 탐지, 복구, 방어 설정 기준에 집중한다.

실습 토폴로지

역할IPMAC설명
클라이언트192.168.11.13200:0c:29:6a:5e:fc외부로 ICMP 요청을 보내는 Windows 7 호스트
게이트웨이192.168.11.100:50:56:fa:45:a4클라이언트의 default gateway
분석 호스트192.168.11.25000:0c:29:ff:9a:04패킷 캡처와 ARP 테이블 변화를 관찰하는 Linux 호스트

ARP가 필요한 이유

클라이언트가 8.8.8.8 같은 외부 IP로 패킷을 보낼 때, 이더넷 프레임의 목적지 MAC은 8.8.8.8의 MAC이 아니라 같은 L2 구간에 있는 default gateway의 MAC이다. 따라서 정상 상태의 ICMP echo request는 다음 구조가 된다.

IP 계층:
 source = 192.168.11.132
 destination = 8.8.8.8

Ethernet 계층:
 source = 00:0c:29:6a:5e:fc
 destination = 00:50:56:fa:45:a4

ARP Spoofing이 발생하면 클라이언트의 ARP cache에서 192.168.11.1이 실제 게이트웨이 MAC이 아닌 다른 MAC으로 바뀐다. 이 상태에서는 클라이언트가 외부로 보내는 프레임이 변조된 MAC 주소로 향하게 된다.

정상 상태 확인

Linux에서 gateway MAC을 확인한다.

ip route
ip neigh show
ip neigh show 192.168.11.1

Windows 클라이언트에서는 ARP cache를 확인한다.

arp -a
ping 8.8.8.8

정상이라면 192.168.11.1의 MAC은 게이트웨이 장비의 MAC인 00:50:56:fa:45:a4로 보여야 한다.

패킷 캡처 기준

분석 호스트에서는 ARP와 ICMP를 함께 캡처한다. 아래 명령은 공격을 수행하는 명령이 아니라 현재 네트워크에서 보이는 ARP/ICMP 흐름을 관찰하는 명령이다.

sudo tcpdump -ni eth0 'arp or icmp'

# 게이트웨이 IP와 관련된 ARP만 좁혀 보기
sudo tcpdump -ni eth0 'arp and host 192.168.11.1'

Wireshark에서는 다음 필터가 유용하다.

arp
arp.opcode == 2
arp.duplicate-address-detected
eth.addr == 00:50:56:fa:45:a4
eth.addr == 00:0c:29:ff:9a:04
ip.addr == 8.8.8.8 and icmp

정상 패킷과 변조 패킷의 차이

구분정상 상태변조 의심 상태
클라이언트 ARP cache192.168.11.1 -> 00:50:56:fa:45:a4192.168.11.1 -> 00:0c:29:ff:9a:04처럼 gateway IP가 다른 MAC으로 표시
ICMP request Ethernet destination게이트웨이 MAC게이트웨이가 아닌 호스트 MAC
ARP reply요청에 대한 정상 응답요청하지 않은 reply, gratuitous ARP, 짧은 간격 반복
사용자 증상정상 통신간헐적 끊김, 인증 세션 이상, gateway MAC 변동

로컬 복구

단말에서 ARP cache를 비우면 일시적으로 정상 MAC을 다시 배울 수 있다. 하지만 원인이 네트워크에 남아 있으면 다시 변조될 수 있으므로 이것은 복구가 아니라 확인 절차에 가깝다.

# Linux
sudo ip neigh flush all
ip neigh show
# Windows 관리자 권한
arp -d *
arp -a

간단한 gateway MAC 감시 스크립트

작은 랩에서는 gateway IP가 예상 MAC과 다르게 보이는지만 감시해도 원인 파악에 도움이 된다.

#!/usr/bin/env bash
set -euo pipefail

GW_IP="${1:-192.168.11.1}"
EXPECTED_MAC="${2:-00:50:56:fa:45:a4}"

CURRENT_MAC="$(ip neigh show "${GW_IP}" | awk '{print $5; exit}')"

if [ -z "${CURRENT_MAC}" ]; then
 echo "UNKNOWN: ${GW_IP} ARP entry not found"
 exit 3
fi

if [ "${CURRENT_MAC,,}" != "${EXPECTED_MAC,,}" ]; then
 echo "ALERT: ${GW_IP} expected=${EXPECTED_MAC} current=${CURRENT_MAC}"
 exit 2
fi

echo "OK: ${GW_IP} current=${CURRENT_MAC}"

스위치 레벨 방어

ARP Spoofing은 단말에서만 막기 어렵다. 운영망에서는 L2 스위치에서 DHCP Snooping, Dynamic ARP Inspection, port security 같은 기능을 같이 설계해야 한다.

  • DHCP Snooping: 신뢰할 수 있는 DHCP server 포트와 client 포트를 구분하고 IP-MAC binding table을 만든다.
  • Dynamic ARP Inspection: ARP packet의 IP-MAC mapping이 DHCP Snooping binding과 맞는지 검사하고, 맞지 않으면 차단한다.
  • Static ARP: gateway, firewall, core service처럼 중요한 일부 장비에는 고정 ARP를 고려할 수 있다.
  • VLAN 분리: 사용자가 많은 flat L2 네트워크를 줄이고, 중요 서버망과 사용자망을 분리한다.
  • 802.1X/NAC: 허가되지 않은 장비가 같은 L2 segment에 들어오는 것을 줄인다.

운영에서 확인할 로그와 증거

장애 또는 보안 이벤트로 다룰 때는 단말 화면만 보지 말고 증거를 남긴다.

date
ip addr
ip route
ip neigh show
sudo tcpdump -ni eth0 -w arp-investigation.pcap 'arp or icmp'

캡처 파일에서는 다음을 확인한다.

  1. gateway IP를 주장하는 MAC이 시간에 따라 바뀌는지
  2. ARP reply가 요청 없이 반복되는지
  3. 클라이언트의 ICMP request가 실제 gateway MAC이 아닌 다른 MAC으로 가는지
  4. 동일 MAC이 여러 IP를 동시에 주장하는지
  5. 문제가 특정 VLAN, 특정 switch port, 특정 시간대에 집중되는지

정리

ARP Spoofing 분석의 핵심은 "IP 목적지"와 "Ethernet 목적지 MAC"을 분리해서 보는 것이다. 외부 IP로 나가는 패킷의 L2 목적지는 gateway MAC이어야 한다. gateway IP가 다른 MAC으로 매핑되거나 ARP reply가 비정상적으로 반복되면 ARP 변조를 의심한다. 단말에서는 ip neigh, arp -a, tcpdump, Wireshark로 증거를 잡고, 운영망에서는 DHCP Snooping과 Dynamic ARP Inspection 같은 스위치 레벨 방어를 적용해야 한다.

문서 링크

BGM EVER