venerdì 26 aprile 2013

Non sono più...

Da oggi non sono più il presidente del corso di studi in Ingegneria Informatica.

Ho ricoperto questo ruolo ininterrottamente dal 2001, solo per spirito di servizio (= ne avrei fatto molto, ma molto volentieri a meno).

Adesso sono stato obbligato alle dimissioni. Una delle infinite norme ministeriali sull'ordinamento universitario impone a chi ha ricoperto questo ruolo per due mandati (sei anni complessivi) di essere "squalificato a vita". Questa norma era sempre stata interpretata in modo molto soft---eufemismo per dire "all'italiana"---ma adesso è diventata cogente per tutta una serie di motivi che è inutile riassumere.

Il nuovo coordinatore è Eric Medvet. Eric è una persona che non solo ha grandi capacità ma è anche piena di entusiasmo. Spero che le immersioni nei moduli, norme, leggi, decreti, tabelle, convalide, transitori, piani di studio, etc etc etc non gli tolgano questo entusiasmo.

Per gli studenti questo cambio di coordinatore non avrà alcun effetto pratico.

Ho riflettuto se fare una sorta di "bilancio pubblico" di questa mia esperienza di servizio. Ho concluso che è meglio di no.


martedì 9 aprile 2013

Com'è fatta una pagina web "vera" ?

La visualizzazione di ogni singola "pagina web" non è il risultato del prelievo di un documento HTML ed una manciata di file JPG.

E' il risultato del prelievo di molti documenti da più server, e dell'elaborazione nel browser di molti programmi Javascript prelevati da più server. In un post di un pò di tempo fa ho anche riportato statistiche molto interessanti calcolate da Google: in media, la visualizzazione di una pagina richiede il prelievo di più di 40 documenti da 7 server diversi.

Ho trovato un servizio web molto interessante per evidenziare questo fenomeno. Si tratta di urlquery.net. E' stato sviluppato per fare analisi relative al malware diffuso via web, ma è molto interessante anche per capire com'è realizzata una pagina "vera".

Gli ho chiesto di analizzare www.gazzetta.it. Dopo qualche decina di secondi ha fornito un report molto dettagliato, con alcuni aspetti di non facile interpretazione ma molto istruttivo:

  • Eseguiti 194 (centonovantaquattro) script.
  • Gli script hanno applicato 457 (quattrocentocinquantasette) modifiche al documento visualizzato dal browser.
  • Il browser ha eseguito 449 (quattrocentoquarantanove) scambi request-response HTTP.
Una "pagina web" reale è quindi qualcosa di molto, ma molto complicato.

Il report dovrebbe essere accessibile a questo link (altrimenti fatelo generare nuovamente); qui sotto una sorta di mappa dei documenti necessari.


martedì 2 aprile 2013

Il grande attacco di questi giorni (e inginf non accessibile)

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:

  1. 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.
  2. 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.
In altre parole, con il punto 2 si ottiene K molto grande. Con il punto 1 si moltiplica K per un fattore a. Se il prodotto a * K è sufficientemente grande allora il gioco è fatto.

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