[SK 쉴더스 루키즈] 네트워크 - ARP, Wireshark, tshark

Ethernet Frame

DIX가 Ethernet을 만들었고 → IEEE가 이를 표준화하면서 MAC(802.3)/LLC(802.2)로 나눴지만 → 실제 인터넷에선 단순한 DIX 방식(Ethernet II)이 살아남았다.

1. Ethernet Frame(DIX 2.0)

Type

• SAP(뒤에 data에 뭐 싣고 가는지 명시)
  • 0x0800 -> IP
  • 0x0806 -> ARP
  • 0x86DD -> IPv6

Data

• mTU: 46+18 = 64 → 충돌을 감지할 수 있는 최소영역(동축케이블 기준)
• MTU: 1500 ⇒ 실제전송 1518

ethernet frame은 endpoint에서 만들어낸 프레임이다.(보통 type을 달고 옴)

 

 

2. IEEE

 

IEEE는 len

 

• MAC(IEEE 802.3) → 프레임을 만듦
  1. 누구에게 보낼지(IP -> MAC 변환. ARP)
  2. 프레임 형식 만들기(Ethernet II / IEEE 802.3) + 헤더 붙이기
  3. 매체 접근 방식(e.g. CSMA/CD)
  4. 실제 전송 단위(패킷 -> 프레임으로 캡슐화)
• LLC(IEEE 802.2) → “프레임 안 데이터를 보고, 어떤 상위 프로토콜로 넘길지 결정하는 역할”
  • 프레임이 도착했다고 가정  >  [Dst MAC][Src MAC][Data]
    이 프레임이 포함하고 있는 상위 계층이 IP일수도, ARP일수도, 다른 프로토콜일 수도..
    => 그래서 상위 프로토콜을 식별할 얘가 필요함(=LLC)

하나의 LLC 위에 여러 MAC을 붙일 수 있음

┌─────────────────────┐
│   LLC (IEEE 802.2)  │  ← 상위 계층(IP, ARP 등)과 인터페이스
├─────────────────────┤
│   MAC (IEEE 802.3)  │  ← 실제 매체(케이블, 무선)와 통신
└─────────────────────┘

 

LLC가 공통 인터페이스 역할을 함.

        IP / ARP / IPv6      ← 상위 계층은 LLC만 알면 됨
               ↑
            LLC (802.2)      ← 공통 통역사
        ┌──────┼──────┐
      Ethernet  Wi-Fi  기타  ← 매체별로 다른 MAC
        (MAC)   (MAC)

 

IP 입장:
"나는 그냥 LLC한테 '이거 보내줘'라고만 하면 돼. 밑에 이더넷이 있든 Wi-Fi가 있든 나는 모름. 알 필요도 없음."
=> "상위 계층은 MAC 종류 몰라도 됨". 추상화(abstraction)라고도 함.

 

정리

DIX Ethernet II

- 역할: MAC + LLC를 나누지 않고 하나의 계층에서 처리

- LLC 없이 MAC 헤더에 EtherType이라는 2바이트 필드를 직접 넣어서 상위 프로토콜을 구분

- 현재 인터넷 표준으로 사용 중

• 0x0800 → IPv4
• 0x0806 → ARP
• 0x86DD → IPv6

 

IEEE
MAC (Media Access Control) — IEEE 802.3

- 역할: 물리적 주소(MAC 주소) 관리, 프레임 송수신, 충돌 처리(CSMA/CD)

- 위치: Data Link Layer 하위 서브레이어

 

 

LLC (Logical Link Control) — IEEE 802.2

- 역할: 상위 프로토콜 식별, 흐름/오류 제어

- 위치: Data Link Layer 상위 서브레이어

 

 

IEEE 방식 → MAC / LLC 두 계층으로 명확히 분리

DIX 방식 → 구분 없이 Type 필드 하나로 해결 (더 단순)

 

ARP

3계층 프로토콜

DIX에서 type: 0x0806→ arp싣고 가고 있어.

 

송 MAC, 수 MAC(FFFFF)→ 브로드. ARP request
송 MAC, 수 MAC→ 유니. ARP reply

Hardware Type: L2계층

Protocol Type: L3계층

 

ARP 동작 원리 정리

기본 전제

• 스위치/허브는 브로드캐스트 패킷을 받으면 flooding (전체 포트로 전달)
• 패킷을 받은 PC는 역캡슐화해서 내용 확인
• ARP Cache Table은 Aging Time 존재 → 일정 시간 동안 통신 없으면 자동 삭제
• ARP 패킷을 받으면 Cache Table에 있는 송신지 정보 업데이트 + Aging Time 초기화

 

1.10 -> 1.20 요청이 가야 하는 상황. 같은 망에 1.30도 있다.

Case 1 — 목적지가 아닌 PC가 받았을 때 (1.10 → 1.30)

상황	Cache Table 업데이트	ARP Reply
송신지 주소(1.10)가 이미 있음	✅ 업데이트	❌
송신지 주소가 없음	❌	❌

 

Case 2 — 목적지 PC가 받았을 때 (1.10 → 1.20)

• 송신지(1.10)의 MAC 주소를 신규로 Cache Table에 등록
• ARP Reply 전송 ✅
• Reply를 보내야 하니까, 상대방 MAC을 미리 기록해두는 것

상황	Cache Table 업데이트	ARP Reply
송신지 주소(1.10)가 이미 있음	✅ 업데이트	✅
송신지 주소가 없음	✅ 신규 등록	✅

 

보안 이슈 — ARP Spoofing / ARP Redirection

ARP Request를 보낸 적 없는데 ARP Reply가 왔다 → Cache Table에 저장됨

ARP는 Reply의 출처를 검증하지 않기 때문에, 공격자가 조작된 Reply를 보내면 피해자의 Cache Table이 덮어씌워진다.

이를 악용한 공격:

• ARP Spoofing → 특정 IP에 대한 MAC을 공격자 MAC으로 위조 → 트래픽 가로채기
• ARP Redirection → 게이트웨이 MAC을 위조 → 모든 외부 트래픽을 공격자에게 유도

 

실습

내가 나한테 보내는 arp 요청? 비정상적인 요청인가? -> ㄴㄴ

PC 전원 ON
    ↓
"목적지 IP = 나 자신(1.10), 누구 MAC이야?" 브로드캐스트
    ↓
스위치가 flooding → 모든 PC에 전달
    ↓
받은 PC들: "아 1.10은 저 MAC이구나" → ARP Cache Table 업데이트

Reply를 기다리는 게 아니라, "나 켜졌어, MAC 이거야" 를 알리는 announcement가 목적. (GARP라고 함)

 

일반 ARP vs Gratuitous ARP

	일반 ARP	Gratuitous ARP
목적	상대방 MAC 주소 알아내기	내 존재를 네트워크에 알리기
Reply 기대	✅	❌ (Reply 안 받아도 됨)
목적지 IP	알고 싶은 상대 IP	자기 자신의 IP

 

부수 효과

• IP 충돌 감지 → 같은 IP를 쓰는 PC가 있으면 Reply가 옴 → 충돌 감지 가능

 

Wireshark 실습

1. Slowloris 공격

0d 0a -> \r\n

0d 0a가 두 개이다. -> header가 끝났다.

 

 

헤더가 안 끝난 것을 악용한 공격 -> Slowloris 공격

서버는 빈 줄(\r\n\r\n)이 올 때까지 헤더가 끝나지 않은 것으로 판단하고 연결을 유지한다.

공격자 → 서버: "GET / HTTP/1.1\r\n"
공격자 → 서버: "Host: target.com\r\n"
공격자 → 서버: "X-a: b\r\n"          ← 의미없는 헤더 계속 추가
공격자 → 서버: "X-a: b\r\n"          ← \r\n\r\n은 절대 안 보냄
공격자 → 서버: "X-a: b\r\n"          ← 연결 유지...
         (수백 개의 연결을 동시에)

 

1. 수백 개의 연결을 열어놓음
2. 각 연결마다 헤더를 조금씩, 천천히 전송
3. 마지막 \r\n\r\n은 절대 보내지 않음
4. 서버는 모든 연결을 열린 채로 유지
5. 서버의 최대 동시 연결 수 고갈 → 정상 사용자 접속 불가

 

2. 302 후 200 패킷 실행 흐름 파악

[전체 흐름 요약]

1. DNS 조회
172.16.0.122 → 4.2.2.1(dns 서버)
: 도메인 IP 요청

2. DNS 응답
4.2.2.1 → 172.16.0.122
: IP 주소 받음

3-5. 첫 번째 서버 연결 (199.181.132.250)
SYN      : 연결 요청
SYN, ACK : 서버 응답
ACK      : 연결 완료
→ TCP 3-way handshake 완료

6. HTTP 요청
GET / HTTP/1.1
: 웹 페이지 요청

7. 서버 응답 (리다이렉트)
HTTP 301 Moved Permanently
: 다른 주소로 이동하라고 안내(url을 받았겠지?)

 

8. 일단 먼저 리다이렉트 응답을 잘 받았다고 서버에 응답(ACK)

9. DNS 재조회 (리다이렉트된 주소의 ip가 뭔지 알려달라!)
172.16.0.122 → 4.2.2.1 (7에서 받은 url의 ip 뭐니)
: 새 도메인 IP 요청

10. DNS 응답
4.2.2.1 → 172.16.0.122
: 새 IP 받음 (68.71.208.11)

11-13. 두 번째 서버(찐 서버) 연결 (68.71.208.11)
SYN      : 연결 요청
SYN, ACK : 서버 응답
ACK      : 연결 완료
→ TCP 3-way handshake 완료

14. HTTP 요청
GET / HTTP/1.1
: 페이지 요청

15. 최종 응답
HTTP 200 OK
: 정상 페이지 수신

[핵심 요약]
DNS → 서버1 접속 → 301 리다이렉트
→ DNS 재조회 → 서버2 접속 → 200 OK
= 최종 페이지 정상 수신

 

3. 와이어샤크 GUI 옵션들

프로토콜 설정

1. Allow subdissector to reassemble TCP streams

TCP로 쪼개진 데이터를 다시 하나로 합쳐서 보여주는 기능

 

왜 필요하냐?

TCP는 데이터를 이렇게 보내기 때문.

[패킷1] "GET / HT"
[패킷2] "TP/1.1\r\n"
[패킷3] "Host: ..."

-> 실제로는 하나의 HTTP 요청인데
->  여러 패킷으로 쪼개짐

그래서 옵션 ON하면, Wireshark가 재조립해서 보여줌

GET / HTTP/1.1
Host: ...

->  사람이 보기 편함

 

 

2. Analyze TCP sequence numbers

TCP 흐름(순서, 재전송, 손실)을 분석해줌

이 옵션 켜면:
Retransmission (재전송)
Lost segment (손실)
Out-of-order (순서 꼬임)

자동 표시됨

 

e.g.

[TCP Retransmission]
[TCP Out-Of-Order]
[TCP Dup ACK]

 

네트워크 인터페이스

Wireshark 목록에 뜨는:

• 로컬 영역 연결
• 이더넷
• Wi-Fi
• vEthernet
• VirtualBox Host-Only
• Loopback

이건 전부: “패킷을 캡처할 수 있는 네트워크 인터페이스”

 

Resolve

편집 → Name Resolution

Resolve 선택 > 숫자들을 문자로 보여준다.

80 → http(80), ip→ url로 변환해서 보여주는 식

 

캡쳐 필터

캡쳐>캡쳐 필터: 필터를 만든다.

기본 페이지로 들어오면 방금 만든 필터를 선택할 수 있다.

캡처 필터  - 주소 기반의 트래픽 수집

1. 특정 ip 주소의 트래픽 수집

•  host 10.3.1.1 -> 송/수신지 주소가 이것인 것 찾기
• host 2406:da00:ff00::6b16:f02d -> ipv6주소
• not host 10.3.1.1 -> 이거 제외
• src host 10.3.1.1 -> 송신지 주소가 이것인 것
• dst host 10.3.1.1 -> 수신지 주소가 이것인 것
• host 10.3.1.1 or host 10.3.1.2 
• host http://www.espn.com

host 명령어는 딱 하나의 IP만 지정할 때 사용!!

 

 

2. ip 주소 범위 트래픽 수집

• net 10.3.0.0/16
• net 10.3.0.0 mask 255.255.0.0
• ipv6 net 2406:da00:ff00::/64
• not dst net 10.3.0.0/16
• dst net 10.3.0.0/16
• src net 10.3.0.0/16

10.3.0.0/16 → 10.3.0.1~10.3.255.255
→ src net 10.3.0.0/16 이면 ~10.3.255.254 까지.
→ src 자리이기 때문에 브로드 캐스트 주소가 올 수 없기 때문
→ dst net 10.3.0.0/16 이면 ~10.3.255.255 까지.

 

 

3. 브로드캐스트 또는 멀티캐스트 트래픽 수집

• ip broadcast
• ip multicast -> 멀티캐스트 패킷만 수집
• dst host ff02::1
• dst host ff02::2

 

 

4. MAC 주소 기반의 트래픽 수집

• ether host 00:08:15:00:08:15
• ether src 00:08:15:00:08:15
• ether dst 00:08:15:00:08:15
• not ether host 00:08:15:00:08:15

 

 

5. 특정 애플리케이션에 대한 트래픽 수집

• port 53

• not port 53

• udp port 67

• potrange 1-80

• tcp portrange 1-80

• port 20 or port 21

• host 10.3.1.1 and port 80

• host 10.3.1.1 and not port 80

• udp src port 68 and udp dst port 67

 

Display Filter (디스플레이 필터)

이미 캡처된 것 중에서 “보여주는 것만” 필터링

- arp

- ip

- ipv6

- tcp

 

3whs 1단계 패킷만 보여달라

tcp.flags.syn == 1 && tcp.flags.ack == 0

 

 

필터로 준비 > 필터창에 적혀짐

필터로 적용 > 바로 적용되어서 화면에 보여짐.

 

window size zero: 송신하지 마라. 나 버퍼 꽉 찼다.

 

keep alive: 재개하자

seq = ack -1 ??       →>>>>>>>>>> keep alive

 

손실 후 재전송

cumulative ack. 중복 ack 3개면 빠른 재전송.

검정색으로 떴다고 해서 항상 위험한 것은 아니다!

 

패킷 색상화

 

FTP

• active mode
  • port 20, 21번
• passive mode
  • 요즘엔 이걸 씀
  • 20번 데이터 채널 안 씀
  • 데이터 채널 보내는 방향이 다르다.

 

 

Active는 서버 → 클라이언트로 “역접속”해야 해서 막히기 쉽고, Passive는 클라이언트가 다 열어서 더 안전하고 잘 된다

 

tshark

 

 

gui보다 cui가 패킷 수집율이 훨씬 높다.

 

 

 

 

tshark -i 3 -a files:3 -b duration:10 -w myshark.pcapng

10초 마다 파일 1개 생성. 그렇게 3개 파일 생성 후 자동 종료

 

파일 읽기

tshark.exe -r filename.pcapng

tcp.analysis.flags ⇒ 전문가 분석기에 나와있는 정보. tcp field에는 없음

 

 

자동으로 새 파일 생성하기

캡처 > 옵션

자동으로 새 파일 생성하기> 체크

조건이 충족되면 자동으로 파일을 만들어라!

링 버퍼 파일 개수: 최대 만들 수 있는 파일 개수

몇 개 이상 모이면 캡쳐 그만 해라.

 

4. 사용 목적에 맞게 프로그램 분리

패킷 분석을 위해선 우선 패킷 수집을 먼저해야 한다.

1. 패킷 수집

- 와이어샤크는 GUI라 놓치는 패킷이 있을 수 있다.

- 그래서 수집은 CUI 툴(TCP dump)을 이용해서 한다.

 

2. 패킷 분석

- 이걸 와이어샤크로 한다.

 

 

5. 환경에 따른 보안 관제

관제 범위 = visibility window

 

허브 환경

허브는 패킷이 들어오면 무조건 flooding을 하기 때문에 sniffer(관제pc)로 모든 패킷을 다 감시할 수 있다.

 

스위치 환경

스위치는 브로드캐스트 요청으로 인한 flooding 패킷이 아닌 이상 sniffer이 패킷을 받아볼 수가 없다.

=> 그래서 해결책(==관제 범위를 넓히는 방법)

 

1. 포트 미러링

관제사가 스위치 담당자에게 요구해야 함

같은 스위치 환경이 아니어도 가능함

 

2. 허빙 아웃

스위치 밑에 허브를 달아 놓는다.

그럼 허브는 무조건 모든 포트로 브로드캐스트(플러딩)하기 때문에 관제사가 패킷을 받아볼 수 있다.

 

3. Aggregated 탭 [가장 많이 이용]

A->B / B->A 패킷을 TAP이 모아서 sniffer한테 전달해준다.

 

    (양방향 트래픽)
        A ⇄ B

   [Switch] ── A
                 \
                  \ 
                 [ TAP ] ── 1 ── [Sniffer]
                  /
                 /
   [Target] ── B

 

스위치 환경인데 스위치를 허브처럼 만드는 공격: mac flooding attack

공격

 

• 스위치에 가짜 MAC 주소를 엄청 많이 보냄
• MAC 테이블(CAM Table) 꽉 채움

 

결과

스위치가 MAC 학습 못 함 -> 모든 트래픽을 flooding (허브처럼 동작)