Sicurezza/DoS, e la Rete si riscopre impotente

Sicurezza/DoS, e la Rete si riscopre impotente

Qualche settimana fa si è assistito ad un'ondata di attacchi di tipo Denial of Service che hanno messo in luce l'estrema fragilità della Rete. Conosciamo meglio il problema ed i possibili rimedi
Qualche settimana fa si è assistito ad un'ondata di attacchi di tipo Denial of Service che hanno messo in luce l'estrema fragilità della Rete. Conosciamo meglio il problema ed i possibili rimedi


E’ di dominio pubblico che l’attacco ai siti di Amazon , Yahoo! , eBay e CNN ha messo in crisi le basi su cui poggia la new economy o, per lo meno, ne ha rimesso in discussione la sicurezza della tecnologia su cui si basa.

Persino case come Microsoft si sono mosse per risolvere il problema, assegnando due finanziamenti a dei ricercatori universitari per aiutare gli amministratori di sistema a chiudere definitivamente il discorso DoS.
Da quanto si apprende da un articolo apparso su Techweb , infatti, è stato assicurato l’invio di 125.000 dollari all’Università della California per ricerche matematiche inerenti il problema DoS e 225.000 dollari all’Università della Virginia per “lo sviluppo di strumenti in grado di mettere a conoscenza gli amministratori di rete quando un particolare sito è sotto attacco”, come ha affermato Bob Herbold, Chief Operating Officer di Microsoft.

Ad un primo impatto l’attribuzione di tali attacchi va come sempre agli hacker: questo termine, “hacker”, viene ormai utilizzato per indicare qualsiasi tipo di sabotatore, spia o pirata della Rete. Un hacker, in realtà, ha un proprio “codice d’onore”, non ha fini vandalici né lucrativi e persegue soltanto la soddisfazione della sua curiosità e della volontà di contribuire attivamente all’accrescimento della sicurezza cercando i punti deboli del software e rendendoli di pubblico dominio.
Indagando un po’ più a fondo scopriamo infatti che generare questo tipo di attacchi è sempre più alla portata di un comune “smanettone” di computer, sia che lavori su Windows, Linux, Unix o che si appoggi anche al Mac (infatti un recente documento del CERT® dichiara che è possibile utilizzare il MacOs 9 per tale scopo), mentre le varie comunità hacker di tutto il mondo si dissociano ufficialmente da tali operazioni di attacco.

Hacker come Cult of Dead Cow porgono infatti le loro scuse di fronte ai fatti di questi ultimi giorni sottolineando però che le accuse rivolte alle comunità come la loro sono da considerarsi offensive, in quanto questo genere di attacchi non costituiscono “qualcosa che possa scrivere pagine importanti nella storia degli hacker e della vita di tutti i giorni”.

Proprio la rivista hacker per eccellenza, la 2600 – The Hackers Quarterly ha pubblicato il 9 febbraio 2000 un documento dal titolo alquanto significativo “Hacker all’attacco? Dubbioso.” da cui riportiamo quanto segue:
“Siamo spiacenti che i maggiori siti di Internet commerce siano stati oggetto di attacchi Denial Of Service, davvero. Ma non possiamo permettere a loro o a qualcun altro di attribuire la colpa alla comunità degli hacker. Inizialmente tutti gli enti preposti all’informazione hanno fatto un pessimo lavoro attribuendo la colpa a noi, cosa che poi hanno smentito affermando che non avevano la più pallida idea di chi si celasse dietro a questi attacchi. Poiché la capacità di avviare un programma (l’attacco Denial Of Service altro non è che questo) non comporta alcuna conoscenza specifica di programmazione, tantomeno di hacking, l’attacco può essere fatto da chiunque sia in possesso di tale programma.”

Ma c’è dell’altro: DJNZ degli The Electrohippies Collective il 1° febbraio 2000 pubblica un documento che complica ancora più la realtà degli attacchi, affermando che un DoS (d’ora in poi userò il termine abbreviato di Denial of Service per comodità) può essere eseguito anche con delle righe di Javascript e dimostra come una pagina Web di pochi Kilobyte possa diventare uno strumento DoS:

<– Simple DoS tool (by DJNZ and the electrohippies
collective Jan. ’00) –>

<HTML><HEAD><TITLE>Basic, standalone
denial of service tool</TITLE></HEAD>

<FRAMESET COLS="50%,50%" FRAMESPACING=0
BORDER=3

ONLOAD="setTimeout(‘self.location.reload(true)’,4000);">

<FRAME SRC="http://www.sitovittima1.com" NAME="sitovittima1"
NORESIZE SCROLLING="no">

<FRAME SRC="http://www.sitovittima2.com" NAME="sitovittima2"
NORESIZE SCROLLING="no">

</FRAMESET></HTML>

Tutto questo è stato pubblicato nel documento “Occasional Paper n°1”, dove vengono trattate varie modalità di attacco e addirittura alcune previsioni sul futuro da parte loro, più progetti futuri della comunità.

Anche Oxblood Ruffin dei Cult of Dead Cow pubblica un articolo in supporto agli Electrohippies dove termina con “Io non penso che gli Electrohippies siano stupidi”.


Il Denial of Service, spesso tradotto in italiano come “Interruzione del Servizio”, è un tipo di attacco che si realizza attraverso azioni solitamente di pura forza bruta, senza quelle “finezze” che spesso caratterizzano i classici attacchi “alla hacker” che tutti ci immaginiamo. Un DoS non ha altri obiettivi se non quelli di rallentare le prestazioni del sistema vittima portandolo, nel peggiore dei casi, al blocco totale. Il risultato dell’attacco è dunque la mancata disponibilità del sistema nella sua interezza o di alcuni suoi servizi, producendo danni a volte ingenti per siti Web che basano la loro attività economica in transazioni online, come, appunto, i siti Web colpiti alcune settimane fa.

Abbiamo visto che un attacco DoS può essere compiuto con un semplice Javascript, ma sulla rete sono disponibili altri strumenti ben più sofisticati e potenti come i programmi trinoo (generalmente lo si trova come trin00), TFN (Tribe Flood Network) e l’ultimo arrivato, TFN2K, che opera allo stesso modo di TFN. Questi piccoli programmi utilizzano spesso varie tecniche per raggiungere i loro scopi: la più potente e conosciuta, la cosiddetta “smurf DoS attack”, è quella che è stata utilizzata per colpire i siti di Amazon , Yahoo! , eBay e CNN .

Nelle tecniche di attacco DoS un ruolo predominante lo riveste il protocollo ICMP (Internet Control Message Protocol): si tratta di un protocollo ausiliario del TCP/IP che ha il compito di inviare in rete dei messaggi di errore e controllo utilizzati dai protocolli di livello superiore per adottare una logica più affidabile e sicura nell’instradamento dei pacchetti. E’ grazie ad ICMP se, ad esempio, possiamo utilizzare il comando “ping” per determinare se un sistema remoto è in linea.
E proprio il comando ping fa uso di “echo”, un messaggio del protocollo ICMP che può essere inviato verso altri host via IP: nel caso l’host risulti attivo il comando ping si preoccuperà, sempre attraverso ICMP, di recapitare in risposta al mittente della richiesta un messaggio “echo reply”.

Il primo passo che compie chi esegue un attacco DoS è quello di esplorare la rete alla ricerca di router non sufficientemente protetti. Per farlo è possibile utilizzare uno dei programmi di scansione della rete reperibili ovunque (anche Tucows ne mette a disposizione, in quanto utilità per gli amministratori di rete) per reperire l’indirizzo broadcast di una rete, ovvero l’indirizzo madre che identifica tutti i dispositivi di una determinata rete.

Generalmente gli IP broadcast, in binario, sono indirizzi di rete che hanno la porzione dell’indirizzo host con i bit impostati tutti a 1. Per esempio, l’indirizzo broadcast per la rete 10.0.0.0 sarà 10.255.255.255 (infatti 255 in codice binario è pari a 11111111). Se avete cambiato la vostra rete di classe A in 256 sottoreti, l’indirizzo broadcast per la sottorete 10.50.0.0 dovrà essere 10.50.255.255. Gli indirizzi di rete con tutti zero nella porzione host, come 10.50.0.0, possono anche produrre una risposta broadcast.

Le parti in gioco in un attacco DoS sono tre: l’attaccante, l’intermediario e la vittima (che può essere l’intermediario stesso). L’intermediario riceve un pacchetto ICMP “echo request” diretto all’indirizzo IP broadcast della sua rete: se l’intermediario non filtra il traffico ICMP diretto all’indirizzo broadcast, le macchine attive riceveranno questo pacchetto di richiesta e invieranno a loro volta un pacchetto ICMP “echo reply” di risposta. Dove (potenzialmente) tutte le macchine di una rete risponderanno con il pacchetto di risposta sopra descritto, potrebbe verificarsi una notevole congestione o sovraccarico.

Ora immaginate questa situazione: un attacco di tipo “smurf” individua una rete dove risiedono 200 componenti attivi ed invia loro la richiesta “echo”. A questo punto ogni componente risponderà affermativamente inviando il pacchetto di dati “echo reply” all’indirizzo contenuto nella richiesta (ancora una volta sarà contenuto l’indirizzo della vittima), l’attacco prosegue individuando e attivando la risposta per altre 5 reti contenenti rispettivamente 100, 200, 150 componenti attivi: per 5 richieste inviate avremo 650 risposte di ritorno! Ripetendo l’azione per un cospicuo numero di volte, riusciremo ad intuire la portata che può acquisire tale attacco.

Se, ad esempio, un hacker (o pseudo tale) riesce ad intrufolarsi in una rete e far partire l’attacco da una linea ISDN a 64 Kbps (tenendo conto che non è poi così raro trovare un centinaio di componenti sullo stesso segmento) potrà produrre una portata di traffico pari a circa 4 linee T1, ovvero quattro volte il traffico generato da una linea in grado di supportare dati pari a 1,544 Mbps. Ancora, se il traffico generato con una serie di ICMP “echo request” sarà pari a 768 Kbps, moltiplicando la risposta per i 100 host attivi si otterrà un traffico pari a 76,8 Mbps, abbastanza per paralizzare la vittima.


Nel sito del CERT (Computer Emergency response Team), fra i cui membri ricordiamo la presenza di Cisco , Sun , IBM , Cray, ed altri grossi nomi dell’industria e ricerca informatica, possiamo trovare alcune soluzioni che, se seguite da tutti gli amministratori di sistema, potrebbero drasticamente ridurre il rischio di una nuova ondata di attacchi DoS come quella verificatasi di recente.

A. SOLUZIONI PER L’INTERMEDIARIO

1. Disabilitare “IP-directed broadcasts” sui router

Il router andrà configurato per vietare il traffico IP broadcast proveniente dall’esterno e diretto verso la rete da proteggere. In alcuni casi, la funzione in questione non è richiesta. Per maggiori informazioni si può consultare le RFC2644/BCP34 (Changing the Default for Directed Broadcasts in Routers).

2. Configurare i sistemi operativi di ogni macchina affinché non rispondano ai pacchetti ICMP inviati dall’IP broadcast address

Se un intruso compromette una macchina qualsiasi di una rete, potrebbe provare a lanciare un attacco smurf dalla rete in questione utilizzandola come intermediario. In questo caso proverà ad utilizzare la macchina corrotta per inviare il pacchetto all’indirizzo broadcast della rete locale: la prima soluzione non sarebbe sufficiente, da sola, a proteggere la potenziale vittima da un attacco di questo genere.

B. SOLUZIONI PER LA VITTIMA

Sfortunatamente non ci sono soluzioni facili per prevenire ed evitare questo genere di attacchi, infatti il traffico proveniente dall’intermediario potrebbe essere bloccato dai router, ma questo potrebbe non necessariamente prevenire la congestione che si crea tra il router della vittima e il suo Internet service provider. In questo caso la vittima dovrà consultare il proprio ISP per bloccare temporaneamente questo tipo di traffico nella rete dello stesso. In più, le vittime potrebbero contattare gli intermediari e informarli dell’attacco e dei passi da seguire per interromperlo.

C. SOLUZIONI PER I SITI DOVE L’ATTACCO HA ORIGINE

Qui l’unica soluzione altamente raccomandata è quella di filtrare i pacchetti in uscita che contengono un indirizzo di una rete diversa da quella locale. Attacchi come lo smurf, infatti, forzano l’indirizzo, ovvero modificano l’indirizzo originale. Con la tecnologia IP corrente è impossibile eliminare i pacchetti IP-spoofed. In ogni caso, si può ridurre il rischio installando sui router un filtro che richieda ai pacchetti che stanno lasciando una certa rete di contenere un indirizzo sorgente della rete stessa.
Una descrizione dettagliata sull’argomento la si può trovare sulla RFC2267.

Marco Trevisan

Link copiato negli appunti

Ti potrebbe interessare

Pubblicato il
20 mar 2000
Link copiato negli appunti