IPv6 보안 — 듀얼스택 시대의 사각지대

잊혀진 절반 — 조직의 IPv4 보안은 촘촘해도, IPv6는 OS 기본 활성화 + 정책 미설정인 경우가 흔합니다. 공격자는 이 틈을 노립니다 — 관리자가 안 보는 IPv6 경로로 RA/DHCPv6 스푸핑, ND 공격, 듀얼스택 우회를 시도합니다. 본 편은 IPv6의 보안 특성 + 대응 기본기를 정리합니다.

1. 왜 IPv6 보안을 따로 다루나

IPv6는 IPv4와 다음이 근본적으로 다릅니다:

• 주소 자동 구성 (SLAAC) — DHCP 없이도 IP를 스스로 생성 → 라우터 광고(RA)가 인증 없는 게 치명적
• Neighbor Discovery (ND) — ARP 대체. 자체 보안 문제 다수
• 확장 헤더 (Extension Header) — 필터링 우회 기법
• 광대역 주소 공간 — 스캔으로 호스트 찾기 어려운 대신 멀티캐스트 발견이 표준

IPv4 ACL·방화벽 룰이 아무리 빡세도 IPv6를 막지 않으면 반쯤 열린 상태입니다.

2. Neighbor Discovery (ND) 위협

ND는 IPv4의 ARP + ICMP Redirect + Router Solicitation/Advertisement를 합친 역할. 주요 공격:

1) Rogue RA (Router Advertisement)

공격자가 “나는 게이트웨이다” RA를 쏘면 같은 링크의 모든 IPv6 호스트가 공격자를 기본 게이트웨이로 삼음. IPv4 DHCP 스푸핑의 IPv6 버전.

2) NS/NA 스푸핑

Neighbor Solicitation/Advertisement를 위조해 캐시 오염(ARP 스푸핑과 동일).

3) Duplicate Address Detection (DAD) DoS

호스트가 새 주소 요청할 때마다 “이미 내가 쓰고 있다”고 거짓 응답 → 주소 할당 거부.

4) ND Cache Exhaustion

/64 서브넷의 광대역(약 2^64) 주소로 핑을 뿌리면 라우터가 각각에 대해 ND 엔트리를 만들다 메모리 고갈.

3. ND 방어 — FHS (First Hop Security)

Cisco의 IPv6 First Hop Security 스위트. IPv4의 DHCP Snooping/DAI에 해당하는 L2 보안.

RA Guard

액세스 포트에서 RA가 들어오면 드롭 (합법 RA는 업링크에서만 와야 함):

SW(config)# ipv6 nd raguard policy ACCESS_POLICY
SW(config-nd-raguard)# device-role host
SW(config-nd-raguard)# exit

SW(config)# interface fastEthernet 0/1
SW(config-if)# ipv6 nd raguard attach-policy ACCESS_POLICY

업링크(합법 라우터 쪽)에는 device-role router 정책 적용.

DHCPv6 Guard

불법 DHCPv6 서버 차단 (IPv4 DHCP Snooping의 IPv6 버전).

SW(config)# ipv6 dhcp guard policy CLIENT_POLICY
SW(config-dhcp-guard)# device-role client
SW(config-dhcp-guard)# exit

SW(config)# interface fastEthernet 0/1
SW(config-if)# ipv6 dhcp guard attach CLIENT_POLICY

IPv6 Snooping (Binding Table)

IPv6-MAC-Interface 바인딩을 학습·유지. 후속 기능들(IPv6 Source Guard, ND Inspection)의 기반.

SW(config)# ipv6 snooping policy SNOOP_POLICY
SW(config-ipv6-snooping)# security-level guard
SW(config-ipv6-snooping)# trusted-port

SW(config)# vlan configuration 10
SW(config-vlan-config)# ipv6 snooping attach-policy SNOOP_POLICY

IPv6 Source Guard

바인딩 테이블을 근거로 스푸핑된 src 주소 드롭:

SW(config)# ipv6 source-guard policy SG_POLICY
SW(config)# interface fa0/1
SW(config-if)# ipv6 source-guard attach-policy SG_POLICY

Destination Guard / Prefix Guard

ND 캐시 고갈·알려지지 않은 목적지로의 패킷 차단, 라우터가 광고한 prefix 외의 src 차단.

FHS 요약 매핑

4. IPv6 ACL

IPv4 ACL과 문법·개념은 유사하지만 몇 가지 차이:

R1(config)# ipv6 access-list WEB_ONLY
R1(config-ipv6-acl)# permit tcp any host 2001:db8::1 eq www
R1(config-ipv6-acl)# permit tcp any host 2001:db8::1 eq 443
R1(config-ipv6-acl)# deny ipv6 any any log

R1(config)# interface gigabitEthernet 0/0
R1(config-if)# ipv6 traffic-filter WEB_ONLY in

주의점:

• ICMPv6는 쉽게 막으면 안 됨. ND·RA·PMTUD 등 핵심 프로토콜이 ICMPv6 위에서 동작. “IPv4처럼 ICMP 다 막기”는 IPv6에선 네트워크를 죽이는 행위.
• RFC 4890에서 IPv6에서 허용해야 하는 ICMPv6 유형을 권고:
  • Destination Unreachable (Type 1)
  • Packet Too Big (Type 2)
  • Time Exceeded (Type 3)
  • Parameter Problem (Type 4)
  • Echo Request/Reply (Type 128/129)
  • ND NS/NA (Type 135/136)
  • Router Solicitation/Advertisement (Type 133/134, 단 RA는 링크 로컬에서만)

IPv6 ACL 템플릿 (엣지 라우터)

ipv6 access-list INFRA_V6
 permit icmp any any nd-na
 permit icmp any any nd-ns
 permit icmp any any packet-too-big
 permit icmp any any destination-unreachable
 permit icmp any any time-exceeded
 permit icmp any any echo-reply
 permit icmp any any echo-request
 
 ! 자체 prefix 스푸핑 차단 (BCP 84)
 deny ipv6 2001:db8:1000::/48 any
 
 ! 루프백, 문서화용 범위 차단
 deny ipv6 ::1/128 any
 deny ipv6 2001:db8::/32 any
 deny ipv6 fe80::/10 any    ! 링크 로컬은 외부에서 오면 이상
 
 ! 그 외 IPv6 트래픽 로깅 후 드롭
 deny ipv6 any any log

5. 확장 헤더 (Extension Header) 이슈

IPv6 패킷은 기본 헤더 뒤에 여러 확장 헤더를 체인으로 달 수 있습니다 (Routing, Fragment, Destination Options 등). 문제:

• 필터링 우회: 일부 방화벽·IDS가 확장 헤더 파싱에 버그 → 공격자가 헤더 체인을 깊게 쌓아 Payload 검사 회피
• Routing Header Type 0 (RH0): 소스 라우팅 → 증폭 DoS 가능. RFC 5095로 폐기됐지만 장비가 확실히 드롭하는지 검증 필요
• Fragment Header: 분할된 첫 조각에만 헤더가 있어 IDS가 놓치는 시나리오

대응:

! RH0 드롭
deny ipv6 any any routing-type 0 log

! 분할 과도 드롭(설계 따라)
deny ipv6 any any fragments

최신 장비는 기본으로 RH0을 드롭하지만, 레거시 코드 돌리는 장비는 확인 필수.

6. Dual-Stack 환경의 함정

대부분 조직은 IPv4·IPv6가 공존하는 듀얼스택 상태. 주의할 점:

• 관리 영역 누락: IPv4 ACL은 촘촘한데 IPv6 인터페이스 링크 로컬·RA 노출 방치 → 관리자가 인지 못하는 사이 IPv6 경로로 장비 접근 가능
• 호스트 OS 기본 IPv6 활성: Windows/Linux/macOS 모두 IPv6 기본 ON. RA만 쏘면 SLAAC로 주소 자동 생성
• 이중 규칙 유지 부담: 방화벽 정책을 IPv4·IPv6 각각 유지 → 한 쪽만 업데이트되어 불일치
• 터널 우회: 6to4, Teredo, ISATAP 터널이 IPv4 내부에서 IPv6 트래픽을 나르며 방화벽 우회 가능

조직 전반 IPv6 정책

1. IPv6 활성화 의사결정: “쓰지 않음”도 명시적 정책 — 이 경우 장비·서버에서 IPv6 스택을 끄고, 터널 프로토콜(6to4, Teredo, ISATAP) 차단 필수
2. 쓸 거라면 전면 설계: Prefix 계획, FHS, IPv6 방화벽/IDS, IPv6 NetFlow까지 동등 수준 배포
3. 듀얼스택 감사: 정기적으로 “IPv4에만 있는 규칙 / IPv6에 빠진 규칙” 비교 스크립트 운영

7. 기타 주의사항

• Privacy Extensions (RFC 4941): 호스트가 SLAAC 주소를 주기적으로 변경 → 로그에서 사용자 추적 어려움. 정책적 고려 필요.
• IPv6 NAT66?: IPv6는 주소가 충분해 NAT가 불필요하다는 원칙이지만, 조직 요구상 NAT66/NPTv6 쓰기도 함. 디버깅 복잡도 증가.
• DNS 이중 레코드: A와 AAAA 둘 다 등록 시 클라이언트가 Happy Eyeballs로 먼저 성공하는 쪽 사용 → “왜 어떤 세션은 v4로 어떤 건 v6로 가나” 혼란
• IPv6 Nmap: -6 옵션. 대형 서브넷 스캔은 무의미하지만 ICMPv6 발견·멀티캐스트 응답 수집이 주요 기법

8. 체크리스트 (내부 감사용)

• 모든 VLAN에 RA Guard가 적용되어 있는가?
• DHCPv6 Guard가 클라이언트 포트에 걸려 있는가?
• IPv6 ACL이 IPv4 ACL과 동등 수준으로 적용되어 있는가?
• 엣지 라우터에서 **자체 prefix의 역스푸핑 차단 (BCP 84)**이 되어 있는가?
• ICMPv6에서 RFC 4890 권고 유형만 허용되는가?
• RH0·확장 헤더 남용 차단이 검증되었는가?
• NetFlow/IPFIX가 IPv6 트래픽을 동등하게 수집하는가?
• 관리 평면(VTY, SNMP) IPv6 접속이 적절히 제한되는가?
• 터널 프로토콜(6to4, Teredo, ISATAP) 정책이 명확한가?

9. 결론

• IPv6는 “ARP가 ND로, DHCP가 SLAAC+DHCPv6로, ICMP가 ICMPv6로” 전환된 세계. 각각 고유의 공격 벡터와 대응이 필요합니다.
• Cisco의 **First Hop Security (FHS)**는 IPv4 DHCP Snooping/DAI/IPSG의 IPv6 대응물. 듀얼스택 환경에선 둘 다 켜야 L2 보안이 완성됩니다.
• ICMPv6는 차단 대상이 아님. 이걸 IPv4처럼 막으면 네트워크가 동작 안 합니다. RFC 4890 권고 유형 선별 허용이 정석.
• 조직 정책은 “IPv6 안 씀”이라도 명시적으로 하고 터널 차단까지 해야 실질적 보안. 암묵적 방치가 가장 위험한 상태.
• 듀얼스택 감사는 정기 업무로 유지 — IPv4 규칙과 IPv6 규칙의 불일치를 주기적으로 찾아내야 합니다.

출처: RFC 4890 (ICMPv6 Filtering), RFC 7610 (RA Guard), Cisco IPv6 First Hop Security Deployment Guide

태그: IPv6, IPv6 Security, FHS, RA Guard, DHCPv6 Guard, ND Security

→ 다음 편: 26_TrustSec / SGT — IPv4/IPv6 공통으로, IP 주소 기반 정책의 한계를 넘어 “사용자·디바이스 역할”로 정책을 짜는 마이크로세그멘테이션.