보안 IP 멀티캐스트 구축

소개

이 문서에서는 IP 멀티캐스트 네트워크 인프라를 보호하기 위한 모범 사례에 대한 일반적인 지침을 설명합니다.

사전 요구 사항

요구 사항

다음 주제에 대한 지식을 보유하고 있으면 유용합니다.

• IP 멀티캐스트

사용되는 구성 요소

이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.

배경 정보

이 문서에서는 몇 가지 기본 개념, 용어에 대해 설명하고 다음과 같은 주제에 대해 설명합니다.

• 일반적으로 특정 플랫폼과 네트워크를 보호하는 메커니즘.
• 모든 ASM(Source Multicast) 및 SSM(Source Specific Multicast) 모델
• 멀티캐스트 MVPN(Virtual Private Network) 보안. 
• 멀티캐스트 데이터 플레인 또는 컨트롤 플레인 트래픽에 대해 기밀성과 무결성을 제공하는 GET(Group Encrypted Transport) VPN(Virtual Private Network) 아키텍처입니다.

용어

IP 멀티캐스트에는 두 가지 기존 서비스 모델이 있습니다.

1. 모든 ASM(Source Multicast)

2. SSM(Source Specific Multicast)

ASM에서 수신기는 IGMP(Internet Group Membership Protocol) 또는 MLD(Multicast Listener Discovery) 멤버십 보고서를 통해 그룹 G에 가입하여 그룹을 나타냅니다. 이 보고서는 모든 소스에서 그룹 G로 전송된 트래픽을 요청하므로 이름이 "any source"입니다. 반면, SSM에서는 수신자가 소스 S에 의해 정의된 특정 채널에 합류하여 그룹 G에 전송합니다. 이러한 서비스 모델 각각에 대해서는 아래에서 자세히 설명합니다.

모든 소스 멀티캐스트

ASM 모델은 두 가지 프로토콜 클래스로 구성됩니다. "dense mode flood-and-prune" 및 "sparse mode explicit join":

i) Dense Mode Flood-and-Prune 프로토콜(DVMRP/MOSPF/PIM-DM)

Dense 모드 프로토콜에서는 네트워크의 모든 라우터가 모든 트리, 해당 소스 및 수신기를 인식합니다. DVMRP(Distance Vector Multicast Routing Protocol) 및 PIM(Protocol Independent Multicast) dense mode 정보와 같은 프로토콜은 전체 네트워크에 "활성 소스" 정보를 플러딩하고, 특정 트리의 트래픽이 원치 않는 토폴로지의 일부에 "Prune State(정리 상태)"를 생성하여 트리를 구축합니다. 플러드 및 정리 프로토콜이라고도 합니다. MOSPF(Multicast Open Shortest Path First)에서는 트리의 구축을 지원하기 위해 네트워크 전체에 수신자에 대한 정보가 플러딩됩니다.

네트워크의 일부 영역에 구축된 모든 트리는 네트워크의 모든 라우터(구성된 경우 관리 범위 내)에 리소스 사용률(컨버전스 영향 포함)을 항상 유발할 수 있으므로 Dense 모드 프로토콜은 바람직하지 않습니다. 이러한 프로토콜은 이 글의 나머지 부분에서 더 이상 논의되지 않는다.

ii) 스파스 모드 명시적 조인 프로토콜(PIM-SM/PIM-BiDir)

스파스 모드 명시적 조인 프로토콜의 경우, 수신자가 그룹에 대한 명시적 IGMP/MLD 멤버십 보고서(또는 "조인")를 전송하지 않는 한 디바이스는 네트워크에서 그룹별 상태를 생성하지 않습니다. ASM의 이 변형은 확장성이 뛰어난 것으로 알려져 있으며 멀티캐스트 중점 패러다임입니다.

이는 대부분의 멀티캐스트 구축에서 이 시점에 사용한 PIM-Sparse Mode의 기본입니다. 이는 많은(소스) - 많은(수신기) 애플리케이션에 점점 더 많이 구축되고 있는 양방향 PIM(PIM-BiDir)의 기반이기도 합니다.

이러한 프로토콜은 "스파스" 수신기 모집단의 IP 멀티캐스트 전달 트리를 효율적으로 지원하고 소스와 수신기 간의 경로에 있는 라우터에서만 컨트롤 플레인 상태를 생성하므로 스파스 모드라고 합니다. 또한 PIM-SM/BiDir에서는 RP(Rendezvous Point)입니다. 네트워크의 다른 부분에서는 상태를 생성하지 않습니다. 라우터의 상태는 다운스트림 라우터 또는 수신자로부터 조인을 수신할 때만 명시적으로 작성됩니다. 따라서 이름은 "명시적 조인 프로토콜"입니다.

PIM-SM과 PIM-BiDir은 모두 "공유 트리"를 사용하므로 모든 소스의 트래픽이 수신자에게 전달될 수 있습니다. 공유 트리의 멀티캐스트 상태를 (*,G) 상태라고 합니다. 여기서 *는 ANY SOURCE의 와일드카드입니다. 또한 PIM-SM은 특정 소스의 트래픽과 관련된 상태 생성을 지원합니다. 이를 SOURCE TREE라고 하며, 관련 상태를 (S,G) 상태라고 합니다.

소스별 멀티캐스트

SSM은 수신기(또는 일부 프록시)가 (S,G) "조인"을 전송하여 소스 S가 그룹 G로 보낸 트래픽을 수신하도록 표시할 때 사용되는 모델입니다. 이는 IGMPv3/MLDv2 "INCLUDE" 모드 멤버십 보고서를 통해 가능합니다. 이 모델을 SSM(Source-Specific Multicast) 모델이라고 합니다. SSM은 라우터 간에 명시적 조인 프로토콜을 사용하도록 지정합니다. 이를 위한 표준 프로토콜은 PIM-SSM이며, 이는 (S,G) 트리를 생성하는 데 사용되는 PIM-SM의 하위 집합입니다. SSM에 공유 트리(*,G) 상태가 없습니다.

따라서 멀티캐스트 수신자는 ASM 그룹 G에 "가입"하거나 SSM(S,G) 채널에 "가입"할 수 있습니다. "ASM 그룹 또는 SSM 채널"이라는 용어가 반복되지 않도록 하기 위해 (멀티캐스트) 플로우라는 용어가 사용됩니다. 이는 플로우가 ASM 그룹 또는 SSM 채널일 수 있음을 의미합니다.

관련 멀티캐스트 프로토콜/패킷 유형

멀티캐스트 네트워크를 보호하려면 일반적으로 발생하는 패킷 유형 및 이를 차단하는 방법을 이해하는 것이 중요합니다. 다음과 같은 세 가지 주요 프로토콜이 있습니다.

1. IGMP / MLD

2. PIM

3. MSDP

다음 절에서는 이러한 각각의 프로토콜과 각각의 프로토콜에서 발생할 수 있는 문제들에 대해 각각 논의한다.

IGMP/MLD 패킷

IGMP/MLD는 멀티캐스트 수신자가 특정 멀티캐스트 그룹에 대한 콘텐츠를 수신할 라우터에 신호를 보내는 데 사용하는 프로토콜입니다. IGMP(Internet Group Membership Protocol)는 IPv4에서 사용되는 프로토콜이고 MLD(Multicast Listener Discovery)는 IPv6에서 사용되는 프로토콜입니다.

일반적으로 구축되는 두 가지 버전의 IGMP는 IGMPv2와 IGMPv3입니다. 또한 일반적으로 구축되는 두 가지 버전의 MLD는 MLDv1과 MLDv2입니다.

IGMPv2와 MLDv1은 기능적으로 동일하며, IGMPv3와 MLDv2는 기능적으로 동일하다.

이러한 프로토콜은 다음 링크에 지정됩니다.

IGMPv2: RFC 2236

MLDv1: RFC 3590

IGMPv3 및 MLDv2: RFC 4604

IGMPv2 및 IGMPv3는 프로토콜일 뿐만 아니라 IPv4 IP 프로토콜(특히 프로토콜 번호 2)입니다. 이 RFC에 설명된 대로 멀티캐스트 그룹 멤버십을 보고하는 데 사용될 뿐만 아니라 DVMRP, PIM 버전 1, mtrace 및 mrinfo 같은 다른 IPv4 멀티캐스트 프로토콜에서도 사용됩니다. 이는 IGMP를 필터링할 때(예: Cisco IOS® ACL을 통해) 기억해야 합니다. IPv6에서 MLD는 IPv6 프로토콜이 아닙니다. 대신 ICMPv6는 MLD 패킷을 전달하는 데 사용됩니다. PIM 버전 2는 IPv4 및 IPv6에서 동일한 프로토콜 유형입니다(프로토콜 번호 103).

PIM 제어 패킷

이 섹션에서는 멀티캐스트 및 유니캐스트 PIM 제어 패킷에 대해 설명합니다. Auto-RP와 BSR(Bootstrap Router)은 PIM-SM 네트워크에서 랑데부 포인트를 선택하고 Group-to-RP 할당을 제어하는 방법입니다.

멀티캐스트 PIM 제어 패킷

멀티캐스트 PIM 제어 패킷에는 다음이 포함됩니다.

• PIM Hello - PIM Hello 패킷은 PIM 인접 디바이스를 설정하기 위해 동일한 네트워크에 연결된 라우터로 전송되는 링크-로컬 범위 IP 멀티캐스트 패킷입니다.
• PIM Join/Prune - PIM Join/Prune은 멀티캐스트 상태를 생성/제거하기 위해 전송되는 링크-로컬 범위 IP 멀티캐스트 패킷이며 PIM 인접 디바이스로만 전송됩니다. 어설션, 보고 억제 및 기타 PIM 프로토콜 세부사항을 용이하게 하기 위해 LAN 내에서 멀티캐스트되지만, 항상 특정 네이버로 전달됩니다.
• PIM DF-elect - PIM Designated Forwarder는 연결된 수신기 또는 다운스트림 PIM 네이버 대신 RP로 전송되는 (*,G) 조인을 담당하는 Bi-Dir PIM 라우터입니다. PIM 라우터가 동일한 그룹 G에 대해 동일한 세그먼트에서 (*,G) JOINS를 전송하는 다른 라우터를 탐지하는 경우, RP에 대한 최상의 경로를 가진 라우터를 확인하는 선택이 있습니다.
• PIM Assert - PIM Assert는 특정 인터페이스(S,G)에 대한 패킷을 특정 인터페이스에서 능동적으로 전달하는 네트워크 세그먼트에 연결된 PIM 라우터가 전달된 동일한(S,G)에 대한 패킷을 동일한 인터페이스에서 수신하기 시작할 때 전송되는 링크 로컬 IP 멀티캐스트 패킷입니다. 이 이벤트는 해당 라우터(S,G)에 대해 SF(Single Forwarder)라고 생각하는 다른 라우터가 있음을 나타냅니다. Assert 메커니즘은 해당(S,G)에 대해 고유한 SF를 선택합니다. PIM SF 라우터는 특정(S,G) 스트림에 대한 패킷을 전달하도록 선택됩니다. PIM을 사용하면 서로 다른 라우터가 서로 다른 (S,G)를 대신하여 SF의 역할을 수행할 수 있습니다. 이상적으로 (S,G)당 SF는 하나뿐입니다. SF와 지정된 라우터를 혼동하지 마십시오. PIM 전용 라우터는 PIM-SM 네트워크의 RP로 전송되는 JOIN/PRUNES 또는 소스 레지스터를 담당하는 라우터입니다.
• PIM 부트스트랩 - PIM 부트스트랩 메시지가 PIMv2 네트워크에서 전송되어 특정 그룹 G에 대한 Rendezvous Point를 동적으로 선택할 수 있게 합니다.

유니캐스트 PIM 제어 패킷

유니캐스트 PIM 제어 패킷은 RP로 전송되거나 RP에서 전송되며 다음과 같습니다.

• Source Register Packet(소스 레지스터 패킷) - PIM 소스 레지스터 패킷을 전송하여 Rendezvous Point에 새 멀티캐스트 소스를 등록합니다. 소스가 멀티캐스트 패킷을 전송하기 시작하면 즉시, 소스 네트워크에 연결된 전용 라우터는 RP에 유니캐스트 레지스터 스트림을 전송하여 RP가 담당하는 멀티캐스트 그룹에 대해 활성 소스가 있음을 나타냅니다.
  소스 레지스터 패킷은 원래 멀티캐스트 스트림의 유니캐스트 캡슐화로서 전송됩니다.
  PIM 레지스터 메시지는 프로세스 레벨 전환되며 RP가 레지스터 중지 메시지를 보낼 때까지만 전송됩니다. 이러한 패킷의 성능 영향은 소스(S,G) 흐름당 속도에 비례합니다.
• Register Stop Packet(등록 중지 패킷) - PIM 등록 중지 패킷은 Rendezvous Point에서 등록 메시지를 전송한 PIM DR로 전송됩니다. Register Stop 메시지는 RP가 소스에서 기본적으로 멀티캐스트 패킷을 수신하기 시작하는 즉시 전송됩니다.
• BSR Candidate-Rendezvous Point Advertisement Packet - PIM BSR C-RP-Advertisement Packets는 BSR이 선택되면 BSR로 전송되어 후보 RP를 광고합니다.

그림 1: PIM 유니캐스트 패킷 

Fig1_PIM_unicast

이러한 패킷을 악용하는 공격은 유니캐스트 패킷이므로 어디서든 발생할 수 있습니다.

라우터에 대한 기본 위협

라우터가 멀티캐스트를 지원하는지, 그리고 공격이 멀티캐스트 트래픽이나 프로토콜을 포함하는지 여부와 관계없이 라우터에 대한 여러 가지 근본적인 위협이 있습니다.

DoS(서비스 거부) 공격은 네트워크에서 가장 중요한 일반 공격 벡터입니다. 원칙적으로 모든 네트워크 요소는 DoS 공격의 표적이 될 수 있으며, 이로 인해 적법한 사용자에 대한 잠재적인 후속 서비스 손실 또는 저하로 요소를 오버로드할 수 있습니다. 유니캐스트에 적용되는 기본 네트워크 보안 권장 사항을 따르는 것이 가장 중요합니다.

멀티캐스트 공격이 항상 의도적인 것이 아니라 종종 우발적인 것이라는 점이 중요합니다. 예를 들어 2004년 3월에 처음 관찰된 위티 웜은 IP 주소에 대한 무작위 공격을 통해 확산된 웜의 한 예입니다. 주소 공간의 완전한 임의 지정으로 인해 멀티캐스트 IP 대상도 웜의 영향을 받았습니다. 많은 조직에서 웜이 여러 가지 다른 멀티캐스트 대상 주소로 패킷을 전송했기 때문에 많은 첫 번째 홉 라우터가 축소되었습니다. 그러나 라우터는 관련 상태 생성과 함께 그러한 멀티캐스트 트래픽 로드의 범위를 정하지 않았으며 효과적으로 리소스 소진을 경험했습니다. 이는 엔터프라이즈에서 멀티캐스트가 사용되지 않는 경우에도 멀티캐스트 트래픽을 보호해야 하는 필요성을 보여줍니다.

라우터에 대한 일반적인 위협은 다음과 같습니다.

• 모든 유형의 패킷 플러드; 예를 들어, 느린(punt) 경로와 같은 하드웨어 경로, SSH(Secure Shell), 텔넷, BGP(Border Gateway Protocol), OSPF, NTP(Network Time Protocol) 등을 포함하는 관리 또는 제어 평면 포트와 같은 소프트웨어 경로에 대해 설명합니다
• 라우터의 기능을 차후에 악용하면서 라우터에 침입하는 행위 약한 텔넷 또는 SSH 암호 및 약한 SNMP(Simple Network Management Protocol) 커뮤니티 문자열은 최신 네트워크에서 흔히 발생하는 문제입니다.
• 컨피그레이션 오류 또는 내부자 공격과 같은 운영 문제는 전체 네트워크 및 해당 트래픽의 보안을 위협할 수 있습니다.
  
  

라우터에서 멀티캐스트가 활성화된 경우 유니캐스트 외에도 보호되어야 합니다. IP 멀티캐스트를 사용해도 근본적인 위협 모델은 변경되지 않습니다. 그러나 공격을 받을 수 있는 추가 프로토콜(PIM, IGMP, MLD, MSDP)을 지원하므로 특별히 보호해야 합니다. 유니캐스트 트래픽이 이러한 프로토콜에서 사용되는 경우 위협 모델은 라우터에서 실행하는 다른 프로토콜과 동일합니다.

멀티캐스트 트래픽은 기본적으로 "수신기 중심"이며 원격 대상을 대상으로 할 수 없기 때문에 라우터를 공격하는 유니캐스트 트래픽과 같은 방식으로 사용할 수 없습니다. 공격 대상이 멀티캐스트 스트림에 명시적으로 "연결"되어야 합니다. 대부분의 경우(Auto-RP가 주요 예외) 라우터는 "링크 로컬" 멀티캐스트 트래픽만 수신 및 수신합니다. 링크 로컬 트래픽은 전달되지 않습니다. 따라서 멀티캐스트 패킷을 사용하는 라우터에 대한 공격은 직접 연결된 공격자에서만 발생할 수 있습니다.

소스 측의 위협

PC 또는 비디오 서버가 네트워크와 동일한 관리 제어 하에 있지 않을 때도 있습니다. 따라서 네트워크 사업자의 입장에서는 송신자가 대부분 신뢰할 수 없는 것으로 취급된다. PC와 서버의 강력한 기능과 복잡한 보안 설정(불완전한 경우가 많음)을 고려할 때 발신자는 멀티캐스트를 비롯한 모든 네트워크에 대해 실질적인 위협을 가합니다. 이러한 위협은 다음과 같습니다.

• 레이어 2 공격: 레이어 2에는 다양한 유형의 공격을 수행하기 위한 다양한 공격 양식이 있습니다. 이는 유니캐스트 및 멀티캐스트에 적용됩니다. 이러한 공격 양식은 멀티캐스트에 국한되지 않으므로 이 문서에서는 자세히 설명하지 않습니다. 자세한 내용은 Cisco 보도 자료 "LAN 스위치 보안", ISBN-10을 참조하십시오. 1-58705-467-1 .
• 멀티캐스트 트래픽으로 공격: 앞서 설명한 것처럼, 그룹에 대한 리스너가 없는 경우 첫 번째 홉 라우터가 멀티캐스트 트래픽을 전달하지 않으므로 멀티캐스트 트래픽으로 공격을 진행하기가 어렵습니다. 그러나 첫 번째 홉은 멀티캐스트 패킷으로 다양한 방법으로 공격을 받을 수 있습니다.
• 네트워크 포화 공격: 공격자는 가용 대역폭의 활용도를 초과하여 멀티캐스트 패킷을 세그먼트로 플러딩할 수 있으며, 이는 DoS 상태로 이어질 수 있습니다.
• 멀티캐스트 상태 공격: 첫 번째 홉 라우터는 멀티캐스트 패킷으로 플러딩되어 너무 많은 상태와 그에 따른 DoS 공격 상태를 생성할 수 있습니다.
• 발신자는 전송된 PIM Hello를 통해 PIM DR이 되려고 시도할 수 있습니다. 이러한 경우 LAN을 오가는 트래픽이 발생하지 않습니다.
• BiDir-PIM DF에 대한 PIM DF 선택 패킷은 스푸핑될 수 있습니다. 이러한 경우 LAN을 오가는 트래픽이 발생하지 않습니다.
• 발신자는 AutoRP RP-discovery 또는 BSR 부트스트랩 메시지를 스푸핑할 수 있습니다. 이렇게 하면 가짜 RP를 효과적으로 알리고 PIM-SM/BiDir 서비스를 중단하거나 중단합니다.
• 발신자는 PIM source register/register-stop 메시지와 같은 유니캐스트 공격을 소싱하거나 BSR 알림 패킷을 보내고 가짜 BSR을 알릴 수 있습니다.
• 필터링되지 않는 한 발신자는 유효한 멀티캐스트 그룹에 전송할 수 있습니다. 소스 주소가 스푸핑되어 에지에서 차단되지 않는 경우, 발신자는 합법적인 발신자의 소스 IP 주소를 사용할 수 있으며, 네트워크의 일부에서 콘텐츠를 재정의할 수 있습니다.
• 컨트롤 플레인 프로토콜에 대한 멀티캐스트 공격: OSPF 및 DHCP(Dynamic Host Configuration Protocol)와 같이 멀티캐스트와 연결되지 않은 여러 프로토콜에서는 멀티캐스트 패킷을 사용하며, 이 패킷을 사용하여 이러한 프로토콜을 공격할 수 있습니다
• 마스커레이드(Masquerade): 발신자가 다른 발신자인 것처럼 가장할 수 있는 여러 공격 양식이 있습니다. 스푸핑된 소스 IP 주소는 그러한 공격 형태 중 하나입니다.
• 서비스 도용: 발신자를 통제하지 않는 한, 발신자 측에서 부정한 방법으로 멀티캐스트 서비스를 이용할 수 있다.

참고: 일반적으로 호스트는 PIM 패킷을 보내거나 받지 않습니다. 이를 수행하는 호스트는 공격을 시도할 수 있습니다.

수신자 측의 위협

또한 수신기는 일반적으로 상당한 CPU 전력 및 대역폭을 사용하는 플랫폼이며 다양한 공격 형태를 허용합니다. 이는 대부분 발신자 측의 위협과 동일합니다. 레이어 2 공격은 중요한 공격 벡터로 남아 있습니다. 공격 벡터가 일반적으로 IGMP(또는 앞서 언급한 대로 레이어 2 공격)라는 점을 제외하면 수신기 측에서도 가짜 수신기 및 서비스 도난이 가능합니다.

Rendezvous Point 및 BSR에 대한 위협

PIM-SM RP 및 PIM-BSR은 멀티캐스트 네트워크의 중요한 지점이므로 공격자의 중요한 표적입니다. 첫 번째 홉 라우터가 아닐 경우 PIM 유니캐스트를 포함하는 유니캐스트 공격 양식만 이러한 요소에 직접 대상이 될 수 있습니다. RP 및 BSR에 대한 위협은 다음과 같습니다.

• "라우터에 대한 기본 위협" 섹션에 설명된 모든 일반 공격 양식
• 스푸핑된 소스 IP 주소를 사용하는 PIM 유니캐스트 공격은 악의적인 디바이스에서 전송하는 PIM 레지스터 또는 레지스터 중지 메시지를 통해 DoS 공격을 허용합니다.

멀티캐스트 및 유니캐스트 보안(비교)

상태 고려 사항/필터

소스, 3개의 수신기(A, B, C), 스위치(S1), 2개의 라우터(R1 및 R2)를 보여 주는 그림 3의 토폴로지를 생각해 보십시오. 파란색 선은 유니캐스트 스트림을 나타내고 빨간색 선은 멀티캐스트 스트림을 나타냅니다. 세 수신기 모두 멀티캐스트 흐름의 멤버입니다.

그림 3: 라우터 및 스위치의 복제

그림 3_replication_RS

특정 소스에서 특정 수신기로의 트래픽 흐름을 금지하려면

• 유니캐스트 스트림의 경우 발신자에서 수신자까지의 경로 어디에나 필터를 설치합니다.
• 그러나 멀티캐스트 스트림의 경우 관리자는 필터를 설치할 위치를 보다 구체적으로 지정해야 합니다. 수신기측 필터에서 수신기까지의 마지막 복제 지점 뒤에 소스 뒤의 첫 번째 복제 지점 앞에 있는 소스 측 필터.

멀티캐스트 소스의 공격

이 섹션은 ASM 및 SSM 서비스 모델 모두에 적용되며, 수신자측 명시적 조인의 수신에 따라 트래픽이 전달됩니다.

유니캐스트 스트림의 경우 암시적 수신기 보호가 없습니다. 유니캐스트 소스는 이 대상에서 트래픽을 요청하지 않은 경우에도 목적지로 트래픽을 전송할 수 있습니다. 따라서 엔드포인트를 보호하기 위해 방화벽과 같은 방어 메커니즘이 일반적으로 사용됩니다. 반면 멀티캐스트는 프로토콜에 내장된 몇 가지 암시적 보호 기능이 있습니다. 트래픽은 문제의 흐름에 합류한 수신기에만 도달하는 것이 좋습니다.

ASM을 사용하면 소스에서 활성 RP에서 지원하는 모든 그룹에 대한 멀티캐스트 트래픽 전송을 통해 트래픽 삽입 또는 DoS 공격을 시작할 수 있습니다. 이 트래픽은 이상적으로는 수신기에 도달하지 않지만, 경로의 첫 번째 홉 라우터 및 제한적인 공격을 허용하는 RP에 최소한 도달할 수 있습니다. 그러나 악의적인 소스가 대상 수신자가 관심 있는 그룹을 알고 적절한 필터가 없는 경우 해당 그룹에 트래픽을 전송할 수 있습니다. 이 트래픽은 수신자가 그룹의 수신 대기하는 동안 수신됩니다.

SSM을 사용하면 원치 않는 소스에 의한 공격은 해당 (S,G) 채널에 참여한 수신자가 없는 경우 트래픽이 중단되는 첫 번째 홉 라우터에서만 가능합니다. 수신기에서 명시적인 조인 상태가 존재하지 않는 모든 SSM 트래픽을 무시하므로 첫 번째 홉 라우터에 대한 상태 공격으로 이어지지 않습니다. 이 모델에서는 "조인"이 소스별로 다르기 때문에 악의적인 소스에서 대상이 어떤 그룹에 관심이 있는지 알기에 충분하지 않습니다. 여기서는 스푸핑된 IP 소스 주소와 잠재적 라우팅 공격이 성공해야 합니다.

국가 공격

네트워크에 수신기가 없어도 PIM-SM은 소스에 가장 가까운 첫 번째 홉 라우터 및 Rendezvous Point에 (S,G) 및 (*,G) 상태를 생성합니다. 따라서 소스 첫 번째 홉 라우터의 네트워크 및 PIM-SM RP에서 상태 공격이 발생할 가능성이 있습니다.

악의적인 소스가 트래픽을 여러 그룹에 전송하기 시작하면 탐지된 각 그룹에 대해 네트워크의 라우터가 소스 및 RP에서 상태를 생성합니다. 단, 문제의 그룹이 RP 컨피그레이션에 의해 허용되어야 합니다.

따라서 PIM-SM은 소스의 상태 및 트래픽 공격을 받습니다. 소스가 올바른 접두사 내에서 소스 IP 주소를 임의로 변경하거나, 다시 말해, 주소의 호스트 비트만 스푸핑되는 경우 공격이 악화될 수 있습니다.

그림 4: ASM RP 공격

그림 4_ASM_RP_Attacks

PIM-SSM과 마찬가지로 소스로부터의 PIM-BiDir 상태 생성 공격은 불가능합니다. PIM-BiDir의 트래픽은 RP로 전달된 트래픽 뿐만 아니라 수신자의 조인에 의해 생성된 상태로 전달됩니다. 따라서 조인은 RP로만 이동하므로 RP 뒤에 있는 수신자에 도달할 수 있습니다. RP로의 상태-전달 트래픽은 (*,G/M) 상태라고 하며 RP 컨피그레이션(정적, 자동 RP, BSR)에 의해 생성됩니다. 출처가 있는 경우에는 변경되지 않습니다. 따라서 공격자는 PIM-BiDir RP에 멀티캐스트 트래픽을 보낼 수 있지만 PIM-SM과 달리 PIM-BiDir RP는 "활성" 엔터티가 아니며 대신 PIM-BiDir 그룹에 대한 트래픽을 전달하거나 버립니다.

참고: 일부 Cisco IOS 플랫폼(*,G/M) 상태는 지원되지 않습니다. 이러한 경우 소스가 여러 PIM-BiDir 그룹에 대한 멀티캐스트 트래픽 전송으로 라우터를 공격할 수 있으며, 이로 인해 (*,G) 상태가 생성됩니다. 예를 들어 Catalyst 6500 스위치는 (*,G/M) 상태를 지원합니다.

수신자가 시작한 공격

공격은 멀티캐스트 수신기에서 발생할 수 있습니다. IGMP/MLD 보고서를 전송하는 모든 수신기는 일반적으로 첫 번째 홉 라우터에 상태를 생성합니다. 유니캐스트에는 상응하는 메커니즘이 없습니다.

그림 5: 수신측 명시적 조인 기반 트래픽 포워딩

그림5_Receiver_Explicit_Join

수신기 공격은 다음 세 가지 유형이 될 수 있습니다.

1. 멀티캐스트 수신자는 승인되지 않은 플로우에 참가를 시도하고 승인되지 않은 콘텐츠를 수신하려고 시도할 수 있습니다.
2. 멀티캐스트 수신기는 여러 그룹 또는 채널에 관심을 가져 잠재적으로 사용 가능한 네트워크 대역폭을 오버로드할 수 있습니다. 이러한 종류의 공격은 다른 잠재적 콘텐츠 수신자에 대한 공유 대역폭 공격이 됩니다.
3. 멀티캐스트 수신기는 라우터 또는 스위치에 대한 공격을 시도할 수 있습니다. 대량의 멀티캐스트 트리 상태를 생성하고 라우터 용량을 과부하 상태로 만들 수 있는 많은 수의 IGMP 보고서를 생성할 수 있습니다. 그러면 멀티캐스트 통합 시간이 증가하거나 라우터의 DoS가 증가할 수 있습니다.
   
   

다음 섹션인 Security within a Multicast Network(멀티캐스트 네트워크 내의 보안)에서 이러한 종류의 공격을 완화하는 다양한 방법

멀티캐스트 네트워크 내의 보안

네트워크 요소 보안

보안은 포인트 기능이 아니라 모든 네트워크 설계의 본질적인 부분입니다. 따라서 네트워크의 모든 지점에서 보안을 고려해야 합니다. 모든 네트워크 요소를 적절하게 보호하는 것이 무엇보다 중요합니다. 모든 기술에 적용할 수 있는 한 가지 가능한 공격 시나리오는 침입자에 의해 파괴되는 라우터입니다. 침입자가 라우터를 제어하게 되면 공격자는 다양한 공격 시나리오를 실행할 수 있습니다. 따라서 각 네트워크 요소는 모든 유형의 기본 공격은 물론 특정 멀티캐스트 공격에도 적절하게 보호되어야 합니다.

LPTS(Local Packet Transport Service)

Cisco IOS XR에서 LPTS(Local Packet Transport Service)는 Cisco IOS의 CoPP와 마찬가지로 라우터의 컨트롤 플레인에 대한 트래픽의 폴리서 역할을 합니다. 또한 유니캐스트 및 멀티캐스트 트래픽을 포함하는 수신 트래픽을 필터링하고 속도를 제한할 수 있습니다.

멀티캐스트 전용 보안

멀티캐스트 지원 네트워크에서 각 네트워크 요소는 멀티캐스트 전용 보안 기능으로 보호되어야 합니다. 이 섹션에서는 일반 라우터 보호를 위해 간략하게 설명합니다. 모든 라우터에 필요하지 않지만 네트워크의 특정 위치에만 필요한 기능 및 라우터 간의 상호 작용(예: PIM 인증)이 필요한 기능에 대해서는 다음 섹션에서 설명합니다.

ip multicast route-limit <mroute-limit> <warning-threshold>

그림 6: Mroute 제한

그림 6_Mroute_Limits

Mroute 제한은 멀티캐스트 라우팅 테이블에 허용된 mroute 수에 대한 임계값을 설정할 수 있도록 합니다. 멀티캐스트 경로 제한이 활성화된 경우 구성된 제한을 초과하는 멀티캐스트 상태가 생성되지 않습니다. 경고 임계값도 있습니다. 경로 수가 경고 임계값을 초과하면 syslog 경고 메시지가 트리거됩니다. 경로 제한에서 상태를 트리거할 추가 패킷은 삭제됩니다.

ip multicast route-limit 명령도 MVRF별로 사용할 수 있습니다.

ip multicast mrinfo-filter 51
		
access-list 51 deny 192.168.1.1
access-list 51 permit any

ip multicast mrinfo-filter 52

access-list 52 deny any

ip multicast group-range <std-acl>  
ipv6 multicast group-range <std-acl>  

ip pim register-rate-limit <count> 		   

ip pim rp-announce-filter

ip multicast boundary 
              
               
               
 
               
access-list 1 deny 224.0.1.39 
               
access-list 1 deny 224.0.1.40 
               
 
               
224.0.1.39 (RP-announce) 224.0.1.40 (RP-discover) 
               
 
              

그림10_Mcast_Boundary

그림13_Interdomain_Filter

컨트롤 플레인을 보호하려면 세 가지 기본 보안 조치를 통해 MSDP를 강화합니다.

1) MSDP SA 필터

MSDP SA 필터를 통해 MSDP 메시지의 내용을 필터링하는 것은 "모범 사례"입니다. 이 필터의 주요 아이디어는 인터넷 전반의 애플리케이션이 아니며 소스 도메인을 넘어 포워딩할 필요가 없는 애플리케이션 및 그룹에 대한 멀티캐스트 상태의 전파를 방지하는 것입니다. 보안의 관점에서 볼 때, 필터는 알려진 그룹(및 잠재적으로 발신자)만 허용하고 알 수 없는 발신자 및/또는 그룹은 거부하는 것이 좋습니다.

일반적으로 허용되는 모든 발신자 및/또는 그룹을 명시적으로 나열할 수는 없습니다. 모든 그룹(MSDP 메시 그룹 없음)에 대해 단일 RP가 있는 PIM-SM 도메인의 기본 컨피그레이션 필터를 사용하는 것이 좋습니다.

!--- Filter MSDP SA-messages. 
         !--- Replicate the following two rules for every external MSDP peer. 
         !
         ip msdp sa-filter in <peer_address> list 111
         ip msdp sa-filter out <peer_address> list 111
         !
         !--- The redistribution rule is independent of peers.
         !
         ip msdp redistribute list 111
         !
         !--- ACL to control SA-messages originated, forwarded. 
         !
         !--- Domain-local applications.
         access-list 111 deny   ip any host 224.0.2.2     ! 
         access-list 111 deny   ip any host 224.0.1.3     ! Rwhod
         access-list 111 deny   ip any host 224.0.1.24    ! Microsoft-ds 
         access-list 111 deny   ip any host 224.0.1.22    ! SVRLOC
         access-list 111 deny   ip any host 224.0.1.2     ! SGI-Dogfight
         access-list 111 deny   ip any host 224.0.1.35    ! SVRLOC-DA
         access-list 111 deny   ip any host 224.0.1.60    ! hp-device-disc
         !--- Auto-RP groups.
         access-list 111 deny   ip any host 224.0.1.39 
         access-list 111 deny   ip any host 224.0.1.40
         !--- Scoped groups.
         access-list 111 deny   ip any 239.0.0.0 0.255.255.255
         !--- Loopback, private addresses (RFC 6761).
         access-list 111 deny   ip 10.0.0.0 0.255.255.255 any
         access-list 111 deny   ip 127.0.0.0 0.255.255.255 any
         access-list 111 deny   ip 172.16.0.0 0.15.255.255 any
         access-list 111 deny   ip 192.168.0.0 0.0.255.255 any
         !--- Default SSM-range. Do not do MSDP in this range.
         access-list 111 deny   ip any 232.0.0.0 0.255.255.255
         access-list 111 permit ip any any
         !

가능한 한 엄격하게 필터링하는 것이 좋으며 인바운드 및 아웃바운드 양방향으로 필터링하는 것이 좋습니다.

MSDP SA 필터 권장 사항에 대한 자세한 내용은 다음을 참조하십시오. https://www.cisco.com/c/en/us/support/docs/ip/ip-multicast/13717-49.html

ip msdp sa-limit <peer> <limit> 

그림14_MSDP_ControlPlane

ip msdp sa-limit 명령을 사용하면 MSDP 피어에서 수락된 SA 메시지로 인해 생성된 SA 상태의 수를 제한할 수 있습니다. 몇 가지 간단한 경험적 권장 사항은 다음과 같습니다.

• stub-neighbor의 작은 제한 
• 트랜짓 네이버의 큰 제한(예: 인터넷의 최대 #SAs)
• 트랜짓 ISP - 플랫폼에서 지원할 수 #SAs 최대 구성

3) MSDP MD5 네이버 인증

MSDP 피어에서 MD5(Message-Digest Algorithm) 비밀번호 인증을 사용하는 것이 좋습니다. 이는 RFC 6691에서 BGP를 보호하는 데 사용하는 것과 동일한 TCP MD5 서명 옵션을 사용합니다.

그림 15: MSDP MD5 네이버 인증

Fig15_MSDP_MD5Auth

이러한 세 가지 MSDP 보안 권장 사항은 서로 다른 목표를 추구합니다.

• 인접 디바이스 인증(MD5 사용)을 통해 신뢰할 수 있는 MSDP 피어만 메시지를 보낼 수 있습니다.
• SA 필터는 신뢰할 수 있는 MSDP 피어도 사전 합의된 소스/그룹 정책에 부합하는 SA 알림만 보낼 수 있도록 보장합니다.
• SA 제한은 또한 합법적인 피어로부터의 합법적인(S,G) 공지를 사용하더라도 사용 가능한 메모리를 소진할 수 없도록 합니다.

발신자/소스 문제

발신자에서 발생하는 많은 멀티캐스트 보안 문제는 적절한 유니캐스트 보안 메커니즘으로 완화할 수 있습니다. 여기에는 여러 유니캐스트 보안 메커니즘이 권장됩니다.

• 소스 주소 스푸핑 보호(액세스 계층의 유니캐스트 역방향 경로 전달, uRPF 또는 ACL 및 IP 소스 보호)
• 인프라 ACL(deny ip any (to) <core address space>)

그러한 조치는 코어에 대한 직접적인 공격을 차단하는 데 사용될 수 있다. 예를 들어, 이는 RP에 대한 PIM 유니캐스트 패킷을 사용하는 공격과 같은 문제도 해결합니다. RP는 네트워크 "내부"이므로 인프라 ACL에 의해 보호됩니다.

패킷 필터 기반 액세스 제어 - 제어 소스

그림 16의 예에서는 필터가 1홉 멀티캐스트 라우터(Designated Router)의 LAN 인터페이스(E0)에 구성됩니다. 필터는 "source"라는 확장 액세스 제어 목록에 의해 정의됩니다. 이 ACL은 소스 LAN에 연결된 Designated Router의 소스 연결 인터페이스에 적용됩니다. 실제로 멀티캐스트 트래픽의 특성 때문에 소스가 활성화될 수 있는 모든 LAN 연결 인터페이스에 유사한 필터를 구성해야 할 수 있습니다. 어떤 경우에는 소스 활동이 어디에서 발생하는지 정확히 알 수 없으므로 네트워크의 모든 인그레스 포인트에 이러한 필터를 적용하는 것이 좋습니다.

그림 16: 제어 소스

Fig16_Controlling_Sources

ip pim accept-register / ipv6 pim accept-register

그림17_PIMSM_Control

PIM-SM 네트워크에서 원치 않는 트래픽 소스는 이 명령으로 제어할 수 있습니다. 소스 트래픽이 첫 번째 홉 라우터에 도달하면 첫 번째 홉 라우터(DR)는 (S,G) 상태를 생성하고 RP에 PIM Source Register 메시지를 보냅니다. 소스가 RP에 구성된 accept-register 필터 목록에 나열되지 않은 경우 RP는 등록을 거부하고 즉시 Register-Stop 메시지를 DR로 다시 보냅니다.

표시된 예에서는 소스 주소에서만 필터링하는 간단한 ACL이 RP에 적용되었습니다. RP에서 확장 ACL을 사용하여 소스 및 그룹을 필터링할 수도 있습니다.

RP에서 pim accept-register 명령을 사용하면 소스의 첫 번째 홉 라우터에서 PIM-SM(S,G) 상태가 계속 생성되므로 소스 필터의 단점이 있습니다. 이 경우 수신기에서 소스에 대해 로컬이고 소스와 RP 사이에 위치한 트래픽이 발생할 수 있습니다. 또한 pim accept-register 명령은 RP의 제어 플레인에서 작동합니다. 이는 가짜 레지스터 메시지로 RP를 오버로드하기 위해 사용될 수 있으며, DoS 상태를 유발할 수 있습니다.

모든 DR의 간단한 데이터 플레인 ACL을 네트워크에 모든 인그레스 포인트에 적용하는 것과 같은 다른 방법 외에도 RP에 pim accept-register 명령을 적용하는 것이 좋습니다. DR의 인그레스 ACL은 완벽하게 구성되고 운영되는 네트워크에서는 충분하지만 에지 라우터에서 잘못 구성된 경우 RP에 pim accept-register 명령을 보조 보안 메커니즘으로 구성하는 것이 좋습니다. 동일한 목표를 가진 계층화된 보안 메커니즘을 "심층 방어"라고 하며, 보안의 일반적인 설계 원칙입니다.

수신기 문제 - 제어 IGMP/MLD

대부분의 수신기 문제는 IGMP/MLD 수신기 프로토콜 상호 작용의 도메인에 속합니다.

그림 18: 제어 IGMP

그림18_Controlling_IGMP

IGMP 또는 MLD 패킷이 필터링되면 다음 사항을 기억하십시오.

• IPv4: IGMP는 IPv4 프로토콜 유형(IPv4 프로토콜 2)입니다
• IPv6: MLD는 ICMPv6 프로토콜 유형 패킷에서 전달됩니다

IP Multicast가 활성화되자마자 IGMP 프로세스가 기본적으로 활성화됩니다. IGMP 패킷도 이러한 프로토콜을 전달하므로 멀티캐스트가 활성화될 때마다 이러한 모든 프로토콜이 활성화됩니다.

• PIMv1 - PIMv1은 PIM의 첫 번째 버전이며 마이그레이션을 위해 Cisco IOS에서 항상 활성화됩니다. 현재 구축에서는 모두 PIMv2를 사용합니다.
• Mrinfo - Mrinfo는 Cisco IOS가 멀티캐스트 네이버를 표시하기 위해 상속한 Unix 명령입니다. mrinfo 명령 대신 SNMP를 사용하는 것이 좋습니다.
• DVMRP - DVMRP는 확장 특성이 매우 제한적인 레거시 고밀도 모드 거리 벡터 프로토콜입니다. DVMRP에 대한 Cisco IOS 지원이 중단되었거나 이미 더 이상 사용되지 않습니다.
• Mtrace - Mtrace는 유니캐스트 "traceroute"의 멀티캐스트 버전이며 유용한 툴입니다

자세한 내용은 IANA의 IGMP(Internet Group Management Protocol) 유형 번호를 참조하십시오

Router> mtrace 172.16.0.0 172.16.0.10 239.254.254.254
		
Type escape sequence to abort.
Mtrace from 172.16.0.0 to 172.16.0.10 via group 239.254.254.254
From source (?) to destination (?)
Querying full reverse path... 
 0  172.16.0.10
-1  172.16.0.8 PIM  thresh^ 0  0 ms 
-2  172.16.0.6 PIM  thresh^ 0  2 ms 
-3  172.16.0.5 PIM  thresh^ 0  894 ms 
-4  172.16.0.3 PIM  thresh^ 0  893 ms 
-5  172.16.0.2 PIM  thresh^ 0  894 ms 
-6  172.16.0.1 PIM  thresh^ 0  893 ms 

유니캐스트 IGMP 패킷(IGMP/UDLR용)은 필터링할 수 있습니다. 이는 공격 패킷일 가능성이 높고 유효한 IGMP 프로토콜 패킷이 아니기 때문입니다. 유니캐스트 IGMP 패킷은 단방향 링크 및 기타 예외 조건을 지원하기 위해 Cisco IOS에서 지원됩니다.

위조된 IGMP/MLD 쿼리 패킷은 예상한 것보다 낮은 IGMP 버전을 초래할 수 있습니다.

특히 하위 IGMP 버전으로 전송된 쿼리는 이 쿼리를 수신하는 모든 호스트가 하위 버전으로 되돌아갈 수 있기 때문에 호스트는 IGMP 쿼리를 보내지 않는 것이 좋습니다. IGMPv3/SSM 호스트가 있는 경우 SSM 스트림을 "공격"할 수 있습니다. IGMPv2의 경우 이로 인해 대기 시간이 더 길어질 수 있습니다.

단일 IGMP 쿼리 기가 있는 비이중화 LAN이 있는 경우 라우터는 수신된 IGMP 쿼리를 삭제해야 합니다.

이중화/공통 패시브 LAN이 있는 경우 IGMP 스누핑을 지원하는 스위치가 필요합니다. 이 경우 다음과 같은 두 가지 특정 기능을 사용할 수 있습니다.

• 라우터 가드
• IGMP 최소 버전 명령

라우터 가드

스위치가 해당 포트에서 멀티캐스트 라우터 제어 패킷(IGMP 일반 쿼리, PIM Hello 또는 CGMP Hello)을 수신하는 경우 모든 스위치 포트는 멀티캐스트 라우터 포트가 될 수 있습니다. 스위치 포트가 멀티캐스트 라우터 포트가 되면 모든 멀티캐스트 트래픽이 해당 포트로 전송됩니다. 이 문제는 "Router Guard"를 통해 방지할 수 있습니다. Router Guard 기능은 IGMP 스누핑을 활성화하지 않아도 됩니다.

Router Guard 기능을 사용하면 지정된 포트를 멀티캐스트 호스트 포트로 지정할 수 있습니다. 멀티캐스트 라우터 제어 패킷이 수신되더라도 포트가 라우터 포트가 될 수 없습니다.

이러한 패킷 유형은 Router Guard가 활성화된 포트에서 수신될 경우 폐기됩니다.

• IGMP 쿼리 메시지
• IPv4 PIMv2 메시지
• IGMP PIM 메시지(PIMv1)
• IGMP DVMRP 메시지
• 라우터 포트 RGMP(Group Management Protocol) 메시지
• CGMP(Cisco Group Management Protocol) 메시지

이러한 패킷이 폐기되면 Router Guard로 인해 패킷이 삭제되었음을 나타내는 통계가 업데이트됩니다.

IGMP 최소 버전

허용되는 IGMP 호스트의 최소 버전을 구성할 수 있습니다. 예를 들어 모든 IGMPv1 호스트 또는 모든 IGMPv1 및 IGMPv2 호스트를 허용하지 않을 수 있습니다. 이 필터는 멤버십 보고서에만 적용됩니다.

호스트가 공통 "패시브" LAN에 연결된 경우(예: IGMP 스누핑을 지원하지 않거나 구성되지 않은 스위치), 라우터가 이러한 잘못된 쿼리에 대해 수행할 수 있는 작업은 트리거된 "이전 버전" 멤버십 보고서를 무시하는 것 외에 없으며 자체적으로 축소되지 않습니다.

IGMP 쿼리는 모든 호스트에 표시되어야 하므로, 고정 키 IPSec과 같은 사전 공유 키와 함께 HMAC(Hash-based message authentication) 메커니즘을 사용하여 "유효한 라우터"에서 IGMP 쿼리를 인증할 수는 없습니다. 두 개 이상의 라우터가 공통 LAN 세그먼트에 연결된 경우 IGMP 쿼리 발생기 선택이 필요합니다. 이 경우 사용할 수 있는 유일한 필터는 쿼리를 전송하는 다른 IGMP 라우터의 소스 IP 주소를 기반으로 하는 ip 액세스 그룹 필터입니다.

"일반" 멀티캐스트 IGMP 패킷을 허용해야 합니다.

이 필터는 수신기 포트에서 "정상" IGMP 패킷만 허용하고 알려진 "불량" 패킷을 필터링하는 데 사용할 수 있습니다.

ip access-list extended igmp-control
   <snip>
   deny   igmp any any  pim        ! No PIMv1
   deny   igmp any any  dvmrp      ! No DVMRP packets
   deny   igmp any any  host-query ! Do not use this command with redundant routers. 
                                   ! In that case this packet type is required !								   
   permit igmp any host 224.0.0.22 ! IGMPv3 membership reports
   permit igmp any any  14         ! Mtrace responses
   permit igmp any any  15         ! Mtrace queries 
   permit igmp any 224.0.0.0 10.255.255.255 host-query  ! IGMPv1/v2/v3 queries
   permit igmp any 224.0.0.0 10.255.255.255 host-report ! IGMPv1/v2 reports
   permit igmp any 224.0.0.0 10.255.255.255 7           ! IGMPv2 leave messages
   deny   igmp any any             ! Implicitly deny unicast IGMP here!
   <snip>
   permit ip   any any             ! Permit other packets

interface ethernet 0
   ip access-group igmp-control in

참고: 이 유형의 IGMP 필터는 수신 ACL 또는 CoPP에 사용할 수 있습니다. 두 애플리케이션 모두에서 라우팅 및 관리 플레인 프로토콜과 같이 처리되는 다른 트래픽에 대한 필터와 결합해야 합니다. 

그림 19: 호스트 수신측 액세스 제어

그림19_Host_Receiver_Access

ip igmp access-group / ipv6 mld access-group

access-list 1 deny 226.1.0.0 0.0.255.255
access-list 1 permit any log
!
interface ethernet 1/3
 ip igmp access-group 1

ip access-list extended test5
 deny igmp host 10.4.4.4 host 232.2.30.30
 permit igmp any any
!
interface Ethernet0/3
 ip igmp access-group test5

ip igmp limit <n> [ except <ext-acl> ]
ipv6 mld limit <n> [ except <ext-acl> ]

ip access-list extended channel-guides
  permit ip any host 239.255.255.254 ! SDR announcements
  deny   ip any any
  
ip igmp limit 1 except channel-guides

interface ethernet 0
  ip igmp limit 2 except channel-guides

그림20_PerInterface_IGMP

ip multicast limit [ rpf | out | connected ] <ext-acl> <max>

ip multicast limit cost <ext-acl> <multiplier>

ip multicast limit cost acl-MP2SD-channels   4000 ! from any provider
ip multicast limit cost acl-MP2HD-channels  18000 ! from any provider
ip multicast limit cost acl-MP4SD-channels   1600 ! from any provider
ip multicast limit cost acl-MP4HD-channels   6000 ! from any provider
!
interface Gig0/0
description --- Interface towards DSLAM ---
<snip> 
! CAC
ip multicast limit out 250000 acl-CP1-channels
ip multicast limit out 250000 acl-CP2-channels
ip multicast limit out 250000 acl-CP3-channels

permit ip 10.0.0.0   0.255.255.255   10.0.0.0   0.255.255.255

permit ip any 239.192.0.0 0.0.255.255

GET VPN을 사용하여 컨트롤 플레인 트래픽 인증

일반적으로 라우팅 프로토콜과 같은 컨트롤 플레인 트래픽을 인증하여 메시지가 신뢰할 수 있는 피어에서 오도록 하는 것이 좋습니다. 이는 BGP와 같은 유니캐스트를 사용하는 컨트롤 플레인 프로토콜의 경우 비교적 간단합니다. 그러나 많은 컨트롤 플레인 프로토콜에서 멀티캐스트 트래픽을 사용합니다. 예를 들면 OSPF, RIP, PIM이 있습니다. 전체 목록은 IANA의 IPv4 멀티캐스트 주소 공간 레지스트리를 참조하십시오.

이러한 프로토콜 중 일부는 RIP(Routing Information Protocol) 또는 EIGRP(Enhanced Interior Group Routing Protocol)와 같은 내장형 인증이 있으며, 다른 일부는 IPSec을 사용하여 이 인증을 제공합니다(예: OSPFv3, PIM). 후자의 경우 GET VPN은 이러한 프로토콜을 보호하는 확장 가능한 방법을 제공합니다. 대부분의 경우, 요구 사항은 프로토콜 메시지 인증, 즉 메시지가 신뢰할 수 있는 피어에 의해 전송되었음을 확인하는 것입니다. 그러나 GET VPN은 이러한 메시지의 암호화도 허용합니다.

이러한 컨트롤 플레인 트래픽을 보호하려면(일반적으로 인증만) ACL로 트래픽을 설명하고 GET VPN 정책에 포함해야 합니다. 세부 정보는 보호할 프로토콜에 따라 다릅니다. 여기서 ACL에 인그레스 GET VPN 노드(캡슐화됨)만 통과하는 트래픽 또는 이그레스 노드도 포함되는지 확인해야 합니다.

PIM 프로토콜을 보호하는 두 가지 기본적인 방법이 있습니다.

• 허용 ip any 224.0.0.13 0.0.0.0: 이는 "All PIM Routers" 멀티캐스트 그룹입니다. 그러나 유니캐스트 PIM 메시지는 보호하지 않습니다
• permit pim any any: 이는 멀티캐스트 또는 유니캐스트 사용 여부와 상관없이 PIM 프로토콜을 보호합니다

참고: 이 명령은 개념을 설명하는 데 도움이 되는 예로 제공됩니다. 예를 들어, BSR 또는 Auto-RP와 같이 PIM을 부트스트랩하는 데 사용되는 특정 PIM 프로토콜을 제외해야 합니다. 모든 방법에는 구축에 따라 특정 장점과 불편함이 있습니다. 자세한 내용은 GET VPN으로 PIM을 보호하는 방법에 대한 특정 문헌을 참조하십시오.

결론

네트워크에서 멀티캐스트가 점점 더 보편화되고 있습니다. 가정용/가정용 광대역 네트워크에서 IPTV 서비스의 등장과 전 세계 많은 금융 시장에서 전자 거래 애플리케이션으로의 전환은 멀티캐스트를 절대적인 요구 사항으로 만드는 요구 사항의 두 가지 예에 불과합니다. 멀티캐스트는 다양한 구성, 운영 및 관리 문제를 수반합니다. 핵심 과제 중 하나는 보안입니다.

이 문서에서는 멀티캐스트를 보호할 수 있는 다양한 방법을 살펴보았습니다.

• 먼저 전반적인 멀티캐스트 제어 및 데이터 플레인을 살펴보고, 유니캐스트와의 차이점이 새로운 보안 문제를 어떻게 야기하는지 설명합니다.
• 다음으로, 멀티 캐스트 네트워크에서 발생하는 주요 프로토콜, 특히 IGMP, PIM, MSDP에 대한 검토를 좀 더 자세히 살펴보았다. 각 사례마다 보안 위협에 대한 설명과 이러한 위협을 완화하기 위한 권장 모범 사례가 제공되었습니다.
• 또한 특정 비디오 플로우에 필요한 대역폭의 양에 비해 대역폭이 제한될 수 있는 광대역 에지 네트워크와 같은 일부 특정 애플리케이션에서 멀티캐스트를 보호하는 방법의 특정 예가 있습니다.
• 마지막으로, GET VPN 아키텍처는 보안 VPN을 제공하기 위해 IPSec과 통합된 멀티캐스트를 사용하는 수단으로 설명되었습니다.

멀티캐스트 보안을 염두에 두고 유니캐스트와 어떻게 다른지 기억하십시오. 멀티캐스트 전송은 동적 상태 생성을 기반으로 하며, 멀티캐스트는 동적 패킷 복제를 포함하며, 멀티캐스트는 PIM JOIN/PRUNE 메시지에 응답하여 단방향 트리를 구축합니다. 이 전체 환경의 보안에는 Cisco IOS 명령의 풍부한 프레임워크를 이해하고 구축하는 작업이 포함됩니다. 이러한 명령은 주로 프로토콜 작업, 상태(멀티캐스트) 또는 CoPP와 같은 패킷에 대해 배치된 폴리서의 보호를 중심으로 합니다. 이러한 명령을 올바르게 사용하면 IP 멀티캐스트에 대해 강력한 보호 서비스를 제공할 수 있습니다.

요약하면, 이 문서에서는 여러 가지 접근 방식을 장려하고 설명합니다.

1. SSM의 광범위한 사용 - (S,G) 포워딩도 사용할 수 있는 가장 간단한 PIM 모드입니다. 
2. ASM 서비스가 필요한 경우 강력한 서비스를 제공할 수 있는지 확인합니다. 고정 정의된 RP를 사용하면 동적 RP 알림보다 더 안전한 컨트롤 플레인이 제공됩니다. Auto-RP 및 BSR이 더 유연함
3. PIM-SM이 활성화된 경우 RP에 대한 레지스터 터널과 같은 특정 취약성의 영역을 살펴보고 DR이 항상 잘 보호되는지 확인합니다. CoPP는 이러한 영역에서 매우 유용합니다.
4. 도메인 간 ASM 서비스가 필요한 경우 BiDir PIM을 구축할 수 있는지 여부를 고려합니다.
5. 글로벌 mroute/igmp 상태 제한 사용 - 정상적인 상황 및 최악의 경우 필요한 최대 상태의 예상과 함께 플랫폼의 기능을 이해합니다. 플랫폼의 기능 내에서 제한을 구성하여 네트워크가 최대 한도까지 작동하도록 합니다.
6. 기본 필터 - 액세스 레이어에서 PIM을 차단하는 rACL/CoPP 및 인프라 ACL

IP 멀티캐스트는 다양한 애플리케이션 서비스를 제공하기 위한 흥미롭고 확장 가능한 수단입니다. 유니캐스트와 마찬가지로 다양한 영역에서 보안이 되어야 합니다. 이 문서에서는 IP 멀티캐스트 네트워크를 보호하는 데 사용할 수 있는 기본 구성 요소를 제공합니다.

관련 정보

• 엔터프라이즈 IP 멀티캐스트 주소 할당 지침
• IPv4 IGMP 필터 구성
• 그룹 암호화 전송 VPN