112. Ethernet 프레임 필드 분석 — eth.src·eth.dst·eth.type로 읽는 2계층 증거

Soc VLAN ethernet mac주소 wireshark 보안관제 패킷분석

네트워크 · 패킷 분석

목록 보기

112/300

📚 네트워크 · 패킷 분석 › 03. Wireshark 패킷 분석 — 112편
이전 글: 111. Endpoints · 다음 글: 113. MAC Address 분석
참고(01. TCP/IP 네트워크 구조 이해): 31. Ethernet 프레임과 MAC 주소 · ARP 동작 원리 — MAC 주소·프레임 구조의 개념은 이 글에서 다뤘습니다.

1. 왜 알아야 하는가

지금까지 Wireshark 화면 구조, 필터, 통계, 증거 보존을 다뤘다면, 이번 편부터는 패킷 한 개를 계층별 필드 단위로 해석합니다. 그 첫 대상이 가장 바깥쪽 헤더인 Ethernet 프레임입니다.

보안관제에서 대부분의 로그(방화벽, IDS, 웹 로그)는 IP 주소부터 기록합니다. 그런데 IP만으로는 답할 수 없는 질문이 있습니다.

이 IP 패킷을 실제로 전송한 장비(NIC)는 무엇인가?
같은 IP를 쓰는 장비가 캡처 중간에 바뀌지는 않았는가?
브로드캐스트·멀티캐스트 프레임이 평소보다 많아지지 않았는가?
이 트래픽은 어느 VLAN에서 발생했는가?

이 질문들은 Ethernet 헤더의 eth.src, eth.dst, eth.type, 그리고 802.1Q 태그의 vlan.id를 읽어야 답할 수 있습니다. 다만 MAC 주소는 같은 브로드캐스트 도메인 안에서만 의미가 있고, 라우터를 지나면 바뀐다는 한계도 함께 이해해야 합니다(라우팅 개념은 17. 게이트웨이와 라우팅 기초 — 다른 네트워크로 패킷은 어떻게 가는가 참고).

이번 글의 핵심 질문은 하나입니다. "이 프레임은 이 구간에서 누가 누구에게, 무엇을 담아 보냈는가?"

2. 핵심 개념

Ethernet 프레임 필드
그림 1. Ethernet II 헤더 필드와 대응하는 디스플레이 필터 필드명

2-1. Ethernet II 헤더와 Wireshark 필드명

Wireshark는 Ethernet II 헤더를 아래 필드로 분해합니다. 필터에 쓰는 이름과 tshark -T fields -e 에 쓰는 이름은 같습니다.

헤더 항목	크기	Wireshark 필드	분석 시 의미
Destination	6바이트	`eth.dst`	이 구간에서 프레임을 받을 NIC (브로드캐스트면 `ff:ff:ff:ff:ff:ff`)
Source	6바이트	`eth.src`	이 구간에서 프레임을 보낸 NIC
출발지·목적지 중 하나	—	`eth.addr`	특정 MAC이 보내거나 받은 프레임을 한 번에 필터
Type (EtherType)	2바이트	`eth.type`	다음 계층이 무엇인지 (IPv4, ARP, VLAN 태그 등)
Padding	가변	`eth.padding`	최소 프레임 길이를 채우기 위한 0 바이트
FCS	4바이트	`eth.fcs`	오류 검출값. 대부분의 캡처 환경에서는 NIC가 제거해 보이지 않음
Trailer	가변	`eth.trailer`	페이로드 뒤에 붙은 해석되지 않은 바이트

eth.addr는 "출발지 또는 목적지"를 뜻하므로 eth.addr == 00:0c:29:11:22:33 은 그 MAC이 관련된 모든 프레임을 보여 줍니다. 반대로 특정 MAC을 제외할 때는 Wireshark 버전에 따라 != 연산자의 해석이 달랐던 적이 있으므로, 의미가 분명한 !(eth.addr == ...) 형태로 쓰는 것이 안전합니다.

2-2. MAC 주소 안에 숨어 있는 정보

MAC 주소 6바이트 중 앞 3바이트는 제조사를 나타내는 OUI이고, 첫 바이트의 하위 두 비트는 주소의 성격을 알려 줍니다.

항목	Wireshark 필드	값의 의미
OUI(제조사) 번호	`eth.src.oui`, `eth.dst.oui`	앞 3바이트 값 (`-T fields` 출력은 10진수로 나옴)
OUI 제조사 이름	`eth.src.oui_resolved`, `eth.dst.oui_resolved`	예: `VMware, Inc.`
이름 해석된 주소	`eth.src_resolved`, `eth.dst_resolved`	예: `VMware_11:22:33`, `Broadcast`
IG 비트	`eth.dst.ig`, `eth.ig`	0 = 개별(유니캐스트), 1 = 그룹(브로드캐스트·멀티캐스트)
LG 비트	`eth.src.lg`, `eth.lg`	0 = 제조사 할당 주소, 1 = 로컬에서 관리(임의 지정·랜덤화)된 주소

패킷 목록의 Source 열에 VMware_11:22:33 처럼 보이는 것은 Wireshark가 OUI를 제조사 이름으로 바꿔서 보여 준 것일 뿐, 실제 값은 00:0c:29:11:22:33 입니다. 증거로 기록할 때는 원래 MAC 값을 함께 적어야 합니다.

2-3. EtherType — 다음 계층을 결정하는 2바이트

`eth.type` 값	다음 헤더	비고
`0x0800`	IPv4	가장 흔한 값
`0x0806`	ARP	다음 편(08)에서 분석
`0x86dd`	IPv6	IPv6 트래픽 존재 여부 확인에 사용
`0x8100`	802.1Q VLAN 태그	태그 뒤에 실제 EtherType(`vlan.etype`)이 다시 나옴
`0x88a8`	802.1ad (QinQ 외부 태그)	사업자망 등에서 사용
`0x88cc`	LLDP	스위치·장비가 자신을 알리는 프로토콜

2-4. 802.1Q VLAN 태그

VLAN 태그가 있으면 Source MAC 뒤에 4바이트가 끼어듭니다. 앞 2바이트가 0x8100(TPID)이고, 뒤 2바이트(TCI)가 다시 세 필드로 나뉩니다.

TCI 항목	크기	Wireshark 필드	의미
PCP (Priority)	3비트	`vlan.priority`	우선순위(QoS) 0~7
DEI	1비트	`vlan.dei`	혼잡 시 폐기 가능 표시 (구버전 명칭 CFI → `vlan.cfi`)
VID	12비트	`vlan.id`	VLAN 번호. 0과 4095는 예약값
(태그 뒤) Type	2바이트	`vlan.etype`	태그 뒤에 오는 실제 프로토콜

3. 동작 원리

Wireshark는 프레임을 받으면 eth.type 값을 보고 다음에 어떤 해석기(dissector)를 호출할지 결정합니다. VLAN 태그가 있으면 한 단계가 더 끼어듭니다.

[캡처된 바이트]
      ↓
Ethernet II 해석: eth.dst(6) → eth.src(6) → eth.type(2)
      ↓
eth.type == 0x8100 ?
   ├─ 예 → 802.1Q 해석: vlan.priority / vlan.dei / vlan.id → vlan.etype
   │          ↓
   └─ 아니오 ─┤
              ↓
   0x0800 → IPv4 (115편)    0x0806 → ARP (114편)    0x86dd → IPv6

여기서 관제 관점으로 꼭 기억할 점이 세 가지 있습니다.

① MAC은 구간(hop)마다 바뀝니다. 외부 서버로 나가는 패킷을 내부에서 캡처하면 eth.dst는 외부 서버가 아니라 게이트웨이의 MAC입니다. 반대로 외부에서 들어오는 패킷의 eth.src도 게이트웨이 MAC입니다.

[PC 192.168.10.20]  --(eth.src=PC MAC, eth.dst=GW MAC)-->  [게이트웨이]  --(MAC 새로 기록)-->  [외부 서버]
                    ↑ 이 구간 캡처에서 보이는 MAC                         ↑ 이 구간은 다른 MAC 쌍

② 캡처 위치에 따라 보이는 것이 다릅니다. 호스트에서 자신이 보내는 프레임을 캡처하면 패딩이 붙기 전이라 ARP 프레임이 42바이트로 보이고, 다른 장비에서 받은 같은 종류의 프레임은 최소 길이(FCS 제외 60바이트)로 패딩되어 보이는 경우가 많습니다. FCS는 NIC가 검사 후 제거하는 경우가 대부분이라 eth.fcs가 없는 것이 정상입니다.

③ VLAN 태그는 캡처 지점에서 이미 제거되었을 수 있습니다. 액세스 포트에 연결된 PC나 가상 머신에서는 태그가 붙지 않은 프레임만 보이는 것이 일반적이고, 트렁크 포트 미러링이나 NIC의 VLAN 오프로드 설정에 따라 태그가 보이거나 보이지 않을 수 있습니다. "vlan 필드가 없다 = VLAN을 안 쓴다"로 단정하면 안 됩니다.

4. 실제 명령어 / 실습

실습 환경: 본인 소유 Linux VM (Rocky Linux 또는 Ubuntu). 인터페이스 이름은 ens33을 예시로 사용합니다. 본인 환경의 이름은 ip link로 확인하세요.

4-1. tshark 설치

# Rocky Linux (tshark는 wireshark-cli 패키지에 포함)
sudo dnf install -y wireshark-cli

# Ubuntu
sudo apt update && sudo apt install -y tshark

4-2. 내 MAC·게이트웨이 확인 (비교 기준 만들기)

ip link show ens33              # link/ether 뒤가 내 MAC
ip route show default           # default via <게이트웨이 IP>
ip neigh show dev ens33         # 현재 ARP 캐시의 IP ↔ MAC

캡처 결과를 해석하기 전에 "내 MAC, 게이트웨이 IP·MAC"을 먼저 적어 두면, 패킷에서 보이는 MAC이 누구인지 바로 대조할 수 있습니다.

4-3. 캡처

# 터미널 1: 300개 프레임 캡처 후 자동 종료
sudo tshark -i ens33 -c 300 -w /tmp/pcap07-eth.pcapng

# 터미널 2: 정상 트래픽 발생
ping -c 3 <게이트웨이 IP>
curl -sI http://example.com > /dev/null

📷 [실습 화면 삽입] ip link show ens33, ip neigh show 결과와 tshark 캡처 진행 화면

4-4. 필드 단위로 읽기

F=/tmp/pcap07-eth.pcapng

# (1) 프레임별 2계층 필드
tshark -r $F -T fields -E header=y \
  -e frame.number -e eth.src -e eth.dst -e eth.type | head -20

# (2) 출발지 MAC별 프레임 수와 제조사
tshark -r $F -T fields -e eth.src -e eth.src.oui_resolved | sort | uniq -c | sort -rn

# (3) 브로드캐스트·멀티캐스트(IG 비트=1) 프레임의 종류
tshark -r $F -Y "eth.dst.ig == 1" -T fields -e eth.dst -e eth.type | sort | uniq -c | sort -rn

# (4) EtherType 분포
tshark -r $F -T fields -e eth.type | sort | uniq -c | sort -rn

# (5) IP ↔ MAC 대응표 (같은 IP에 MAC이 둘 이상인지 확인용)
tshark -r $F -Y ip -T fields -E occurrence=f -e ip.src -e eth.src | sort -u

# (6) MAC 단위 통계
tshark -r $F -q -z endpoints,eth

-E occurrence=f 는 한 패킷에 같은 필드가 여러 번 나올 때 첫 번째 값만 출력하는 옵션입니다. ICMP 오류 메시지처럼 IP 헤더가 두 번 들어 있는 패킷(117편에서 다룸)에서 192.168.10.30,192.168.10.20 같은 값이 섞이는 것을 막아 줍니다.

4-5. (선택) VLAN 태그 관찰

VLAN 서브 인터페이스를 만들면 부모 인터페이스에서 태그가 붙은 프레임을 관찰할 수 있습니다. 실습이 끝나면 반드시 삭제합니다.

sudo ip link add link ens33 name ens33.10 type vlan id 10
sudo ip addr add 10.10.10.1/24 dev ens33.10
sudo ip link set ens33.10 up

sudo tshark -i ens33 -c 10 -Y vlan -T fields -e eth.type -e vlan.id -e vlan.priority -e vlan.etype &
ping -c 2 10.10.10.2      # 응답이 없어도 태그된 ARP 요청이 나감

sudo ip link del ens33.10  # 실습 후 삭제

NIC 드라이버의 VLAN 오프로드 설정에 따라 태그가 캡처에 보이지 않을 수도 있습니다. 이 경우에도 "태그가 없었다"가 아니라 "이 캡처 지점에서는 보이지 않았다"로 기록합니다.

📷 [실습 화면 삽입] Wireshark 상세 창에서 Ethernet II와 802.1Q Virtual LAN 트리를 펼친 화면

5. 결과 확인

아래는 형식 예시(값은 환경마다 다름) 입니다.

frame.number  eth.src            eth.dst            eth.type
1             00:0c:29:11:22:33  ff:ff:ff:ff:ff:ff  0x0806
2             00:0c:29:99:88:77  00:0c:29:11:22:33  0x0806
3             00:0c:29:11:22:33  00:0c:29:99:88:77  0x0800

1번: 내 PC가 브로드캐스트로 ARP를 보냄 (eth.dst.ig=True)
2번: 게이트웨이가 내 PC에게 유니캐스트로 ARP 응답
3번: IPv4 패킷이지만 목적지 MAC은 게이트웨이 → 외부로 나가는 트래픽

VLAN 태그가 있는 경우 형식 예시:

eth.type  vlan.id  vlan.priority  vlan.etype
0x8100    10       0              0x0806

확인 체크리스트

eth.src 중 내 MAC과 게이트웨이 MAC을 구분할 수 있다
외부 IP로 가는 패킷의 eth.dst가 게이트웨이 MAC인 것을 확인했다
eth.type 분포에서 IPv4·ARP·IPv6 비율을 확인했다
eth.dst.ig == 1 프레임이 무엇인지(ARP, 멀티캐스트 등) 설명할 수 있다
목록의 VMware_... 같은 이름이 OUI 해석 결과이며 원래 MAC 값이 따로 있다는 것을 확인했다
(선택) VLAN 태그가 보였다면 vlan.id와 vlan.etype을 읽었다

6. 패킷 / 로그 분석

2계층 필드는 단독으로 "공격"을 증명하지 못하지만, 다른 증거와 어긋나는 지점을 찾는 데 유용합니다.

관찰	정상일 수 있는 경우	의심해야 하는 경우
여러 IP가 같은 `eth.src`를 가짐	게이트웨이를 거쳐 들어온 외부 트래픽(외부 IP 전부가 GW MAC)	같은 서브넷 내부 IP 여러 개가 한 MAC에서 나옴
같은 IP가 다른 `eth.src`로 나타남	DHCP로 IP가 다른 장비에 재할당, 이중화 장비 전환	짧은 시간 안에 게이트웨이 IP의 MAC이 바뀜 (114편 ARP 분석과 연결)
`eth.src.lg == 1` (로컬 관리 주소)	스마트폰·노트북의 MAC 랜덤화, 가상 인터페이스	서버 대역에서 등록되지 않은 랜덤 MAC 출현
브로드캐스트 프레임 증가	부팅 직후, DHCP·ARP 갱신 시기	특정 MAC 하나가 짧은 시간에 대량 브로드캐스트 발생
예상 밖의 `vlan.id`	트렁크 포트 미러링 구간	해당 포트에 존재하지 않아야 할 VLAN 태그
낯선 `eth.type`	LLDP 등 장비 관리 프로토콜	목적을 설명할 수 없는 EtherType이 반복

확인에 쓰는 필터 예시입니다.

# 게이트웨이 IP를 출발지로 하는 프레임의 MAC이 하나인지 확인
tshark -r $F -Y "ip.src == 192.168.10.1" -T fields -e eth.src | sort | uniq -c

# 같은 IP에 MAC이 2개 이상인 경우만 출력
tshark -r $F -Y ip -T fields -E occurrence=f -e ip.src -e eth.src | sort -u \
  | awk '{c[$1]++; m[$1]=m[$1]" "$2} END {for (i in c) if (c[i]>1) print i, m[i]}'

# 로컬 관리 주소를 출발지로 쓰는 프레임
tshark -r $F -Y "eth.src.lg == 1" -T fields -e eth.src | sort | uniq -c

# 특정 MAC이 관련된 프레임만 (출발지 또는 목적지)
tshark -r $F -Y "eth.addr == 00:0c:29:11:22:33" | head

주의할 점은 외부 IP들이 모두 같은 MAC(게이트웨이)으로 보이는 것은 정상이라는 것입니다. "하나의 MAC에 IP가 여러 개"라는 조건은 반드시 같은 서브넷 내부 IP로 한정해서 봐야 오탐을 줄일 수 있습니다(서브넷 판단은 14. IPv4 주소와 서브넷(CIDR) — 같은 네트워크인지 판단하는 법 참고).

7. 보안관제 관점

흔적이 남는 곳

방화벽·IDS 이벤트는 일반적으로 IP·포트 중심이라 MAC 정보가 없거나 제한적입니다.
MAC 정보는 주로 스위치의 MAC 주소 테이블·포트 보안 로그, DHCP 서버의 임대 기록, NAC(네트워크 접근 제어) 로그에서 확인합니다. 이 로그와 pcap의 eth.src를 대조하면 "그 시각 그 IP를 쓴 장비"를 좁혀 갈 수 있습니다(장비별 로그는 04. 네트워크 장비 실습 시리즈에서 다룸).
여러 장비의 로그를 한 화면에서 연결하는 방법은 07. 네트워크 보안관제 통합 분석 시리즈에서 다룹니다.

한계와 오탐 주의

MAC 주소는 소프트웨어로 쉽게 바꿀 수 있습니다. eth.src는 "그 NIC가 그렇게 주장한 주소"이지 장비의 신원 증명이 아닙니다.
OUI 제조사 이름은 추정일 뿐입니다. 가상 머신, 랜덤화된 주소, 재판매 장비는 실제 장비와 다를 수 있습니다.
MAC은 라우터를 넘으면 사라지므로, 다른 서브넷에서 온 트래픽의 원래 장비 MAC은 이 캡처로 알 수 없습니다.
VLAN 태그가 보이지 않는 것은 캡처 지점의 특성일 수 있습니다.

그래서 2계층 필드는 "IP만으로 설명되지 않는 이상 징후를 찾는 보조 증거"로 쓰고, 결론은 DHCP·스위치 로그 등 다른 증거와 함께 내리는 것이 바람직합니다.

8. 핵심 정리

Ethernet 헤더는 eth.dst, eth.src, eth.type 세 필드가 핵심이며, eth.addr는 출발지·목적지를 함께 필터합니다.
목록에 보이는 VMware_11:22:33 같은 이름은 OUI 해석 결과이고, 증거 기록에는 원래 MAC 값을 남깁니다.
eth.dst.ig(브로드캐스트·멀티캐스트 여부)와 eth.src.lg(로컬 관리 주소 여부)로 MAC의 성격을 판단할 수 있습니다.
802.1Q 태그는 eth.type == 0x8100 뒤에 vlan.id·vlan.priority·vlan.etype으로 해석되며, 캡처 지점에 따라 보이지 않을 수 있습니다.
MAC은 구간마다 바뀌므로 외부 트래픽의 eth.src/eth.dst는 게이트웨이 MAC인 것이 정상입니다.
MAC은 위조 가능하므로 단독 증거가 아니라 DHCP·스위치 로그와 대조하는 보조 증거로 씁니다.

다음 글: 114. ARP 패킷 필드 분석 — opcode와 Sender·Target 필드로 IP-MAC 매핑 검증하기

changseop lee

코드에 숨겨진 위협을 읽고 AI로 보안의 미래를 설계합니다. 프론트엔드 개발 경험을 자산 삼아 더 견고하고 지능적인 보안 운영 시스템을 구축해 나가는 과정을 기록합니다