📚 네트워크 · 패킷 분석 › 01. TCP/IP 구조 이해 — 33편
이전 글: 32. ARP Request와 Reply · 다음 글: 34. ICMP와 ping — 오류 보고 프로토콜 읽는 법
1. 개념
ARP Cache(ARP 테이블, Linux에서는 Neighbor Table)는 ARP로 알아낸 IP 주소 → MAC 주소 대응을 잠시 저장해 두는 호스트의 메모리 테이블입니다. 패킷을 보낼 때마다 32. ARP Request와 Reply의 Request/Reply를 반복하면 브로드캐스트가 너무 많아지므로, 한 번 알아낸 결과를 일정 시간 재사용합니다.
| 항목 유형 | 만들어지는 방법 | 유지 기간 |
|---|---|---|
| 동적(Dynamic) 항목 | ARP Reply 수신, 또는 상대의 Request를 받으면서 학습 | 일정 시간 사용하지 않으면 확인 후 만료 |
| 정적(Static/Permanent) 항목 | 관리자가 직접 등록 | 삭제하거나 재부팅(설정 방식에 따라)할 때까지 |
캐시는 호스트마다 따로 있습니다. 같은 네트워크의 PC 두 대가 게이트웨이 MAC을 서로 다르게 기억하고 있을 수도 있으며, 이 점이 ARP 스푸핑 분석에서 중요합니다.
2. 동작 원리
Linux는 각 항목에 상태(NUD, Neighbor Unreachability Detection 상태)를 붙여 관리합니다. 대표적인 흐름은 다음과 같습니다.
[전송할 IP 패킷 발생, 캐시에 항목 없음]
↓
INCOMPLETE ── ARP Request 전송 후 Reply 대기
│ └─ 응답 없음 → FAILED (패킷 전송 실패)
↓ Reply 수신
REACHABLE ── 최근 확인됨, 그대로 사용
│ (일정 시간 경과, 기본 약 30초 전후의 무작위 값)
↓
STALE ── 아직 사용은 가능하지만 확인 필요
│ (이 항목으로 패킷을 보내는 순간)
↓
DELAY ── 상위 계층(TCP ACK 등)의 확인을 잠깐 기다림
│ └─ 확인됨 → REACHABLE
↓ 확인 없음
PROBE ── 유니캐스트 ARP Request로 직접 확인
├─ Reply 수신 → REACHABLE
└─ 응답 없음 → FAILED- STALE 항목도 즉시 쓰입니다. "오래돼서 못 쓴다"가 아니라 "쓰면서 다시 확인한다"는 뜻입니다.
- 사용되지 않는 STALE 항목은 가비지 컬렉션으로 정리되며, 정리 시점은 커널 설정(
gc_stale_time,gc_thresh1~3등)에 따라 달라집니다. - Windows도 비슷한 상태(Reachable, Stale, Probe, Unreachable, Permanent 등)를 사용하며, 세부 타이머 값은 OS와 버전마다 다릅니다.
3. 주요 특징
Linux ip neigh 출력에서 볼 수 있는 상태입니다.
| 상태 | 의미 | 관제 시 해석 |
|---|---|---|
REACHABLE | 최근 도달 확인됨 | 현재 통신 중인 상대 |
STALE | 확인 기간이 지남, 사용 시 재확인 | 가장 흔한 상태. 이상 아님 |
DELAY / PROBE | 재확인 진행 중 | 짧게 스쳐 지나가는 상태 |
INCOMPLETE | Request를 보냈으나 아직 Reply 없음 | 존재하지 않는 IP로 전송 시도 중일 수 있음 |
FAILED | 확인 실패 | 대상 다운, 또는 없는 IP. 대량이면 대역 탐색 흔적일 수 있음 |
PERMANENT | 정적 항목 | 관리자가 등록한 값인지 확인 |
조회·관리 명령은 OS마다 다릅니다.
| 목적 | Linux (Rocky/Ubuntu 공통, iproute2) | Windows |
|---|---|---|
| 전체 조회 | ip neigh show | arp -a 또는 PowerShell Get-NetNeighbor |
| 특정 인터페이스 | ip neigh show dev ens33 | Get-NetNeighbor -InterfaceIndex <번호> |
| 정적 항목 추가 | sudo ip neigh replace <IP> lladdr <MAC> dev ens33 nud permanent | netsh interface ipv4 add neighbors "<인터페이스명>" <IP> <MAC> |
| 항목 삭제 | sudo ip neigh del <IP> dev ens33 | arp -d <IP> (관리자 권한) |
| 캐시 비우기 | sudo ip neigh flush dev ens33 | netsh interface ip delete arpcache |
arp -n(net-tools)은 Linux에서도 쓸 수 있지만 최신 배포판에는 기본 설치되지 않는 경우가 많아 ip neigh를 기준으로 합니다.
4. 예시
실습 예시 — 본인 소유 Linux VM에서 캐시 상태 변화를 관찰합니다. 인터페이스 ens33은 예시입니다.
# 현재 캐시
ip neigh show dev ens33
# 게이트웨이와 통신 → REACHABLE로 바뀌는지 확인
ping -c 1 192.168.10.1 > /dev/null; ip neigh show 192.168.10.1
# 없는 IP로 전송 시도 → INCOMPLETE → FAILED 관찰
ping -c 1 -W 1 192.168.10.250 > /dev/null; ip neigh show 192.168.10.250
# 변화를 실시간으로 보기 (Ctrl+C로 종료)
ip monitor neigh
# 타이머 관련 커널 설정 조회
sysctl net.ipv4.neigh.default.base_reachable_time_ms net.ipv4.neigh.default.gc_stale_time출력 형식 예시(값은 환경마다 다름):
192.168.10.1 dev ens33 lladdr 02:00:00:00:00:01 REACHABLE
192.168.10.30 dev ens33 lladdr 02:00:00:00:00:30 STALE
192.168.10.250 dev ens33 FAILEDFAILED 항목에는 MAC(lladdr)이 없습니다. Windows arp -a 출력은 인터넷 주소 / 물리적 주소 / 유형(동적·정적) 형태로 표시됩니다.
📷 [실습 화면 삽입 위치]
ip monitor neigh실행 중 ping을 보냈을 때 상태가 INCOMPLETE → REACHABLE로 바뀌는 화면
5. 보안 관점
ARP Cache는 ARP 스푸핑의 실제 목표물입니다. 위조된 Reply가 들어오면 캐시의 게이트웨이 항목이 공격자 MAC으로 덮어써지고, 그 뒤 해당 호스트의 외부행 트래픽이 공격자 장비를 먼저 거치게 됩니다(중간자 위치). 원리 수준의 흔적은 다음과 같습니다.
| 캐시에서 보이는 흔적 | 의미 |
|---|---|
| 게이트웨이 IP의 MAC이 평소와 다름 | 변조 또는 게이트웨이 교체·절체 |
| 서로 다른 두 IP가 같은 MAC을 가리킴 | 한 장비가 두 IP를 가로채는 중일 수 있음 (단, 라우터·다중 IP 서버는 정상) |
| 정적 항목이 예상과 다름 | 설정 변경 이력 확인 필요 |
정적 항목으로 게이트웨이 MAC을 고정하면 해당 호스트는 변조에 강해지지만, 장비 교체 시 수동 갱신이 필요해 대규모 환경에서는 스위치의 DAI 같은 네트워크 측 대책이 주로 쓰입니다(04. 네트워크 장비 실습 영역에서 다룸).
6. SOC 관점
ARP Cache는 휘발성 증거입니다. 수 분 안에 바뀌거나 사라지므로, 의심 상황에서는 다른 조치보다 먼저 수집하는 것이 좋습니다.
| 흔적 위치 | 확인할 수 있는 것 |
|---|---|
호스트 캐시 (ip neigh, arp -a) | 현재 시점의 IP-MAC 대응. 기록이 남지 않으므로 조회 시각과 함께 저장 |
| arpwatch 등 모니터링 도구 로그 | new station, changed ethernet address, flip flop 같은 변화 이벤트 |
| EDR·에이전트 수집 데이터 | 에이전트가 캐시·네트워크 설정을 수집하도록 구성된 경우 |
| 스위치 MAC 테이블 | 해당 MAC이 실제로 어느 포트에 연결되어 있는지 |
관제자가 확인할 질문
- 의심 호스트의 캐시에서 게이트웨이 MAC이 실제 게이트웨이 MAC과 같은가?
- 그 MAC은 스위치의 어느 포트, 어떤 자산에 해당하는가?
- 같은 대역의 다른 호스트들도 같은 변화를 보이는가?
오탐 주의: 이중화 장비 절체, 가상 IP(VIP)를 쓰는 로드밸런서, 게이트웨이 교체 작업은 정상적으로 MAC 변경을 만듭니다. FAILED 항목 다수는 단순히 꺼진 장비로 통신을 시도한 결과일 수 있으므로, 짧은 시간에 대역 전체로 퍼져 있는지를 함께 봅니다(05. 네트워크 스캔 징후 분석 영역 228. 내부망 정찰에서 다룸).
7. 핵심 정리
- ARP Cache는 호스트마다 따로 가진 IP → MAC 대응 테이블이며, 동적 항목은 시간이 지나면 재확인되거나 사라집니다.
- Linux에서는
ip neigh로 REACHABLE, STALE, FAILED 등 항목 상태를 볼 수 있고, STALE은 정상적인 흔한 상태입니다. - Windows는
arp -a와Get-NetNeighbor로 조회합니다. - ARP 스푸핑은 결국 이 캐시를 덮어쓰는 것이므로, 게이트웨이 MAC 불일치가 핵심 확인 포인트입니다.
- 캐시는 휘발성이므로 조회 시각과 함께 먼저 수집하고, 스위치 MAC 테이블·자산 정보와 대조합니다.
