Sichere IP-Multicast-Bereitstellungen

Einleitung

Dieses Dokument beschreibt allgemeine Richtlinien zu Best Practices für den Schutz einer IP-Multicast-Netzwerkinfrastruktur.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• IP-Multicast

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle verstehen.

Hintergrundinformationen

In diesem Dokument werden einige grundlegende Konzepte und Begriffe beschrieben und die folgenden Themen behandelt:

• Mechanismen zur Sicherung einer bestimmten Plattform und des Netzwerks im Allgemeinen.
• Alle Modelle für Source Multicast (ASM) und Source Specific Multicast (SSM).
• Multicast Virtual Private Network (MVPN)-Sicherheit. 
• Group Encrypted Transport (GET) Virtual Private Network (VPN)-Architektur zur Gewährleistung der Vertraulichkeit und Integrität des Datenverkehrs auf Multicast- oder Kontrollebene.

Terminologie

Im IP-Multicast gibt es zwei klassische Servicemodelle:

1. Any Source Multicast (ASM)

2. Source Specific Multicast (SSM)

In ASM wird der Empfänger über einen IGMP- (Internet Group Membership Protocol) oder MLD-Mitgliedschaftsbericht (Multicast Listener Discovery) zu einer Gruppe G hinzugefügt, um die Gruppe anzugeben. In diesem Bericht wird Datenverkehr angefordert, der von einer beliebigen Quelle an die Gruppe G gesendet wird, und somit der Name "any source". In SSM hingegen schließt sich der Empfänger einem bestimmten Kanal an, der durch eine Quelle S definiert ist, die an eine Gruppe G sendet. Jedes dieser Dienstmodelle wird nachfolgend näher beschrieben.

Beliebiges Quell-Multicast

Das ASM-Modell ist durch zwei Protokollklassen gekennzeichnet: "Dense Mode Flood-and-Prune" und "Sparse Mode Explicit Join":

i) Flood-and-Prune-Protokolle mit dichtem Modus (DVMRP/MOSPF/PIM-DM)

Bei Protokollen im Dense-Modus erkennen alle Router im Netzwerk alle Trees, ihre Quellen und Empfänger. Protokolle wie das Distance Vector Multicast Routing Protocol (DVMRP) und das Protocol Independent Multicast (PIM) Dense Mode übertragen "Active Source"-Informationen über das gesamte Netzwerk und erstellen Trees durch die Erstellung von "Prune State" in Teilen der Topologie, in denen der Datenverkehr für einen bestimmten Tree unerwünscht ist. Sie werden auch als Flood-and-Prune-Protokolle bezeichnet. In Multicast Open Shortest Path First (MOSPF) werden Informationen zu Empfängern durch das gesamte Netzwerk geleitet, um die Erstellung von Bäumen zu unterstützen.

Protokolle für den dichten Modus sind unerwünscht, da jeder in einem Teil des Netzwerks erstellte Tree immer die Ressourcennutzung (mit Auswirkungen auf die Konvergenz) auf allen Routern im Netzwerk (oder, falls konfiguriert, innerhalb des administrativen Bereichs) verursachen kann. Diese Protokolle werden im weiteren Verlauf dieses Artikels nicht näher erläutert.

ii) Explizite Verbindungsprotokolle im Sparse-Mode (PIM-SM/PIM-BiDir)

Bei expliziten Zusammenführungsprotokollen im Sparse-Mode erzeugen Geräte keinen gruppenspezifischen Zustand im Netzwerk, es sei denn, ein Empfänger hat einen expliziten IGMP/MLD-Mitgliedschaftsbericht (oder "Join") für eine Gruppe gesendet. Diese ASM-Variante lässt sich gut skalieren und ist das Multicast-Paradigma des Fokus.

Dies ist die Grundlage für den PIM-Sparse-Mode, den die meisten Multicast-Bereitstellungen bisher verwendet haben. Dies ist auch die Grundlage für das bidirektionale PIM (PIM-BiDir), das zunehmend für VIELE Anwendungen (Quellen) zu VIELEN Anwendungen (Empfängern) bereitgestellt wird.

Diese Protokolle werden als Sparse-Mode bezeichnet, da sie IP-Multicast-Bereitstellungsbäume mit einer "spärlichen" Empfängerpopulation effizient unterstützen und einen Status auf der Kontrollebene nur auf Routern im Pfad zwischen Quellen und Empfängern und im PIM-SM/BiDir, dem Rendezvous Point (RP), erstellen. In anderen Teilen des Netzwerks wird niemals ein Zustand erzeugt. Der Status eines Routers wird nur dann explizit erstellt, wenn er einen Join von einem Downstream-Router oder -Empfänger erhält. Daher wird der Name "Explicit Join Protocols" (Explizite Join-Protokolle) verwendet.

Sowohl PIM-SM als auch PIM-BiDir verwenden "SHARED TREES", um die Weiterleitung von Datenverkehr von einer beliebigen Quelle an einen Empfänger zu ermöglichen. Der Multicast-Status in einem Shared Tree wird als (*,G)-Status bezeichnet, wobei das * für JEDE QUELLE ein Platzhalter ist. Darüber hinaus unterstützt PIM-SM die Erstellung eines Status, der sich auf den Datenverkehr von einer bestimmten Quelle bezieht. Diese werden als SOURCE TREES bezeichnet, und der zugehörige Status wird als (S,G)-Status bezeichnet.

Source-Specific Multicast

SSM ist das Modell, das verwendet wird, wenn der Empfänger (oder ein Proxy) "Joins" sendet (S,G), um anzuzeigen, dass er Datenverkehr empfangen möchte, der von der Quelle S an Gruppe G gesendet wird. Dies ist mit IGMPv3/MLDv2-Mitgliedschaftsberichten im "INCLUDE"-Modus möglich. Dieses Modell wird als SSM-Modell (Source-Specific Multicast) bezeichnet. SSM erfordert die Verwendung eines Explicit-Join-Protokolls zwischen Routern. Das Standardprotokoll hierfür ist PIM-SSM, das einfach die Teilmenge von PIM-SM ist, die zum Erstellen von (S,G)-Bäumen verwendet wird. In SSM gibt es keine Shared Trees (*,G).

Multicast-Empfänger können somit einer ASM-Gruppe G "beitreten" oder einem SSM-Kanal (S,G) "beitreten" (oder genauer gesagt "abonnieren"). Um eine Wiederholung des Begriffs "ASM-Gruppe oder SSM-Kanal" zu vermeiden, wird der Begriff (Multicast)-Fluss verwendet, was bedeutet, dass es sich bei dem Fluss um eine ASM-Gruppe oder einen SSM-Kanal handeln könnte.

Relevante Multicast-Protokolle/-Pakettypen

Zum Sichern eines Multicast-Netzwerks ist es wichtig, die gängigen Pakettypen zu kennen und sich vor diesen zu schützen. Es gibt drei Hauptprotokolle, die betroffen sein sollten:

1. IGMP/MLD

2. PIM

3. MSDP

Im nächsten Abschnitt werden diese Protokolle und die damit verbundenen Probleme behandelt.

IGMP-/MLD-Pakete

IGMP/MLD ist das Protokoll, das von Multicast-Empfängern verwendet wird, um einem Router zu signalisieren, dass sie Inhalte für eine bestimmte Multicast-Gruppe empfangen möchten. Internet Group Membership Protocol (IGMP) ist das Protokoll, das in IPv4 und Multicast Listener Discovery (MLD) in IPv6 verwendet wird.

Es gibt zwei häufig verwendete IGMP-Versionen: IGMPv2 und IGMPv3. Es gibt auch zwei häufig verwendete MLD-Versionen: MLDv1 und MLDv2.

IGMPv2 und MLDv1 sind funktional äquivalent, IGMPv3 und MLDv2 sind funktional äquivalent.

Diese Protokolle werden in den folgenden Links angegeben:

IGMPv2: RFC 2236

MLDv1: RFC 3590

IGMPv3 und MLDv2: RFC 4604

IGMPv2 und IGMPv3 ist nicht nur ein Protokoll, sondern auch ein IPv4-IP-Protokoll (insbesondere Protokollnummer 2). Es wird nicht nur wie in diesen RFCs beschrieben verwendet, um Multicast-Gruppenmitgliedschaften zu melden, sondern auch von anderen IPv4-Multicast-Protokollen wie DVMRP, PIM Version 1, mtrace und mrinfo. Dies ist wichtig, um sich zu erinnern, wenn Sie versuchen, IGMP zu filtern (z. B. über Cisco IOS® ACLs). Bei IPv6 ist MLD kein IPv6-Protokoll. Stattdessen wird ICMPv6 verwendet, um MLD-Pakete zu übertragen. PIM Version 2 ist der gleiche Protokolltyp in IPv4 und IPv6 (Protokollnummer 103).

PIM-Steuerungspakete

In diesem Abschnitt werden Multicast- und Unicast-PIM-Steuerungspakete behandelt. Auto-RP sowie Bootstrap Router (BSR), mit denen Rendezvous Points ausgewählt und Zuweisungen von Gruppen zu RP in PIM-SM-Netzwerken gesteuert werden können, werden besprochen.

Multicast-PIM-Steuerungspakete

Multicast-PIM-Steuerungspakete umfassen:

• PIM Hello - Das PIM Hello-Paket ist ein IP-Multicast-Paket mit lokalem Gültigkeitsbereich, das an einen Router gesendet wird, der mit demselben Netzwerk verbunden ist, um PIM-Nachbarn einzurichten.
• PIM Join/Prune - PIM Join/Prunes sind IP-Multicast-Pakete mit lokalem Gültigkeitsbereich, die gesendet werden, um den Multicast-Status zu erstellen/zu entfernen. Sie werden nur an PIM-Nachbarn gesendet. Sie sind Multicast-fähig im LAN, um die Bestätigung, Unterdrückung von Berichten und andere Details des PIM-Protokolls zu erleichtern, werden aber immer an einen bestimmten Nachbarn weitergeleitet.
• PIM DF-elect - Der von PIM designierte Forwarder ist der Bi-Dir PIM-Router, der für (*,G) JOINS verantwortlich ist und im Auftrag angeschlossener Empfänger oder nachgeschalteter PIM-Nachbarn an den RP gesendet wird. Wenn ein PIM-Router einen anderen Router erkennt, der (*,G) JOINS für dasselbe Segment für dieselbe Gruppe G sendet, können Sie den Router mit dem besten Pfad zum RP auswählen.
• PIM-Assert - PIM-Asserts sind verbindungslokale IP-Multicast-Pakete, die gesendet werden, wenn ein PIM-Router, der an ein Netzwerksegment angeschlossen ist, das aktiv Pakete für einen bestimmten Punkt (S,G) von einer bestimmten Schnittstelle weiterleitet, beginnt, Pakete für denselben Punkt (S,G) auf derselben Schnittstelle zu EMPFANGEN, an die weitergeleitet wird. Dieses Ereignis zeigt das Vorhandensein eines anderen Routers an, der dies als Single Forwarder (SF) ansieht (S,G). Der Assert-Mechanismus wählt dafür eine eindeutige SF (S,G). Der PIM SF-Router kann Pakete für einen bestimmten (S,G)-Stream weiterleiten. PIM ermöglicht es verschiedenen Routern, die Rolle der SF für verschiedene (S,G) zu übernehmen. Idealerweise ist nur ein SF pro (S,G) vorhanden. Verwechseln Sie SF nicht mit dem designierten Router. Der vom PIM designierte Router ist der Router, der für JOIN/PRUNES- oder SOURCE-REGISTER verantwortlich ist, die an den RP in einem PIM-SM-Netzwerk gesendet werden.
• PIM-Bootstrap - PIM-Bootstrap-Nachrichten werden in einem PIMv2-Netzwerk gesendet, um die dynamische Auswahl eines Rendezvous Points für eine bestimmte Gruppe G zu erleichtern.

Unicast-PIM-Steuerungspakete

Unicast-PIM-Steuerungspakete werden vom oder zum RP geleitet und umfassen:

• Source Register Packet - PIM Source Register Packets werden gesendet, um eine neue Multicast-Quelle mit einem Rendezvous Point zu registrieren. Sobald eine Quelle beginnt, Multicast-Pakete zu senden, sendet der designierte Router, der mit dem Quellnetzwerk verbunden ist, einen Unicast-Register-Stream an den RP, um anzuzeigen, dass eine aktive Quelle für eine Multicast-Gruppe vorhanden ist, für die der RP zuständig ist.
  Die Quellregisterpakete werden als Unicast-Kapselung des ursprünglichen Multicast-Streams gesendet.
  PIM-Registernachrichten werden auf Prozessebene umgeschaltet und nur gesendet, bis der RP eine Register-Stopp-Nachricht sendet. Die Auswirkungen dieser Pakete auf die Performance sind proportional zur Rate der Quelle (pro (S,G)-Fluss).
• Register Stopp Packet - PIM Register Stopp Packets werden vom Rendezvous Point an den PIM DR gesendet, der die Registernachricht gesendet hat. Register Stopp-Nachrichten werden gesendet, sobald der RP anfängt, native Multicast-Pakete von der Quelle zu empfangen.
• BSR Candidate-Rendezvous Point Advertisement Packet - PIM BSR C-RP-Advertisement Packets werden an den BSR gesendet, um einen Kandidaten-RP anzukündigen, sobald der BSR gewählt wurde.

Abb. 1: PIM-Unicast-Pakete 

Abb. 1_PIM_Unicast

Angriffe, die solche Pakete ausnutzen, können von überall ausgehen, da es sich bei diesen Paketen um Unicast-Pakete handelt.

Grundlegende Bedrohungen für einen Router

Es gibt eine Reihe grundlegender Bedrohungen für einen Router, die unabhängig davon auftreten, ob der Router Multicast unterstützt und ob der Angriff Multicast-Datenverkehr oder -Protokolle umfasst.

Denial of Service (DoS)-Angriffe sind die wichtigsten generischen Angriffsvektoren in einem Netzwerk. Im Prinzip kann jedes Netzwerkelement mit einem DoS-Angriff angegriffen werden, wodurch das Element überlastet wird, was zu einem potenziellen späteren Verlust oder einer Verschlechterung des Service für legitime Benutzer führen kann. Es ist äußerst wichtig, die grundlegenden Empfehlungen für die Netzwerksicherheit zu befolgen, die für Unicast gelten.

Es ist zu beachten, dass Multicast-Angriffe nicht immer absichtlich erfolgen, sondern häufig versehentlich erfolgen. Der Witty-Wurm beispielsweise, der erstmals im März 2004 beobachtet wurde, ist ein Beispiel für einen Wurm, der sich durch zufällige Angriffe auf IP-Adressen verbreitete. Infolge der vollständigen Randomisierung des Adressraums wurden auch Multicast-IP-Ziele vom Wurm beeinflusst. In vielen Unternehmen ging die Anzahl der First-Hop-Router zurück, da der Wurm Pakete an viele verschiedene Multicast-Zieladressen schickte. Die Router waren jedoch nicht für eine solche Multicast-Datenverkehrslast ausgelegt, und der zugehörige Status wurde erstellt. Außerdem waren die Ressourcen praktisch erschöpft. Dies zeigt, dass der Multicast-Datenverkehr geschützt werden muss, selbst wenn er in einem Unternehmen nicht verwendet wird.

Allgemeine Bedrohungen für Router:

• Paketüberflutungen jeder Art; z. B. für Hardwarepfade wie langsame Pfade (Punkt-Pfade) und Softwarepfade wie Ports auf Verwaltungs- oder Steuerungsebene, einschließlich Secure Shell (SSH), Telnet, Border Gateway Protocol (BGP), OSPF, Network Time Protocol (NTP) usw.
• Eindringen in den Router mit anschließender Nutzung der Funktionen des Routers schwache Telnet- oder SSH-Passwörter und schwache SNMP-Community-Strings (Simple Network Management Protocol) sind in modernen Netzwerken ein häufiges Problem.
• Betriebliche Probleme wie Fehlkonfigurationen oder Insider-Angriffe können die Sicherheit des gesamten Netzwerks und seines Datenverkehrs gefährden.
  
  

Wenn Multicast auf einem Router aktiviert ist, muss es zusätzlich zu Unicast gesichert werden. Die Verwendung von IP-Multicast ändert nichts am grundlegenden Bedrohungsmodell. Sie ermöglicht jedoch zusätzliche Protokolle (PIM, IGMP, MLD, MSDP), die Angriffen ausgesetzt sein könnten und die speziell geschützt werden müssen. Wenn in diesen Protokollen Unicast-Datenverkehr verwendet wird, ist das Bedrohungsmodell mit anderen Protokollen identisch, die vom Router ausgeführt werden.

Dabei ist zu beachten, dass Multicast-Datenverkehr nicht auf die gleiche Weise wie Unicast-Datenverkehr für Angriffe auf einen Router verwendet werden kann, da Multicast-Datenverkehr grundsätzlich "empfängergesteuert" ist und nicht auf ein entferntes Ziel ausgerichtet werden kann. Ein Angriffsziel muss explizit mit dem Multicast-Stream "verbunden" werden. In den meisten Fällen (Auto-RP ist die wichtigste Ausnahme) empfangen Router nur Multicast-Datenverkehr "link local". Link-lokaler Datenverkehr wird nie weitergeleitet. Daher können Angriffe auf einen Router mit Multicast-Paketen nur von direkt verbundenen Angreifern ausgehen.

Bedrohungen von der Quellseite

Multicast-Quellen, z. B. PCs oder Videoserver, stehen manchmal nicht unter derselben administrativen Kontrolle wie das Netzwerk. Aus Sicht des Netzbetreibers wird der Absender daher meist als nicht vertrauenswürdig behandelt. Angesichts der leistungsstarken Funktionen von PCs und Servern und ihrer komplexen Sicherheitseinstellungen, die häufig unvollständig sind, stellen die Absender eine erhebliche Bedrohung für jedes Netzwerk dar, zu dem auch Multicast gehört. Diese Bedrohungen umfassen:

• Layer-2-Angriffe: Auf Layer 2 gibt es eine Vielzahl von Angriffsformen, um verschiedene Arten von Angriffen auszuführen. Diese gelten für Unicast ebenso wie für Multicast. Da diese Angriffsformen nicht spezifisch für Multicast sind, werden sie in diesem Dokument nicht näher erläutert. Weitere Informationen finden Sie im Cisco Press Book "LAN Switch Security", ISBN-10: 1-58705-467-1.
• Angriffe mit Multicast-Datenverkehr: Wie bereits beschrieben, ist es schwierig, Angriffe mit Multicast-Datenverkehr durchzuführen, da der First-Hop-Router keinen Multicast-Datenverkehr weiterleitet, es sei denn, es ist ein Listener für die Gruppe vorhanden. Der erste Hop kann jedoch auf verschiedene Weise mit Multicast-Paketen angegriffen werden:
• Netzwerksättigungsangriffe: Ein Angreifer kann ein Segment mit Multicast-Paketen überfluten und dabei die verfügbare Bandbreite überlasten, was zu einem DoS-Zustand führen kann.
• Multicast-Status-Angriffe: Der First-Hop-Router ist mit Multicast-Paketen überschwemmt, die zu viele Zustände verursachen können, was zu einem DoS-Angriff führen kann.
• Ein Absender könnte versuchen, über versendete PIM-Hellos zum PIM DR zu werden. In diesen Fällen wird kein Datenverkehr zum oder vom LAN weitergeleitet.
• PIM DF-Auswahlpakete für einen BiDir-PIM DF konnten gefälscht werden. In diesen Fällen wird kein Datenverkehr zum oder vom LAN weitergeleitet.
• Ein Absender kann AutoRP-Discovery- oder BSR-Bootstrap-Nachrichten als Spoofing verwenden. Dadurch wird ein gefälschter RP gemeldet und ein PIM-SM/BiDir-Service wird deaktiviert oder unterbrochen.
• Ein Absender könnte Unicast-Angriffe wie PIM-Quellregistrierung/Register-Stopp-Nachrichten auslösen oder BSR Announce-Pakete senden und einen gefälschten BSR ankündigen.
• Ein Absender kann an jede gültige Multicast-Gruppe senden, sofern diese nicht gefiltert wird. Wenn eine Quelladresse gefälscht und nicht am Edge verhindert wird, kann der Absender die Quell-IP-Adresse eines legitimen Absenders verwenden und Inhalte in Teilen des Netzwerks überschreiben.
• Multicast-Angriffe auf Kontrollebenenprotokolle: Eine Reihe von Protokollen, die nicht mit Multicast verknüpft sind, wie OSPF und DHCP (Dynamic Host Configuration Protocol), verwenden Multicast-Pakete, die zum Angriff auf diese Protokolle verwendet werden können
• Masquerading: Es gibt eine Reihe von Angriffsformen, bei denen ein Absender vorgeben kann, ein anderer Absender zu sein. Gefälschte Quell-IP-Adressen gehören zu diesen Angriffsformen.
• Diebstahl des Dienstes: Sofern die Absender nicht kontrolliert werden, ist es möglich, den Multicast-Dienst unrechtmäßig von der Absenderseite aus zu verwenden.

Anmerkung: Hosts senden oder empfangen normalerweise keine PIM-Pakete. Host, der dies tut, kann wahrscheinlich einen Angriff versuchen.

Bedrohungen von der Empfängerseite

Der Receiver ist in der Regel auch eine Plattform mit hoher CPU-Leistung und Bandbreite, die eine Reihe von Angriffsformen ermöglicht. Diese sind meist identisch mit den Bedrohungen auf der Absenderseite. Layer-2-Angriffe bleiben ein wichtiger Angriffsvektor. Auch auf Empfängerseite sind gefälschte Empfänger und Diebstahl von Services möglich, mit der Ausnahme, dass der Angriffsvektor typischerweise IGMP (oder Layer-2-Angriffe, wie erwähnt) ist.

Bedrohungen gegen einen Rendezvous Point und BSR

PIM-SM-RPs und PIM-BSRs sind kritische Punkte in einem Multicast-Netzwerk und daher wertvolle Ziele für einen Angreifer. Wenn es sich bei dem First-Hop-Router nicht um einen handelt, können nur Unicast-Angriffsformen, zu denen auch PIM-Unicast gehört, direkt auf diese Elemente ausgerichtet werden. Zu den Bedrohungen für RPs und BSRs gehören:

• Alle allgemeinen Angriffsformen, wie im Abschnitt "Grundlegende Bedrohungen gegen einen Router" beschrieben.
• PIM-Unicast-Angriffe, möglicherweise mit gefälschten Quell-IP-Adressen, ermöglichen DoS-Angriffe. Dabei werden PIM-Registrierungs- oder Register-Stopp-Nachrichten verwendet, die von einem böswilligen Gerät gesendet werden.

Multicast- und Unicast-Sicherheit (verglichen)

Statusüberlegungen/Filter

Betrachten Sie die Topologie in Abbildung 3, die eine Quelle, drei Empfänger (A, B, C), einen Switch (S1) und zwei Router (R1 und R2) zeigt. Die blaue Linie stellt einen Unicast-Stream dar, die rote Linie einen Multicast-Stream. Alle drei Empfänger sind Mitglieder des Multicast-Flusses.

Abb. 3: Replikation in Routern und Switches

Abb. 3_Replikation_RS

So unterbinden Sie den Datenverkehrsfluss von einer bestimmten Quelle zu einem bestimmten Empfänger:

• Installieren Sie für den Unicast-Stream einen Filter an einer beliebigen Stelle auf dem Pfad von Sender zu Empfänger.
• Für den Multicast-Stream müssen Administratoren jedoch genauer festlegen, wo Filter installiert werden: am empfängerseitigen Filter nach dem letzten Replikationspunkt vor dem Empfänger; auf der Quellseite vor dem ersten Replikationspunkt nach der Quelle filtern.

Angriffe von Multicast-Quellen

Dieser Abschnitt gilt für die ASM- und SSM-Servicemodelle, bei denen die Weiterleitung des Datenverkehrs auf dem Empfang expliziter Joins auf Empfängerseite basiert.

Für Unicast-Streams gibt es keinen impliziten Empfängerschutz. Eine Unicast-Quelle kann Datenverkehr an ein Ziel senden, selbst wenn dieses Ziel nicht nach dem Datenverkehr gefragt hat. Daher werden Abwehrmechanismen wie Firewalls in der Regel verwendet, um Endpunkte zu schützen. Multicast dagegen verfügt über einen gewissen impliziten Schutz, der in die Protokolle integriert ist. Der Datenverkehr erreicht idealerweise nur einen Empfänger, der sich dem betreffenden Datenfluss angeschlossen hat.

Mit ASM können Quellen Datenverkehr einfügen oder DoS-Angriffe durch Multicast-Datenverkehrsübertragung an eine beliebige Gruppe starten, die von einem aktiven RP unterstützt wird. Idealerweise wird dieser Datenverkehr nicht an einen Empfänger weitergeleitet, sondern kann mindestens den First-Hop-Router im Pfad sowie den RP erreichen, was begrenzte Angriffe ermöglicht. Wenn eine böswillige Quelle jedoch eine Gruppe kennt, an der ein Empfänger interessiert ist, und keine geeigneten Filter vorhanden sind, kann sie Datenverkehr an diese Gruppe senden. Dieser Datenverkehr wird empfangen, solange die Empfänger die Gruppe überwachen.

Mit SSM sind Angriffe unerwünschter Quellen nur auf dem First-Hop-Router möglich, an dem der Datenverkehr gestoppt wird, wenn kein Empfänger diesem (S,G)-Kanal beigetreten ist. Dies führt zu keinem Zustandsangriff auf den First-Hop-Router, da der gesamte SSM-Datenverkehr, für den kein expliziter Join-Zustand besteht, von den Empfängern verworfen wird. Bei diesem Modell reicht es nicht aus, dass eine böswillige Quelle weiß, an welcher Gruppe ein Ziel interessiert ist, da "Joins" quellenspezifisch sind. In diesem Fall wären gefälschte IP-Quelladressen sowie potenzielle Routing-Angriffe erforderlich.

Statusangriffe

Selbst ohne Empfänger in einem Netzwerk erstellt PIM-SM den Status (S,G) und (*,G) auf dem der Quelle nächstgelegenen First-Hop-Router sowie auf dem Rendezvous Point. Somit besteht die Möglichkeit eines State-Angriffs auf das Netzwerk am Source First-Hop-Router und auf den PIM-SM-RP.

Wenn eine schädliche Quelle beginnt, Datenverkehr an mehrere Gruppen zu senden, dann erzeugen die Router im Netzwerk für jede erkannte Gruppe einen Status an der Quelle und am RP, vorausgesetzt, die betreffenden Gruppen sind gemäß der RP-Konfiguration zulässig.

Daher ist PIM-SM Status- und Datenverkehrsangriffen von Quellen ausgesetzt. Der Angriff kann noch verstärkt werden, wenn die Quelle ihre Quell-IP-Adresse innerhalb des richtigen Präfix zufällig ändert, d. h. wenn nur die Host-Bits der Adresse gefälscht werden.

Abb. 4: ASM RP-Angriffe

Abb. 4_ASM_RP_Angriffe

Wie bei PIM-SSM sind PIM-BiDir-Angriffe zur Erstellung des Status von Quellen nicht möglich. Der Datenverkehr in PIM-BiDir wird sowohl nach einem durch Joins von Empfängern erstellten Zustand als auch nach einem durch den Zustand weitergeleiteten Datenverkehr an den RP weitergeleitet, sodass er Empfänger hinter dem RP erreichen kann, da die Joins nur an den RP weitergeleitet werden. Der Status "State-to-Forwarding" (Status von Status zu Weiterleitung) zum RP wird als Status (*,G/M) bezeichnet und durch die RP-Konfiguration (statisch, Auto-RP, BSR) erstellt. Es ändert sich nicht, wenn Quellen vorhanden sind. Aus diesem Grund können Angreifer Multicast-Datenverkehr an einen PIM-BiDir-RP senden. Im Gegensatz zu PIM-SM ist ein PIM-BiDir-RP jedoch keine "aktive" Einheit, sondern leitet oder verwirft lediglich Datenverkehr für PIM-BiDir-Gruppen weiter.

Anmerkung: Auf einigen Cisco IOS-Plattformen (*,G/M) wird der Status nicht unterstützt. In solchen Fällen können Quellen den Router durch Multicast-Datenverkehrsübertragung an mehrere PIM-BiDir-Gruppen angreifen, was zur Erstellung eines (*,G)-Status führt. Beispielsweise unterstützt der Catalyst 6500-Switch (*,G/M)-Status.

Vom Empfänger ausgelöste Angriffe

Angriffe können von Multicast-Empfängern ausgehen. Jeder Empfänger, der IGMP-/MLD-Berichte sendet, erzeugt normalerweise einen Status auf dem First-Hop-Router. Es gibt keinen entsprechenden Mechanismus in Unicast.

Abb. 5: Explizite Join-basierte Datenweiterleitung auf Empfängerseite

Abb. 5_Empfänger_Explicit_Join

Es gibt drei Arten von Empfängerangriffen:

1. Ein Multicast-Empfänger kann versuchen, einem Fluss beizutreten, für den er nicht autorisiert ist, und versuchen, Inhalte zu empfangen, für die er nicht autorisiert ist.
2. Ein Multicast-Empfänger kann die verfügbare Netzwerkbandbreite durch Interesse an vielen Gruppen oder Kanälen überlasten. Diese Art von Angriff wird zu einem Angriff mit gemeinsam genutzter Bandbreite gegen andere potenzielle Empfänger von Inhalten.
3. Ein Multicast-Empfänger kann versuchen, einen Angriff auf Router oder Switches zu starten. Es kann eine große Anzahl von IGMP-Berichten generiert werden, was zu einem großen Anteil an Multicast-Tree-Status und einer möglichen Überlastung der Routerkapazität führen kann. Dies wiederum kann die Multicast-Konvergenzzeiten erhöhen oder zu einem DoS auf dem Router führen.
   
   

Im nächsten Abschnitt, Security within a Multicast Network (Sicherheit in einem Multicast-Netzwerk), werden verschiedene Möglichkeiten zur Abwehr dieser Art von Angriffen beschrieben.

Sicherheit in einem Multicast-Netzwerk

Netzwerkelementsicherheit

Sicherheit ist keine isolierte Funktion, sondern fester Bestandteil jedes Netzwerkdesigns. Daher muss die Sicherheit an jedem Punkt im Netzwerk berücksichtigt werden. Es ist äußerst wichtig, dass jedes Netzwerkelement angemessen geschützt ist. Ein mögliches Angriffsszenario, das auf jede Technologie anwendbar ist, ist ein Router, der von einem Eindringling unterwandert wird. Sobald ein Eindringling die Kontrolle über einen Router hat, kann der Angreifer eine Reihe verschiedener Angriffsszenarien ausführen. Jedes Netzwerkelement muss daher angemessen vor jeder Form von einfachem Angriff sowie vor bestimmten Multicast-Angriffen geschützt werden.

Local Packet Transport Service (LPTS)

Auf Cisco IOS XR dient der Local Packet Transport Service (LPTS) ähnlich wie CoPP auf Cisco IOS als Überwachung des Datenverkehrs zur Steuerungsebene des Routers. Außerdem kann der Empfangsdatenverkehr, der Unicast- und Multicast-Datenverkehr umfasst, gefiltert und der Übertragungsrate eingeschränkt werden.

Multicast-spezifische Sicherheit

In einem Multicast-fähigen Netzwerk muss jedes Netzwerkelement mit Multicast-spezifischen Sicherheitsfunktionen gesichert werden. Diese werden in diesem Abschnitt für einen allgemeinen Router-Schutz beschrieben. Funktionen, die nicht auf jedem Router, sondern nur an bestimmten Standorten im Netzwerk erforderlich sind, und Funktionen, die eine Interaktion zwischen Routern erfordern (z. B. PIM-Authentifizierung), werden im nächsten Abschnitt behandelt.

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

Abb. 6: Routengrenzwerte

Abb6_Route_Limits

Routinglimits ermöglichen das Festlegen eines Grenzwerts für die Anzahl von Routen, die in die Multicast-Routing-Tabelle aufgenommen werden dürfen. Wenn ein Grenzwert für die Multicast-Route aktiviert ist, wird kein Multicast-Status erstellt, der über den konfigurierten Grenzwert hinausgeht. Außerdem gibt es eine Warnschwelle. Wenn die Anzahl der Routen den Warnschwellenwert überschreitet, werden Syslog-Warnmeldungen ausgelöst. An der Routengrenze werden alle weiteren Pakete verworfen, die den Status auslösen würden.

Der Befehl ip multicast route-limit ist ebenfalls pro MVRF verfügbar.

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) 
               
 
              

Abb10_Multicast_Boundary

Abb. 13_Interdomain_Filter

Zur Sicherung der Kontrollebene muss die MSDP mithilfe von drei grundlegenden Sicherheitsmaßnahmen gehärtet werden:

1) MSDP-SA-Filter

Es ist eine "bewährte Vorgehensweise", den Inhalt von MSDP-Nachrichten über MSDP-SA-Filter zu filtern. Die Grundidee dieses Filters besteht darin, die Weitergabe des Multicast-Zustands für Anwendungen und Gruppen zu vermeiden, die keine Internetanwendungen sind und nicht über die Quelldomäne hinaus weitergeleitet werden müssen. Im Idealfall lassen die Filter aus Sicherheitsgründen nur bekannte Gruppen (und möglicherweise Absender) zu und lehnen unbekannte Absender und/oder Gruppen ab.

Es ist in der Regel nicht möglich, alle zulässigen Absender und/oder Gruppen explizit aufzulisten. Es wird empfohlen, den Standardkonfigurationsfilter für PIM-SM-Domänen mit einem einzigen RP für jede Gruppe (keine MSDP-Mesh-Gruppe) zu verwenden:

!--- 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
         !

Es wird empfohlen, die Filter so streng wie möglich und in beide Richtungen, eingehend und ausgehend, zu gestalten.

Weitere Informationen zu den Filterempfehlungen für MSDP-SA finden Sie unter: https://www.cisco.com/c/en/us/support/docs/ip/ip-multicast/13717-49.html

ip msdp sa-limit <peer> <limit> 

Abb. 14_MSDP_Kontrollebene

Mit dem Befehl ip msdp sa-limit können Sie die Anzahl der SA-Zustände begrenzen, die aufgrund von SA-Nachrichten erstellt werden, die von einem MSDP-Peer akzeptiert werden. Hier einige einfache Empfehlungen:

• Kleiner Grenzwert von Stub-Neighbor 
• Großer Grenzwert für Transit-Nachbar (z. B. Höchstwert #SAs im Internet)
• Transit-ISP: Konfigurieren Sie das maximale #SAs, das Ihre Plattform unterstützen kann.

3) Nachbar-Authentifizierung mit MSDP MD5

Es wird empfohlen, die Passwortauthentifizierung mittels Message-Digest Algorithm (MD5) auf MSDP-Peers anzuwenden. Dabei wird die Option für die TCP MD5-Signatur verwendet. Dies entspricht der in RFC 6691 beschriebenen Verwendung zum Sichern von BGP.

Abb. 15: Nachbar-Authentifizierung mit MSDP MD5

Abb. 15_MSDP_MD5Auth

Diese drei MSDP-Sicherheitsempfehlungen verfolgen unterschiedliche Ziele:

• Die Nachbarauthentifizierung (mit MD5) stellt sicher, dass nur vertrauenswürdige MSDP-Peers Nachrichten senden können.
• Die SA-Filter stellen sicher, dass selbst ein vertrauenswürdiger MSDP-Peer nur SA-Ankündigungen senden kann, die mit einer zuvor vereinbarten Quell-/Gruppenrichtlinie im Einklang stehen.
• Der SA-Grenzwert stellt außerdem sicher, dass der verfügbare Speicher selbst bei legitimen (S,G) Ankündigungen von legitimen Peers nicht ausgeschöpft werden kann.

Absender-/Quellprobleme

Viele Multicast-Sicherheitsprobleme, die vom Absender ausgehen, können durch geeignete Unicast-Sicherheitsmechanismen behoben werden. Eine Reihe von Unicast-Sicherheitsmechanismen werden hier als Best Practices empfohlen:

• Spoofschutz für Quelladressen (Unicast Reverse Path Forwarding, uRPF oder ACL und IP Source Guard für den Access Layer)
• Infrastruktur-ACLs (deny ip any (to) <Core-Adressraum>)

Solche Maßnahmen können dazu verwendet werden, gezielte Angriffe auf den Kern zu blockieren. Auf diese Weise können beispielsweise auch Probleme wie Angriffe gelöst werden, bei denen PIM-Unicast-Pakete an den RP gesendet werden, der sich "innerhalb" des Netzwerks befindet und daher durch die Infrastruktur-ACL geschützt ist.

Paketfilter-basierte Zugriffskontrolle - Steuerungsquellen

Im Beispiel in Abbildung 16 wird der Filter an der LAN-Schnittstelle (E0) des First-Hop-Multicast-Routers (Designated Router) konfiguriert. Der Filter wird durch eine erweiterte Zugriffskontrollliste mit der Bezeichnung "source" definiert. Diese ACL wird auf die an die Quelle gerichtete Schnittstelle des designierten Routers angewendet, der mit dem Quell-LAN verbunden ist. Aufgrund der Art des Multicast-Datenverkehrs kann ein ähnlicher Filter für alle LAN-Schnittstellen konfiguriert werden, auf denen Quellen aktiv werden können. Da es nicht in allen Fällen möglich ist, genau zu wissen, wo die Quellaktivität auftritt, wird empfohlen, solche Filter auf alle Eingangspunkte im Netzwerk anzuwenden.

Abb. 16: Kontrollquellen

Abb. 16_Controlling_Sources

ip pim accept-register / ipv6 pim accept-register

Abb. 17_PIMSM_Control

In einem PIM-SM-Netzwerk kann mit diesem Befehl eine Quelle für unerwünschten Datenverkehr gesteuert werden. Wenn der Quelldatenverkehr den First-Hop-Router erreicht, erstellt der First-Hop-Router (DR) den Status (S,G) und sendet eine PIM Source Register-Nachricht an den RP. Wenn die Quelle nicht in der Liste der Accept-Register-Filter (konfiguriert auf dem RP) aufgeführt ist, lehnt der RP die Registrierung ab und sendet eine sofortige Register-Stopp-Nachricht an den DR zurück.

Im gezeigten Beispiel wurde eine einfache ACL auf den RP angewendet, die nur nach der Quelladresse filtert. Es ist auch möglich, die Quelle UND die Gruppe mithilfe einer erweiterten Zugriffskontrollliste auf dem RP zu filtern.

Es gibt Nachteile von Quellfiltern, da mit dem Befehl pim accept-register auf dem RP der Status von PIM-SM (S,G) auf dem First-Hop-Router der Quelle weiterhin erstellt wird. Dies kann zu Datenverkehr an Empfängern führen, die sich vor Ort zwischen der Quelle und dem RP befinden. Der Befehl pim accept-register funktioniert darüber hinaus auf der Kontrollebene des RP. Dies kann dazu verwendet werden, den RP mit gefälschten Registernachrichten zu überlasten und möglicherweise eine DoS-Bedingung zu verursachen.

Es wird empfohlen, den Befehl pim accept-register auf dem RP zusätzlich zu anderen Methoden anzuwenden, z. B. die Anwendung einfacher Datenebenen-ACLs auf allen DRs an allen Eingangspunkten im Netzwerk. Während Eingangs-ACLs auf dem DR in einem perfekt konfigurierten und betriebenen Netzwerk ausreichen würden, wird empfohlen, den Befehl pim accept-register auf dem RP als sekundären Sicherheitsmechanismus zu konfigurieren. Fehlkonfigurationen auf den Edge-Routern. Mehrschichtige Sicherheitsmechanismen mit demselben Ziel werden als "tief greifende Abwehr" bezeichnet und gelten als gemeinsames Designprinzip für die Sicherheit.

Empfängerprobleme - IGMP/MLD steuern

Die meisten Empfängerprobleme fallen in die Domäne der IGMP/MLD-Empfängerprotokollinteraktionen.

Abb. 18: IGMP steuern

Abb. 18 - Controlling IGMP

Bei der Filterung von IGMP- oder MLD-Paketen sind folgende Punkte zu beachten:

• IPv4: IGMP ist ein IPv4-Protokolltyp (IPv4 Protokoll 2)
• IPv6: MLD wird in ICMPv6-Protokollpaketen übertragen

Der IGMP-Prozess wird standardmäßig aktiviert, sobald IP Multicast aktiviert ist. IGMP-Pakete enthalten auch diese Protokolle. Daher werden alle diese Protokolle bei Aktivierung von Multicast aktiviert:

• PIMv1 - PIMv1 war die erste Version von PIM und wird zu Migrationszwecken in Cisco IOS aktiviert. Bei aktuellen Bereitstellungen wird PIMv2 verwendet.
• Mrinfo - Mrinfo ist ein Unix-Befehl, den Cisco IOS zur Anzeige von Multicast-Nachbarn geerbt hat. Cisco empfiehlt die Verwendung von SNMP anstelle des Befehls mrinfo.
• DVMRP - DVMRP ist ein älteres Distanzvektorprotokoll im Dense-Modus mit sehr begrenzten Skalierungseigenschaften. Die Cisco IOS-Unterstützung für DVMRP wurde eingestellt oder ist bereits veraltet.
• Mtrace - Mtrace ist das Multicast-Äquivalent von Unicast-"Traceroute" und ein nützliches Tool.

Weitere Informationen finden Sie unter IGMP-Typnummern (Internet Group Management Protocol) der IANA

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 

Unicast-IGMP-Pakete (für IGMP/UDLR) können gefiltert werden, da es sich dabei höchstwahrscheinlich um Angriffspakete und nicht um gültige IGMP-Protokollpakete handelt. Unicast-IGMP-Pakete werden von Cisco IOS zur Unterstützung unidirektionaler Verbindungen und anderer Ausnahmebedingungen unterstützt.

Gefälschte IGMP/MLD-Abfragepakete können zu einer niedrigeren IGMP-Version führen als erwartet.

Insbesondere senden Hosts idealerweise niemals IGMP-Abfragen, da eine mit einer niedrigeren IGMP-Version gesendete Abfrage dazu führen kann, dass alle Hosts, die diese Abfrage empfangen, auf die niedrigere Version zurückgesetzt werden. Bei Vorhandensein von IGMPv3/SSM-Hosts können die SSM-Streams "angegriffen" werden. Bei IGMPv2 kann dies zu längeren Wartezeiten führen.

Wenn ein nicht redundantes LAN mit einer einzigen IGMP-Abfrage vorhanden ist, muss der Router empfangene IGMP-Abfragen verwerfen.

Wenn ein redundantes/gemeinsames passives LAN vorhanden ist, ist ein Switch erforderlich, der IGMP-Snooping unterstützen kann. In diesem Fall können zwei spezifische Funktionen hilfreich sein:

• Router Guard
• IGMP-Mindestversion - Befehl

Router Guard

Jeder Switch-Port kann ein Multicast-Router-Port werden, wenn der Switch an diesem Port ein Multicast-Router-Steuerungspaket (IGMP General Query, PIM Hello oder CGMP Hello) empfängt. Wenn ein Switch-Port zu einem Multicast-Router-Port wird, wird der gesamte Multicast-Datenverkehr an diesen Port gesendet. Dies kann mit "Router Guard" verhindert werden. Für die Router Guard-Funktion muss IGMP-Snooping nicht aktiviert sein.

Mit der Router Guard-Funktion kann ein bestimmter Port als Multicast-Host-Port festgelegt werden. Der Port kann kein Router-Port werden, selbst wenn Multicast-Router-Steuerungspakete empfangen werden.

Diese Pakettypen werden verworfen, wenn sie an einem Port mit aktiviertem Router Guard empfangen werden:

• IGMP-Abfragenachrichten
• IPv4-PIMv2-Nachrichten
• IGMP-PIM-Nachrichten (PIMv1)
• IGMP-DVMRP-Nachrichten
• Router-Port Group Management Protocol (RGMP)-Nachrichten
• Cisco Group Management Protocol (CGMP)-Nachrichten

Wenn diese Pakete verworfen werden, werden Statistiken aktualisiert, die anzeigen, dass Pakete aufgrund von Router Guard verworfen werden.

IGMP-Mindestversion

Es ist möglich, die zulässige Mindestversion der IGMP-Hosts zu konfigurieren. Sie können beispielsweise alle IGMPv1-Hosts oder alle IGMPv1- und IGMPv2-Hosts deaktivieren. Dieser Filter gilt nur für Mitgliedsberichte.

Wenn die Hosts an ein gemeinsames "passives" LAN angeschlossen sind (z. B. an einen Switch, der IGMP-Snooping nicht unterstützt oder dafür nicht konfiguriert ist), kann ein Router solche falschen Abfragen auch nicht bearbeiten, außer die Mitgliedsberichte der "alten Version" zu ignorieren, die dann ausgelöst werden und nicht auf sich selbst zurückgreifen.

Da IGMP-Abfragen für alle Hosts sichtbar sein müssen, ist es nicht möglich, Hash-basierte Nachrichtenauthentifizierungsmechanismen (HMAC) mit einem Pre-Shared Key, z. B. dem statischen Schlüssel IPSec, zur Authentifizierung von IGMP-Abfragen von "gültigen Routern" zu verwenden. Wenn zwei oder mehr Router mit einem gemeinsamen LAN-Segment verbunden sind, muss der IGMP-Abfrager ausgewählt werden. In diesem Fall kann als einziges Filter ein IP-Zugriffsgruppenfilter verwendet werden, der auf der Quell-IP-Adresse des anderen IGMP-Routers basiert, der Abfragen sendet.

"Normale" Multicast-IGMP-Pakete müssen zugelassen werden.

Dieser Filter kann an Empfänger-Ports verwendet werden, um nur "gute" IGMP-Pakete zuzulassen und um bekannte "schlechte" zu filtern:

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

Anmerkung: Dieser IGMP-Filtertyp kann in Empfangs-ACLs oder CoPP verwendet werden. In beiden Anwendungen muss sie mit Filtern für anderen verarbeiteten Datenverkehr kombiniert werden, z. B. Routing- und Verwaltungsebenenprotokolle. 

Abb. 19: Host Receiver-seitige Zugriffskontrolle

Abb. 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

Abb. 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 zur Authentifizierung des Datenverkehrs auf der Kontrollebene verwenden

Im Allgemeinen empfiehlt es sich, den Datenverkehr der Steuerungsebene wie Routing-Protokolle zu authentifizieren, um sicherzustellen, dass die Nachrichten von einem vertrauenswürdigen Peer stammen. Dies ist für Kontrollebenenprotokolle, die Unicast verwenden, wie BGP, vergleichsweise einfach. Viele Kontrollebenenprotokolle verwenden jedoch Multicast-Verkehr. Beispiele sind OSPF, RIP und PIM. Die vollständige Liste finden Sie in der IPv4 Multicast Address Space Registry der IANA.

Einige dieser Protokolle verfügen über integrierte Authentifizierungsfunktionen wie Routing Information Protocol (RIP) oder Enhanced Interior Group Routing Protocol (EIGRP). Andere verwenden IPSec, um diese Authentifizierung bereitzustellen (z. B. OSPFv3, PIM). Im letzteren Fall bietet GET VPN eine skalierbare Möglichkeit, diese Protokolle zu sichern. In den meisten Fällen ist die Protokollnachrichtenauthentifizierung erforderlich, d. h. die Überprüfung, ob eine Nachricht von einem vertrauenswürdigen Peer gesendet wurde. GET VPN ermöglicht jedoch auch die Verschlüsselung solcher Nachrichten.

Um diesen Steuerungsebenen-Datenverkehr zu sichern (in der Regel nur für die Authentifizierung), muss er mit einer ACL beschrieben und in die GET VPN-Richtlinie integriert werden. Die Details hängen vom zu sichernden Protokoll ab. Dabei muss berücksichtigt werden, ob die ACL Datenverkehr enthält, der nur über einen Eingangs-GET-VPN-Knoten (der gekapselt ist) oder einen Ausgangs-Knoten läuft.

Es gibt zwei grundlegende Möglichkeiten, PIM-Protokolle zu sichern:

• permit ip any 224.0.0.13 0.0.0.0: Dies ist die Multicast-Gruppe "Alle PIM-Router". Dies schützt jedoch keine Unicast-PIM-Nachrichten.
• Erlauben Sie pim any: Dadurch wird das PIM-Protokoll unabhängig davon gesichert, ob Multicast oder Unicast verwendet wird.

Anmerkung: Die Befehle werden als Beispiele zur Erläuterung eines Konzepts angegeben. Beispielsweise müssen bestimmte PIM-Protokolle, die zum Bootstrap von PIM verwendet werden, wie BSR oder Auto-RP ausgeschlossen werden. Neue Verfahren haben gewisse Vorteile und Unannehmlichkeiten, die von der Bereitstellung abhängen. Weitere Informationen zum Sichern von PIM mit GET VPN finden Sie in der entsprechenden Literatur.

Schlussfolgerungen

Multicast wird in Netzwerken immer häufiger verwendet. Das Aufkommen von IPTV-Diensten in Breitband-Heimnetzwerken und die Entwicklung hin zu elektronischen Handelsanwendungen auf vielen Finanzmärkten sind nur zwei Beispiele für Anforderungen, die Multicast zu einer absoluten Anforderung machen. Multicast bringt eine Vielzahl unterschiedlicher Herausforderungen in Bezug auf Konfiguration, Betrieb und Management mit sich. Eine der größten Herausforderungen ist die Sicherheit.

In diesem Dokument werden verschiedene Möglichkeiten zum Sichern von Multicast untersucht:

• Sehen Sie sich zunächst die gesamte Multicast-Kontroll- und Datenebene an, um zu erklären, wie die Unterschiede zu Unicast neue Sicherheitsherausforderungen darstellen.
• Anschließend wurden die wichtigsten Protokolle, die in einem Multicast-Netzwerk vorkommen, insbesondere IGMP, PIM und MSDP, eingehend untersucht. In jedem Fall wurden eine Beschreibung der Sicherheitsbedrohungen und empfohlene Best Practices zur Eindämmung dieser Bedrohungen bereitgestellt.
• Darüber hinaus gibt es einige Beispiele dafür, wie Multicast in bestimmten Anwendungen gesichert werden kann, z. B. in Breitband-Edge-Netzwerken, in denen die Bandbreite im Vergleich zur Bandbreite, die für bestimmte Videodatenströme erforderlich ist, begrenzt werden kann.
• Schließlich wurde die GET-VPN-Architektur als Mittel zur integrierten Multicast-Funktion mit IPSec für die Bereitstellung sicherer VPNs beschrieben.

Berücksichtigen Sie bei der Multicast-Sicherheit den Unterschied zu Unicast. Die Multicast-Übertragung basiert auf der Erstellung eines dynamischen Zustands, Multicast umfasst die dynamische Paketreplikation und Multicast erstellt unidirektionale Trees als Reaktion auf PIM JOIN/PRUNE-Nachrichten. Die Sicherheit dieser gesamten Umgebung erfordert das Verständnis und die Bereitstellung eines umfangreichen Frameworks von Cisco IOS-Befehlen. Diese Befehle konzentrieren sich hauptsächlich auf den Schutz von Protokollvorgängen, Zuständen (Multicast) oder Policern, die gegen Pakete wie CoPP gesetzt werden. Mit der richtigen Verwendung dieser Befehle ist es möglich, einen robusten geschützten Dienst für IP-Multicast bereitzustellen.

Zusammenfassend lässt sich sagen, dass in diesem Whitepaper verschiedene Ansätze beschrieben und gefördert werden:

1. Weit verbreitete Verwendung von SSM: Dies ist der einfachste PIM-Modus, der auch die Verwendung von (S,G)-Weiterleitung ermöglicht. 
2. Wenn ASM-Services benötigt werden, stellen Sie sicher, dass ein zuverlässiger Service bereitgestellt werden kann. Die Verwendung statisch definierter RPs bietet eine sicherere Kontrollebene als dynamische RP-Ankündigungen. Auto-RP und BSR sind flexibler
3. Wenn PIM-SM aktiviert ist, prüfen Sie Bereiche mit besonderen Schwachstellen, wie den Registrierungstunnel zum RP, und stellen Sie sicher, dass der DR stets gut geschützt ist. CoPP ist in diesen Bereichen sehr hilfreich.
4. Wenn domänenübergreifende ASM-Services erforderlich sind, überlegen Sie, ob BiDir PIM bereitgestellt werden kann.
5. Verwenden Sie globale mroute/igmp-Statusgrenzen - verstehen Sie die Funktionen Ihrer Plattformen sowie die erwartete maximale Anzahl an Status, die Sie unter normalen Umständen und im schlimmsten Fall benötigen. Konfigurieren Sie Grenzen innerhalb der Funktionen Ihrer Plattform, die es Ihrem Netzwerk ermöglichen, seine maximalen Grenzen zu erreichen.
6. Grundlegende Filter: rACL/CoPP und Infrastruktur-ACLs blockieren PIM auf dem Access Layer

IP-Multicast ist ein leistungsstarkes und skalierbares Mittel zur Bereitstellung einer Vielzahl von Anwendungsservices. Wie bei Unicast muss auch hier eine Vielzahl unterschiedlicher Bereiche geschützt werden. In diesem Dokument werden die grundlegenden Bausteine zum Sichern eines IP-Multicast-Netzwerks beschrieben.

Zugehörige Informationen

• Richtlinien für die Zuweisung von IP-Multicast-Adressen
• Konfigurieren von IPv4-IGMP-Filtern
• Gruppenverschlüsseltes Transport-VPN