1. L2 보안 기본기 - 스위치 레벨에서 벌어지는 전쟁

네트워크 보안을 이야기할 때 우리는 보통 밖에서 들어오는 공격을 먼저 떠올립니다. 인터넷에서 회사 네트워크로 들어오는 스캔, 악성 트래픽, 외부 침입 시도 — 이런 것들을 막으려고 라우터에 ACL을 걸고, 경계에 방화벽을 놓고, IPS를 붙입니다.

그런데 보안 사고의 또 다른 큰 축이 있습니다. 이미 네트워크 안에 들어와 있는 호스트끼리 벌어지는 문제입니다. 직원이 무심코 꽂은 가정용 공유기가 부서 전체에 가짜 IP를 뿌리는 사고, 같은 VLAN 안에서 누군가 “내가 게이트웨이다”라고 거짓말해서 다른 직원의 트래픽을 가로채는 공격, 불법으로 꽂힌 스위치가 STP 루트를 가로채는 시나리오 — 이런 일들은 라우터까지 올라가지도 않습니다. 같은 스위치 안쪽에서 시작하고 끝나거든요. 그래서 라우터의 ACL이나 방화벽 룰로는 손도 못 댑니다.

이 공백을 메우는 기술이 바로 L2 보안입니다. 스위치 안쪽 — 즉 같은 VLAN의 호스트들 사이에서 벌어지는 ARP 스푸핑, DHCP 고갈, MAC flooding, STP 탈취, VLAN Hopping 같은 공격을 스위치 자체가 인지하고 차단하도록 만드는 기능들의 묶음이죠.

2. Port Security - MAC 기반 포트 제한

Port Security란 무엇인가?

가장 오래되고 가장 기본적인 L2 통제 기능입니다. 개념은 아주 단순합니다.

“이 포트에는 정해진 MAC 주소만 들어올 수 있다”

회사 출입증에 비유하면, 한 자리에 앉는 직원의 얼굴을 미리 등록해두고 그 사람 외에는 앉지 못하게 하는 것과 같습니다. 다른 사람이 그 자리에 앉으려고 하면? 경보가 울리고 자리를 봉쇄합니다.

위반 모드 - 세 가지 선택지

위반이 발생했을 때 어떻게 반응할지 세 가지 모드 중에 고를 수 있습니다.

“세 개 중에 뭘 쓰는 게 좋아요?”라고 물으시면, 현업에서는 restrict를 가장 많이 권장 합니다. 이유가 있습니다.

• shutdown은 너무 과격합니다. 사용자가 실수로 PC 한 대 더 꽂았다고 포트가 내려가면 콜센터가 울리기 시작합니다. “왜 내 네트워크 안 돼요!” 전화가 쏟아지죠.
• protect는 너무 조용합니다. 위반이 일어나도 로그도, 알림도 없습니다. 관제센터 입장에서 “아무 일 없었던 것처럼” 보이니 공격을 탐지할 방법이 사라집니다.
• restrict는 딱 적당합니다. 위반 프레임은 막되, 로그와 SNMP trap으로 “뭔가 일어나고 있다”고 알려줍니다. 포트는 살아있으니 정상 사용자 업무에는 지장이 없고요.

Port Security의 한 가지 진실

Port Security는 아주 강력하지만, 한 가지 명확한 한계가 있습니다. 이 기능은 “어떤 MAC이 포트에 붙었나” 만 봅니다. 그 이상의 컨텍스트 — IP, ARP, DHCP, BPDU, 페이로드 — 는 일절 검사하지 않습니다.

“그게 왜 문제인데요?”라고 물으실 수 있습니다. 몇 가지 시나리오를 던져드릴 테니 하나씩 같이 생각해봅시다. 그리고 각 시나리오를 막아주는 기능을 이어서 하나씩 배워볼게요. 각 시나리오 끝에는 GNS3에서 직접 공격과 방어를 재현하는 랩이 따라옵니다.

3. 실습 환경 준비

본편의 모든 시나리오는 하나의 공통 토폴로지 에서 진행됩니다. 매번 그림을 새로 그리지 않고, 공격자 역할만 바꿔가면서 시연하는 방식입니다.

공통 토폴로지

                    [R1] (합법 DHCP 서버 + 게이트웨이)
                    10.10.10.1
                       │ Gi0/0
                       │
                       │ (업링크, 나중에 trust 포트)
                       ▼
                ┌──────────────┐
                │     SW1      │  ← L2 보안 기능 장착 대상
                └──┬──┬──┬─────┘
              Gi0/1 Gi0/2 Gi0/3
                  │   │    │
              [PC1][PC2][R-ATK]
              VPCS VPCS 공격자 역할(상황마다 설정 변경)

💡 공격자 장비 선택: 원래 공격 시연에는 Kali Linux나 Ubuntu 같은 공격 도구가 있는 장비를 쓰지만, GNS3에서 도커 이미지 호환성 문제가 자주 발생합니다. 이번 랩에서는 두 번째 Cisco 라우터(R-ATK)를 공격자 자리에 배치 하는 방식으로 진행합니다. 현업에서 Rogue DHCP 사고의 주 원인도 “직원이 꽂은 가정용 공유기”라는 점을 생각하면, 라우터로 시연하는 것도 전혀 부자연스럽지 않습니다.

초기에는 R-ATK 없이 R1·SW1·PC1·PC2 만 연결해 베이스라인을 잡고, 시나리오 ①부터 R-ATK를 Gi0/3에 추가합니다.

R-ATK가 추가되면 노드 정보에서 Gi0/0이 SW1 Gi0/3에 연결, MAC = 0c:9c:85:9f:00:00 으로 잡혀 있는지 확인합니다. 이 MAC은 이후 SW1 로그에서 공격자 식별자로 계속 등장합니다.

IP 계획

초기 설정

R1 - 합법 DHCP 서버

enable
configure terminal
hostname R1
no ip domain-lookup
!
interface GigabitEthernet0/0
 description to-SW1
 ip address 10.10.10.1 255.255.255.0
 no shutdown
!
ip dhcp excluded-address 10.10.10.1 10.10.10.99
ip dhcp excluded-address 10.10.10.200 10.10.10.254
!
ip dhcp pool LAN
 network 10.10.10.0 255.255.255.0
 default-router 10.10.10.1
 dns-server 8.8.8.8
 lease 1
!
end
write memory

SW1 - 기본 액세스 스위치 + Port Security 베이스라인

Port Security는 모든 시나리오의 기본 방어선입니다. 여기서 한 번 걸어두면 이후 랩들은 이 상태에서 시작합니다.

enable
configure terminal
hostname SW1
no ip domain-lookup
!
vlan 10
 name USER
!
interface range GigabitEthernet0/0 - 3
 switchport
 switchport mode access
 switchport access vlan 10
 no shutdown
!
! Port Security 베이스라인 (사용자 포트에만)
interface range GigabitEthernet0/1 - 3
 switchport port-security
 switchport port-security maximum 2
 switchport port-security mac-address sticky
 switchport port-security violation restrict
!
end
write memory

각 Port Security 옵션의 의미:

• maximum 2: “이 포트에는 최대 2개의 MAC만 학습해라”
• mac-address sticky: “한 번 학습한 MAC은 설정 파일에 고정해서 기억해라”
• violation restrict: “규칙 위반하면 프레임은 드롭하되 로그를 남겨라” (포트는 살려둠)

📎 왜 1이 아니라 2인가

maximum 2는 IP 폰 + PC 데이지체인 같은 표준 구조를 흡수하기 위한 의도적 여유입니다. 시스코·아바야 IP 폰은 LLDP-MED로 Voice VLAN을 분리하면서 PC 트래픽을 그대로 통과시키므로 한 포트에 2개 MAC이 정상이에요.

한 가지 주의 — 허브나 미관리형 5포트 스위치는 의도적으로 막아야 할 대상입니다. 우연히 max 2 안에 들어와도 정책상 허용 대상이 아니에요. 이런 비인가 장비는 BPDU Guard(트렁크 BPDU 감지)나 LLDP 기반 자산 인벤토리로 별도 탐지하는 게 정석입니다.

PC1, PC2 - DHCP로 IP 받기

PC1> ip dhcp
PC2> ip dhcp

베이스라인 확인

PC1에서:

ping 10.10.10.1       # 게이트웨이 OK
ping 10.10.10.101     # PC2 OK

여기까지 되면 준비 완료입니다. 이제 공격자(R-ATK)를 Gi0/3에 연결하고 시나리오별 시연을 시작합니다.

4. 시나리오 ① - 가짜 DHCP 서버가 들어오면?

공격 상황

자, 이런 상황을 상상해봅시다.

“회사 사무실 액세스 스위치의 한 포트(예: Fa0/5)에 공격자 PC가 꽂혔습니다. Port Security는 정상적으로 통과했습니다(MAC이 허용 목록에 등록됨). 그런데 이 PC가 같은 VLAN에 있는 다른 직원들에게 몰래 DHCP 서버 역할을 하면서 ‘게이트웨이는 내 IP야, DNS도 내 IP야’라고 잘못된 정보를 뿌린다면요? 스위치의 Port Security가 이걸 막아줄 수 있을까요?”

결론부터 말씀드리면 못 막습니다. Port Security는 패킷 안에 DHCPOFFER가 들어있는지 쳐다보지도 않거든요. MAC만 허용 목록에 있으면 “네, 통과”입니다.

실제 사례 - 2014년 브라질 가정 공유기 DNS 하이재킹

이게 얼마나 실제로 자주 일어나는 일인지 감을 잡으시라고, Kaspersky가 2014년에 분석해 발표한 브라질 대규모 은행 피싱 캠페인을 소개해드립니다. 공격 흐름을 따라가 봅시다.

1. 피해자가 악성 웹사이트를 방문합니다 (평범한 스팸 링크입니다)
2. 웹사이트의 자바스크립트가 피해자 집 공유기의 관리자 페이지 를 몰래 자동 공격합니다
   • admin:admin, admin:1234 같은 기본 자격증명을 무차별 시도
3. 공유기 로그인에 성공하면, 공유기 DHCP가 배포하는 DNS 서버 주소 를 공격자 DNS로 바꿔버립니다
4. 이제 집 안의 모든 장비(PC, 폰, 태블릿)가 피해자가 bancodobrasil.com.br(브라질 최대 은행) 같은 사이트에 접속하면:
   • DNS 조회 → 공격자 DNS → “은행 IP는 여기야” (거짓말, 공격자 서버 IP 반환)
   • 피해자는 픽셀 단위로 똑같이 생긴 가짜 은행 페이지 에 도달
   • ID/PW/OTP 입력 → 계정 탈취 완료

무서운 점은 이겁니다. 피해자 PC에는 악성코드가 단 하나도 설치되지 않습니다. 공유기 한 대만 조작하면 OS와 디바이스에 상관없이 집 안 모두가 피해를 봅니다.

출처: Web-based attack targeting home routers, the Brazilian way - Kaspersky Securelist (2014) 

브라질 사례는 가정 공유기 가 타깃이었지만, 같은 메커니즘을 기업 LAN에 옮기면 오히려 더 쉽습니다. 공격자 PC가 LAN에 꽂히기만 하면 dnsmasq 한 줄이면 끝이죠. 심지어 악의 없이도 터집니다. 직원이 집에서 쓰던 iptime 공유기를 회사 LAN 포트에 무심코 연결한 순간, 공유기 DHCP가 부서 전체에 엉뚱한 IP를 뿌려대는 사고. 이게 현업에서 가장 흔한 Rogue DHCP 사고 입니다.

또 다른 변형 - DHCP Starvation 공격

Rogue DHCP와 자주 짝으로 등장하는 공격이 하나 더 있습니다. 이번엔 공격자가 가짜 DHCP 서버를 세우는 게 아니라, 반대로 합법 DHCP 서버의 IP 풀을 고갈시키는 공격입니다.

“공격자가 자신의 MAC은 고정한 채로(그래서 Port Security는 통과), DHCP 요청 패킷 안의 CHADDR(클라이언트 MAC) 필드만 매번 다르게 위조해서 초당 수백~수천 번씩 DHCPDISCOVER를 뿌려댑니다. 합법 DHCP 서버 입장에서는 ‘아, 새 클라이언트들이 엄청 많이 들어왔네?‘라며 IP를 하나씩 임대해줍니다. 몇 분 안에 DHCP 풀이 완전히 바닥나고, 그때부터는 진짜 직원이 출근해서 PC를 켜도 IP를 받지 못합니다.”

📎 CHADDR 이 뭔가요?

CHADDR (Client Hardware Address) 은 DHCP 메시지(RFC 2131) 안에 들어있는 16바이트 필드입니다. “이 요청을 보낸 클라이언트의 MAC 은 무엇인가” 를 담는 자리예요. DHCP 서버는 이 값을 보고 클라이언트를 식별하고 IP 를 발급합니다.

핵심은 이 CHADDR 이 이더넷 프레임의 src MAC 과 별개의 필드 라는 점입니다. 한 PC 가 자기 src MAC 은 그대로 둔 채 패킷 안의 CHADDR 만 매번 다르게 위조해서, 수천 개 클라이언트로 위장 할 수 있는 거죠.

┌─────────────────────────────────────────┐
│ Ethernet src: AA:BB:CC:DD:EE:FF  ←  공격자 본인 (Port Security 통과)
├─────────────────────────────────────────┤
│ IP / UDP 헤더                            │
├─────────────────────────────────────────┤
│ DHCP Message:                           │
│   ...                                   │
│   CHADDR: 00:11:22:33:44:01  ←  매번 위조  ★
│   ...                                   │
└─────────────────────────────────────────┘

DHCP Snooping 을 켜면 자동으로 활성화되는 옵션 중 Verification of hwaddr field is enabled 가 바로 이 두 MAC 의 일치 여부를 검증합니다. 안 맞으면 드롭. → DHCP Snooping 한 줄이 Starvation 방어까지 같이 해주는 이유.

이 공격은 두 가지로 활용됩니다:

1. 서비스 거부(DoS): 그냥 IP 풀을 말려 버려서 업무 마비
2. Rogue DHCP와 연계: 합법 서버가 IP를 못 주는 상황에서 공격자의 가짜 DHCP 서버가 대신 응답 → 피해자 설정 장악 성공률 급상승

Port Security는 이걸 막을 수 있을까요? 제한적 입니다. maximum 1로 걸어두면 프레임의 src MAC이 공격자 본인 것이니 한 개 MAC으로 취급돼 통과됩니다. 문제는 DHCP 요청 안쪽 CHADDR 필드가 매번 달라지는데, Port Security는 그 안까지 안 들여다보거든요.

해결책 - DHCP Snooping

이런 상황을 막기 위해 등장한 기능이 DHCP Snooping 입니다. 이름부터 해석하면 “DHCP를 엿본다(snoop)“는 뜻입니다. 스위치가 오가는 DHCP 메시지를 엿들으면서 합법과 불법을 판단합니다.

핵심은 포트를 두 종류로 나누는 것입니다.

• Trusted 포트: 합법 DHCP 서버로 향하는 업링크. 여기서 나오는 DHCPOFFER, DHCPACK는 통과시킵니다.
• Untrusted 포트: 일반 사용자 포트. 여기서 서버 응답이 나오면? “어? 사용자 PC가 DHCP 서버 행세를 한다고? 드롭!”

주요 옵션은 두 가지입니다:

• limit rate 10: 포트당 DHCP 패킷을 초당 10개로 제한. DHCP Starvation 공격(수천 개 요청으로 IP 풀 고갈)을 완화합니다.
• trust: 합법 DHCP 서버로 가는 업링크에만 설정. 기본값은 untrusted이므로 “신뢰할 포트만 명시적으로 지정” 하는 화이트리스트 방식입니다.

DHCP Snooping Binding Table - 진실의 원천

DHCP Snooping을 켜면 스위치가 자동으로 바인딩 테이블 을 만들기 시작합니다. 각 엔트리에는 MAC ↔ IP ↔ VLAN ↔ Interface ↔ Lease 정보가 담깁니다.

SW1# show ip dhcp snooping binding
MacAddress          IpAddress        Lease(sec)  Type           VLAN  Interface
------------------  ---------------  ----------  -------------  ----  --------------
00:11:22:33:44:55   192.168.10.100   86400       dhcp-snooping  10    Fa0/1

“이 테이블이 왜 중요하냐”면, 뒤에 나올 기능들이 이 테이블을 근거 자료로 쓰기 때문 입니다. 이 테이블은 L2 보안의 “진실의 원천(source of truth)” 역할을 합니다. 그래서 DHCP Snooping을 먼저 안정화한 뒤 다른 기능을 켜는 순서가 실무의 불문율입니다.

🔬 Lab ① - Rogue DHCP 직접 재현

Phase 1 - 방어 OFF 상태에서 공격 성공 재현

Step 1. R-ATK 설정 (공격자 DHCP 서버)

R-ATK 콘솔에서:

enable
configure terminal
hostname R-ATK
no ip domain-lookup
!
interface GigabitEthernet0/0
 description to-SW1-RogueDHCP
 ip address 10.10.10.200 255.255.255.0
 no shutdown
!
! 가짜 DHCP 풀 - 게이트웨이/DNS를 R-ATK 자신으로 배포
ip dhcp excluded-address 10.10.10.200
!
ip dhcp pool ROGUE
 network 10.10.10.0 255.255.255.0
 default-router 10.10.10.200     ! 가짜 게이트웨이 = 공격자
 dns-server 10.10.10.200          ! 가짜 DNS = 공격자
 lease 0 1
!
! 응답 속도 최대화 (ping 체크 스킵)
ip dhcp ping packets 0
!
end
write memory

Step 2. 합법 DHCP 서버 일시 중지

두 DHCP 서버가 동시에 떠 있으면 경쟁 상태가 되어 시연 결과가 복불복이 됩니다. 확실한 시연을 위해 R1의 DHCP를 잠시 끕니다.

💡 현실 대응: 실제 공격에서는 공격자가 DHCP Starvation으로 합법 서버의 풀을 고갈시킨 뒤 Rogue DHCP로 응답을 가로챕니다. 우리 랩에서는 시연 편의를 위해 R1 DHCP를 일시 정지하지만, 본질적으로 같은 결과(합법 서버가 응답 못 하는 상태)를 만드는 것입니다.

R1에서:

configure terminal
no service dhcp
end

Step 3. PC2에서 DHCP 재요청

PC2 콘솔:

ip dhcp -r        # 기존 임대 해제
ip dhcp           # 새로 DHCP 요청
show ip

Step 4. 공격 성공 확인

PC2의 show ip 출력에서:

Gateway와 DNS가 모두 공격자 IP(10.10.10.200)로 설정되었다면 공격 성공 입니다. 이제 PC2의 모든 인터넷 트래픽은 공격자를 거쳐 나가게 됩니다 (MITM 상태).

R-ATK에서 증거 확인:

show ip dhcp binding

→ PC2의 MAC(0050.7966.6801) 과 공격자가 할당한 IP(10.10.10.101) 가 R-ATK의 가짜 풀에 기록돼 있습니다.

💡 DHCP Starvation 시연은 생략합니다

앞에서 언급한 DHCP Starvation 공격(CHADDR 위조로 합법 서버 풀 고갈)은 초당 수백 개의 위조 DHCPDISCOVER를 뿌리는 작업이라, Linux 기반 공격 도구(yersinia dhcp -attack 1, dhcpstarv, scapy 스크립트 등)가 필요합니다. 본 랩에서는 공격자를 Cisco 라우터(R-ATK)로 구성했기 때문에 실제 Starvation 공격 시연은 생략합니다.

다만 방어는 이미 걸려 있습니다. 다음 단계에서 설정할 ip dhcp snooping limit rate 10 한 줄이 포트당 DHCP 패킷을 초당 10개로 제한하므로, 실제 현장에서 Starvation이 시도되면 초당 11번째 DHCP 패킷부터 드롭되고 설정에 따라 포트가 err-disabled로 전환됩니다. 이 rate-limit 기능은 DHCP Snooping의 서브 기능 이므로 Snooping을 켜는 것만으로 Starvation 방어도 함께 활성화된다고 보시면 됩니다.

Phase 2 - 방어 ON: DHCP Snooping 적용

이제 SW1에 DHCP Snooping을 켜고, 같은 공격이 막히는지 확인합니다.

Step 1. SW1에 DHCP Snooping 설정

configure terminal
!
ip dhcp snooping
ip dhcp snooping vlan 10
!
! 업링크(R1 쪽)만 trust
interface GigabitEthernet0/0
 ip dhcp snooping trust
!
! 나머지는 rate-limit (DHCP Starvation 완화)
interface range GigabitEthernet0/1 - 3
 ip dhcp snooping limit rate 10
!
end
write memory

Step 2. R1 DHCP 복구

R1(config)# service dhcp

이제 R1과 R-ATK 둘 다 DHCP 서버로 떠있지만, SW1이 Gi0/3(R-ATK 포트)를 untrusted로 간주하므로 R-ATK의 DHCPOFFER는 드롭됩니다.

Step 3. PC2 재요청 후 확인

PC2> ip dhcp -r
PC2> ip dhcp
PC2> show ip

이번엔 Gateway가 10.10.10.1(R1)로 제대로 돌아옵니다. R-ATK가 응답하려 해도 SW1에서 차단됩니다.

Step 4. 차단 로그 확인

SW1에서:

show ip dhcp snooping
show ip dhcp snooping binding
show ip dhcp snooping statistics

• show ip dhcp snooping: trust/untrusted 포트 설정 확인
• show ip dhcp snooping binding: 합법 DHCP 바인딩 테이블 (다음 랩에서 DAI/IPSG의 근거 자료가 됨)
• show ip dhcp snooping statistics: Gi0/3에서 DHCPOFFER 드롭 카운터 증가

show ip dhcp snooping 출력에서 Gi0/0 만 Trusted=yes, 나머지는 rate-limit 10 으로 잡혀야 합니다.

🛠️ 트러블슈팅 - PC가 DHCP를 못 받을 때 (Option 82 이슈)

DHCP Snooping을 켰는데 PC2에서 갑자기 DHCP가 안 잡히는 경우가 있습니다. 증상은 이렇습니다.

PC2> ip dhcp -r
PC2> ip dhcp
DDD
Can't find dhcp server

(DDD는 DHCPDISCOVER를 3번 보냈는데 OFFER가 하나도 안 왔다는 뜻)

원인: DHCP Snooping이 켜지면 스위치가 untrusted 포트에서 들어온 DHCP 패킷에 Option 82 (DHCP Relay Agent Information) 를 자동으로 삽입해서 서버로 전달합니다. show ip dhcp snooping 출력에서 다음 두 줄이 있다면 이 모드입니다.

Insertion of option 82 is enabled
Option 82 on untrusted port is not allowed

문제는 Cisco IOS 라우터가 DHCP 서버 역할을 할 때 발생합니다. 본인이 relay agent도 아닌데 Option 82가 붙은 패킷이 오고 giaddr=0이면, 라우터가 “이상한 패킷이네” 하고 그냥 드롭해버립니다. R1·R-ATK 둘 다 응답을 못 하니 PC는 영원히 OFFER를 못 받죠.

해결: SW1에서 Option 82 삽입을 끕니다.

SW1(config)# no ip dhcp snooping information option

한 줄이면 끝납니다. 다시 PC2에서:

PC2> ip dhcp -r
PC2> ip dhcp
PC2> show ip      # Gateway: 10.10.10.1 (R1) ✅

언제 이 옵션을 유지해야 하나: Option 82가 조직 설계에 필수인 경우입니다. 예를 들어 ISP가 가입자 식별에 Option 82를 쓰거나, 외부 DHCP 서버(ISC dhcpd, Windows DHCP)가 Option 82 기반 정책을 적용하는 환경에서는 유지해야 합니다. 다만 그 경우엔 서버 측에서도 trust-circuit-id 같은 옵션을 같이 맞춰줘야 합니다.

📖 용어 정리 - Option 82 & giaddr

위 트러블슈팅을 제대로 이해하려면 두 용어를 알아야 합니다.

▸ Option 82 (DHCP Relay Agent Information Option, RFC 3046)

DHCP 패킷이 중간 장비(릴레이 에이전트나 스누핑 스위치)를 지나갈 때 “이 요청이 어느 포트/어느 장비에서 들어왔는지”를 표시하는 꼬리표입니다. 옵션 번호가 82번이라 Option 82.

활용 시나리오:

• ISP 가입자 식별 — DSLAM/OLT 단에서 Option 82를 박아 “어느 가입자 회선의 요청”인지 식별
• IP 할당 정책 — DHCP 서버가 “Fa0/1이면 게스트 풀, Fa0/2면 직원 풀” 식 분기
• DHCP Snooping 보안 — 응답이 같은 포트로 돌아오도록 강제 (위조 방지)

▸ giaddr (Gateway IP Address)

DHCP 패킷 헤더의 IP 필드 4종 중 하나로, 릴레이 에이전트(ip helper-address 설정 장비)의 IP가 들어갑니다. 일반 게이트웨이가 아님에 주의.

giaddr 값의 의미:

• giaddr = 0.0.0.0 — 릴레이를 거치지 않았다 = 클라이언트가 같은 브로드캐스트 도메인에 있음
• giaddr ≠ 0 — 이 IP의 릴레이가 패킷을 전달했다 → 서버는 (1) 응답을 이 IP로 유니캐스트 회신, (2) 이 IP가 속한 서브넷 풀에서 IP 할당

▸ 그래서 왜 충돌이 났나

Option 82 = 있음   ← "나는 릴레이/스누핑 거쳐왔어"
giaddr   = 0     ← "근데 릴레이는 안 거쳤어"

원래 RFC 3046은 “릴레이 에이전트가 Option 82를 박는다”는 전제로 설계됐습니다. 즉 둘은 세트로 움직여야 합니다. 그런데 DHCP Snooping은 L2 장비라 릴레이가 아닌데도 Option 82만 박으니, Cisco IOS DHCP 서버는 “Option 82가 있는데 giaddr=0? 모순이네 → 폐기” 판단을 내리는 겁니다.

서버 쪽에서 받아주게 하려면 ip dhcp relay information trust-all(전역) 또는 인터페이스의 ip dhcp relay information trusted 설정이 필요합니다.

가짜 DHCP 서버가 있어도 SW1이 문지기 역할을 해서 차단한다는 것을 눈으로 확인했습니다. 공격자는 포기를 모릅니다. 다음 각도의 공격으로 넘어가봅시다.

5. 시나리오 ② - 공격자가 “나는 게이트웨이다”라고 거짓말하면?

공격 상황

“이번엔 공격자가 DHCP는 건드리지 않습니다. 대신 LAN에 대고 이렇게 외칩니다. ‘나는 게이트웨이다! 내 MAC은 AA:BB:CC:DD:EE:FF다!’ 이걸 Gratuitous ARP라고 하는데요, 피해 호스트들이 이걸 그대로 믿고 ARP 캐시를 업데이트하면, 이후 피해자의 모든 트래픽은 공격자를 거쳐 가게 됩니다. 이게 바로 중간자 공격(MITM)의 본질이죠. Port Security로 막을 수 있을까요?”

역시 못 막습니다. ARP 페이로드를 검사하는 기능 자체가 Port Security에는 없습니다. ARP는 태생부터 인증 장치가 없는 프로토콜 이라, 누구나 거짓말을 할 수 있고 모두가 그걸 믿습니다.

DHCP Snooping도 이 공격은 못 막습니다. DHCP 메시지가 아니라 ARP 메시지니까요.

해결책 - Dynamic ARP Inspection (DAI)

여기서 등장하는 것이 DAI(Dynamic ARP Inspection) 입니다. DAI는 모든 ARP 패킷을 DHCP Snooping 바인딩 테이블(또는 정적 ARP ACL)과 대조 해 위조 여부를 검사합니다. 바인딩에 “Fa0/1 포트 = MAC A = IP X”라고 기록돼 있는데, 그 포트에서 “나는 IP Y다”라는 ARP가 나오면? 즉시 드롭합니다.

앞에서 DHCP Snooping 바인딩 테이블을 “진실의 원천”이라고 불렀던 이유가 이제 드러납니다. DAI가 이 테이블을 근거로 삼아 “너 진짜 네 IP 맞아?”를 검증하는 겁니다.

동작 원리는 단순합니다.

• VLAN 단위 로 DAI를 활성화
• 업링크 포트(합법 게이트웨이 쪽)만 trust 로 지정, 나머지는 기본값(untrusted)
• untrusted 포트에서 들어온 ARP는 DHCP Snooping 바인딩과 sender IP/MAC을 비교해 일치하지 않으면 드롭

정적 호스트는 어떻게 하나요?

좋은 질문입니다. DHCP를 안 쓰고 IP를 고정으로 박은 서버들(대부분의 서버 장비가 그렇죠)은 DHCP Snooping 바인딩에 기록이 없습니다. 그럼 DAI가 “바인딩에 없네, 드롭!”이라고 차단해버립니다. 이런 경우에는 ARP ACL 로 예외를 등록해줘야 합니다. 랩 Phase 2 마지막 단계에서 실제 예시를 보겠습니다.

🔬 Lab ② - ARP 스푸핑 직접 재현

Phase 1 - 방어 OFF 상태에서 공격 성공

ARP 스푸핑은 Cisco 라우터로 시연하기가 까다롭습니다(라우터는 기본적으로 거짓 ARP를 쏘지 않도록 설계됨). 대신 “공격자가 게이트웨이와 같은 IP를 수동 설정” 하는 방식으로 충돌 시연이 가능합니다.

Step 1. R-ATK를 게이트웨이 IP와 같은 IP로 설정

R-ATK(config)# interface GigabitEthernet0/0
R-ATK(config-if)# ip address 10.10.10.1 255.255.255.0

이 순간 LAN에는 10.10.10.1을 주장하는 장비가 두 대 가 됩니다. ARP는 인증이 없으므로 나중에 응답한 쪽이 피해자의 ARP 캐시를 덮어씁니다.

R1 측에서는 즉시 충돌을 감지해 로그를 토해냅니다:

*Apr 25 06:07:50.848: %IP-4-DUPADDR: Duplicate address 10.10.10.1 on GigabitEthernet0/0, sourced by 0c9c.859f.0000

0c9c.859f.0000이 R-ATK MAC인데, 이게 R1의 IP를 주장하고 있다는 뜻입니다. R1 입장에서는 “어, 누가 내 IP 쓰고 있어!” 라며 30초마다 한 번씩 경고를 띄웁니다.

Step 2. PC2에서 ARP 캐시 확인

PC2> clear ip        # ARP 캐시 초기화 (VPCS에서는 show arp)
PC2> arp             # 또는 ping 10.10.10.1 후 show arp

게이트웨이 MAC이 R1의 MAC이 아닌 R-ATK의 MAC(0c:9c:85:9f:00:00) 으로 찍혀있다면 → ARP 스푸핑 성공.

Phase 2 - 방어 ON: DAI 적용

Step 1. SW1에 DAI 설정

configure terminal
!
ip arp inspection vlan 10
!
interface GigabitEthernet0/0
 ip arp inspection trust
!
end

• DHCP Snooping은 Lab ①에서 켜둔 상태 그대로 유지 (DAI는 그 바인딩 테이블을 근거로 씁니다)
• R1 업링크만 trust, 나머지는 untrusted

Step 2. R-ATK의 거짓 ARP 차단 확인

R-ATK가 10.10.10.1로 뭔가 ARP 응답을 보내면, SW1은 DHCP Snooping 바인딩 테이블에 “Gi0/3 = 10.10.10.200”으로 기록된 걸 근거로 “거짓말이다” 판단하고 드롭합니다.

SW1에서:

show ip arp inspection statistics
show ip arp inspection interfaces

Gi0/3의 Drop 카운터가 증가 하면 공격 차단 성공. 드롭된 ARP 패킷 수가 급증하고 있다면 두 가지 중 하나입니다: 공격 시도 또는 설정 오류(trust 포트 누락, 정적 IP 호스트 미등록 등). 관제 입장에서는 양쪽 다 조사할 가치가 있는 신호입니다.

Dropped와 DHCP Drops 카운터가 같이 올라갑니다. DHCP Drops는 “DHCP Snooping 바인딩 테이블에 없어서 드롭”이라는 뜻이라, 이 두 숫자가 같이 가는 건 “DAI가 바인딩을 근거로 위조 ARP를 차단했다” 는 신호입니다.

show ip arp inspection interfaces에서는 Gi0/0만 Trusted, 나머지는 전부 Untrusted로 잡혀야 정상입니다.

Step 3. 정적 IP 서버 예외 처리 (참고)

만약 DHCP를 안 쓰고 고정 IP를 박은 서버가 있다면 ARP ACL로 예외를 등록:

configure terminal
!
arp access-list STATIC-SERVERS
 permit ip host 10.10.10.50 mac host 0050.56AA.BBCC
!
ip arp inspection filter STATIC-SERVERS vlan 10
!
end

ARP가 위조돼도 SW1이 바인딩 테이블로 검증해 차단합니다. 하지만 공격자는 또 다른 각도를 시도합니다.

6. 시나리오 ③ - IP 주소를 남의 것으로 위조하면?

공격 상황

“공격자가 이번엔 MAC과 ARP는 건들지 않습니다. 자기 본래 MAC을 그대로 쓰되, 패킷의 출발지 IP만 다른 사람의 IP로 몰래 바꿉니다(IP 스푸핑). 예를 들어 공격 트래픽의 src IP를 다른 직원 IP로 세팅해서 로그를 물타기 한다거나, 권한이 있는 IP로 위장해서 서버에 접근한다거나. Port Security로 막을 수 있을까요?”

역시 못 막습니다. Port Security는 L2의 MAC만 볼 뿐, L3의 IP는 관심조차 없습니다. DHCP Snooping도 DAI도 마찬가지입니다. 둘 다 ARP까지만 보지, 일반 IP 패킷의 src IP를 검사하지는 않습니다.

해결책 - IP Source Guard (IPSG)

이 빈틈을 메우는 것이 IPSG(IP Source Guard) 입니다. IPSG는 DHCP Snooping 바인딩 테이블을 활용해 한 단계 더 나아갑니다. untrusted 포트에서 올라오는 IP 패킷의 src IP가 바인딩과 일치하는지 검사하고, 일치하지 않으면 드롭합니다.

비유하자면 이렇습니다. DHCP Snooping이 “너 이 IP 받아가”라고 줬는데, 막상 패킷 보낼 때 다른 IP로 위장하면? “너 아까 받은 IP 아니잖아!” 하고 차단하는 겁니다.

검사 모드는 두 가지:

• IP만 검사 (ip verify source): DHCP 바인딩의 IP와 패킷 src IP만 비교
• IP + MAC 동시 검사 (ip verify source port-security): Port Security와 연동해 MAC까지 함께 검사

🔬 Lab ③ - IP 스푸핑 직접 재현

⚠️ 진행 순서 주의

이 시점에서는 이미 Lab ①(DHCP Snooping)·Lab ②(DAI)가 켜져 있습니다. 그 상태에서 R-ATK가 위조 IP로 트래픽을 던지면 DAI가 ARP 단계에서 먼저 막아버려서 IPSG의 효과가 따로 보이지 않습니다. 그래서 Lab ③은 시연 흐름이 다른 랩과 다릅니다:

1. DAI/IPSG 둘 다 잠시 OFF → R-ATK가 위조 IP로 ping 성공시키기
2. DAI/IPSG 다시 ON → 같은 ping이 0/5 로 막히는 것 확인

즉, “Phase 1에서 별도 공격 환경을 만든다”가 아니라 “방어를 잠시 풀고 → 다시 채운다” 흐름입니다.

🛠️ 트러블슈팅 - 문서 초기 버전의 loopback 접근법은 IOSv에서 동작 안 함

“공격자 라우터에 loopback 0을 만들고 PC1 IP(10.10.10.100/24) 를 박은 뒤 ping ... source loopback 0 으로 src IP 위조” 라는 고전 기법이 있습니다. 그런데 IOSv 환경에서는:

R-ATK(config-if)# ip address 10.10.10.100 255.255.255.0
% 10.10.10.0 overlaps with GigabitEthernet0/0

Gi0/0이 같은 서브넷(10.10.10.0/24) 을 갖고 있어서 loopback이 올라가지 않습니다. /32로 줘도 마찬가지로 overlap 으로 거부됩니다. 이후 ping ... source loopback 0 도 “Invalid source interface - IP not enabled or interface is down” 으로 실패합니다.

그래서 본 랩에서는 loopback 대신 R-ATK Gi0/0 자체의 IP를 PC1 IP(10.10.10.100) 로 바꾸는 단순 위장 방식 을 사용합니다. PC1이 현재 다른 IP(예: 10.10.10.103) 를 받고 있다면 IP 충돌은 발생하지 않습니다.

Phase 1 - 방어 일시 OFF, 위조 ping 성공 확인

Step 1. SW1에서 DAI + IPSG 임시 비활성화

configure terminal
!
no ip arp inspection vlan 10
!
interface range GigabitEthernet0/1 - 3
 no ip verify source
!
end

비활성화 확인:

show ip arp inspection interfaces      ! Gi0/0 빼고 Untrusted, vlan 10에서 빠진 상태
show ip verify source                   ! 출력에 아무것도 안 나오면 OK

show ip verify source 가 비어 있으면 IPSG가 빠진 상태, show ip arp inspection interfaces 의 vlan 컬럼이 비어 있으면 DAI가 빠진 상태입니다.

Step 2. R-ATK에서 위장 IP로 ping

R-ATK Gi0/0 의 IP를 PC1의 자리(10.10.10.100) 로 바꿉니다:

R-ATK(config)# interface GigabitEthernet0/0
R-ATK(config-if)# ip address 10.10.10.100 255.255.255.0
R-ATK(config-if)# end
R-ATK# ping 10.10.10.1

방어가 풀려 있으면 R-ATK 가 PC1 자리에 앉아있는 것처럼 R1 과 통신이 됩니다 (4/5~5/5 success).

첫 ping 의 첫 패킷 한두 개는 ARP 학습 시간 때문에 종종 빠집니다. Success rate is 80 percent (4/5) 정도면 정상입니다.

Phase 2 - 방어 ON: IPSG + DAI 재적용

Step 1. SW1에 DAI + IPSG 다시 켜기

configure terminal
!
ip arp inspection vlan 10
!
interface range GigabitEthernet0/1 - 3
 ip verify source
!
end

• DHCP Snooping 바인딩 테이블의 포트 ↔ IP 매핑을 기준으로 검증
• 바인딩과 다른 src IP 패킷은 드롭

Step 2. 같은 ping 재시도

R-ATK 에서 ping 10.10.10.1 그대로 한 번 더 → 0/5 (실패) 가 나와야 정상입니다.

Step 3. SW1에서 차단 증거 수집

show ip verify source
show ip arp inspection statistics
show log | include DHCP_SNOOPING_DENY

기대 결과:

• show ip verify source 의 Gi0/3 = deny-all (R-ATK 포트, DHCP 바인딩 없음 → 어떤 src IP도 통과 못 함)
• 같은 출력에서 Gi0/1 = PC1 IP, Gi0/2 = PC2 IP 가 active 로 잡혀 있음
• show ip arp inspection statistics 의 Dropped / DHCP Drops 카운터 동시 증가
• 로그에 %SW_DAI-4-DHCP_SNOOPING_DENY ... 0c9c.859f.0000/10.10.10.100/0000.0000.0000/10.10.10.1 ... 메시지 — R-ATK가 자신을 10.10.10.100 으로 속여 R1(10.10.10.1) 의 MAC을 물어본 ARP 요청이 SW1에서 잘려나간 흔적

DHCP로 정식 발급받지 않은 IP로는 ARP 자체가 통과하지 못하고, 설령 ARP를 통과시킨다 해도 IPSG에서 한 번 더 걸러집니다. 두 단계의 검증이 직렬로 동작하는 셈입니다.

💡 정리: Lab ③에서 두 기능이 서로를 보강하는 모습

R-ATK는 DHCP를 받지 않은 장비라 SW1의 바인딩 테이블에 등록이 안 됩니다. 그러면:

• DAI: “이 포트(Gi0/3) 에서 10.10.10.100 을 주장하는 ARP? 바인딩에 없어. 드롭.”
• IPSG: “이 포트(Gi0/3) 에서 src=10.10.10.100 인 IP 패킷? 바인딩에 없어. 드롭.”

두 기능이 같은 바인딩 테이블을 다른 각도에서 활용 합니다. 그래서 한쪽만 켜져 있으면 공격자가 우회할 여지가 있고, 둘 다 켜야 빈틈이 닫힙니다.

여기까지 정리 - L2 보안의 4대 기둥

잠깐 숨을 고르고 지금까지 배운 것을 정리해봅시다.

Port Security + DHCP Snooping + DAI + IPSG 를 모두 켜면, 한 포트에 연결된 호스트는 이런 제약을 받게 됩니다:

1. 허용된 MAC만 사용 가능 (Port Security)
2. 불법 DHCP 서버 못 세움 (DHCP Snooping)
3. ARP로 본인이 아닌 척 못 함 (DAI)
4. DHCP로부터 받은 IP만 사용 가능 (IPSG)

L2 스푸핑 공격 벡터가 대부분 차단됩니다. 이 네 가지 조합이 엔터프라이즈 캠퍼스 네트워크의 기본 템플릿 입니다. 하나라도 빠지면 구멍이 뚫리는 구조죠.

이제 마지막 두 가지 남았습니다. 지금까지는 데이터 흐름에 대한 공격이었는데, 공격자가 더 야심찬 목표를 노린다면요?

7. 시나리오 ④ - 공격자가 스위치 토폴로지 자체를 장악하려 한다면?

공격 상황

“공격자가 이번엔 소규모 공격이 아니라 판을 뒤집으려 합니다. 사용자 자리에 불법 스위치를 몰래 꽂고, 아주 낮은 bridge priority를 가진 BPDU를 쏩니다. 그러면 다른 스위치들이 ‘어, 얘가 우선순위가 가장 높네. 얘가 루트 브리지야’라고 인식하고, 공격자 스위치가 루트 브리지 자리를 차지합니다. 이 순간부터 네트워크의 모든 트래픽 흐름은 공격자를 거쳐가게 됩니다. 거의 네트워크 장악 수준의 공격이죠. Port Security로 막을 수 있을까요?”

이번에도 못 막습니다. BPDU의 MAC 주소가 합법적으로 보이기 때문에 Port Security는 그대로 통과시킵니다. DHCP·ARP·IP 검사 기능들도 BPDU는 보지 않습니다. STP는 태생부터 BPDU를 기본적으로 신뢰 하는 프로토콜이라 이런 공격에 무방비입니다.

해결책 - BPDU Guard (액세스 포트 방어)

사용자 PC가 꽂히는 액세스 포트에는 BPDU가 들어올 일이 없습니다. PC는 BPDU를 만들지 않으니까요. 그러니 “액세스 포트에서 BPDU가 들어오면 = 불법 스위치가 꽂혔다”로 판단해 즉시 포트를 내려버리는 것이 BPDU Guard 입니다. PortFast와 짝으로 쓰는 것이 정석이며, 전역 기본값으로도 걸 수 있습니다.

🔬 Lab ④ - STP 루트 탈취 직접 재현

Phase 1 - 방어 OFF 상태

STP 공격 시연에는 두 번째 스위치(SW-ATK) 가 필요합니다. R-ATK 라우터로는 BPDU를 생성할 수 없으니, GNS3에 스위치 한 대를 추가합니다.

Step 0. SW-ATK 추가

• 새 L2 스위치 노드 드래그 → SW-ATK로 이름 지정
• SW-ATK의 한 포트를 SW1의 Gi0/3에 연결 (R-ATK 연결 해제)

Step 1. SW1 현재 루트 브리지 상태 확인

SW1# show spanning-tree vlan 10

출력에서 “This bridge is the root” 메시지 또는 현재 루트 브리지 ID를 기록해둡니다.

Step 2. SW-ATK에 낮은 priority 설정해 루트 탈취

SW-ATK(config)# spanning-tree vlan 10 priority 0

• 기본 priority는 32768
• 0으로 설정하면 가장 작은 값이므로 새로운 루트가 됨

Step 3. SW1에서 루트 변경 확인

SW1# show spanning-tree vlan 10

출력에서 Root ID가 SW-ATK의 MAC 으로 바뀌었다면 → 공격 성공.

🛠️ 트러블슈팅 - SW1 과 SW-ATK 둘 다 자기가 root 라고 주장한다면

SW-ATK 의 priority 를 0 으로 낮췄는데도 SW1 출력에 여전히 This bridge is the root 가 보이고, SW-ATK 도 자기가 root 라고 우긴다면 — SW1 이 SW-ATK 의 BPDU 를 한 번도 받지 못한 상황 입니다. 함께 다음 로그가 5초마다 찍히는지 확인해보세요.

%PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred,
  caused by MAC address 0c94.2fcf.0000 on port GigabitEthernet0/3

원인: §3 베이스라인의 Port Security 가 Lab ① ~ ③ 동안 R-ATK 의 MAC(0c9c.859f.0000) 을 sticky 로 학습해서 running-config 에 박아뒀습니다. R-ATK 자리에 SW-ATK 를 새로 꽂으니 SW-ATK MAC(0c94.2fcf.0000) 이 maximum 슬롯을 초과해 위반 처리되고, 그 결과 SW-ATK 의 BPDU 프레임도 통째로 드롭됩니다.

해결: Gi0/3 의 Port Security 상태를 한 번 비우고 maximum 을 넉넉히 늘립니다.

SW1(config)# interface GigabitEthernet0/3
SW1(config-if)# no switchport port-security mac-address sticky
SW1(config-if)# no switchport port-security
SW1(config-if)# switchport port-security
SW1(config-if)# switchport port-security maximum 5
SW1(config-if)# switchport port-security violation restrict

다시 10 ~ 30초 기다린 뒤 show spanning-tree vlan 10 을 보면 Root ID 가 SW-ATK MAC 으로 바뀌어 있을 겁니다. 사실 이건 부수적 발견이기도 한데, Port Security 가 STP 공격을 우연히 일부 막아준 셈 입니다. 다만 의도된 방어가 아니라 부작용이라, max 만 넉넉히 잡거나 MAC 만 위장하면 우회되니 STP 공격에는 명시적으로 BPDU Guard / Root Guard 를 써야 합니다.

Phase 2 - 방어 ON: BPDU Guard 적용

Step 1. SW1 Gi0/3에 BPDU Guard 설정

configure terminal
!
interface GigabitEthernet0/3
 spanning-tree portfast
 spanning-tree bpduguard enable
!
end

참고: PortFast는 “액세스 포트에서는 STP 수렴 단계를 스킵하고 바로 forwarding”입니다. BPDU Guard와 짝으로 씁니다. 전역 적용하려면 spanning-tree portfast bpduguard default.

Step 2. SW1에서 포트 err-disabled 확인

SW1# show interfaces status err-disabled
SW1# show log | include BPDU

BPDU Guard가 동작하면 Gi0/3이 err-disabled 상태가 되며, 로그에 %SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port GigabitEthernet0/3 같은 메시지가 기록됩니다.

8. 시나리오 ⑤ - VLAN 벽을 뚫고 다른 부서로 넘어간다면?

공격 상황

“공격자가 HR VLAN(VLAN 10)의 사용자 PC 자리에 앉았습니다. 옆 부서인 Finance VLAN(VLAN 20)에는 급여 정보, 회계 데이터가 돌아다니고 있죠. 원래는 VLAN이 서로 격리돼 있어서 HR에서 Finance로 접근이 불가능해야 합니다. 그런데 공격자가 특수한 프레임을 만들어서 VLAN 20에 있는 서버에 패킷을 밀어넣는다면요? 지금까지 배운 Port Security, DHCP Snooping, DAI, IPSG, BPDU Guard로 막을 수 있을까요?”

아쉽게도 이 공격 벡터는 앞의 5대 방어 기능 어느 것도 막지 못합니다. MAC도 정상, ARP도 정상, DHCP도 안 건드리고, IP도 자기 것이며, BPDU도 안 쏘기 때문입니다. 완전히 다른 결의 공격이죠.

이 공격을 VLAN Hopping 이라고 부릅니다. 두 가지 기법이 있습니다.

기법 ① - 이중 태깅(Double Tagging)

802.1Q 트렁크의 네이티브 VLAN 특성 을 악용하는 고전적인 기법입니다.

💡 복습: 802.1Q 트렁크에서 “네이티브 VLAN” 프레임은 태그 없이 전송됩니다. 관리의 편의를 위한 설계인데, 여기에 허점이 있습니다.

공격자는 이렇게 합니다.

1. 공격자가 액세스 포트(VLAN 10)에 꽂혀 있습니다
2. 프레임에 VLAN 태그를 두 개 겹쳐 붙여서 쏩니다: [outer: VLAN 10][inner: VLAN 20][페이로드]
3. 첫 번째 스위치가 프레임을 받고 outer 태그(10)를 벗겨냅니다 (자기 네이티브 VLAN과 같으니 태그 제거)
4. 그 프레임을 트렁크로 내보내는데, inner 태그(20)가 이제 진짜 태그 로 보입니다
5. 다음 스위치는 “아, VLAN 20 프레임이네”라고 인식해서 Finance VLAN으로 전달

공격 성공. 공격자는 VLAN 10에 앉아서 VLAN 20의 서버에 패킷을 쏘는 데 성공했습니다.

주의: 이중 태깅은 단방향 공격 입니다. 응답 프레임을 받을 수 있는 구조가 아니에요. 그래서 주로 DoS나 데이터 밀어넣기(ex: 명령 주입, 익스플로잇 페이로드 전달)에 쓰입니다.

기법 ② - DTP 트렁크 협상 악용

Cisco 스위치의 기본 설정에는 DTP(Dynamic Trunking Protocol) 가 활성화돼 있습니다. 포트가 “자동으로 트렁크로 올라갈지 액세스로 내려갈지” 협상하는 프로토콜이죠. 편리한 기능인데, 이게 공격자에겐 놀이터입니다.

공격자가 자기 PC에 스위치 흉내를 내는 소프트웨어(예: yersinia)를 띄워서 DTP 협상을 시도하면:

공격자 → 스위치: "안녕 나 스위치야, 트렁크로 올려줄래?"
스위치 → 공격자: "오케이, 트렁크로 설정!"

이 순간 공격자 PC는 모든 VLAN의 트래픽을 받는 트렁크 포트 에 연결된 상태가 됩니다. VLAN 격리가 통째로 무너집니다.

해결책 - DTP 비활성화 (액세스 고정)

VLAN Hopping 방어는 스위치의 기본 설정을 바꾸는 것 에서 시작합니다. DHCP Snooping이나 DAI 같은 별도 기능이 아니라, 트렁크/액세스 포트 설정을 제대로 하는 것 이 방어 그 자체입니다.

액세스 포트와 트렁크 포트 모두에서 DTP를 끕니다. switchport nonegotiate 명령으로 트렁크는 수동으로 고정하고, 액세스 포트는 “나는 액세스이고 협상도 안 한다” 로 못 박습니다. 이 설정 덕분에 공격자의 DTP 협상 시도가 무시됩니다.

이중 태깅 방어(네이티브 VLAN을 더미로 지정 + vlan dot1q tag native 전역 강제) 도 같은 맥락에서 같이 걸어두는 것이 정석이지만, 본 랩에서는 공격 자체를 IOSv 로 만들 수 없어 검증을 생략 합니다. 다음 랩에서는 DTP 협상 악용 만 직접 재현·차단합니다.

🔬 Lab ⑤ - DTP 트렁크 협상 직접 재현

🔧 도구 한계 안내 - 이중 태깅 시연은 생략

이중 태깅 공격은 [outer:VLAN10][inner:VLAN20] 같은 두 겹의 802.1Q 헤더가 붙은 프레임 을 직접 만들어서 쏴야 합니다. 이런 비표준 프레임은 IOSv 라우터/스위치로는 생성할 수 없고, Linux 의 scapy 나 yersinia 같은 도구가 필요합니다. 게다가 이중 태깅은 단방향 공격 이라 ping reply 가 안 와서 시연 결과도 눈에 띄지 않습니다. 그래서 본 랩은 두 기법 중 DTP 협상 악용 만 재현합니다.

이 랩은 Lab ④ 에서 추가했던 SW-ATK 를 그대로 재활용합니다. SW-ATK 가 “나는 스위치야, 트렁크 같이 올리자” 라고 DTP 협상을 시도하면 SW1 의 기본 동작이 어떻게 반응하는지, 그리고 switchport nonegotiate 가 그걸 어떻게 막는지를 비교합니다.

사전 정리 - Gi0/3 깨끗하게 만들기

Lab ④ 직후 Gi0/3 은 err-disabled (BPDU Guard) + Port Security 흔적 + access vlan 10 이 뒤섞인 상태입니다. DTP 시연을 위해 한 번 정리합니다.

configure terminal
!
default interface GigabitEthernet0/3
!
interface GigabitEthernet0/3
 switchport
 no shutdown
!
end

default interface 한 줄로 Gi0/3 의 모든 설정이 공장 초기값으로 돌아갑니다. 이제 모드는 명시되지 않은 상태(IOSv-L2 기본값은 dynamic auto) 가 됩니다.

💡 dynamic auto vs dynamic desirable

• dynamic auto (기본): “상대가 트렁크 하자고 하면 OK, 내가 먼저 제안은 안 함”
• dynamic desirable: “내가 먼저 트렁크 하자고 적극 제안”

SW1 이 dynamic auto (기본) + SW-ATK 가 dynamic desirable (공격) → 트렁크 협상 성립. 이게 Phase 1 의 공격 시나리오입니다.

SW-ATK 도 마찬가지로 정리:

SW-ATK# configure terminal
SW-ATK(config)# default interface GigabitEthernet0/0
SW-ATK(config)# interface GigabitEthernet0/0
SW-ATK(config-if)# switchport
SW-ATK(config-if)# no shutdown
SW-ATK(config-if)# end

Phase 1 - 방어 OFF, DTP 협상 성공 확인

Step 1. SW1 측 현재 상태 확인 (방어 없음)

SW1# show interfaces GigabitEthernet0/3 switchport

Administrative Mode: dynamic auto 와 Negotiation of Trunking: On 이 공격에 노출된 상태 입니다.

Step 2. SW-ATK가 트렁크 협상 적극 시도

SW-ATK# configure terminal
SW-ATK(config)# interface GigabitEthernet0/0
SW-ATK(config-if)# switchport mode dynamic desirable
SW-ATK(config-if)# end

이 한 줄이 SW-ATK 를 “트렁크 하자고 먼저 외치는 공격자” 로 만듭니다. DTP 가 양쪽에서 켜져 있고 한 쪽이 desirable 이면 협상 성립.

10 ~ 30초 정도 기다린 뒤 (DTP 는 30초 주기) SW1 에서 다시 확인:

SW1# show interfaces trunk
SW1# show interfaces GigabitEthernet0/3 switchport

기대 결과:

• show interfaces trunk 에 Gi0/3 이 trunk 로 등장
• show interfaces ... switchport 에서 Operational Mode: trunk 로 바뀜
• Trunking VLANs Enabled 가 1-4094 (또는 all)

이 순간 SW-ATK 는 SW1 위에 있는 모든 VLAN 의 트래픽을 받을 수 있는 위치 가 됩니다. VLAN 격리가 통째로 무너진 거죠.

Phase 2 - 방어 ON: switchport nonegotiate + access 고정

Step 1. SW1 Gi0/3 을 access 로 고정 + DTP 끄기

configure terminal
!
interface GigabitEthernet0/3
 switchport mode access
 switchport access vlan 10
 switchport nonegotiate
!
end

세 줄의 의미:

• switchport mode access: “나는 액세스 포트다, 트렁크 안 한다”
• switchport access vlan 10: VLAN 10 만 허용
• switchport nonegotiate: “DTP 프레임 자체를 보내지도, 받지도 않는다”

마지막 한 줄이 핵심입니다. 그냥 switchport mode access 만 있으면 IOS 가 여전히 DTP 프레임을 흘릴 수 있는데, nonegotiate 가 그 통로를 완전히 닫습니다.

Step 2. SW-ATK 가 다시 협상 시도

SW-ATK(config)# interface GigabitEthernet0/0
SW-ATK(config-if)# shutdown
SW-ATK(config-if)# no shutdown
SW-ATK(config-if)# end

(포트를 한 번 내렸다 올려서 DTP 협상을 강제 재시도)

Step 3. SW1 에서 차단 확인

기대 결과:

• show interfaces trunk 출력에 Gi0/3 이 안 보임 (트렁크 목록에 없음)
• show interfaces ... switchport 에서:

  Administrative Mode: static access
  Operational Mode: static access      ← 여전히 access, 트렁크 안 됨
  Negotiation of Trunking: Off         ← DTP 꺼짐

Negotiation of Trunking: Off 가 보이면 DTP 협상 통로가 차단됐다는 결정적 증거 입니다. SW-ATK 가 아무리 desirable 로 졸라도 SW1 은 답을 안 합니다.

정리

SW1 의 변화는 단 세 줄(switchport mode access, switchport access vlan 10, switchport nonegotiate) 이지만, VLAN 격리의 운명이 그 세 줄에 달려있습니다. “기본 설정으로 두는 것” 자체가 곧 취약점 인 거죠.

핵심 정리 - 5대 방어 기둥

이제 L2 보안은 4대 기둥에서 5대 기둥 으로 확장됩니다.

VLAN Hopping 방어가 특별한 점은 “추가 기능을 켜는 것”이 아니라 “기본 설정을 제대로 해두는 것” 이라는 점입니다. 감사에서 이 항목이 지적되는 이유는 대부분 “그냥 기본값으로 뒀다” 이거든요. 5분이면 끝나는 설정을 안 해서 VLAN 격리가 무너지는 경우가 현업에 생각보다 많습니다.

9. 최종 운영 템플릿 - 결과물

지금까지 다섯 가지 시나리오와 다섯 번의 랩을 거쳐왔습니다. 이제 실전에 그대로 써먹을 수 있는 통합 템플릿을 정리합니다. 현업 장비에 붙여넣어도 무방한 수준입니다.

액세스 포트 (사용자 PC 연결)

interface fastEthernet 0/1
 switchport mode access
 switchport access vlan 10
 switchport nonegotiate                ! VLAN Hopping 방어
 switchport port-security
 switchport port-security maximum 2
 switchport port-security mac-address sticky
 switchport port-security violation restrict
 spanning-tree portfast
 spanning-tree bpduguard enable
 ip verify source
 ip arp inspection limit rate 15
 no cdp enable

업링크/트렁크 포트 (스위치-라우터, 스위치-스위치)

interface gigabitEthernet 0/1
 switchport mode trunk
 switchport nonegotiate                ! VLAN Hopping 방어
 switchport trunk allowed vlan 10,20,30
 ip dhcp snooping trust
 ip arp inspection trust

전역 설정

ip dhcp snooping
ip dhcp snooping vlan 10,20,30
ip arp inspection vlan 10,20,30
spanning-tree portfast bpduguard default
errdisable recovery cause bpduguard
errdisable recovery cause psecure-violation
errdisable recovery interval 300

마지막 줄의 자동 복구(errdisable recovery)는 편의와 보안 사이의 트레이드오프입니다. 보안이 엄격해야 하는 환경에서는 수동 복구를 유지하는 것이 원칙입니다. “자동으로 복구되면 운영은 편하지만, 공격자가 계속 시도할 여지가 생긴다”는 점을 기억해 두세요.

랩을 거치며 드러난 핵심 교훈

다섯 차례의 랩을 직접 돌려본 결과 몇 가지가 피부로 와닿습니다.

첫째, DHCP Snooping의 중심성. 이 기능 하나가 꺼져 있으면 DAI도, IPSG도 의미가 없어집니다. 바인딩 테이블이 모든 검증의 근거이기 때문에 DHCP Snooping → DAI → IPSG 순서는 “권장”이 아니라 “필수”입니다.

둘째, trust 포트 설정의 치명성. 업링크 하나를 trust로 지정 안 해두면, 합법 DHCP 서버의 응답이 전부 드롭되면서 네트워크 전체가 마비됩니다. 운영 환경에 적용할 때는 trust 포트부터 먼저 확실하게 잡아둔 뒤 각 기능을 순차적으로 켜는 것 이 기본 원칙입니다.

셋째, BPDU Guard의 파급력. 액세스 포트 하나만 잘못 설정해도 사용자 실수(허브/스위치 연결) 한 번에 포트가 err-disabled 됩니다. errdisable recovery 설정을 같이 해두지 않으면 현업에서는 콜센터 전화가 쏟아집니다. 편의와 보안의 트레이드오프를 각 조직의 정책에 맞게 결정해야 합니다.

넷째, 기본값의 위험성 (Lab ⑤). Cisco 스위치 포트의 출고 기본값은 dynamic auto + Negotiation On 입니다. 즉 아무 설정도 안 한 포트 가 자동으로 상대의 트렁크 협상에 응답합니다. 누군가 그 포트에 desirable 모드 스위치를 꽂는 순간 모든 VLAN 의 격리가 무너집니다. switchport mode access + switchport nonegotiate 두 줄로 닫히는 구멍이라, 안 해두면 감사에서 즉시 지적당하는 항목입니다.

10. 결론 - 왜 L2 보안을 모두 켜야 하는가

이번 편은 “공격 시나리오 → 방어 기능 → 랩 재현”을 짝지어가며 진행했습니다. 정리하면 이렇습니다.

핵심을 몇 줄로 압축하면:

• Port Security + DHCP Snooping + DAI + IPSG 는 엔터프라이즈 L2 보안의 4대 기둥 입니다. 하나만 빼도 구멍이 생깁니다.
• DHCP Snooping의 바인딩 테이블 이 DAI와 IPSG의 근거 데이터입니다. 그래서 DHCP Snooping을 먼저 안정화한 뒤 DAI/IPSG를 켜는 것이 올바른 순서입니다.
• STP 보안은 공격자의 토폴로지 탈취 를 막습니다. 액세스 포트마다 BPDU Guard 를 거는 것이 기본입니다.
• VLAN Hopping 방어는 “기본 설정을 제대로 하는 것” 입니다. switchport nonegotiate 한 줄이 핵심이고, 5분 설정이면 끝납니다.
• 모든 L2 보안 기능은 “어느 포트를 trust로 지정했는가” 가 운명을 가릅니다. 설정 실수 하나로 전체가 무력화됩니다.
• 발표나 감사 자리에서 “Port Security 만 켜뒀어요”로는 부족합니다. 위 조합이 최소한 언급·배치되어 있어야 실무 수준으로 인정받습니다.

2014년 브라질 은행 피싱 사건에서 봤듯, L2에서의 작은 허점 하나가 수십만 명의 계정 탈취로 이어지는 세상 입니다. Port Security가 전부인 시절은 이미 옛날 이야기가 되었습니다.