Qualche giorno fa uno studente mi ha inviato un mail chiedendomi chiarimenti su una notizia comparsa su Wired.it: L'attacco a Spamhaus che sta rallentando Internet Un'offensiva senza precedenti che potrebbe mettere in ginocchio tutta la rete.
Nei giorni successivi tutti i siti della zona inginf.units.it sono diventati irraggiungibili (problema risolto pochi minuti fa).
Il secondo fenomeno è stato una conseguenza del primo. Cerco di spiegare brevemente la faccenda in questo post. Se qualcuno avesse dubbi o curiosità mi chieda a lezione.
Premessa: l'articolo su Wired.it secondo me è incomprensibile dal punto di vista tecnico. Non si capisce minimamente cosa sia successo.
Per capire cosa sia successo, consiglio questo articolo:
Massive DDoS attack against anti-spam provider impacts millions of internet users
In brevissimo:
Una organizzazione A ha deciso di lanciare un attacco "Distributed Denial of Service" nei confronti di una organizzazione B. Denial of Service significa che A ha iniziato ad inondare B di un flusso di dati enorme, talmente grande da saturare le risorse di calcolo e/o di comunicazione di B. In pratica, B non fa altro che ricevere e scartare messaggi generati (indirettamente) da A. Distributed significa che l'attacco è stato generato da un insieme di calcolatori sparsi in giro per il mondo (e probabilmente partecipanti all'attacco all'insaputa dei rispettivi proprietari).
L'attacco si basa, in estrema sintesi, su due tecniche:
Ovviamente le query DNS non possono essere inviate tutte allo stesso name server, altrimenti sarebbe saturato quel name server invece del bersaglio dell'attacco. Per questo motivo è necessario distribuire le query su un insieme di server DNS. A tale scopo è sufficiente identificare dei server DNS che accettano di effettuare risoluzione ricorsiva per qualsiasi client---i cosiddetti open resolvers.
Osservazione sul punto 1 e sugli open resolver: la faccenda è spiegata molto bene e molto brevemente in questo documento dello US-CERT: DNS Amplification Attacks. Il documento spiega anche come configurare un name server affinché non funzioni da open resolver.
Osservazione sul punto 2. Le botnet si possono comprare, ad un prezzo dell'ordine dei pochi centesimi di euro per nodo. Con poche decine di euro si acquistano cioè centinaia di calcolatori sui quali è stato installato un software a scelta, tipicamente controllabile da remoto e tipicamente all'insaputa del proprietario. Ovviamente in un mercato che non è legale.Informalmente si dice che un nodo "ha un virus". In realtà il nodo ha un malware (cioè sul nodo è installato un programma maligno); molti malware sono programmati per tentare di diffondersi il più possibile; il termine virus si riferisce a questa funzionalità dei malware. Quello delle botnet è un tema molto affascinante e molto complicato...ogni botnet ha il proprio protocollo C&C (command and control) che permette all'attaccante di inviare i comandi alle botnet senza essere localizzato; comandi autenticati, in modo che ogni bot esegua solo i comandi inviati dal proprio proprietario; comandi che non possono essere falsificati neanche quando i "buoni" entrano in possesso di un nodo della bot e possono analizzare sia il suo funzionamento sia il traffico con il rispettivo proprietario...
Anche se l'attacco di questi giorni era da una organizzazione A verso una organizzazione B, l'impatto è stato molto diffuso in quanto la dimensione dell'attacco è stata talmente elevata da causare sovraccarichi su molti "canali di comunicazione comuni", anche ad organizzazioni che non hanno nulla a che fare con A o con B.
Venerdi scorso molti enti di ricerca, tra i quali il nostro ateneo, hanno ricevuto una direttiva da parte del GARR (l'organizzazione che coordina gli accessi Internet degli enti di ricerca italiani) in cui imponevano di eliminare l'utilizzo degli open resolver, per contribuire a disinnescare l'attacco (da notare che si stima ci siano venti milioni di open resolver in giro per il mondo...). Il nostro ateneo ha quindi bloccato tutto il traffico in ingresso sulla porta 53 (e spero sia chiaro il motivo) a meno del traffico diretto verso le zone "sotto" units.it gestite da name server interni alla rete di ateneo.
Per un errore organizzativo, si erano dimenticati di permettere il traffico in ingresso verso la porta 53 del name server della nostra zona inginf.units.it, server che non è un open resolver....
Nei giorni successivi tutti i siti della zona inginf.units.it sono diventati irraggiungibili (problema risolto pochi minuti fa).
Il secondo fenomeno è stato una conseguenza del primo. Cerco di spiegare brevemente la faccenda in questo post. Se qualcuno avesse dubbi o curiosità mi chieda a lezione.
Premessa: l'articolo su Wired.it secondo me è incomprensibile dal punto di vista tecnico. Non si capisce minimamente cosa sia successo.
Per capire cosa sia successo, consiglio questo articolo:
Massive DDoS attack against anti-spam provider impacts millions of internet users
In brevissimo:
Una organizzazione A ha deciso di lanciare un attacco "Distributed Denial of Service" nei confronti di una organizzazione B. Denial of Service significa che A ha iniziato ad inondare B di un flusso di dati enorme, talmente grande da saturare le risorse di calcolo e/o di comunicazione di B. In pratica, B non fa altro che ricevere e scartare messaggi generati (indirettamente) da A. Distributed significa che l'attacco è stato generato da un insieme di calcolatori sparsi in giro per il mondo (e probabilmente partecipanti all'attacco all'insaputa dei rispettivi proprietari).
L'attacco si basa, in estrema sintesi, su due tecniche:
- Si invia una query DNS su UDP falsificando l'indirizzo mittente; l'indirizzo mittente (falso) è quello di uno dei nodi che si vogliono colpire (falsificare l'indirizzo mittente in UDP è banale; farlo in TCP, come abbiamo detto a lezione, è molto più difficile). L'attaccante cioè invia la query ed il nodo che si vuole colpire riceve la response, ad una query che non ha mai fatto. La dimensione di una DNS response è più grande della dimensione di una DNS query, diciamo di un fattore a (con a circa 10). In questo modo, un attaccante in grado di generare un flusso di K bit/sec ha un meccanismo di amplificazione automatico per generare a * K bit/sec.
- L'attaccante deve avere a disposizione una botnet, cioè migliaia o decine di migliaia di computer in grado di eseguire comandi scelti da lui. Normalmente all'insaputa del proprietario del computer. In pratica, ogni computer infettato da un "malware" rimane in attesa di comandi inviati dal creatore, o dal proprietario, del malware ed esegue quei comandi. Ad esempio, l'invio di query DNS come quelle indicate al punto precedente.
Ovviamente le query DNS non possono essere inviate tutte allo stesso name server, altrimenti sarebbe saturato quel name server invece del bersaglio dell'attacco. Per questo motivo è necessario distribuire le query su un insieme di server DNS. A tale scopo è sufficiente identificare dei server DNS che accettano di effettuare risoluzione ricorsiva per qualsiasi client---i cosiddetti open resolvers.
Osservazione sul punto 1 e sugli open resolver: la faccenda è spiegata molto bene e molto brevemente in questo documento dello US-CERT: DNS Amplification Attacks. Il documento spiega anche come configurare un name server affinché non funzioni da open resolver.
Osservazione sul punto 2. Le botnet si possono comprare, ad un prezzo dell'ordine dei pochi centesimi di euro per nodo. Con poche decine di euro si acquistano cioè centinaia di calcolatori sui quali è stato installato un software a scelta, tipicamente controllabile da remoto e tipicamente all'insaputa del proprietario. Ovviamente in un mercato che non è legale.Informalmente si dice che un nodo "ha un virus". In realtà il nodo ha un malware (cioè sul nodo è installato un programma maligno); molti malware sono programmati per tentare di diffondersi il più possibile; il termine virus si riferisce a questa funzionalità dei malware. Quello delle botnet è un tema molto affascinante e molto complicato...ogni botnet ha il proprio protocollo C&C (command and control) che permette all'attaccante di inviare i comandi alle botnet senza essere localizzato; comandi autenticati, in modo che ogni bot esegua solo i comandi inviati dal proprio proprietario; comandi che non possono essere falsificati neanche quando i "buoni" entrano in possesso di un nodo della bot e possono analizzare sia il suo funzionamento sia il traffico con il rispettivo proprietario...
Anche se l'attacco di questi giorni era da una organizzazione A verso una organizzazione B, l'impatto è stato molto diffuso in quanto la dimensione dell'attacco è stata talmente elevata da causare sovraccarichi su molti "canali di comunicazione comuni", anche ad organizzazioni che non hanno nulla a che fare con A o con B.
Venerdi scorso molti enti di ricerca, tra i quali il nostro ateneo, hanno ricevuto una direttiva da parte del GARR (l'organizzazione che coordina gli accessi Internet degli enti di ricerca italiani) in cui imponevano di eliminare l'utilizzo degli open resolver, per contribuire a disinnescare l'attacco (da notare che si stima ci siano venti milioni di open resolver in giro per il mondo...). Il nostro ateneo ha quindi bloccato tutto il traffico in ingresso sulla porta 53 (e spero sia chiaro il motivo) a meno del traffico diretto verso le zone "sotto" units.it gestite da name server interni alla rete di ateneo.
Per un errore organizzativo, si erano dimenticati di permettere il traffico in ingresso verso la porta 53 del name server della nostra zona inginf.units.it, server che non è un open resolver....
Commenti