📚 네트워크 · 패킷 분석 › 02. 포트 · 프로토콜 분석 — 80편
이전 글: 79. ICMP · 다음 글: 81. Web Server Port
1. 개념
ARP(Address Resolution Protocol)는 같은 네트워크 안에서 IP 주소에 해당하는 MAC 주소를 찾는 프로토콜입니다. Request·Reply의 구조와 ARP Cache는 01 영역에서 다뤘습니다.
이 글은 "ARP는 몇 번 포트를 쓰는가?"라는 흔한 질문을 정리합니다. 답은 ARP에는 포트도, IP 헤더도 없다입니다. 포트는 한 호스트 안에서 어느 프로그램(소켓)으로 보낼지 정하는 4계층 번호이고, ARP는 같은 링크에서 어느 장비(NIC)로 보낼지 정하는 2계층 동작이기 때문입니다.
| 구분 | ARP | Port (TCP/UDP) |
|---|---|---|
| 계층 | 2계층과 3계층 사이 (Ethernet 위) | 4계층 |
| 식별 대상 | 같은 링크의 장비(MAC) | 호스트 안의 프로세스(소켓) |
| 담기는 곳 | Ethernet 프레임 (EtherType 0x0806) | IP 패킷 안 TCP/UDP 헤더 |
| IP 헤더 | 없음 | 있음 |
| 전달 범위 | 브로드캐스트 도메인 내부, 라우터를 넘지 않음 | 라우팅되어 인터넷 끝까지 |
| 처리 주체 | 커널(OS) | 포트를 연 응용 프로그램 |
2. 동작 원리
같은 LAN의 웹 서버에 접속할 때, ARP와 포트는 서로 다른 단계에서 쓰입니다.
클라이언트 192.168.10.10 → 웹 서버 192.168.10.20:80
① 목적지 IP가 같은 네트워크인가? (다르면 게이트웨이 IP로 ②)
↓
② ARP: "192.168.10.20의 MAC은?" ← 브로드캐스트, 포트 없음
ARP Reply: "aa:bb:cc:00:00:20"
↓
③ Ethernet 프레임 조립
[목적지 MAC aa:bb:cc:00:00:20][EtherType 0x0800 IPv4]
[IP 192.168.10.10 → 192.168.10.20, proto=6]
[TCP 51000 → 80] ← 여기서 처음 포트가 등장
↓
④ 서버 NIC가 프레임 수신 → 커널이 IP·TCP 확인 → 80번 소켓(웹 서버)에 전달- ARP는 "어느 문 앞(장비)으로 갈지", 포트는 "건물 안 어느 방(프로그램)으로 갈지"를 정합니다.
- 다른 네트워크의 서버로 갈 때도 ARP는 게이트웨이의 MAC만 찾습니다. 원격 서버의 포트와 ARP는 직접 관련이 없습니다.
3. 주요 특징
포트 개념이 없다는 점은 보안 장비와 도구에서 실제 차이를 만듭니다.
| 항목 | ARP | TCP/UDP 포트 |
|---|---|---|
ss -tuln에 표시 | 안 됨 (소켓이 아님) | 됨 |
| iptables·firewalld 규칙 | 적용 대상 아님 (별도 ARP 필터 필요) | 주 적용 대상 |
| L3/L4 방화벽 장비 로그 | 대부분 남지 않음 | 남음 |
| "서비스 끄기" | 불가 (IPv4 통신에 필수) | 서비스 중지로 포트 닫힘 |
| 관찰 도구 | ip neigh, tcpdump -e arp, 스위치 | ss, 방화벽, IDS |
그 결과, 모든 포트를 막은 호스트도 같은 LAN에서는 ARP에 응답합니다. IPv4 통신을 하려면 ARP 응답이 필요하기 때문입니다.
| 상황 | 같은 LAN에서 | 다른 네트워크에서 |
|---|---|---|
| 모든 TCP/UDP 포트 차단, ping 차단 | ARP 응답으로 존재가 드러남 | 존재 확인이 어려움 |
| 포트 80만 허용 | ARP + 80 응답 | 80 응답만 |
4. 예시
실습 예시 — 본인 소유 VM 두 대(192.168.10.10, 192.168.10.20), 인터페이스 ens33은 예시입니다. 명령은 Rocky/Ubuntu 공통입니다.
# [VM2] 소켓 목록에는 ARP 관련 항목이 없음을 확인
sudo ss -tuln
# [VM1] ARP와 TCP 80을 함께 캡처 (-e: MAC 주소 표시)
sudo tcpdump -e -nn -i ens33 'arp or tcp port 80'
# [VM1] 캐시를 지우고 접속해 ARP → TCP 순서 발생
sudo ip neigh flush dev ens33
curl -s -o /dev/null http://192.168.10.20/
# [VM1] ARP 캐시 확인
ip neigh show dev ens33tcpdump 출력 형식 예시(값은 환경마다 다름, 일부 생략):
aa:bb:cc:00:00:10 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.10.20 tell 192.168.10.10
aa:bb:cc:00:00:20 > aa:bb:cc:00:00:10, ethertype ARP (0x0806), length 60: Reply 192.168.10.20 is-at aa:bb:cc:00:00:20
aa:bb:cc:00:00:10 > aa:bb:cc:00:00:20, ethertype IPv4 (0x0800), length 74: 192.168.10.10.51000 > 192.168.10.20.80: Flags [S], ...| 줄 | 확인 포인트 |
|---|---|
| ARP Request | EtherType 0x0806, IP 주소는 ARP 본문 안의 값, 포트 표기 없음 |
| ARP Reply | MAC 정보만 돌려줌 |
| TCP SYN | EtherType 0x0800 이후 IP·포트(.51000 > .80) 등장 |
같은 서버에서 sudo systemctl stop nginx(또는 httpd)로 웹 서비스를 멈춰도 ARP Reply는 계속 나오고, TCP 80에 대해서만 RST가 돌아오는 것을 비교할 수 있습니다.
5. 보안 관점
- 포트 기반 통제의 범위 밖: ARP 위조(ARP Spoofing)는 포트와 무관하게 동작하므로, 포트 차단·호스트 방화벽으로는 막을 수 없습니다. 스위치의 DAI(Dynamic ARP Inspection), 포트 보안 같은 2계층 대책이 필요합니다(04 영역에서 다룸).
- 내부 호스트 발견: 같은 LAN의 공격자는 포트가 모두 막힌 호스트도 ARP로 찾을 수 있습니다. 호스트 발견 방식은 05 영역 205. Host Discovery에서 다룹니다.
- 로그 공백: 방화벽·IDS가 3계층 이상만 보거나 다른 세그먼트에 있으면 ARP 이상 징후가 전혀 기록되지 않습니다.
6. SOC 관점
| 흔적 위치 | ARP 관찰 가능 여부 |
|---|---|
| 경계 방화벽 로그 | 대부분 없음 (포트·IP 기반 기록) |
| 같은 세그먼트의 IDS 센서 | ARP 이상(같은 IP의 MAC 변경 등) 탐지 규칙 가능 |
| L2 스위치 로그 | DAI 위반, MAC 이동(flapping) 이벤트 |
| 호스트 | ip neigh, Windows arp -a 캐시 |
| 패킷 캡처 | ARP Request·Reply의 MAC·IP 대응 |
관제자가 확인할 질문
- 이 이상 징후는 포트·IP 로그로 확인할 수 있는 종류인가, 2계층 증거가 필요한 종류인가?
- 센서가 해당 브로드캐스트 도메인 안에 있는가?
- 게이트웨이 IP에 대응하는 MAC이 바뀌었는가?
오탐 주의: 서버 이중화(VRRP 등)의 장애 전환, NIC 교체, VM 이동 시 같은 IP의 MAC이 정상적으로 바뀝니다. 변경 이력과 대조합니다.
7. 핵심 정리
- 포트는 호스트 안의 프로세스를, ARP는 같은 링크의 장비(MAC)를 찾는 것이며 계층이 다릅니다.
- ARP는 EtherType 0x0806 프레임에 직접 실리고 IP 헤더도 포트도 없으며 라우터를 넘지 않습니다.
ss소켓 목록, iptables·firewalld 규칙, 경계 방화벽 로그는 ARP를 다루지 않습니다.- 모든 포트를 막은 호스트도 같은 LAN에서는 ARP에 응답하므로 존재가 드러납니다.
- ARP 관련 이상은 같은 세그먼트의 센서, 스위치 로그, 호스트 ARP 캐시로 확인합니다.
