Broadcast storm
Una broadcast storm (tempesta di trasmissioni), nelle reti informatiche, è una situazione che si può verificare quando vengono trasmessi nella rete dei messaggi broadcast o multicast, ognuno dei quali richiede al nodo che lo riceve di rispondere inoltrando il suo messaggio. La possibile conseguenza è un aumento esponenziale del traffico di rete, che comporta una saturazione completa delle risorse di rete disponibili o, in ogni caso, un drastico calo delle prestazioni. Un pacchetto che induce una tale tempesta è talvolta soprannominato pacchetto di Chernobyl. [1]
Sintomi
I sintomi più comuni che si rilevano nella rete sono:
- Un rallentamento sostanziale delle attività
- L’incapacità della rete di gestire il normale flusso del traffico
- Il malfunzionamento di alcune interfacce di rete collegate alla LAN (router, personal computer, print server ecc.)
- Il blocco totale dei dispositivi wi-fi collegati
Cause
Switching loops
Una broadcast storm è principalmente dovuta a carenze dei sistemi di reti informatiche che, seppure efficienti, a volte presentano debolezze intrinseche nelle strutture e nei protocolli di funzionamento.
Più comunemente la causa è un loop di commutazione, reso possibile dalla topologia e dal cablaggio della rete. Nello switching di secondo livello (layer II switching), i collegamenti ridondanti, che sono usati per assicurare la connettività con gli altri switch della rete, stabiliscono l’esistenza di due o più percorsi tra le stazioni terminali e possono causare bridge loops (o switching loops). Poiché le trasmissioni broadcast e multicast vengono inoltrate dagli switch su ogni porta di uscita, fatta eccezione per la porta che ha ricevuto il frame in ingresso, in assenza di particolari configurazioni dei dispositivi gli switch ritrasmettono ripetutamente messaggi broadcast fino ad invadere la rete. Inoltre, dato che l’header del data link layer non supporta un valore time to live (TTL), se un frame viene inviato in una topologia a loop, può eseguire il ciclo per sempre.
Una situazione del genere, ad esempio, si può verificare concretamente quando un host invia un pacchetto ARP (Address Resolution Protocol), per definizione del protocollo di tipo broadcast, necessario per la comunicazione in una rete locale. Il frame raggiunge tutti gli switch della rete che ne esaminano il campo Destination Address e stabiliscono la porta nella quale inoltrarlo. La topologia della rete potrebbe causare di conseguenza un bridge loop, anche in seguito alla ricezione di una copia del frame da parte della destinazione, poiché più switch continuano a ripetere il pacchetto in segmenti opposti della rete.
Facendo riferimento alla figura sulla destra, si può riassumere, con i seguenti punti, una broadcast storm dovuta ad un bridge loop (o switching loop):
- L'host invia un messaggio broadcast nella rete
- Il primo switch analizza il pacchetto ricevuto e lo inoltra nella parte inferiore della rete
- Il secondo switch riceve la copia del pacchetto e opera di conseguenza come il primo switch, inoltrandolo nella parte superiore della rete
- Poiché il pacchetto è di tipo broadcast, gli switch lo ripetono sempre su tutte le porte escludendo la porta da cui è arrivato. Il ciclo è così destinato a continuare all'infinito.
In genere, inoltre, più switch ricevono da segmenti diversi la copia originale del pacchetto, trattandosi appunto di un messaggio broadcast. È possibile, quindi, che diverse copie del pacchetto percorrano il ciclo anche nella direzione opposta, amplificando ulteriormente la quantità di traffico nella rete.
Attacchi informatici
Una broadcast storm può anche essere generata da un cracker in modo da costituire un attacco denial of service (DoS), ai fini di fare collassare una rete. In questo caso si sfruttano funzioni del protocollo ICMP che, usate impropriamente, minano la sicurezza del protocollo stesso. Metodi di attacco provati sono smurf e fraggle. Un attacco smurf invia un gran numero di ICMP Echo Request (ping) all’indirizzo di broadcast, dove in ogni pacchetto l'indirizzo del mittente è modificato con quello della vittima (IP spoofing), che riceverà quindi le risposte: quando il pacchetto falsificato giunge alla rete di destinazione, tutti gli host della rete rispondono all'indirizzo scelto dall'attaccante (quello della vittima). L'iniziale richiesta di eco si moltiplica per tutti gli host della rete, generando una tempesta di risposte che satura la banda e il processore della vittima.[2] Un attacco smurf può essere eseguito congiuntamente ad un attacco ping flood, con lo scopo di incrementare le Echo Requests e massimizzarne la velocità. Un attacco fraggle è invece una variante dello smurf e utilizza il protocollo UDP al posto di ICMP.
Nelle reti wireless, un pacchetto di dissociazione con una fonte diversa da quella del punto di accesso wireless (MAC spoofing) e inviato all’indirizzo di broadcast può generare un attacco DoS. I client colpiti dall’attaccante, ricevendo tale pacchetto e credendo che provenga realmente dall’access point, si dissociano dallo stesso. Si genera così una tempesta di trasmissioni poiché, tipicamente, i client si riassociano al dispositivo, ma l’attaccante continua ad inviare disassociation broadcast packet nella rete.[3]
Difesa e prevenzione
Per verificare la presenza di uno storm è possibile effettuare una semplice prova: lanciare un "echo request" o ping verso un'altra interfaccia ethernet; in questa condizione si potrebbe notare un tempo di risposta con latenza molto elevata superiore ai 200ms, o addirittura la mancata risposta del dispositivo di destinazione. Il problema è risolvibile fisicamente, ricercando il dispositivo Hub/Switch/Router a cui sono stati collegati due cavi in loop, oppure tramite strumenti software che ne prevengono la propagazione.
Ad oggi si tratta comunque di un problema meno diffuso rispetto al passato, poiché con il tempo sono state adottate diverse soluzioni di switching a livello 3 (livello di rete) e sono stati introdotti diversi accorgimenti (anche a livello 2) per impedire il verificarsi di tali situazioni. Occorre invece prestare sempre attenzione e proteggersi adeguatamente da broadcast storm generate da attaccanti. I principali metodi di prevenzione utilizzabili sono i seguenti:
- Implementazione di vari algoritmi e tecnologie negli switch, come Shortest Path Bridging, Spanning Tree Protocol o altre soluzioni proprietarie, per escludere i loop di commutazione e di conseguenza il perpetuarsi dell’invio di messaggi. Negli anelli Ethernet Metro impedire l’utilizzo dei protocolli Ethernet Ring Protection Switching (ERPS) o Ethernet Automatic Protection System (EAPS).
- Filtraggio dei pacchetti broadcast tramite apparecchiature layer 3, in genere router (o switch, che impiagano filtri avanzati, chiamati brouters [4]).
- Segmentazione fisica dei domini di broadcast utilizzando i router a livello 3 (o logicamente con le VLAN a livello 2), nello stesso modo in cui gli switch riducono la dimensione dei domini di collisione a livello 2.
- Configurazione di router o firewall per rilevare e prevenire broadcast storm indotte malevolmente da attaccanti, ad esempio tramite attacchi smurf o fraggle.
- Monitoraggio delle reti wireless e dello schema delle associazioni, ai fini di rilevare eccessive richieste e sessioni di breve durata. In questo modo è possibile proteggersi da attacchi DoS di dissociazione, identificando l’origine di un attacco ed escludendolo dalla rete.
- Utilizzo della funzionalità Broadcast storm control, presente in molti switch, grazie alla quale lo switch cessa intenzionalmente di inoltrare tutto il traffico broadcast se la larghezza di banda consumata dai frame broadcast in ingresso supera una soglia designata. Sebbene ciò non identifichi e risolva l’origine della tempesta di trasmissioni, ne limita l’intensità e consente quindi a un amministratore di rete di comunicare con le apparecchiature di rete per diagnosticare e risolvere il problema [5].
Errori di interpretazione
- Un comune errore di interpretazione è ritenere che i routing loops abbiano a che fare con le broadcast storms. Lavorando a livello 3, i router (a differenza delle apparecchiature di livello 2) non inoltrano il traffico broadcast a livello MAC.
- Comunemente si ritiene che solo i router possano filtrare le trasmissioni e incidere sul dominio di broadcast. Anche se è necessario un router per inoltrare il traffico, in realtà gli switch possono filtrarlo e possono segmentare la rete locale (ad esempio con le VLAN).
- Un’altra interpretazione errata è pensare che i router non possano inoltrare, in ogni caso, messaggi broadcast. Alcuni protocolli di instradamento supportano l’uso di trasmissioni broadcast a livello di rete. Quindi in particolari circostanze, quando il router è configurato per l’inoltro, la segmentazione del dominio di broadcast è compromessa.
- È sbagliato ritenere che ad un messaggio broadcast sia possibile rispondere con un'altra trasmissione broadcast. Tuttavia, è possibile emettere una trasmissione per raccogliere le informazioni necessarie e rispondere successivamente ad un messaggio ricevuto. In una topologia ad anello ridondante questa seconda trasmissione può raggiungere l’interfaccia che ha inviato il messaggio iniziale.
MANET broadcast storms
In una rete ad-hoc mobile (MANET), solitamente si trasmettono pacchetti di richiesta (RREQ) per scoprire nuovi percorsi. Questi pacchetti RREQ possono causare tempeste di trasmissione transitando sul canale con i pacchetti di dati. Un approccio per ridurre la broadcast storm è quello di impedire la ritrasmissione ad alcuni host per ridurre la ridondanza e quindi la collisione dei pacchetti.[6]
Note
- ^ (EN) What is a Chernobyl Packet?. URL consultato il 26 dicembre 2017.
- ^ SecurityDocs: Comment on Defense Against the DoS/DDoS Attacks on Cisco Routers, su securitydocs.com, 11 dicembre 2006. URL consultato il 26 dicembre 2017 (archiviato dall'url originale l'11 dicembre 2006).
- ^ Disassociation Broadcast Attack using ESSID Jack, su manageengine.adventnet.com, 11 dicembre 2006. URL consultato il 26 dicembre 2017 (archiviato dall'url originale l'11 dicembre 2006).
- ^ (EN) What is brouter? - Definition from WhatIs.com, in SearchNetworking. URL consultato il 26 dicembre 2017.
- ^ (EN) Catalyst 6500 Release 12.2SX Software Configuration Guide - Traffic Storm Control [Cisco Catalyst 6500 Series Switches], su Cisco. URL consultato il 26 dicembre 2017.
- ^ Ni Sze-Yao, Tseng Yu-Chee, Chen Yuh-Shyan, Sheu Yang-Ping, The Broadcast Storm Problem in a Mobile Ad Hoc Network (PDF), MobiCom '99 Proceedings of the 5th annual ACM/IEEE international conference on Mobile computing and networking, Agosto 1999, pp. 151-162.
Bibliografia
- Wayne Lewis, Switching e complementi di routing, CCNA 3 Companion Guide, Pearson, 2007
Voci correlate
Collegamenti esterni
- What is a Broadcast Storm, su www.techopedia.com