Per prima cosa, cosa è successo a Yahoo? Immaginiamo una società che lavora principalmente con il telefono, e il cui centralino improvvisamente viene tempestato da migliaia di telefonate senza nessuno all'altro capo del filo. Questa società si troverà di colpo nell'impossibilità di lavorare, perché le telefonate legittime troveranno le linee occupate e il personale sarà impegnato a rispondere alle telefonate fasulle. Quello che è successo a Yahoo è sostanzialmente la stessa cosa: una quantità enorme di pacchetti si è riversata sulla loro connessione con Internet: voci, perché non mi risultano rapporti tecnici ufficiali, parlano di un Gigabit per secondo (Gbps, un miliardo di bit per secondo) di dati. Un singolo computer non è normalmente in grado di produrre una tale quantità di traffico, e infatti per questo tipo di attacchi vengono utilizzati molti computer, preventivamente "conquistati", che mandano traffico in modo coordinato: si tratta dei cosiddetti "attacchi distribuiti di blocco del servizio" (Distributed Denial of Service) o DDOS. Non sono niente di particolarmente nuovo, sono noti da tempo ma finora sono sempre stati poco interessanti. Dal punto di vista di chi è attaccato, si tratta di perdere per un certo tempo la propria raggiungibilità da Internet: per la maggior parte delle reti è un problema quasi trascurabile, dato che non blocca le ben più importanti attività in corso sulla rete locale. Per gli attaccanti non è mai stato interessante "sprecare" un gran numero di macchine per un attacco senza nessun ritorno immediato in termini di immagine i o di informazioni o di siti conquistati. Le cose sono cambiate con i siti la cui attività principale riguarda l'offerta di servizi su Internet, come appunto Yahoo e Amazon.
Il problema è quindi, cosa si può fare per proteggersi? La risposta tradizionale di chi si occupa di sicurezza è sempre stata: "contro i Denial of Service si può fare poco", perché nel momento in cui i pacchetti arrivano alla nostra rete e noi possiamo cominciare a fare qualcosa, la connessione è già stata intasata. Infatti, Yahoo e gli altri hanno subito completamente l'attacco. A complicare le cose, i pacchetti che vengono inviati hanno un indirizzo mittente falsificato, e quindi anche il nostro provider, che magari potrebbe affrontare il problema prima che arrivi a noi, non è in grado di distinguere il traffico legittimo da quello falsificato. Di fronte a un attacco delle dimensioni di quello su Yahoo, che è sembrato poter mettere in discussione l'utilità commerciale dell'intera Internet, si sono dovute cercare delle risposte più concrete.
Le prime proposte arrivate a caldo sono state, come sempre, le peggiori. C'è stato un rifiorire di proposte di varie forme di regolamentazione di Internet: i pochi tentativi che sono stati fatti in questo senso sono sempre falliti di fronte alla natura stessa di Internet, in cui le frontiere hanno poco senso e quindi qualsiasi legislazione nazionale viene superata spostando un'attività da un paese a un altro, senza considerare il fatto che, come ha detto qualcuno, è come pensare di aver risolto il problema dei furti negli appartamenti rendendo illegale il possesso di attrezzi da scasso. Un'altra soluzione deludente è stata proposta RSA con i suoi "client puzzles" L'opinione diffusa è che si sia trattato di una semplice mossa commerciale, sul tono "con la crittografia si può risolvere qualsiasi problema di sicurezza". Per prima cosa, l'ormai accettato fallimento dell'introduzione di IPv6 ha mostrato che soluzioni che prevedano la modifica della totalità degli stack TCP/IP esistenti non è praticabile. Inoltre il tipo di Denial of Service di cui stiamo parlando non si basa sul consumo di risorse sul server, ma sul semplice consumo di banda.
Man mano che si calmavano le acque, si sono cominciate a vedere delle proposte più interessanti. Trovo abbastanza sconfortante notare che le discussioni più interessanti non sono state nei gruppi che si occupano di sicurezza, ma in quelli dei sistemisti, come ad esempio http://www.merit.edu/mail.archives/nanog/threads.html Alla fine sembrano emerse due direzioni di lavoro. Da una parte, ridurre la possibilità di falsificare gli indirizzi mittente dei pacchetti, in modo da poter individuare più facilemente sia il traffico legato agli attacchi che i sistemi utilizzati. Dall'altra, un meccanismo di segnalazione in banda che permetta di ridurre l'afflusso di questi pacchetti.
La prima parte è tecnicamente quasi banale: ogni provider sa quali reti gestisce e quindi può scartare il traffico che, provenendo dalla sua rete, va verso Internet ma non ha indirizzo mittente nella sua rete. A questo principio sfuggono alcune reti più complesse, ma la maggior parte dei provider dovrebbe solo mettere poche regole di filtraggio sui propri router. L'unica obiezione tecnica alla diffusione di questa pratica sarebbe il fatto che l'attivazione di questi filtri sovraccaricherebbe i router. L'obiezione è stata ampiamente confutata e riportata nella maggior parte dei casi ad una configurazione inadeguata dei router o dei filtri. Rimane il problema principale, che è, come si può immaginare, di gestione: come convincere un provider ad attivare una configurazione dei propri router che gli può quantomeno complicare la gestione, e che serve a proteggere non lui ma qualche altra rete che potrebbe essere attaccata dalla sua. Al di là delle solite proposte di tono legale, sembra che le soluzioni più ragionevoli si possano basare sui meccanismi che hanno sempre funzionato meglio su Internet: la collaborazione diffusa nell'isolare chi si comporta in modo scorretto, come ad esempio il "blacklisting" che si sta diffondendo nei confronti di chi facilita la diffusione dello spam. Da questo punto di vista può aiutare la prossima approvazione come "Best Common Practice" di un prodotto del working group "Guidelines and Recommendations for Security Incident Processing" dell'IETF, il draft "Security Expectations for Internet Service Providers" che insieme ad altri ottimi principi suggerisce già da tempo il filtraggio descritto.
La seconda parte, ovvero il meccanismo di segnalazione in banda, è concettualmente altrettanto semplice ma tecnicamente più complesso da realizzare. L'idea è che se a un router arriva troppo traffico da un indirizzo, possa segnalare al router che glielo sta passando di "chiudere il rubinetto": questo router a sua volta potrebbe fare la stessa cosa con il router che sta passando il traffico a lui, risalendo e "chiudendo rubinetti" fino alla fonte. Esisteva già un meccanismo di questo genere, il pacchetto ICMP "source quench", che era però troppo primitivo ed inefficace ed è stato sostituito con altri strumenti di controllo del traffico. Non è pensabile di rispolverarlo a questo scopo, quindi dovrà essere studiato qualche altro sistema.
Si tratta comunque sempre di meccanismi che coinvolgono l'intera Internet e non il sistema di sicurezza della singola rete che si vuole proteggere, e quindi richiederanno tempo per essere realizzati. Nel frattempo? Dopo i casi da prima pagina, di nuovo non si sente più niente... fino al prossimo DDOS.