218004-Secure-IP-multicast implementaties

Inleiding

Dit document beschrijft algemene richtlijnen over best practices om een IP-multicast netwerkinfrastructuur te beveiligen.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• IP-multicast

Gebruikte componenten

Dit document is niet beperkt tot specifieke software- en hardware-versies.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Achtergrondinformatie

Dit document behandelt enkele basisconcepten, terminologie en behandelt de vermelde onderwerpen:

• Mechanismen om een specifiek platform en het netwerk in het algemeen te beveiligen.
• Alle Source Multicast- (ASM) en Source Specific Multicast-modellen (SSM).
• Multicast Virtual Private Network (MVPN)-beveiliging. 
• Architectuur voor Group Encrypted Transport (GET) Virtual Private Network (VPN) die vertrouwelijkheid en integriteit biedt voor multicast-gegevensvlak of besturingsplantverkeer.

Terminologie

In IP multicast zijn er twee klassieke servicemodellen:

1. Elke bronmulticast (ASM)

2. Source Specific Multicast (SSM)

In ASM, sluit de ontvanger zich aan bij een groep G via een het lidmaatschapsrapport van de Groep van Internet van het Protocol (IGMP) of van de Multicast Luisterontdekking (MLD) om de groep aan te duiden. Dit rapport vraagt verkeer door om het even welke bron naar groep G wordt verzonden, en vandaar de naam "om het even welke bron die." In SSM daarentegen sluit de ontvanger zich aan bij een specifiek kanaal dat wordt gedefinieerd door een bron S, die naar een groep G stuurt. Elk van deze servicemodellen wordt hieronder in detail beschreven.

Any Source Multicast

Het ASM-model wordt gekenmerkt door twee protocolklassen: "dense mode flood-and-prune" en "sparse mode expres":

i) Dense Mode Flood-and-Prune Protocols (DVMRP/MOSPF/PIM-DM)

In dense mode protocollen, alle routers in het netwerk zijn bewust van alle bomen, hun bronnen en ontvangers. Protocollen zoals het Vector Multicast Routing Protocol van de Afstand (DVMRP) en de Dichte van het Protocol Onafhankelijke Multicast (PIM) "actieve bron"informatie van de overstromingswijze over het gehele netwerk en bouwen bomen via de verwezenlijking van "Prune Staat"in delen van de topologie waar het verkeer voor een specifieke boom ongewenst is. Ze worden ook wel "flood-and-prune"-protocollen genoemd. In Multicast Open Shortest Path First (MOSPF) wordt informatie over ontvangers overstroomd door het netwerk om de opbouw van bomen te ondersteunen.

De protocollen van de dichte wijze zijn ongewenst omdat elke boom die in één of ander deel van het netwerk wordt gebouwd middelgebruik (met convergentieeffect) op alle routers in het netwerk (of binnen het administratieve werkingsgebied, indien gevormd) altijd kan veroorzaken. Deze protocollen worden in de rest van dit artikel niet verder besproken.

ii) Expliciete join-protocollen (PIM-SM/PIM-biDir) in spaarstand

Met sparse mode-expliciete samenvoegingsprotocollen maken apparaten geen groepspecifieke status in het netwerk, tenzij een ontvanger een expliciet IGMP/MLD-lidmaatschapsrapport (of "samenvoegen") voor een groep heeft verzonden. Deze variant van ASM staat bekend om zijn schaal en is het multicast paradigma van focus.

Dit is de basis voor PIM-Sparse Mode, die de meeste multicast implementaties tot dit punt hebben gebruikt. Dit is ook de basis voor Bidirectionele PIM (PIM-BiDir), die in toenemende mate wordt ingezet voor VEEL (bronnen) tot VEEL (ontvangers) toepassingen.

Deze protocollen worden de dunne wijze genoemd omdat zij IP multicast leveringsbomen met een "dunne"ontvangerpopulatie efficiënt steunen en tot een controlevliegtuigstaat slechts op routers in de weg tussen bronnen en ontvangers, en in PIM-SM/BiDir, het Rendezvous Point (RP) leiden. Ze maken nooit status in andere delen van het netwerk. De staat in een router wordt slechts uitdrukkelijk gebouwd wanneer het ontvangt toetreedt van een stroomafwaartse router of een ontvanger, vandaar de naam "expliciet toetreedt protocollen".

Zowel PIM-SM als PIM-BiDir maken gebruik van "GEDEELDE BOMEN", waarmee verkeer vanuit elke bron naar een ontvanger kan worden doorgestuurd. De multicast staat op een gedeelde boom wordt bedoeld als (*,G) staat, waar * een wilde kaart voor OM HET EVEN WELKE BRON is. Bovendien ondersteunt PIM-SM de creatie van een toestand die betrekking heeft op verkeer vanuit een specifieke bron. Deze staan bekend als SOURCE TREES, en de bijbehorende staat wordt aangeduid als (S,G)-staat.

Source-Specific Multicast

SSM is het model dat wordt gebruikt wanneer de ontvanger (of een proxy) (S,G) "joins" verstuurt om aan te geven dat hij verkeer wil ontvangen dat door bron S naar groep G wordt gestuurd. Dit is mogelijk met IGMPv3/MLDv2 "INCLUDEER"-modemlidmaatschapsrapporten. Dit model wordt het Source Specific Multicast (SSM)-model genoemd. SSM mandateert het gebruik van expliciet-sluit zich aan bij protocol tussen routers. Het standaardprotocol hiervoor is PIM-SSM, wat simpelweg de subset is van PIM-SM die gebruikt wordt om (S,G) bomen te maken. Er zijn geen gedeelde bomen (*,G) staat in SSM.

Multicastontvangers kunnen zich dus "aansluiten" bij een ASM-groep G, of "toetreden" (of zich nauwkeuriger "abonneren" op) tot een SSM-kanaal (S,G). Om herhaling van de term "ASM-groep of SSM-kanaal" te voorkomen, wordt de term (multicast) stroom gebruikt, wat impliceert dat de stroom een ASM-groep of een SSM-kanaal kan zijn.

Relevante multicastprotocollen/pakkettypen

Om een multicast netwerk te beveiligen is het belangrijk om de pakkettypes te begrijpen die algemeen worden ontmoet en hoe te tegen hen te beschermen. Er zijn drie belangrijke protocollen waarmee rekening moet worden gehouden:

1. IGMP/MLD

2. PIM

3. MSDP

In de volgende paragraaf wordt elk van deze protocollen besproken en worden de problemen besproken die met elk ervan kunnen ontstaan.

IGMP/MLD-pakketten

IGMP/MLD is het protocol dat door multicast-ontvangers wordt gebruikt om aan te geven dat zij voor een bepaalde multicast groep inhoud willen ontvangen. Internet Group Membership Protocol (IGMP) is het protocol dat in IPv4 wordt gebruikt en Multicast Listener Discovery (MLD) is het protocol dat in IPv6 wordt gebruikt.

Er zijn twee versies van IGMP die algemeen worden geïmplementeerd, IGMPv2 en IGMPv3. Er zijn ook twee versies van MLD die algemeen worden ingezet, MLDv1 en MLDv2.

IGMPv2 en MLDv1 zijn functioneel gelijkwaardig en IGMPv3 en MLDv2 zijn functioneel gelijkwaardig.

Deze protocollen worden in deze koppelingen gespecificeerd:

IGMPv2: RFC 2236

MLDv1: RFC 3590

IGMPv3 en MLDv2: RFC 4604

IGMPv2 en IGMPv3 is niet alleen een protocol maar ook een IPv4 IP-protocol (met name protocol nummer 2). Het wordt niet alleen gebruikt zoals beschreven in deze RFCs om multicast groepslidmaatschap te melden, maar ook door andere IPv4 multicast protocollen zoals DVMRP, PIM versie 1, mtrace en mrinfo. Dit is belangrijk om te onthouden wanneer u probeert IGMP te filteren (bijvoorbeeld via Cisco IOS® ACL’s). In IPv6 is MLD geen IPv6-protocol; in plaats daarvan wordt ICMPv6 gebruikt om MLD-pakketten te dragen. PIM versie 2 is hetzelfde protocoltype in IPv4 en IPv6 (protocolnummer 103).

PIM-beheerpakketten

In deze paragraaf worden multicast- en unicast PIM-controlepakketten besproken. Auto-RP en Bootstrap Router (BSR), die manieren zijn om Rendezvous Points te selecteren en controlegroep-to-RP toewijzingen in PIM-SM netwerken te controleren, worden besproken.

Multicast PIM-beheerpakketten

Multicast PIM Control-pakketten omvatten:

• PIM Hello - Het pakket van PIM Hello is een verbinding-lokaal bereikIP multicast pakket dat naar een router wordt verzonden in bijlage aan het zelfde netwerk om buren te vestigen PIM.
• PIM Join/Prune - PIM Join/Prunes zijn link-local scope IP multicast-pakketten die worden verzonden om multicast status te maken / te verwijderen en alleen worden verzonden naar PIM-buren. Zij zijn multicast binnen LAN om bewering, rapportonderdrukking, en andere PIM protocoldetails te vergemakkelijken, maar zij worden altijd gericht aan een specifieke buur.
• PIM DF-elected - PIM Designated Forwarder is de Bi-Dir PIM router verantwoordelijk voor (*,G) JOINS verzonden naar de RP namens aangesloten ontvangers of downstream PIM buren. Voor gevallen waarin een PIM router een andere router detecteert die (*,G) VERSTUURT OP hetzelfde segment voor dezelfde groep G, is er een verkiezing om de router met het beste pad naar de RP te bepalen.
• PIM Assert - PIM Asserts zijn link-lokale IP multicast pakketten verzonden wanneer een PIM router gekoppeld is aan een netwerksegment dat actief pakketten doorstuurt voor een bepaalde (S,G) uit een bepaalde interface begint met het ONTVANGEN van pakketten voor die zelfde (S,G) op dezelfde interface waarop doorgestuurd worden. Deze gebeurtenis geeft de aanwezigheid aan van een andere router die denkt dat het de Single Forwarder (SF) voor deze (S,G) is. Het Assert mechanisme kiest daarvoor een unieke SF (S, G). De PIM SF router wordt verkozen om pakketten voor een bepaalde (S,G) stroom door te sturen. PIM staat voor verschillende routers toe om de rol van SF uit te voeren namens verschillende (S, G)'s, idealiter is er slechts één SF per (S, G). Verwar de SF niet met de aangewezen router. De aangewezen PIM router is de router die verantwoordelijk is voor Josef/PRUNES of SOURCE REGISTERS die naar de RP worden verzonden in een PIM-SM-netwerk.
• PIM Bootstrap - PIM Bootstrap berichten worden verzonden in een PIMv2 netwerk om de dynamische verkiezing van een Rendezvous Point voor een bepaalde groep G te vergemakkelijken.

Unicast PIM-beheerpakketten

Unicast PIM Control Packets zijn gericht naar of van de RP en omvatten:

• Source Register Packet - PIM Source Register Packets worden verzonden om een nieuwe multicast bron te registreren met een Rendezvous Point. Zodra een Bron multicast pakketten begint te verzenden, stuurt de Aangewezen router die aan het bronnetwerk is verbonden een unicastregisterstroom naar de RP om aan te geven dat er een actieve bron aanwezig is voor een multicast groep waarvoor de RP verantwoordelijk is.
  De pakketten van het bron Register worden verzonden als unicastinkapseling van de originele multicast stroom.
  PIM-registerberichten worden op procesniveau geschakeld en worden alleen verstuurd totdat de RP een register stopbericht verstuurt. Het effect van deze pakketten op de prestaties is evenredig met het debiet van de bron (per (S,G) stroom).
• Het Pakket van het Stop van het register - De Pakketten van het Stop van het PIM- Register worden verzonden van het Punt Rendezvous naar PIM DR. die het Bericht van het Register verzond. Registreer Stop-berichten worden verzonden zodra de RP multicast-pakketten natief uit de bron begint te ontvangen.
• BSR Kandidaat-Rendezvous Point Advertisement Packet - PIM BSR C-RP-Advertisement Pakketten worden naar de BSR gestuurd om een kandidaat RP te adverteren zodra de BSR is gekozen.

Afbeelding 1: PIM Unicast-pakketten 

Aanvallen die zulke pakketten uitbuiten kunnen overal vandaan komen, omdat deze pakketten unicast zijn.

Basisbedreigingen tegen een router

Er zijn een aantal fundamentele bedreigingen tegen een router die onafhankelijk zijn van of de router multicast steunt en of de aanval multicast verkeer of protocollen impliceert.

De aanvallen van de ontkenning van de dienst (Dos) zijn de belangrijkste generische aanvalsvectoren in een netwerk. In principe kan elk netwerkelement met een aanval van Dos worden gericht, die het element met potentieel verder verlies of degradatie van de dienst voor wettige gebruikers kan overbelasten. Het is van het grootste belang dat u de basisaanbevelingen voor netwerkbeveiliging opvolgt die van toepassing zijn op unicast.

Het is het opmerken waard dat multicast aanvallen niet altijd opzettelijk, maar vaak toevallig zijn. De Witty-worm bijvoorbeeld, voor het eerst waargenomen in maart 2004, is een voorbeeld van een worm die zich verspreidt door willekeurige aanvallen op IP-adressen. Als gevolg van de volledige randomisatie van de adresruimte, werden multicast IP-bestemmingen ook beïnvloed door de worm. In vele organisaties, stortte een aantal eerste-hoprouters omdat de worm pakketten naar vele verschillende multicast bestemmingsadressen verzond. De routers, echter, waren niet scoped voor zulk een multicast verkeerslading met de bijbehorende staatsverwezenlijking, en effectief ervaren middeluitputting. Dit illustreert de noodzaak om multicast verkeer te beveiligen, zelfs als multicast niet in een onderneming wordt gebruikt.

Generieke bedreigingen tegen routers zijn onder meer:

• Packet-overstromingen van elk type; bijvoorbeeld tegen hardwarepaden zoals trage paden (punt) en softwarepaden zoals beheer- of besturingsplantpoorten, die Secure Shell (SSH), Telnet, BGP-protocol (BGP), OSPF, Network Time Protocol (NTP) omvatten, enzovoort
• Inbraken in de router, met daaropvolgende exploitatie van functies op de router; zwakke Telnet- of SSH-wachtwoorden en zwakke Simple Network Management Protocol (SNMP)-communitystrings zijn een veel voorkomend probleem in moderne netwerken.
• Operationele problemen zoals misconfiguraties of aanvallen met voorkennis kunnen de beveiliging van het gehele netwerk en het bijbehorende verkeer in gevaar brengen.
  
  

Wanneer multicast is ingeschakeld op een router, moet deze worden beveiligd naast unicast. Het gebruik van IP-multicast verandert het fundamentele bedreigingsmodel niet; het maakt echter aanvullende protocollen (PIM, IGMP, MLD, MSDP) mogelijk die onderhevig kunnen zijn aan aanvallen, die specifiek moeten worden beveiligd. Wanneer unicastverkeer in deze protocollen wordt gebruikt, is het bedreigingsmodel identiek aan andere protocollen die door de router worden uitgevoerd.

Het is belangrijk om op te merken dat multicast verkeer niet op dezelfde manier kan worden gebruikt als unicast verkeer om een router aan te vallen omdat multicast verkeer fundamenteel "ontvanger gedreven" is en niet op een verre bestemming kan worden gericht. Een aanvalsdoel moet expliciet worden "aangesloten" bij de multicast-stroom. In de meeste gevallen (Auto-RP is de belangrijkste uitzondering) luisteren routers alleen naar en ontvangen ze "link local" multicast verkeer. Link Local Traffic wordt nooit doorgestuurd. Daarom kunnen aanvallen op een router met multicast pakketten alleen voortkomen uit direct verbonden aanvallers.

Bedreigingen van de bronkant

Multicastbronnen, of pc's of videoservers soms niet onder dezelfde administratieve controle staan als het netwerk. Vanuit het oogpunt van de netwerkexploitant wordt de afzender dan ook meestal als onbetrouwbaar behandeld. Gezien de krachtige mogelijkheden van PC's en servers, en hun complexe beveiligingsinstellingen, die vaak onvolledig zijn, vormen de zenders een aanzienlijke bedreiging tegen elk netwerk, inclusief multicast. Deze bedreigingen omvatten:

• Layer 2-aanvallen: Er zijn een breed scala aan aanvalsformulieren op Layer 2 om verschillende soorten aanvallen uit te voeren. Deze zijn zowel van toepassing op unicast als op multicast. Aangezien deze aanvalsvormen niet specifiek voor multicast zijn, worden zij niet meer in detail in dit document besproken. Zie voor meer informatie het boek van Cisco Press "LAN Switch Security", ISBN-10: 1-58705-467-1.
• Aanvallen met multicast verkeer: Zoals eerder beschreven, is het moeilijk om aanvallen met multicast verkeer te voeren aangezien de eerste-hop router geen multicast verkeer door:sturen tenzij er een luisteraar voor de groep is. Echter, de eerste hop kan worden aangevallen op verschillende manieren met multicast pakketten:
  • Netwerkverzadigingsaanvallen: een aanvaller kan een segment overspoelen met multicast-pakketten, over het gebruik van de beschikbare bandbreedte, wat kan leiden tot een DoS-conditie.
  • Multicaststatenaanvallen: De router van de eerste hop wordt overspoeld met multicastpakketten, die tot teveel staat, en een gevolgvoorwaarde van de Dos-aanval kunnen leiden.
  • Een afzender kan proberen de PIM DR te worden, via PIM hellos die worden verzonden. In dergelijke gevallen wordt er geen verkeer naar of van het netwerk doorgestuurd.
  • PIM PDF-kiespakketten voor een BiDir-PIM PDF kunnen worden gespoofd. In dergelijke gevallen wordt er geen verkeer naar of van het netwerk doorgestuurd.
  • Een afzender kon parodie AutoRP RP-ontdekking of BSR bootstrap berichten. Dit zou effectief een nep-RP aankondigen, en een PIM-SM/BiDir service neerhalen of ontwrichten.
  • Een afzender kon unicastaanvallen, zoals PIM bronregister/register-stop berichten, of kon BSR aankondigen pakketten verzenden en een nep BSR aankondigen.
  • Een afzender kan naar elke geldige multicast groep verzenden, tenzij dit wordt gefilterd. Als een bronadres wordt gespoofd en niet verhinderd bij de rand, kan de afzender het bron IP adres van een wettige afzender gebruiken, en inhoud in delen van het netwerk met voeten treden.
  • Multicast-aanvallen tegen besturingsplatformprotocollen: een aantal protocollen die niet aan multicast zijn gekoppeld, zoals OSPF en Dynamic Host Configuration Protocol (DHCP), gebruiken multicast-pakketten die kunnen worden gebruikt om deze protocollen aan te vallen
• Masquerading: Er zijn een aantal aanvalsvormen waar een afzender kan doen alsof hij een andere afzender is. IP-adressen van gespoofde bronnen zijn zo'n aanvalsvorm.
• Diefstal van de dienst: Tenzij de afzenders worden gecontroleerd, is het mogelijk om de multicast dienst van de afzender onwettig te gebruiken.

Opmerking: hosts verzenden of ontvangen normaal geen PIM-pakketten. De gastheer die dit doet kan waarschijnlijk een aanval proberen.

Bedreigingen van de ontvangerzijde

De ontvanger is doorgaans ook een platform met een aanzienlijke CPU-voeding en bandbreedte, en maakt een aantal aanvalsformulieren mogelijk. Deze zijn grotendeels identiek aan de bedreigingen aan de afzenderkant. Layer 2-aanvallen blijven een belangrijke aanvalsvector. Fake-ontvangers en diefstal van service zijn ook mogelijk aan de ontvangerzijde, behalve dat de aanvalsvector meestal IGMP (of Layer-2-aanvallen, zoals vermeld) is.

Bedreigingen tegen een rendez-vous point en BSR

PIM-SM RP's en PIM-BSR's zijn cruciale punten in een multicast netwerk en zijn daarom waardevolle doelwitten voor een aanvaller. Wanneer geen van beide de eerste-hop router is, kunnen slechts de vormen van de unicastaanval, die PIM unicast omvat, direct tegen die elementen worden gericht. De bedreigingen tegen RP's en BSR's omvatten:

• Alle generische aanvalsvormen, zoals die in de sectie "Basis Bedreigingen Tegen een router"worden beschreven.
• PIM unicast-aanvallen, mogelijk met gespoofde IP-adressen, maken DoS-aanvallen mogelijk, via PIM-register of register-stop-berichten die door een kwaadaardig apparaat worden verzonden.

Multicast- en Unicast-beveiliging (vergeleken)

Overwegingen/filters voor status

Overweeg de topologie in Figuur 3, die een bron, drie ontvangers (A, B, C), een switch (S1), en twee routers (R1 en R2) toont. De blauwe lijn vertegenwoordigt een unicaststroom en de rode lijn vertegenwoordigt een multicaststroom. Alle drie de ontvangers zijn lid van de multicast flow.

Fig 3: replicatie in routers en Switches

Zo remt u de verkeersstroom van een specifieke bron naar een specifieke ontvanger:

• Voor de unicaststroom, installeer overal een filter op de weg van afzender aan ontvanger.
• Voor de multicaststroom, echter, moeten de beheerders meer specifiek zijn over waar te om filters te installeren: bij de ontvangerzijfilter na het laatste replicatiepunt vóór de ontvanger; bij de bronzijfilter vóór het eerste replicatiepunt na de bron.

Aanvallen vanuit multicastbronnen

Deze paragraaf is van toepassing op zowel de ASM- als de SSM-servicemodellen, waarbij het verkeer wordt doorgestuurd op basis van de ontvangst van expliciete verbindingen aan de ontvangerzijde.

Voor unicaststromen is er geen impliciete ontvangerbescherming. Een unicastbron kan verkeer naar een bestemming verzenden, zelfs als deze bestemming niet om het verkeer heeft gevraagd. Daarom worden verdedigingsmechanismen zoals firewalls gewoonlijk gebruikt om eindpunten te beschermen. Multicast heeft daarentegen een impliciete bescherming in de protocollen ingebouwd. Het verkeer bereikt idealiter alleen een ontvanger die zich heeft aangesloten bij de stroom in kwestie.

Met ASM, kunnen de bronnen verkeerstoevoeging of aanvallen van Dos door multicast verkeerstransmissie aan om het even welke groepen lanceren die door een actieve RP worden ondersteund. Dit verkeer bereikt idealiter geen ontvanger, maar kan de router van de eerste hop in de weg op zijn minst bereiken, evenals de RP, die voor beperkte aanvallen toestaat. Als een kwaadaardige bron echter een groep kent waarin een doelontvanger geïnteresseerd is, en als er geen geschikte filters aanwezig zijn, kan het verkeer naar die groep verzenden. Dit verkeer wordt ontvangen zolang de ontvangers naar de groep luisteren.

Met SSM zijn aanvallen door ongewenste bronnen alleen mogelijk op de first-hop router waar het verkeer stopt als geen ontvanger zich bij dat (S,G) kanaal heeft aangesloten. Dit leidt niet tot enige staatsaanval op de eerste-hop router omdat het al SSM verkeer verwerpt waarvoor geen expliciete toetreden staat van ontvangers bestaat. In dit model is het niet voldoende voor een kwaadaardige bron om te weten in welke groep een doelwit geïnteresseerd is omdat "toetreedt" bronspecifiek zijn. Hier zouden IP-bronadressen die worden gespoofd plus potentiële routingaanvallen nodig zijn om te slagen.

Statusaanvallen

Zelfs zonder ontvangers die in een netwerk aanwezig zijn, leidt PIM-SM tot (S, G) en (*, G) staat op de eerste-hoprouter het dichtst bij de bron en ook op het Rendezvous Punt. Zo bestaat er de mogelijkheid van een staatsaanval op het netwerk bij de bron eerste-hop router en op de PIM-SM RP.

Als een kwaadaardige bron verkeer naar meerdere groepen begint te verzenden, dan voor elk van de groepen die worden gedetecteerd, maken de routers in het netwerk staat bij de bron en de RP, op voorwaarde dat de groepen in kwestie zijn toegestaan door de RP-configuratie.

Daarom is PIM-SM onderworpen aan staat en verkeersaanvallen door bronnen. De aanval kan worden verergerd als de bron zijn bron IP adres willekeurig binnen de juiste prefix verandert, of met andere woorden, alleen de host bits van het adres worden gespoofd.

Fig 4: ASM RP-aanvallen

Net als bij PIM-SSM zijn aanvallen van de staat PIM-BiDir vanuit bronnen onmogelijk. Het verkeer in PIM-BiDir wordt doorgestuurd op de staat die wordt gecreëerd door joins van ontvangers en op het door de staat doorgestuurde verkeer naar de RP, zodat het ontvangers achter de RP kan bereiken, aangezien de joins alleen naar de RP gaan. State-to-forward verkeer naar de RP wordt de status (*,G/M) genoemd en wordt gecreëerd door RP-configuratie (statisch, Auto-RP, BSR). Het verandert niet in de aanwezigheid van bronnen. Daarom kunnen aanvallers multicast verkeer naar een PIM-BiDir RP sturen, maar in tegenstelling tot PIM-SM, is een PIM-BiDir RP geen "actieve" entiteit, en in plaats daarvan gewoon doorsturen of weggooien van verkeer voor PIM-BiDir groepen.

Opmerking: op sommige Cisco IOS-platforms (*,G/M) wordt de status niet ondersteund. In zulke gevallen kunnen bronnen de router aanvallen door multicast verkeersoverdracht naar meerdere PIM-BiDir groepen, wat (*,G) statusvorming veroorzaakt. De Catalyst 6500-switch ondersteunt bijvoorbeeld wel (*,G/M) toestanden).

Door ontvanger geïnitieerde aanvallen

De aanvallen kunnen uit multicast ontvangers voortkomen. Elke ontvanger die een IGMP/MLD-rapport verstuurt, maakt doorgaans een status aan op de router van de eerste hop. Er is geen gelijkwaardig mechanisme in unicast.

Fig 5: Expliciet doorsturen van verkeer op basis van verbindingen aan ontvangerzijde

De aanvallen van de ontvanger kunnen van drie types zijn:

1. Een multicast-ontvanger kan proberen zich aan te sluiten bij een stroom waarvoor hij niet is geautoriseerd en probeert inhoud te ontvangen die hij niet-geautoriseerd is om te ontvangen.
2. Een multicast-ontvanger kan de beschikbare netwerkbandbreedte potentieel overladen door de belangstelling voor veel groepen of kanalen. Dit soort aanval wordt een gedeelde bandbreedte aanval tegen andere potentiële ontvangers van content.
3. Een multicast-ontvanger kan proberen een aanval te lanceren op routers of switches. Er kan een groot aantal IGMP-rapporten worden gegenereerd, waardoor een grote hoeveelheid multicast-boomstatus kan worden gecreëerd en mogelijk routercapaciteit kan worden overbelast. Dit kan op zijn beurt resulteren in een toename van multicast conversietijden of in een DoS op de router.
   
   

Verschillende manieren om dit soort aanvallen te verzachten in de volgende sectie, Security binnen een Multicast Network.

Beveiliging binnen een multicast-netwerk

Security voor netwerkelement

Beveiliging is geen puntfunctie, maar een intrinsiek onderdeel van elk netwerkontwerp. Als zodanig moet op elk punt in het netwerk rekening worden gehouden met de veiligheid. Het is van het grootste belang dat elk netwerkelement op de juiste wijze wordt beveiligd. Eén mogelijk aanvalsscenario dat op iedere technologie van toepassing is, is een router die door een indringer is omgedraaid. Zodra een indringer controle van een router heeft, kan de aanvaller een aantal verschillende aanvalsscenario's in werking stellen. Elk netwerkelement moet daarom op passende wijze worden beveiligd tegen elke vorm van basisaanval, en tegen specifieke multicast-aanvallen.

Local Packet Transport Service (LPTS)

Op Cisco IOS XR fungeert Local Packet Transport Service (LPTS) als een policer van verkeer naar het besturingsplane van de router, vergelijkbaar met CoPP op Cisco IOS. Bovendien, ontvang verkeer, dat unicast en multicast verkeer omvat, kan worden gefiltreerd en tarief beperkt.

Multicastspecifieke beveiliging

In een multicast-netwerk moet elk netwerkelement worden beveiligd met multicast-specifieke beveiligingsfuncties. Deze worden in deze sectie geschetst, voor generische routerbescherming. De eigenschappen die niet op elke router, maar slechts in specifieke plaatsen in het netwerk worden vereist, en de eigenschappen die interactie tussen routers (zoals authentificatie PIM) vereisen worden besproken in de volgende sectie.

Fig 6: limieten route

De limieten van Mroute staan het instellen van een drempel op het aantal routes toe die in de multicast routeringstabel zijn toegestaan. Als een multicast routelimiet is ingeschakeld, wordt er geen multicast status gecreëerd buiten de ingestelde limiet. Er is ook een waarschuwingsdrempel. Wanneer het aantal routes de waarschuwingsdrempel overschrijdt, worden de syslog waarschuwingsberichten teweeggebracht. Bij de route limiet elke verdere pakketten die de status zou veroorzaken worden verworpen.

De opdracht IP multicast route-limit is ook beschikbaar per MVRF.

Om het bedieningsvliegtuig te beveiligen, verhardt MSDP via drie fundamentele veiligheidsmaatregelen:

1) MSDP SA-filters

Het is een "best common practice" om de inhoud van MSDP berichten via MSDP SA filters te filteren. Het belangrijkste idee van dit filter is om propagatie van multicast staat voor toepassingen en groepen te vermijden die geen toepassingen voor het hele internet zijn en niet buiten het brondomein hoeven te worden doorgestuurd. Idealiter staan de filters uit veiligheidsoogpunt alleen bekende groepen toe (en mogelijk afzenders) en ontkennen ze onbekende afzenders en/of groepen.

Het is gewoonlijk niet mogelijk om alle toegestane afzenders en/of groepen expliciet op te sommen. aanbevolen wordt om het standaardconfiguratiefilter voor PIM-SM-domeinen te gebruiken met één RP voor elke groep (geen MSDP-mesh-groep):

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

Het wordt aanbevolen om zo strikt mogelijk en in beide richtingen, inkomend en uitgaand te filteren.

Gebruik voor meer informatie over aanbevelingen voor MSDP SA-filters: https://www.cisco.com/c/en/us/support/docs/ip/ip-multicast/13717-49.html

Met de ip msdp sa-limit opdracht kunt u het aantal SA-staten beperken die zijn gemaakt vanwege SA-berichten die zijn geaccepteerd door een MSDP-peer. Enkele eenvoudige aanbevelingen voor een vuistregel zijn:

• Kleine limiet van stub-buurman 
• Grote limiet voor transit-buurman (bijvoorbeeld maximum #SAs in internet)
• Transit ISP - configureer maximaal #SAs uw platform kan ondersteunen

3) MSDP MD5-buurverificatie

Aanbevolen wordt om de wachtwoordverificatie met Message-Digest Algorithm (MD5) op MSDP-peers te gebruiken. Hierbij wordt de TCP/MD5-handtekeningsoptie gebruikt die equivalent is aan het gebruik dat in RFC 6691 is beschreven om BGP te beveiligen.

Afbeelding 15: MSDP MD5-buurverificatie

Deze drie MSDP-beveiligingsaanbevelingen hebben verschillende doelstellingen:

• Buurverificatie (met MD5) zorgt ervoor dat alleen vertrouwde MSDP-peers berichten kunnen verzenden.
• De SA-filters zorgen ervoor dat zelfs een vertrouwde MSDP-peer alleen SA-aankondigingen kan verzenden die in overeenstemming zijn met vooraf overeengekomen bron/groepsbeleid.
• De SA-limiet zorgt er verder voor dat zelfs met legitieme (S,G) aankondigingen van legitieme peers het beschikbare geheugen niet kan worden uitgeput.

Afzender/bron problemen

Vele multicast veiligheidskwesties die bij de afzender voortkomen kunnen met aangewezen unicast veiligheidsmechanismen worden verlicht. Een aantal unicast beveiligingsmechanismen worden aanbevolen best practices hier:

• Bescherming tegen bronadres (Unicast Reverse Path Forwarding, uRPF of ACL en IP-bronbeveiliging voor de toegangslaag)
• ACL’s voor infrastructuur (IP geen (naar) <ruimte voor kernadres> ontkennen)

Dergelijke maatregelen kunnen worden gebruikt om gerichte aanvallen op de kern te blokkeren. Dit zou bijvoorbeeld ook problemen oplossen zoals aanvallen die PIM unicastpakketten gebruiken voor de RP, die "binnen" het netwerk is en daarom beschermd zou worden door de infrastructuur ACL.

Op pakketfilter gebaseerde toegangscontrole - controlebronnen

In het voorbeeld in afbeelding 16 wordt het filter geconfigureerd op de LAN-interface (E0) van de eerste-hop multicast router (Aangewezen router). Het filter wordt gedefinieerd door een uitgebreide toegangscontrolelijst met de naam "bron". Deze ACL wordt toegepast op de broninterface van de aangewezen router die op de bron-LAN is aangesloten. In feite, vanwege de aard van multicast verkeer, zou er een gelijkaardig filter kunnen moeten zijn dat op alle LAN-onder ogen ziende interfaces wordt gevormd waarop de bronnen actief zouden kunnen worden. Aangezien het niet in alle gevallen mogelijk is om precies te weten waar de bronactiviteit plaatsvindt, wordt aanbevolen om dergelijke filters op alle ingangspunten in het netwerk toe te passen.

Fig 16: Controlebronnen

In een PIM-SM-netwerk kan een ongewenste verkeersbron met deze opdracht worden bestuurd. Wanneer het bronverkeer de router van de eerste hop raakt, leidt de router van de eerste hop (DR) tot (S, G) staat en verzendt een PIM BronRegister bericht naar RP. Als de bron niet vermeld is in de acceptatie-register filterlijst (geconfigureerd op de RP), dan verwerpt de RP het Register en stuurt een onmiddellijk Register-Stop bericht terug naar de DR.

In het getoonde voorbeeld, is eenvoudige ACL toegepast op de RP, die filters alleen op het bronadres. Het is ook mogelijk om de bron EN de groep te filteren met behulp van een uitgebreide ACL op de RP.

Er zijn nadelen met bronfilters omdat met de pim accepteer-register opdracht op de RP, PIM-SM (S,G) status nog steeds op de eerste-hop router van de bron wordt gecreëerd. Dit kan resulteren in verkeer bij ontvangers lokaal aan de bron en gelegen tussen de bron en de RP. Bovendien werkt de pim accepteer-register commando op het controlevlak van de RP. Dit kan worden gebruikt om de RP te overladen met nep-register berichten, en mogelijk een DoS-conditie veroorzaken.

Het wordt aanbevolen om de pim acceptatie-register opdracht op de RP toe te passen naast andere methoden, zoals de toepassing van eenvoudige dataplatform ACL's op alle DR's, op alle ingangspunten in het netwerk. Terwijl toegang ACLs op DR. in een perfect gevormd en bediend netwerk voldoende zou zijn, wordt het geadviseerd om het pim acceptatie-register bevel op RP als secundair veiligheidsmechanisme in het geval van misconfigurations op de randrouters te vormen. Gelaagde veiligheidsmechanismen met hetzelfde doel worden "verdediging in de diepte" genoemd, en is een gemeenschappelijk ontwerpprincipe in veiligheid.

Problemen met ontvangers - Control IGMP/MLD

De meeste ontvangerproblemen vallen binnen het domein van de interacties van het IGMP/MLD-ontvangerprotocol.

Afbeelding 18: Control IGMP

Wanneer IGMP- of MLD-pakketten worden gefilterd, onthoud deze punten:

• IPv4: IGMP is een IPv4-protocoltype (IPv4 protocol 2)
• IPv6: MLD wordt meegeleverd in pakketten met protocoltypen ICMPv6

Het IGMP-proces wordt standaard ingeschakeld zodra IP-multicast is ingeschakeld. IGMP-pakketten dragen ook deze protocollen, en daarom worden al deze protocollen ingeschakeld wanneer multicast is ingeschakeld:

• PIMv1 - PIMv1 was de eerste versie van PIM en is altijd ingeschakeld in Cisco IOS voor migratiedoeleinden. Huidige implementaties maken allemaal gebruik van PIMv2.
• Mrinfo - Mrinfo is een Unix-opdracht die Cisco IOS heeft geërfd om multicast-buren weer te geven. Cisco raadt het gebruik van SNMP aan in plaats van de opdracht mrinfo.
• DVMRP - DVMRP is een legacy dense mode afstandvectorprotocol met zeer beperkte schalingkenmerken. Cisco IOS-ondersteuning voor DVMRP is teruggetrokken of is al afgekeurd.
• Mtrace - Mtrace is het multicast-equivalent van unicast "traceroute" en is een handig hulpmiddel

Zie IGMP-typenummers (Internet Group Management Protocol) van Iran voor meer informatie

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-pakketten (voor IGMP/UDLR) kunnen worden gefilterd, aangezien dit waarschijnlijk aanvalspakketten zijn en geen geldige IGMP-protocolpakketten. Unicast IGMP-pakketten worden ondersteund door Cisco IOS ter ondersteuning van unidirectionele links en andere uitzonderingsvoorwaarden.

Gesmede IGMP/MLD-querypakketten kunnen resulteren in een lagere IGMP-versie dan verwacht.

In het bijzonder sturen hosts idealiter nooit IGMP-queries omdat een query verzonden met een lagere IGMP-versie alle hosts die deze query ontvangen kan veroorzaken om terug te keren naar de lagere versie. In aanwezigheid van IGMPv3 / SSM-hosts kan dit de SSM-stromen "aanvallen". In het geval van IGMPv2 kan dit resulteren in langere verloftijden.

Als er een niet-redundante LAN met één IGMP-query aanwezig is, moet de router IGMP-vragen die zijn ontvangen, laten vallen.

Als er een redundante / gemeenschappelijke passieve LAN bestaat, is een switch die IGMP-spionage kan uitvoeren vereist. Er zijn 2 specifieke functies die in dit geval kunnen helpen:

• Routerbewaker
• Minimale IGMP-versie, opdracht

Routerbewaker

Elke routerpoort kan een multicast routerpoort worden als de switch een multicast routerbeheerpakket (IGMP algemene query, PIM Hello of CGMP Hello) op die switch ontvangt. Wanneer een switch poort een multicast routerpoort wordt, wordt al het multicast verkeer naar die poort verzonden. Dit kan worden voorkomen met "Router Guard". De functie Router Guard vereist niet dat IGMP-spionage is ingeschakeld.

Met de functie Router Guard kan een gespecificeerde poort worden aangewezen als een multicast hostpoort. De poort kan geen routerpoort worden, zelfs als multicast routerbeheerpakketten worden ontvangen.

Deze pakkettypes worden verworpen als zij op een poort worden ontvangen die Router Guard heeft ingeschakeld:

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

Wanneer deze pakketten worden vernietigd, worden de statistieken bijgewerkt die erop wijzen dat de pakketten wegens Router Guard worden gelaten vallen.

Minimale IGMP-versie

Het is mogelijk om de minimumversie van toegestane IGMP-hosts te configureren. U kunt bijvoorbeeld alle IGMPv1-hosts of alle IGMPv1- en IGMPv2-hosts verbieden. Dit filter is alleen van toepassing op lidmaatschapsrapporten.

Als de hosts zijn aangesloten op een gemeenschappelijk "passief" LAN (bijvoorbeeld een switch die IGMP-controle niet ondersteunt of niet daarvoor is geconfigureerd), is er ook niets dat een router kan doen aan dergelijke foutieve vragen anders dan de "oude versie"-lidmaatschapsrapporten negeren die dan worden geactiveerd en niet zelf terugvallen.

Aangezien IGMP-vragen zichtbaar moeten zijn voor alle hosts, is het niet mogelijk om een op hash gebaseerd mechanisme voor berichtverificatie (HMAC) te gebruiken met een vooraf gedeelde sleutel, zoals statische sleutel IPSec, om IGMP-vragen te verifiëren via "geldige routers". Als twee of meer routers zijn gekoppeld aan een gemeenschappelijk LAN-segment, moet u een IGMP-querier kiezen. In dat geval is het enige filter dat kan worden gebruikt een IP-toegangsgroepfilter op basis van het IP-bronadres van de andere IGMP-router die vragen verstuurt.

"Normale" multicast IGMP-pakketten moeten worden toegestaan.

Deze filter kan op ontvangerpoorten worden gebruikt om alleen "goede" IGMP-pakketten toe te staan en bekende "slechte" pakketten te filteren:

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

Opmerking: dit type IGMP-filter kan worden gebruikt voor het ontvangen van ACL’s of CoPP. In beide toepassingen moet het worden gecombineerd met filters voor ander verkeer dat wordt verwerkt, zoals routering en beheer van vliegtuigprotocollen. 

Fig. 19: toegangscontrole voor hostontvanger

Gebruik GET VPN om verkeer van besturingsplane te verifiëren

Het is over het algemeen een beste praktijk om verkeer van het controlevliegtuig, zoals het verpletteren van protocollen voor authentiek te verklaren, om ervoor te zorgen dat de berichten van een vertrouwde op peer komen. Dit is relatief eenvoudig voor controlevlakke protocollen die unicast, zoals BGP gebruiken. Echter, veel besturingsplane protocollen gebruiken multicast verkeer. De voorbeelden zijn OSPF, RIP, en PIM. Zie IANA's IPv4 Multicast Address Space Registry voor de volledige lijst.

Sommige van deze protocollen hebben ingebouwde verificatie, zoals Routing Information Protocol (RIP) of Enhanced Interior Group Routing Protocol (EIGRP), anderen vertrouwen op IPSec om deze verificatie te leveren (bijvoorbeeld OSPFv3, PIM). Voor het laatste geval, GET VPN biedt een schaalbare manier om deze protocollen te beveiligen. In de meeste gevallen is de vereiste de authentificatie van het protocolbericht, of met andere woorden, de controle dat een bericht door een vertrouwde op peer werd verzonden. GET VPN maakt echter ook versleuteling van dergelijke berichten mogelijk.

Om te beveiligen (gewoonlijk alleen authenticeren) van dergelijk verkeer van besturingsplane, moet het verkeer worden beschreven met een ACL en worden opgenomen in het GET VPN-beleid. De details hangen van het protocol af dat moet worden beveiligd, waar de aandacht moet worden besteed aan of ACL verkeer omvat dat slechts een toegang KRIJGT VPN-knooppunt (dat is ingesloten), of ook een uitgangsknooppunt.

Er zijn twee fundamentele manieren om PIM-protocollen te beveiligen:

• Laat ip toe om het even welke 24.0.0.13 0.0.0.0: Dit is de multicast groep "Alle PIM Routers". Dit beveiligt echter geen unicast PIM-berichten
• Laat pim toe om het even welk: Dit beveiligt het PIM protocol, ongeacht of multicast of unicast wordt gebruikt

Opmerking: de opdrachten worden als voorbeelden gegeven om een concept te helpen uitleggen. Het is bijvoorbeeld nodig om bepaalde PIM-protocollen uit te sluiten die gebruikt worden om PIM te bootstrap, zoals BSR of Auto-RP. Beide methoden hebben bepaalde voordelen en ongemakken die afhankelijk zijn van de inzet. Raadpleeg specifieke documentatie over het beveiligen van PIM met GET VPN voor meer informatie.

Conclusies

Multicast wordt in netwerken steeds populairder. De opkomst van IPTV-diensten in breedbandnetwerken voor woningen en woningen en de verschuiving naar elektronische handelstoepassingen in veel van de financiële markten in de wereld zijn slechts twee voorbeelden van vereisten die multicast tot een absolute vereiste maken. Multicast wordt geleverd met een groot aantal verschillende uitdagingen op het gebied van configuratie, bediening en beheer. Een van de belangrijkste uitdagingen is veiligheid.

Dit document onderzocht verschillende manieren waarop multicast kan worden beveiligd:

• Kijk eerst naar de algemene multicast controle- en dataplanes, een verklaring van hoe de verschillen van unicast nieuwe beveiligingsuitdagingen met zich meebrengen.
• Vervolgens is een onderzoek uitgevoerd naar de belangrijkste protocollen die in een multicastnetwerk worden aangetroffen, met name IGMP, PIM en MSDP. In elk geval werd een beschrijving van beveiligingsbedreigingen en aanbevolen best practices voor beperking tegen deze bedreigingen verstrekt.
• Bovendien zijn er een aantal specifieke voorbeelden van hoe multicast kan worden beveiligd in bepaalde specifieke toepassingen, zoals breedbandnetwerken met randapparatuur waarbij de bandbreedte kan worden beperkt in vergelijking met de hoeveelheid bandbreedte die specifieke videostromen zouden kunnen vereisen.
• Tot slot, GET VPN architectuur werd beschreven als een middel van geïntegreerde multicast met IPSec voor levering van beveiligde VPN’s.

Met multicast beveiliging in gedachten, onthoud hoe het verschilt van unicast. Multicasttransmissie is gebaseerd op de aanmaak van dynamische status, multicast omvat dynamische pakketreplicatie en multicast bouwt unidirectionele bomen in antwoord op PIM CONNECT / PRUNE-berichten. De beveiliging van deze hele omgeving omvat de kennis en implementatie van een rijk framework van Cisco IOS-opdrachten. Deze opdrachten zijn grotendeels gecentreerd rond de bescherming van protocolbewerkingen, statussen (multicast) of policers die tegen pakketten zoals CoPP zijn geplaatst. Door het juiste gebruik van deze opdrachten is het mogelijk om een robuuste beveiligde service voor IP-multicast te bieden.

Kort samengevat worden in dit artikel meerdere benaderingen gepromoot en beschreven:

1. Wijdverbreid gebruik van SSM - dit is de meest eenvoudige PIM-modus die ook het gebruik van (S,G) doorsturen mogelijk maakt. 
2. Als ASM-diensten nodig zijn, zorg ervoor dat een robuuste service kan worden geleverd - het gebruik van statisch gedefinieerde RP's biedt een veiliger controlevliegtuig dan dynamische RP-aankondigingen. Auto-RP en BSR zijn flexibeler
3. Als PIM-SM is ingeschakeld, kijk dan naar gebieden die bijzonder kwetsbaar zijn, zoals de registertunnel naar de RP, en zorg ervoor dat de DR altijd goed beschermd is. CoPP is zeer behulpzaam op deze gebieden.
4. Als er interdomeinASM-services nodig zijn, overweeg dan of BiDir PIM kan worden geïmplementeerd.
5. Gebruik wereldwijde limieten voor de route-/igmp-status - begrijp de mogelijkheden van uw platforms samen met de verwachte maximale hoeveelheid status die u onder normale omstandigheden en in het ergste geval nodig hebt. Configureer de limieten binnen de mogelijkheden van uw platform die uw netwerk in staat stellen om binnen de maximale limieten te werken.
6. Fundamentele filters - rACL/CoPP en infrastructuur ACLs, die PIM bij de toegangslaag blokkeert

IP Multicast is een opwindend en schaalbaar middel om een scala aan toepassingsservices te leveren. Net als unicast moet het worden beveiligd op verschillende gebieden. Dit artikel bevat de basisbouwstenen die kunnen worden gebruikt om een IP-multicast netwerk te beveiligen.

Gerelateerde informatie

• Richtlijnen voor IP-multicast adrestoewijzing voor ondernemingen
• IPv4 IGMP-filters configureren
• Groep versleuteld transport via VPN