21804-secure-ip-multicast-deployments

Introduzione

In questo documento vengono fornite linee guida generali sulle best practice per proteggere un'infrastruttura di rete IP multicast.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Multicast IP

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

In questo documento vengono illustrati alcuni concetti di base e viene fornita una descrizione degli argomenti elencati di seguito.

• Meccanismi per proteggere una piattaforma specifica e la rete in generale.
• Qualsiasi modello ASM (Source Multicast) e SSM (Source Specific Multicast).
• Sicurezza Multicast Virtual Private Network (MVPN). 
• Architettura VPN (Virtual Private Network) di Group Encrypted Transport (GET) che fornisce riservatezza e integrità per il traffico del data plane o del control plane multicast.

Terminologia

Nel multicast IP sono disponibili due modelli di servizi classici:

1. Any Source Multicast (ASM)

2. Multicast specifico all'origine (SSM)

In ASM, il ricevente si unisce a un gruppo G tramite un rapporto di appartenenza IGMP (Internet Group Membership Protocol) o MLD (Multicast Listener Discovery) per indicare il gruppo. Questo report richiede il traffico inviato da qualsiasi origine al gruppo G e, di conseguenza, il nome "qualsiasi origine". Al contrario, in SSM, il ricevitore si unisce a un canale specifico definito da una sorgente S, che invia a un gruppo G. Ciascuno di questi modelli di assistenza è descritto in dettaglio di seguito.

Any Source Multicast

Il modello ASM è caratterizzato da due classi di protocollo: "dense mode flood-and-prune" e "sparse mode explicit join":

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

Nei protocolli a modalità densa, tutti i router della rete sono a conoscenza di tutte le strutture, delle relative origini e dei ricevitori. Protocolli come il DVMRP (Distance Vector Multicast Routing Protocol) e PIM (Protocol Independent Multicast) inondano le informazioni sulla "fonte attiva" sull'intera rete e creano alberi tramite la creazione di "Stato di eliminazione" in parti della topologia in cui il traffico per un albero specifico non è desiderato. Sono anche chiamati protocolli di inondazione e prugna. In Multicast Open Shortest Path First (MOSPF), le informazioni sui ricevitori vengono trasmesse in tutta la rete per supportare la creazione di alberi.

I protocolli in modalità Dense non sono desiderabili perché ogni albero incorporato in una parte della rete può sempre causare l'utilizzo delle risorse (con impatto sulla convergenza) su tutti i router della rete (o all'interno dell'ambito amministrativo, se configurato). Questi protocolli non vengono ulteriormente discussi nel prosieguo di questo articolo.

ii) Protocolli di join espliciti in modalità sparsa (PIM-SM/PIM-BiDir)

Con i protocolli di join espliciti in modalità sparse, i dispositivi non creano uno stato specifico del gruppo nella rete a meno che un ricevitore non abbia inviato un rapporto di appartenenza esplicito IGMP/MLD (o "join") per un gruppo. Questa variante dell'ASM è ben scalabile ed è il paradigma multicast della messa a fuoco.

Questa è la base per la modalità di sparsità PIM, che la maggior parte delle distribuzioni multicast ha utilizzato fino a questo punto. Questa è anche la base per PIM bidirezionale (PIM-BiDir), che viene sempre più implementato per applicazioni MOLTI (sorgenti) a MOLTI (ricevitori).

Questi protocolli sono chiamati modalità sparse perché supportano in modo efficiente strutture di recapito multicast IP con una popolazione di ricevitori "sparsa" e creano uno stato del control plane solo sui router nel percorso tra le origini e i ricevitori e in PIM-SM/BiDir, il Rendezvous Point (RP). Non creano mai uno stato in altre parti della rete. Lo stato di un router viene generato in modo esplicito solo quando riceve un join da un router o da un ricevitore downstream, da cui il nome "protocolli di join espliciti".

Sia PIM-SM che PIM-BiDir utilizzano "ALBERI CONDIVISI", che consentono l'inoltro del traffico da qualsiasi origine a un destinatario. Lo stato multicast in una struttura condivisa è detto stato (*,G), dove * è un carattere jolly per QUALSIASI ORIGINE. Inoltre, PIM-SM supporta la creazione di stati correlati al traffico proveniente da una specifica origine. Questi sono noti come ALBERI DI ORIGINE e lo stato associato viene indicato come stato (S,G).

Multicast specifico dell'origine

SSM è il modello utilizzato quando il ricevitore (o un proxy) invia (S,G) "join" per indicare che desidera ricevere il traffico inviato dalla sorgente S al gruppo G. Ciò è possibile con i report di appartenenza in modalità "INCLUDE" di IGMPv3/MLDv2. Questo modello viene indicato come modello SSM (Source-Specific Multicast). SSM impone l'uso di un protocollo di join esplicito tra router. Il protocollo standard per questo è PIM-SSM, che è semplicemente il sottoinsieme di PIM-SM usato per creare alberi (S,G). Stato alberi condivisi (*,G) non presente in SSM.

I ricevitori multicast possono quindi "unirsi" a un gruppo ASM G o "unirsi" (o più precisamente "sottoscrivere" a) a un canale SSM (S,G). Per evitare la ripetizione del termine "gruppo ASM o canale SSM", viene utilizzato il termine flusso (multicast), che implica che il flusso potrebbe essere un gruppo ASM o un canale SSM.

Protocolli Multicast Pertinenti / Tipi Di Pacchetto

Per proteggere una rete multicast, è importante conoscere i tipi di pacchetto più comuni e come proteggerli. I protocolli principali da seguire sono tre:

1. IGMP/MLD

2. PIM

3. MSDP

Nella sezione successiva, verranno discussi ciascuno di questi protocolli e i problemi che possono sorgere rispettivamente con ciascuno di essi.

Pacchetti IGMP/MLD

IGMP / MLD è il protocollo utilizzato dai ricevitori multicast per segnalare ad un router che desiderano ricevere contenuti per un particolare gruppo multicast. IGMP (Internet Group Membership Protocol) è il protocollo utilizzato in IPv4, mentre MLD (Multicast Listener Discovery) è il protocollo utilizzato in IPv6.

Esistono due versioni di IGMP comunemente utilizzate, IGMPv2 e IGMPv3. Sono inoltre disponibili due versioni di MLD, MLDv1 e MLDv2.

IGMPv2 e MLDv1 sono equivalenti dal punto di vista funzionale, mentre IGMPv3 e MLDv2 sono equivalenti dal punto di vista funzionale.

Questi protocolli sono specificati nei seguenti collegamenti:

IGMPv2: RFC 2236

MLDv1: RFC 3590

IGMPv3 e MLDv2: RFC 4604

IGMPv2 e IGMPv3 non sono solo un protocollo ma anche un protocollo IP IPv4 (in particolare, il protocollo numero 2). Non viene utilizzato solo come descritto in queste RFC per segnalare l'appartenenza a un gruppo multicast, ma anche da altri protocolli multicast IPv4 come DVMRP, PIM versione 1, mtrace e mrinfo. Questo è importante da ricordare quando si cerca di filtrare i dati IGMP (ad esempio tramite ACL Cisco IOS®). In IPv6, MLD non è un protocollo IPv6, ma viene utilizzato per trasportare i pacchetti MLD. PIM versione 2 è lo stesso tipo di protocollo in IPv4 e IPv6 (numero di protocollo 103).

Pacchetti di controllo PIM

In questa sezione vengono discussi i pacchetti di controllo PIM multicast e unicast. Vengono discussi sia Auto-RP che Bootstrap Router (BSR), due modi per selezionare i punti di rendering e controllare le assegnazioni da gruppo a RP nelle reti PIM-SM.

Pacchetti controllo PIM multicast

I pacchetti di controllo PIM multicast includono:

• PIM Hello - Il pacchetto PIM Hello è un pacchetto multicast IP con ambito locale al collegamento inviato a un router collegato alla stessa rete per stabilire i router adiacenti PIM.
• PIM Join/Prune - I PIM Join/Prune sono pacchetti multicast IP con ambito locale al collegamento inviati per creare/rimuovere lo stato multicast e vengono inviati solo ai vicini PIM. Sono multicast all'interno della LAN per facilitare l'asserzione, la soppressione dei report e altri dettagli del protocollo PIM, ma sono sempre indirizzati a un router adiacente specifico.
• PIM DF-elect - PIM Designated Forwarder è il router PIM Bi-Dir responsabile per (*,G) JOIN inviati al punto di ripristino per conto di ricevitori collegati o vicini PIM downstream. Nei casi in cui un router PIM rileva un altro router che invia (*,G) JOIN sullo stesso segmento per lo stesso gruppo G, è possibile scegliere il router con il percorso migliore per l'RP.
• PIM Assert - PIM Assert sono pacchetti multicast IP locali al collegamento inviati quando un router PIM collegato a un segmento di rete che inoltra attivamente i pacchetti per un particolare (S,G) da un'interfaccia particolare inizia a RICEVERE i pacchetti per quello stesso (S,G) sulla stessa interfaccia su cui vengono inoltrati. Questo evento indica la presenza di un altro router che si ritiene sia il Single Forwarder (SF) per questo (S,G). Il meccanismo Assert seleziona un'unica IF per tale (S,G). Il router PIM SF viene scelto per inoltrare i pacchetti per un particolare flusso (S,G). PIM consente a router diversi di svolgere il ruolo di IF per conto di (S,G) diversi, idealmente esiste solo un SF per (S,G). Non confondere l'IF con il router designato. Il PIM Designated Router è il router responsabile per JOIN / PRUNES o SOURCE REGISTERS che vengono inviati al RP in una rete PIM-SM.
• PIM Bootstrap - I messaggi PIM Bootstrap vengono inviati in una rete PIMv2 per facilitare la scelta dinamica di un Rendezvous Point per un particolare gruppo G.

Pacchetti di controllo PIM unicast

I pacchetti di controllo PIM unicast vengono indirizzati da o verso l'RP e includono:

• Source Register Packet - I pacchetti PIM Source Register vengono inviati per registrare una nuova origine multicast con un punto di rendering. Non appena un'origine inizia a inviare pacchetti multicast, il router designato collegato alla rete di origine invia un flusso di registro unicast all'RP per indicare che esiste un'origine attiva per un gruppo multicast di cui l'RP è responsabile.
  I pacchetti del registro di origine vengono inviati come incapsulamento unicast del flusso multicast originale.
  I messaggi PIM register sono commutati a livello di processo e vengono inviati solo fino a quando l'RP non invia un messaggio di interruzione del registro. L'impatto di questi pacchetti sulle prestazioni è proporzionale alla velocità dell'origine (per flusso (S,G)).
• Register Stop Packet - PIM Register Stop I pacchetti vengono inviati dal punto di rendering al DR PIM che ha inviato il messaggio Register. I messaggi Register Stop vengono inviati non appena l'RP inizia a ricevere pacchetti multicast nativi dall'origine.
• BSR Candidate-Rendezvous Point Advertisement Packet - PIM BSR C-RP-Advertisement I pacchetti vengono inviati al BSR per pubblicizzare un RP candidato una volta scelto il BSR.

Fig 1: Pacchetti PIM Unicast 

Gli attacchi che sfruttano tali pacchetti possono avere origine ovunque, in quanto si tratta di pacchetti unicast.

Minacce di base contro un router

Contro un router esistono diverse minacce fondamentali che sono indipendenti dal fatto che il router supporti il multicast e che l'attacco riguardi il traffico multicast o i protocolli.

Gli attacchi DoS (Denial of Service) sono i più importanti vettori di attacco generici in una rete. In linea di principio, ogni elemento di rete può essere bersaglio di un attacco DoS, che può sovraccaricare l'elemento con una potenziale perdita o degradazione successiva del servizio per gli utenti legittimi. È di fondamentale importanza seguire le raccomandazioni di base per la sicurezza della rete che si applicano a unicast.

È da notare che gli attacchi multicast non sono sempre intenzionali, ma spesso accidentali. Ad esempio, il worm Witty, osservato per la prima volta nel marzo 2004, è un esempio di worm che si è diffuso attraverso attacchi casuali a indirizzi IP. Come conseguenza della completa randomizzazione dello spazio di indirizzi, anche le destinazioni IP multicast sono state influenzate dal worm. In molte organizzazioni, alcuni router di primo hop sono stati compressi perché il worm ha inviato pacchetti a molti indirizzi di destinazione multicast diversi. I router, tuttavia, non avevano l'ambito per un carico di traffico multicast di questo tipo con la creazione dello stato associato e l'esaurimento delle risorse è stato effettivamente riscontrato. Ciò dimostra la necessità di proteggere il traffico multicast, anche se questo non viene utilizzato in un'organizzazione.

Le minacce generiche contro i router includono:

• Inondazioni di pacchetti di qualsiasi tipo; ad esempio, in base a percorsi hardware quali percorsi lenti (punt) e percorsi software quali porte di gestione o control plane, che includono Secure Shell (SSH), Telnet, Border Gateway Protocol (BGP), OSPF, Network Time Protocol (NTP) e così via
• Intrusioni nel router, con conseguente sfruttamento delle funzionalità su di esso; password Telnet o SSH deboli e stringhe della community SNMP (Simple Network Management Protocol) deboli sono un problema comune nelle reti moderne.
• Problemi operativi come configurazioni errate o attacchi insider possono mettere a rischio la sicurezza dell'intera rete e il suo traffico.
  
  

Quando su un router è abilitato il multicast, oltre a unicast deve essere protetto. L'utilizzo del multicast IP non modifica il modello di minaccia fondamentale, ma abilita protocolli aggiuntivi (PIM, IGMP, MLD, MSDP) che potrebbero essere soggetti ad attacchi, che devono essere protetti in modo specifico. Quando in questi protocolli viene utilizzato il traffico unicast, il modello di rischio è identico agli altri protocolli eseguiti dal router.

È importante notare che il traffico multicast non può essere utilizzato allo stesso modo del traffico unicast per attaccare un router perché il traffico multicast è fondamentalmente "gestito dal destinatario" e non può essere indirizzato a una destinazione remota. Una destinazione di attacco deve essere esplicitamente "unita" al flusso multicast. Nella maggior parte dei casi (l'eccezione principale è Auto-RP), i router ascoltano e ricevono solo il traffico multicast "link local". Il traffico locale del collegamento non viene mai inoltrato. Pertanto, gli attacchi a un router con pacchetti multicast possono avere origine solo da utenti connessi direttamente.

Minacce dal lato dell'origine

Le sorgenti multicast, che si tratti di PC o server video, talvolta non sono sottoposte allo stesso controllo amministrativo della rete. Pertanto, dal punto di vista dell’operatore di rete, il mittente è per lo più considerato non attendibile. Date le potenti funzionalità di PC e server e le complesse impostazioni di sicurezza, spesso incomplete, i mittenti rappresentano una minaccia sostanziale contro qualsiasi rete, inclusa la rete multicast. Queste minacce includono:

• Attacchi di livello 2: sul livello 2 è presente un'ampia gamma di forme di attacco per eseguire vari tipi di attacchi. Si applicano sia a unicast che a multicast. Dal momento che queste forme di attacco non sono specifiche del multicast, non vengono trattate in dettaglio in questo documento. Per ulteriori informazioni, vedere il libro della Cisco Press "LAN Switch Security", ISBN-10: 1-58705-467-1.
• Attacchi con traffico multicast: come descritto in precedenza, è difficile condurre attacchi con traffico multicast poiché il router del primo hop non inoltra il traffico multicast a meno che non ci sia un listener per il gruppo. Tuttavia, il primo hop può essere attaccato in diversi modi con i pacchetti multicast:
  • Attacchi di saturazione della rete: un utente malintenzionato può inondare un segmento di pacchetti multicast, sovrautilizzo della larghezza di banda disponibile, che può portare a una condizione DoS.
  • Attacchi di stato multicast: il router del primo hop è pieno di pacchetti multicast, che possono creare uno stato troppo grande e una conseguente condizione di attacco DoS.
  • Un mittente potrebbe tentare di diventare il DR PIM, tramite gli helper PIM inviati. In questi casi, non è possibile inoltrare il traffico da o verso la LAN.
  • I pacchetti di selezione DF PIM per BiDir-PIM DF potrebbero essere oggetto di spoofing. In questi casi, non è possibile inoltrare il traffico da o verso la LAN.
  • Un mittente potrebbe contraffare i messaggi di bootstrap di AutoRP-discovery o BSR. In questo modo verrebbe effettivamente annunciato un falso RP e verrebbe interrotto un servizio PIM-SM/BiDir.
  • Un mittente potrebbe generare attacchi unicast, ad esempio messaggi PIM source register/register-stop, o inviare pacchetti BSR e annunciare un falso BSR.
  • Un mittente può inviare messaggi a qualsiasi gruppo multicast valido, a meno che non sia filtrato. Se un indirizzo di origine viene oggetto di spoofing e non viene impedito nel perimetro della rete, il mittente può utilizzare l'indirizzo IP di origine di un mittente legittimo e sovrascrivere il contenuto in alcune parti della rete.
  • Attacchi multicast ai protocolli del control plane: alcuni protocolli non associati al multicast, ad esempio OSPF e DHCP (Dynamic Host Configuration Protocol), utilizzano pacchetti multicast che possono essere utilizzati per attaccare tali protocolli
• Mascheramento: ci sono diverse forme di attacco in cui un mittente può fingere di essere un altro mittente. Gli indirizzi IP di origine oggetto di spoofing sono uno di questi tipi di attacchi.
• Furto di servizio: a meno che i mittenti non siano controllati, è possibile utilizzare il servizio multicast in modo illegittimo dal lato mittente.

Nota: in genere, gli host non inviano o ricevono pacchetti PIM. L'host che esegue questa operazione può probabilmente tentare un attacco.

Minacce dal lato del ricevitore

Il ricevitore è anche tipicamente una piattaforma con una notevole potenza della CPU e larghezza di banda, e consente una serie di forme di attacco. Queste sono per la maggior parte identiche alle minacce dal lato del mittente. Gli attacchi di livello 2 rimangono un importante vettore di attacco. I ricevitori falsi e i furti di servizio sono possibili anche sul lato ricevente, tranne per il fatto che il vettore di attacco è in genere un attacco IGMP (o di livello 2, come accennato).

Minacce contro un Rendezvous Point e BSR

I PIM-SM RP e i PIM-BSR sono punti critici in una rete multicast, e sono quindi preziosi bersagli per un attaccante. Quando nessuno dei due è il router del primo hop, solo le forme di attacco unicast, che includono il protocollo PIM unicast, possono essere indirizzate direttamente verso questi elementi. Le minacce contro RP e BSR includono:

• Tutte le forme di attacco generiche, come descritto nella sezione "Minacce di base contro un router".
• Gli attacchi unicast PIM, potenzialmente con indirizzi IP di origine oggetto di spoofing, consentono attacchi DoS, anche se i messaggi PIM di registrazione o di arresto del registro inviati da un dispositivo dannoso.

Multicast e Unicast Security (a confronto)

Considerazioni sullo stato/filtri

Si consideri la topologia nella Figura 3, che mostra una fonte, tre ricevitori (A, B, C), uno switch (S1) e due router (R1 e R2). La linea blu rappresenta un flusso unicast, mentre la linea rossa rappresenta un flusso multicast. I tre ricevitori sono membri del flusso multicast.

Figura 3: Replica in router e switch

Per inibire il flusso del traffico da un'origine specifica a un ricevitore specifico:

• Per il flusso unicast, installare un filtro in un punto qualsiasi del percorso dal mittente al destinatario.
• Per il flusso multicast, tuttavia, gli amministratori devono essere più specifici sulla posizione in cui installare i filtri: sul filtro del lato ricevente dopo l'ultimo punto di replica prima del destinatario; sul filtro del lato origine prima del primo punto di replica dopo l'origine.

Attacchi Da Fonti Multicast

Questa sezione è valida sia per i modelli di servizio ASM sia per SSM, in cui il traffico viene inoltrato in base alla ricezione di join espliciti sul lato ricevente.

Per i flussi unicast non è prevista la protezione implicita del ricevitore. Un'origine unicast può inviare traffico a una destinazione, anche se questa destinazione non ha richiesto il traffico. Pertanto, i meccanismi di difesa, ad esempio i firewall, vengono in genere utilizzati per proteggere i punti finali. Il multicast, d'altro canto, ha una protezione implicita integrata nei protocolli. Il traffico idealmente raggiunge solo un ricevitore che si è unito al flusso in questione.

Con ASM, le origini possono avviare l'inserimento del traffico o attacchi DoS attraverso la trasmissione del traffico multicast a qualsiasi gruppo supportato da un RP attivo. Questo traffico idealmente non raggiunge un destinatario, ma può raggiungere almeno il router del primo hop nel percorso, oltre al router RP, che consente attacchi limitati. Se tuttavia una fonte dannosa è a conoscenza di un gruppo a cui un destinatario è interessato e non sono disponibili filtri appropriati, può inviare traffico a tale gruppo. Questo traffico viene ricevuto finché i ricevitori ascoltano il gruppo.

Con SSM, gli attacchi da fonti indesiderate sono possibili solo sul router del primo hop dove il traffico si arresta se nessun ricevitore si è unito a quel canale (S,G). Ciò non porta a alcun attacco di stato sul router del primo hop perché ignora tutto il traffico SSM per cui non esiste alcuno stato di join esplicito dai ricevitori. In questo modello non è sufficiente che un'origine dannosa sappia a quale gruppo è interessata una destinazione perché i "join" sono specifici dell'origine. In questo caso, per la riuscita dell'operazione sono necessari indirizzi di origine IP oggetto di spoofing più potenziali attacchi di routing.

Attacchi di stato

Anche senza ricevitori presenti in una rete, PIM-SM crea lo stato (S,G) e (*,G) sul router del primo hop più vicino alla sorgente e anche sul punto di rendering. Esiste quindi la possibilità di un attacco di stato sulla rete al router del primo hop di origine e sul PIM-SM RP.

Se una fonte dannosa inizia a inviare traffico a più gruppi, per ognuno dei gruppi rilevati i router della rete creano lo stato all'origine e all'RP, a condizione che i gruppi in questione siano autorizzati dalla configurazione RP.

Pertanto, il PIM-SM è soggetto ad attacchi di stato e di traffico da parte delle fonti. L'attacco può essere aggravato se l'origine modifica il proprio indirizzo IP di origine in modo casuale all'interno del prefisso corretto, o in altre parole, vengono falsificati solo i bit host dell'indirizzo.

Figura 4: attacchi RP ASM

Come nel caso del PIM-SSM, gli attacchi PIM-BiDir per la creazione di stati da fonti sono impossibili. Il traffico in PIM-BiDir viene inoltrato sullo stato creato dai join dai ricevitori e sullo stato inoltrato al RP, in modo che possa raggiungere i ricevitori dietro al RP, poiché i join vanno solo al RP. Il traffico da stato a stato successivo all'RP viene chiamato stato (*,G/M) e viene creato dalla configurazione RP (statica, Auto-RP, BSR). Non cambia in presenza di fonti. Pertanto, gli aggressori possono inviare traffico multicast a un PIM-BiDir RP, ma a differenza di PIM-SM, un PIM-BiDir RP non è un'entità "attiva", ma si limita a inoltrare o scartare il traffico per i gruppi PIM-BiDir.

Nota: su alcune piattaforme Cisco IOS (*,G/M) lo stato non è supportato. In questi casi, le origini possono attaccare il router trasmettendo il traffico multicast a più gruppi PIM-BiDir, causando la creazione dello stato (*,G). Ad esempio, lo switch Catalyst 6500 supporta gli stati (*,G/M).

Attacchi originati dal ricevitore

Gli attacchi possono provenire da ricevitori multicast. Qualsiasi ricevitore che invia un report IGMP/MLD in genere crea lo stato sul router del primo hop. In unicast non esiste un meccanismo equivalente.

Fig 5: Inoltro del traffico basato sul join esplicito dal lato ricevente

Gli attacchi dei ricevitori possono essere di tre tipi:

1. Un ricevitore multicast può tentare di unirsi a un flusso per il quale non è autorizzato e di ricevere contenuto che non è autorizzato a ricevere.
2. Un ricevitore multicast può potenzialmente sovraccaricare la larghezza di banda di rete disponibile a causa dell'interesse in molti gruppi o canali. Questo tipo di attacco diventa un attacco di larghezza di banda condivisa contro altri potenziali destinatari di contenuti.
3. Un ricevitore multicast può tentare di lanciare un attacco contro router o switch. È possibile generare un numero elevato di report IGMP, che possono creare una grande quantità di stato della struttura multicast e sovraccaricare potenzialmente la capacità del router. Ciò a sua volta può causare un aumento dei tempi di convergenza multicast o un aumento della funzionalità DoS del router.
   
   

Nella sezione successiva, dedicata alla protezione all'interno di una rete multicast, sono disponibili diversi metodi per mitigare questo tipo di attacchi.

Sicurezza all'interno di una rete multicast

Sicurezza degli elementi di rete

La sicurezza non è una caratteristica specifica, ma una parte intrinseca di ogni progettazione di rete. Per questo motivo, la sicurezza deve essere presa in considerazione in ogni punto della rete. È di fondamentale importanza che ogni singolo elemento della rete sia adeguatamente protetto. Un possibile scenario di attacco, applicabile a qualsiasi tecnologia, è un router sovvertito da un intruso. Una volta che un intruso ha il controllo di un router, può eseguire una serie di diversi scenari di attacco. Ciascun elemento di rete deve pertanto essere adeguatamente protetto da qualsiasi forma di attacco di base e da attacchi multicast specifici.

Servizio Local Packet Transport Service (LPTS)

Su Cisco IOS XR, il servizio LPTS (Local Packet Transport Service) svolge il ruolo di policer del traffico diretto al control plane del router, in modo simile al protocollo CoPP su Cisco IOS. Inoltre, il traffico di ricezione, che include il traffico unicast e multicast, può essere filtrato e la velocità limitata.

Sicurezza specifica del multicast

In una rete abilitata per il multicast, ogni elemento di rete deve essere protetto con funzionalità di protezione specifiche per il multicast. come descritto in questa sezione, per la protezione generica del router. Nella sezione successiva vengono descritte le funzionalità che non sono necessarie su ogni router, ma solo in percorsi specifici della rete, e le funzionalità che richiedono l'interazione tra router (ad esempio l'autenticazione PIM).

Figura 6: Limiti route

I limiti di route consentono di impostare una soglia per il numero di route consentite nella tabella di routing multicast. Se è abilitato un limite di route multicast, non viene creato alcuno stato multicast oltre il limite configurato. Esiste anche una soglia di avvertenza. Quando il numero di route supera la soglia di avviso, vengono attivati messaggi di avviso syslog. Al limite di route, eventuali altri pacchetti che attiverebbero lo stato vengono scartati.

il comando ip multicast route-limit è disponibile anche per MVRF.

Per proteggere il control plane, fortificare MSDP utilizzando tre misure di sicurezza di base:

1) Filtri SA MSDP

È consigliabile filtrare il contenuto dei messaggi MSDP tramite i filtri SA MSDP. L'idea principale di questo filtro è evitare la propagazione dello stato multicast per le applicazioni e i gruppi che non sono applicazioni a livello di Internet e che non devono essere inoltrati oltre il dominio di origine. Idealmente, dal punto di vista della sicurezza, i filtri consentono solo i gruppi noti (e potenzialmente i mittenti) e negano tutti i mittenti e/o i gruppi sconosciuti.

In genere non è possibile elencare in modo esplicito tutti i mittenti e/o i gruppi consentiti. Si consiglia di utilizzare il filtro di configurazione predefinito per i domini PIM-SM con un singolo RP per ogni gruppo (nessun mesh-group MSDP):

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

È consigliabile filtrare nel modo più rigoroso possibile e in entrambe le direzioni, in entrata e in uscita.

Utilizzare per ulteriori dettagli sulle raccomandazioni relative ai filtri SA MSDP: https://www.cisco.com/c/en/us/support/docs/ip/ip-multicast/13717-49.html

Il comando ip msdp sa-limit consente di limitare il numero di stati SA creati in seguito all'accettazione di messaggi SA da un peer MSDP. Di seguito sono riportati alcuni semplici consigli pratici:

• Limite minimo da stub-neighbor 
• Limite grande dal router adiacente di transito (ad esempio, il numero massimo di associazioni di protezione in Internet)
• ISP transit - configurare il numero massimo di #SA supportati dalla piattaforma in uso

3) Autenticazione router adiacente MSDP MD5

È consigliabile utilizzare l'autenticazione della password MD5 (Message-Digest Algorithm) sui peer MSDP. In questo modo viene utilizzata l'opzione di firma TCP MD5, equivalente all'utilizzo descritto nella RFC 691 per proteggere BGP.

Figura 15: autenticazione router adiacente MSDP MD5

Le tre raccomandazioni di sicurezza di MSDP seguenti perseguono obiettivi diversi:

• L'autenticazione tramite router adiacenti (con MD5) garantisce che solo i peer MSDP attendibili possano inviare messaggi.
• I filtri SA garantiscono che anche un peer MSDP attendibile possa inviare solo annunci SA in linea con i criteri di origine/gruppo prestabiliti.
• Il limite dell'associazione di protezione garantisce inoltre che, anche con gli annunci legittimi (S,G) provenienti da peer legittimi, la memoria disponibile non possa essere esaurita.

Problemi mittente/origine

Molti problemi di protezione multicast che hanno origine presso il mittente possono essere risolti con meccanismi di protezione unicast appropriati. Di seguito sono riportati alcuni meccanismi di protezione unicast consigliati:

• Protezione da spoof dell'indirizzo di origine (inoltro percorso inverso unicast, uRPF o ACL e protezione origine IP per il livello di accesso)
• ACL di infrastruttura (deny ip any (to) <spazio di indirizzi di base>)

Tali misure possono essere utilizzate per bloccare attacchi diretti al nucleo. Ad esempio, questa procedura potrebbe risolvere problemi come attacchi che usano pacchetti unicast PIM all'RP, che si trova "all'interno" della rete e sarebbe quindi protetto dall'ACL dell'infrastruttura.

Controllo degli accessi basato sul filtro pacchetti - Origini di controllo

Nell'esempio mostrato nella Figura 16, il filtro è configurato sull'interfaccia LAN (E0) del router multicast del primo hop (router designato). Il filtro è definito da un elenco di controllo di accesso esteso denominato "source". Questo ACL viene applicato all'interfaccia dell'origine del router designato collegato alla LAN di origine. A causa della natura del traffico multicast, potrebbe essere necessario configurare un filtro simile su tutte le interfacce connesse a una LAN sulle quali le origini potrebbero diventare attive. Poiché non è sempre possibile sapere esattamente dove si verifica l'attività di origine, si consiglia di applicare tali filtri a tutti i punti di ingresso nella rete.

Fig. 16: Origini di controllo

In una rete PIM-SM, con questo comando è possibile controllare una fonte di traffico indesiderata. Quando il traffico di origine colpisce il router del primo hop, il router del primo hop (DR) crea lo stato (S,G) e invia un messaggio PIM Source Register all'RP. Se l'origine non è elencata nell'elenco di filtri di accettazione-registrazione (configurato nell'RP), l'RP rifiuta il registro e invia un messaggio di registrazione-interruzione immediato al DR.

Nell'esempio mostrato, un ACL semplice è stato applicato all'RP, che filtra solo l'indirizzo di origine. È possibile anche filtrare l'origine E il gruppo usando un ACL esteso sull'RP.

I filtri di origine presentano alcuni inconvenienti perché con il comando pim accept-register sull'RP, lo stato PIM-SM (S,G) viene ancora creato sul router del primo hop dell'origine. Ciò può generare traffico nei ricevitori locali verso l'origine e situati tra l'origine e l'RP. Inoltre, il comando pim accept-register funziona sul piano di controllo dell'RP. Ciò potrebbe essere utilizzato per sovraccaricare l'RP con messaggi di registro falsi e probabilmente causare una condizione DoS.

Si consiglia di applicare il comando pim accept-register sull'RP in aggiunta ad altri metodi, come l'applicazione di semplici ACL data plane su tutti i DR, su tutti i punti in entrata nella rete. Anche se gli ACL in entrata sul DR sono sufficienti in una rete perfettamente configurata e gestita, si consiglia di configurare il comando pim accept-register sull'RP come meccanismo di sicurezza secondario in caso di configurazioni errate sui router perimetrali. I meccanismi di sicurezza a più livelli con lo stesso obiettivo sono chiamati "difesa in profondità" ed è un principio di progettazione comune nella sicurezza.

Problemi del ricevitore - Controllo IGMP/MLD

La maggior parte dei problemi del ricevitore rientrano nel dominio delle interazioni del protocollo del ricevitore IGMP/MLD.

Figura 18: Controllo IGMP

Quando i pacchetti IGMP o MLD vengono filtrati, tenere presente quanto segue:

• IPv4: IGMP è un tipo di protocollo IPv4 (protocollo IPv4 2)
• IPv6: MLD è contenuto in pacchetti di tipo protocollo ICMPv6

Il processo IGMP è abilitato per impostazione predefinita non appena il multicast IP è abilitato. Anche i pacchetti IGMP sono dotati di questi protocolli, e quindi tutti questi protocolli sono abilitati quando è abilitato il multicast:

• PIMv1 - PIMv1 è stata la prima versione di PIM ed è sempre abilitata in Cisco IOS a scopo di migrazione. Tutte le distribuzioni correnti utilizzano PIMv2.
• Mrinfo - Mrinfo è un comando Unix ereditato da Cisco IOS per visualizzare i router adiacenti multicast. Cisco consiglia di utilizzare il protocollo SNMP anziché il comando mrinfo.
• DVMRP - DVMRP è un protocollo vettoriale di distanza in modalità densa preesistente con caratteristiche di scalabilità molto limitate. Il supporto Cisco IOS per DVMRP è stato ritirato o è già obsoleto.
• Mtrace: Mtrace è l'equivalente multicast di "traceroute" unicast ed è uno strumento utile

Per ulteriori informazioni, vedere Numeri di tipo IGMP (Internet Group Management Protocol) di 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 

È possibile filtrare i pacchetti IGMP unicast (per IGMP/UDLR), in quanto si tratta molto probabilmente di pacchetti di attacco e di pacchetti di protocollo IGMP non validi. I pacchetti IGMP unicast sono supportati da Cisco IOS a supporto dei collegamenti unidirezionali e di altre condizioni di eccezione.

I pacchetti di query IGMP/MLD forgiati possono produrre una versione IGMP inferiore a quella prevista.

In particolare, gli host idealmente non inviano mai query IGMP perché una query inviata con una versione IGMP inferiore può causare il ripristino della versione inferiore di tutti gli host che ricevono la query. In presenza di host IGMPv3 / SSM, questo può "attaccare" i flussi SSM. Nel caso di IGMPv2, ciò può determinare latenze di uscita più lunghe.

Se è presente una LAN non ridondante con un singolo query IGMP, il router deve eliminare le query IGMP ricevute.

Se esiste una LAN passiva ridondante/comune, è necessario uno switch in grado di eseguire lo snooping IGMP. In questo caso, sono disponibili due caratteristiche specifiche:

• Protezione router
• IGMP versione minima, comando

Protezione router

Qualsiasi porta dello switch può diventare una porta del router multicast se lo switch riceve un pacchetto di controllo del router multicast (IGMP General Query, PIM Hello o CGMP Hello) su tale porta. Quando una porta dello switch diventa una porta del router multicast, tutto il traffico multicast viene inviato a tale porta. Per evitare questo problema, usare "Router Guard". La funzione Router Guard non richiede l'attivazione dello snooping IGMP.

La funzione Router Guard consente di designare una porta specificata come porta host multicast. La porta non può diventare una porta router, anche se vengono ricevuti pacchetti di controllo del router multicast.

Questi tipi di pacchetto vengono scartati se vengono ricevuti su una porta con Router Guard abilitato:

• Messaggi di query IGMP
• Messaggi IPv4 PIMv2
• messaggi IGMP PIM (PIMv1)
• Messaggi IGMP DVMRP
• Messaggi RGMP (Router-port Group Management Protocol)
• Messaggi CGMP (Cisco Group Management Protocol)

Quando i pacchetti vengono scartati, vengono aggiornate le statistiche che indicano che i pacchetti vengono scartati a causa di Router Guard.

Versione minima IGMP

È possibile configurare la versione minima di host IGMP consentita. Ad esempio, è possibile non consentire tutti gli host IGMPv1 o tutti gli host IGMPv1 e IGMPv2. Questo filtro si applica solo ai rapporti di appartenenza.

Se gli host sono collegati a una LAN "passiva" comune (ad esempio, uno switch che non supporta lo snooping IGMP o che non è configurato per esso), non vi è nulla che un router possa fare per queste query false se non ignorare i report di appartenenza alla "vecchia versione" che vengono quindi attivati e non eseguire il fallback stesso.

Poiché le query IGMP devono essere visibili per tutti gli host, non è possibile utilizzare un meccanismo di autenticazione dei messaggi basato su hash (HMAC) con una chiave già condivisa, ad esempio IPSec con chiave statica, per autenticare le query IGMP da "router validi". Se due o più router sono collegati a un segmento LAN comune, è necessario selezionare un query IGMP. In questo caso, l'unico filtro utilizzabile è un filtro del gruppo di accesso ip basato sull'indirizzo IP di origine dell'altro router IGMP che invia le query.

I pacchetti IGMP multicast "normali" devono essere autorizzati.

Questo filtro può essere usato sulle porte del ricevitore per consentire solo pacchetti IGMP "buoni" e per filtrare quelli "sbagliati":

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

Nota: questo tipo di filtro IGMP può essere usato negli ACL di ricezione o nel protocollo CoPP. In entrambe le applicazioni, deve essere combinata con filtri per altro traffico gestito, come i protocolli del routing e del piano di gestione. 

Fig. 19: Controllo degli accessi lato ricevitore host

Usa GET VPN per autenticare il traffico del Control Plane

È in genere consigliabile autenticare il traffico del control plane, ad esempio i protocolli di routing, per garantire che i messaggi provengano da un peer attendibile. Questa operazione è relativamente semplice per i protocolli del control plane che utilizzano unicast, ad esempio BGP. Tuttavia, molti protocolli del control plane utilizzano il traffico multicast. Gli esempi sono OSPF, RIP e PIM. Per l'elenco completo, vedere IANA's IPv4 Multicast Address Space Registry.

Alcuni di questi protocolli dispongono di un'autenticazione incorporata, ad esempio RIP (Routing Information Protocol) o EIGRP (Enhanced Interior Group Routing Protocol), altri si basano su IPSec per fornire questa autenticazione (ad esempio OSPFv3, PIM). In quest'ultimo caso, GET VPN fornisce un modo scalabile per proteggere questi protocolli. Nella maggior parte dei casi, il requisito è l'autenticazione tramite protocollo o, in altre parole, la verifica che un messaggio sia stato inviato da un peer attendibile. Tuttavia, GET VPN consente anche la crittografia di tali messaggi.

Per proteggere (in genere solo per l'autenticazione) il traffico del control plane, è necessario descrivere il traffico con un ACL e includerlo nella policy GET VPN. I dettagli variano a seconda del protocollo da proteggere, in cui è necessario decidere se l'ACL include il traffico che passa solo per un nodo GET VPN in entrata (incapsulato) o anche per un nodo in uscita.

Per proteggere i protocolli PIM, è possibile procedere in due modi:

• allow ip any 24.0.0.13 0.0.0.0: questo è il gruppo multicast "All PIM Router". Tuttavia, non protegge i messaggi PIM unicast
• allow pim any any: protegge il protocollo PIM, indipendentemente dal fatto che venga utilizzato multicast o unicast

Nota: i comandi sono forniti come esempi per spiegare un concetto. Ad esempio, è necessario escludere alcuni protocolli PIM utilizzati per il bootstrap di PIM, come BSR o Auto-RP. Entrambi i metodi presentano alcuni vantaggi e inconvenienti che dipendono dall'implementazione. Per ulteriori informazioni, consultare la documentazione specifica su come proteggere PIM con GET VPN.

Conclusioni

Il multicast è un servizio sempre più comune nelle reti. L’emergere dei servizi IPTV nelle reti a banda larga domestiche/residenziali e il passaggio ad applicazioni di commercio elettronico in molti mercati finanziari mondiali sono solo due esempi di requisiti che fanno del multicast un requisito assoluto. Il multicast è accompagnato da una serie di problematiche diverse relative a configurazione, funzionamento e gestione. Una delle sfide principali è la sicurezza.

In questo documento vengono esaminati vari modi in cui il multicast può essere protetto:

• Innanzitutto, è possibile esaminare i piani dati e di controllo multicast complessivi, spiegando in che modo le differenze rispetto ai sistemi unicast rappresentano nuove sfide per la sicurezza.
• Successivamente, è stato esaminato in dettaglio un esame dei protocolli chiave rilevati in una rete multicast, in particolare IGMP, PIM e MSDP. In ogni caso, è stata fornita una descrizione delle minacce alla sicurezza e delle best practice consigliate per attenuarle.
• Inoltre, alcuni esempi specifici su come il multicast può essere protetto in alcune applicazioni specifiche, come le reti a banda larga, dove la larghezza di banda può essere limitata rispetto alla quantità di larghezza di banda richiesta da flussi video specifici.
• Infine, l'architettura GET VPN è stata descritta come un mezzo di multicast integrato con IPSec per la fornitura di VPN sicure.

Con in mente la sicurezza multicast, ricordate che è diverso da unicast. La trasmissione multicast si basa sulla creazione di uno stato dinamico, il multicast implica la replica dinamica dei pacchetti e crea alberi unidirezionali in risposta ai messaggi PIM JOIN / PRUNE. La sicurezza di questo intero ambiente implica la comprensione e l'implementazione di una ricca struttura di comandi Cisco IOS. Questi comandi sono centrati principalmente sulla protezione delle operazioni di protocollo, degli stati (multicast) o dei policer posizionati su pacchetti come CoPP. Con l'uso corretto di questi comandi è possibile fornire un servizio protetto per il multicast IP.

In sintesi, questo documento promuove e descrive diversi approcci:

1. Uso diffuso di SSM: è la modalità PIM più semplice che consente anche l'uso dell'inoltro (S,G). 
2. Se sono necessari servizi ASM, assicurarsi che sia possibile fornire un servizio affidabile: l'utilizzo di RP definiti staticamente offre un control plane più sicuro rispetto agli annunci RP dinamici. Auto-RP e BSR sono più flessibili
3. Se il PIM-SM è abilitato, esaminare le aree di particolare vulnerabilità, come il tunnel di registro per l'RP, e assicurarsi che il DR sia sempre ben protetto. Il CoPP è molto utile in queste aree.
4. Se sono necessari servizi ASM tra domini, valutare se è possibile distribuire la funzionalità PIM Bidirezionale.
5. Usa limiti di stato route globale/igmp: consente di comprendere le funzionalità delle piattaforme insieme alla quantità massima di stato necessaria in circostanze normali e nello scenario peggiore. Configurare i limiti all'interno delle funzionalità della piattaforma che consentono alla rete di funzionare al massimo.
6. Filtri fondamentali: ACL/CoPP e ACL di infrastruttura, che bloccano il PIM al livello di accesso

IP Multicast è un mezzo entusiasmante e scalabile per offrire una varietà di servizi applicativi. Come per il formato unicast, anche questo formato deve essere protetto in una vasta gamma di aree. In questo documento vengono illustrati gli elementi di base che è possibile utilizzare per proteggere una rete multicast IP.

Informazioni correlate

• Linee guida per l'allocazione di indirizzi multicast IP aziendali
• Configura filtri IGMP IPv4
• Group Encrypted Transport VPN