📚 네트워크 · 패킷 분석 › 03. Wireshark 패킷 분석 — 103편
이전 글: 102. Wireshark 설치와 실행 · 다음 글: 104. Wireshark 화면 구조와 필드 읽는 법
참고(리눅스 시스템 기초): Linux 네트워크 구조 — 인터페이스·커널 네트워크 스택 기본
참고(리눅스 시스템 기초): ss와 ip 명령어 —ip link로 인터페이스 상태 확인
1. 왜 알아야 하는가
이번 시리즈의 핵심 질문은 하나입니다.
"실제로 어떤 패킷이 오갔는가?"
로그는 장비가 "기록하기로 한 것"만 남기지만, 패킷은 회선 위를 실제로 지나간 바이트 그 자체입니다. 그래서 경보나 로그가 애매할 때 최종 판단 근거로 pcap을 찾습니다.
그런데 Wireshark를 켜기 전에 먼저 답해야 할 질문이 있습니다.
- 이 인터페이스에서 내가 보려는 트래픽이 애초에 보이는 위치인가?
- 보이지 않는다면 스위치 설정(SPAN)이나 장비(TAP)가 필요한가?
- 이 네트워크를 캡처해도 되는 권한이 있는가?
캡처 위치를 잘못 잡으면 "패킷이 없다 = 통신이 없었다"라는 잘못된 결론에 도달합니다. 이 글은 그 전제 조건을 정리합니다.
2. 핵심 개념
2-1. NIC는 원래 "내 것만" 받는다
NIC(Network Interface Card)는 수신한 Ethernet 프레임의 목적지 MAC을 보고 걸러냅니다. (프레임·MAC 구조는 02. Ethernet 프레임과 MAC 주소 · ARP 동작 원리에서 다뤘습니다.)
| 목적지 MAC | 일반 모드 | Promiscuous 모드 |
|---|---|---|
| 내 NIC의 MAC (유니캐스트) | 수신 | 수신 |
브로드캐스트 ff:ff:ff:ff:ff:ff | 수신 | 수신 |
| 가입한 멀티캐스트 | 수신 | 수신 |
| 다른 호스트의 유니캐스트 | 폐기 | 수신 |
2-2. Promiscuous 모드의 한계
Promiscuous 모드는 "NIC까지 도착한 프레임을 버리지 않는 것"일 뿐입니다. 스위치는 MAC 주소 테이블을 보고 해당 포트로만 유니캐스트를 전달하므로, 스위치 환경에서는 Promiscuous 모드를 켜도 다른 호스트끼리의 유니캐스트는 대부분 보이지 않습니다. 보이는 것은 내 트래픽, 브로드캐스트, 멀티캐스트, 그리고 MAC 테이블에 없는 목적지로 flooding된 프레임 정도입니다.
2-3. SPAN(포트 미러링)과 TAP
다른 호스트의 트래픽을 보려면 트래픽을 캡처 지점으로 "복사해 주는" 장치가 필요합니다.
| 구분 | SPAN / Mirror Port | Network TAP |
|---|---|---|
| 방식 | 스위치가 지정 포트·VLAN의 트래픽을 복사해 모니터 포트로 전송 | 회선 중간에 물리적으로 삽입해 신호를 복사 |
| 비용·도입 | 기존 스위치 기능으로 설정만 하면 됨 | 별도 장비 구매·회선 작업 필요 |
| 누락 가능성 | 모니터 포트 대역폭 초과 시 드롭, 스위치 부하 시 우선순위 낮음, 오류 프레임은 복사되지 않을 수 있음 | 설계상 누락이 적음 (단, 전이중 회선은 송·수신이 분리되어 나오는 경우가 많음) |
| 설정 변경 영향 | 스위치 설정 변경·실수에 영향받음 | 물리 설치 후에는 상대적으로 안정적 |
| 대표 용도 | 실습, 임시 분석, 소규모 구간 | 상시 관제 센서, 증거 수준의 수집 |
⚠️ SPAN·TAP 장비 운용 자체는 「04. 네트워크 장비 실습」 시리즈에서 다룹니다. 이 글에서는 "캡처 결과에 어떤 차이가 생기는가"만 봅니다.
2-4. 캡처는 반드시 권한이 있는 곳에서만
패킷에는 계정 정보, 메일 본문, 개인정보가 포함될 수 있습니다. 타인의 통신을 권한 없이 수집하면 법적 문제가 될 수 있으므로, 실습은 본인 소유 VM·실습망, 업무는 명시적으로 승인된 범위에서만 해야 합니다. 공용 Wi-Fi, 회사·학원 네트워크에서 임의로 캡처하지 않습니다. 샘플이 필요하면 공개 pcap(예: Wireshark SampleCaptures)을 활용합니다.
3. 동작 원리
리눅스에서 libpcap 기반 도구(tcpdump, dumpcap)가 패킷을 받는 흐름은 다음과 같습니다.
그림 1. 호스트·SPAN·TAP 캡처의 차이
[회선 / SPAN / TAP]
↓ 전기·광 신호
[NIC] ── 목적지 MAC 필터 (Promiscuous면 통과)
↓ DMA → 드라이버
[커널 네트워크 스택] ──→ 정상 처리 (IP → TCP/UDP → 소켓 → 애플리케이션)
│
└→ 패킷 소켓(AF_PACKET)으로 "복사본" 전달
↓ BPF 캡처 필터 (커널에서 먼저 걸러냄)
[libpcap 버퍼]
↓
[tcpdump / dumpcap] → 화면 출력 또는 .pcap/.pcapng 저장핵심은 세 가지입니다.
- 캡처는 원본을 가로채는 것이 아니라 복사본을 받습니다. 캡처가 통신을 막지는 않습니다.
- 캡처 필터(BPF)는 커널 단계에서 적용되므로, 걸러진 패킷은 나중에 복구할 수 없습니다. (3편에서 다룹니다.)
- 호스트 캡처는 NIC 오프로딩(TSO/GRO, 체크섬 오프로드) 영향을 받아, MTU보다 큰 패킷이 보이거나 송신 패킷 체크섬이 "incorrect"로 표시될 수 있습니다. 공격 징후가 아니라 캡처 위치의 특성입니다.
캡처 지점별로 보이는 것
| 캡처 지점 | 보이는 트래픽 | 주의점 |
|---|---|---|
| 서버 자신(호스트 캡처) | 해당 서버 송수신 트래픽 | 오프로딩 영향, 서버가 침해되면 캡처 자체를 신뢰하기 어려움 |
| 스위치 SPAN 포트 | 지정한 포트/VLAN 전체 | 드롭 가능, 설정 범위 밖은 안 보임 |
| 인터넷 경계(방화벽 바깥) | NAT 이후 공인 IP 기준 트래픽 | 내부 사설 IP가 보이지 않음 |
| 인터넷 경계(방화벽 안쪽) | NAT 이전 내부 IP 기준 트래픽 | 방화벽에서 차단된 외부 트래픽은 안 보임 |
| 가상화 vSwitch | 같은 가상 스위치의 VM 트래픽 | 하이퍼바이저 보안 정책(Promiscuous 허용 여부)에 좌우됨 |
같은 사건도 방화벽 안쪽은 사설 IP, 바깥쪽은 공인 IP로 찍힙니다. (NAT는 05. 사설 IP · 공인 IP와 NAT 참고)
4. 실제 명령어 / 실습
실습 환경: 본인 소유 Linux VM (Rocky Linux 또는 Ubuntu). 인터페이스 이름은 ens33을 예시로 사용합니다. 본인 환경의 이름은 ip link로 확인하세요.
4-1. 도구 설치
# Rocky Linux 9 (GUI: AppStream의 wireshark, CLI 도구: wireshark-cli)
sudo dnf install tcpdump wireshark wireshark-cli
# Ubuntu
sudo apt install tcpdump wireshark tshark패키지 이름은 배포판 버전에 따라 다를 수 있으므로 dnf search wireshark 또는 apt search wireshark로 먼저 확인하는 것을 권장합니다.
4-2. 캡처 가능한 인터페이스 확인
ip -br link # 인터페이스 목록과 상태
sudo tcpdump -D # tcpdump가 캡처 가능한 인터페이스 목록4-3. Promiscuous 상태 확인
# promiscuity 카운터 확인 (0이면 비활성)
ip -d link show ens33 | grep -o 'promiscuity [0-9]*'
# 캡처 시작 (기본적으로 promiscuous 모드로 캡처 시도)
sudo tcpdump -i ens33 -nn -c 20
# 다른 터미널에서, 캡처 중 카운터와 커널 메시지 확인
ip -d link show ens33 | grep -o 'promiscuity [0-9]*'
sudo journalctl -k | grep -i promiscuous리눅스의 libpcap은 인터페이스 플래그 대신 패킷 소켓 멤버십으로 Promiscuous를 설정하는 경우가 많아, ip link 출력에 PROMISC 플래그가 안 보여도 promiscuity 카운터와 커널 메시지(entered promiscuous mode)로 확인할 수 있습니다.
Promiscuous 모드 없이 캡처하려면 tcpdump에 -p 옵션을 붙입니다.
📷 [실습 화면 삽입] 캡처 전후
ip -d link show ens33의 promiscuity 값 변화와journalctl -k의 promiscuous 메시지
4-4. 오프로딩 설정 확인
sudo ethtool -k ens33 | grep -E 'segmentation-offload|receive-offload|checksum'ethtool이 없으면 sudo dnf install ethtool / sudo apt install ethtool로 설치합니다. 오프로딩 설정 변경은 성능에 영향을 주므로 운영 서버가 아닌 실습 VM에서만 다룹니다.
📷 [실습 화면 삽입]
ethtool -k ens33결과 중 offload 관련 항목
5. 결과 확인
형식 예시(값은 환경마다 다름):
$ ip -d link show ens33 | grep -o 'promiscuity [0-9]*'
promiscuity 1
$ sudo journalctl -k | grep -i promiscuous
... kernel: ens33: entered promiscuous mode
... kernel: ens33: left promiscuous mode
(커널 버전에 따라 "device ens33 entered promiscuous mode" 형태로도 출력)$ sudo tcpdump -i ens33 -nn -c 3
listening on ens33, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:00:01.100000 IP 192.168.10.20.52344 > 192.168.10.10.22: Flags [P.], ...
10:00:01.100500 IP 192.168.10.10.22 > 192.168.10.20.52344: Flags [.], ...
10:00:01.300000 ARP, Request who-has 192.168.10.1 tell 192.168.10.30, length 46
3 packets captured- 캡처 대상 인터페이스 이름을
ip -br link로 확인했다 - 캡처 중
promiscuity값이 증가하고, 종료 후 원래대로 돌아오는 것을 확인했다 - 커널 로그에서
entered/left promiscuous mode메시지를 확인했다 - 스위치(또는 가상 스위치) 환경에서 다른 호스트 간 유니캐스트가 보이지 않는 이유를 설명할 수 있다
- 캡처가 허용된 범위(본인 실습망)에서만 수행했다
6. 패킷 / 로그 분석
캡처 결과를 해석할 때 "보이지 않음"과 "이상함"을 캡처 위치와 연결해 판단해야 합니다.
| 관찰 | 정상일 수 있는 경우 | 의심해야 하는 경우 |
|---|---|---|
| 다른 호스트 간 통신이 안 보임 | 스위치 환경에서 SPAN 없이 호스트 캡처 | SPAN을 설정했는데도 안 보임 → 미러링 범위·VLAN 설정 확인 |
| 송신 패킷 체크섬 오류 표시 | 체크섬 오프로드로 NIC가 나중에 계산 | 수신 패킷, 또는 SPAN/TAP 캡처에서 반복되는 체크섬 오류 |
| MTU(1500)보다 큰 TCP 세그먼트 | 호스트 캡처 + TSO/GRO | SPAN/TAP 캡처인데 비정상 크기 반복 |
캡처하지 않았는데 entered promiscuous mode 로그 | 관리자가 승인된 점검 수행 | 계획에 없는 캡처 → 스니퍼 설치 가능성 |
| 서버의 promiscuity 값이 계속 1 이상 | IDS 센서·모니터링 에이전트가 상주 | 해당 서버에 캡처 도구가 설치될 이유가 없음 |
마지막 두 항목은 침해된 서버에 설치된 스니퍼를 찾는 단서가 될 수 있습니다.
# promiscuous 모드 진입 기록 확인
sudo journalctl -k --since "7 days ago" | grep -i promiscuous
# 캡처 관련 프로세스 확인
ps -ef | grep -Ei 'tcpdump|dumpcap|tshark' | grep -v grep패킷 소켓을 연 프로세스는 16. 프로세스와 네트워크 소켓의 방식처럼 ss -p 계열로도 점검할 수 있습니다. (ss -0p는 패킷 소켓을 표시합니다.)
7. 보안관제 관점
- 센서 위치가 곧 가시성입니다. 관제 센터의 IDS·NDR 센서는 대부분 SPAN이나 TAP에 연결되어 있으며, 어떤 구간을 보고 있는지 모르면 "탐지 없음"을 "공격 없음"으로 오해하게 됩니다.
- 흔적이 남는 곳: 캡처 도구 실행은 커널 로그(
entered promiscuous mode), 프로세스 목록, 감사 로그(auditd를 설정한 경우)에 흔적을 남길 수 있습니다. 원격 Syslog로 수집하면 서버가 침해돼도 기록을 보존할 수 있습니다. (36. 원격 Syslog와 중앙 로그 서버) - 한계: SPAN 드롭, 암호화 트래픽(TLS), 캡처 호스트의 시간 오차 때문에 pcap도 완전하지 않습니다. 시간 동기화는 17. NTP와 로그 시간 동기화를 참고하세요.
- 오탐 주의: 모니터링 에이전트 등도 Promiscuous 모드를 쓸 수 있으므로 자산 목록과 대조합니다.
- 센서 배치 설계, IDS 연동은 「06. 방화벽 · IDS/IPS 분석」, 「07. 네트워크 보안관제 통합 분석」 시리즈에서 다룹니다.
8. 핵심 정리
- 캡처는 커널이 전달하는 복사본을 받는 것이며, 캡처 필터는 커널 단계에서 적용됩니다.
- Promiscuous 모드는 NIC에 도착한 프레임을 버리지 않을 뿐, 스위치 환경에서 남의 트래픽을 끌어오지 못합니다.
- 다른 호스트의 트래픽은 SPAN(설정 기반, 드롭 가능) 또는 TAP(물리 장비, 누락 적음)으로 가져옵니다.
- 호스트 캡처는 오프로딩 때문에 체크섬 오류·큰 패킷이 보일 수 있으며, 이는 캡처 위치의 특성입니다.
- 계획에 없는
entered promiscuous mode로그는 스니퍼 설치 단서가 될 수 있습니다. - 캡처는 본인 실습망 또는 승인된 범위에서만 수행합니다.
