| |
- ======================
"Tribe Flood Network 3000"
======================
*** Tradotto dal LOA ( http://www.ecn.org/loa ) ***
Una recensione su cosa sono esattamente i DDOS (distributed denial of service), come possono essere usati, quali funzioni ancora piu' pericolose possono essere implementate in futuro, e spunti iniziali per stabilire le regole per il rivelamento delle intrusuoni nelle reti per quanto riguarda i DDOS.
Molte persone tecnicamente poco informate considerano i DDOS un'arma, che non dovrebbe essere sviluppata pubblicamente ne distribuita.
*************
Questa e' l'unica altra cosa, comprensibile a TUTTI, che diro' per
spiegare i tool di DDOS e ulteriori feature che in futuro potrebbero
essere implementate nei DDOS: una breve descrizione teorica.
*************
Comunque: le persone con conoscenze tecniche possono saltare le parti I. e II.
- Che cosa e' un DDOS, per cosa puo' essere usato, come funziona ?
- Quali sono le funzioni di un DDOS, quali saranno le funzioni future, come si stanno evolvendo i DDOS ?
- DDOS, un exploit oppure no ? Dovrebbe essere reso pubblico ? Qual'e' il problema principale ?
- Come puo' il traffico di un DDOS essere rilevato da un rilevatore di intrusione in una rete (Network Intrusion Detection NIDS) ?
I.
Che cosa e' un Distributed DOS ?
I DDOS, renderanno semplice coordinare una procedura che eviene lanciata da molti computer. In questo caso e' un DOS (Denial of Service - blocco del servizio) in forma di un'enorme flusso di pacchetti (packet flooding) per sovraccaricare le connessioni della rete.
I DDOS NON SONO UNA CATEGORIA DI STRUMENTI DI HACKING. I DDOS sono strumenti PENETRAZIONE.
Non sfruttano vulnerabilita' della sicurezza, ma possono dimostrare quale livello di traffico un nodo puo' o non puo' sopportare.
I DDOS vengono usati da molto tempo da consulenti professionali per la sicurezza in test di penetrazione.
Prima c'erano strumenti di attacco di tipo DDOS, che erano programmi commerciali non open-source che potevano lanciare dei packet floods distribuiti.
Questi erano usati negli affari di consulenza sulla sicurezza delle informazioni, per realizzare un servizio di sicurezza chiamato "Capacity Management" (Capacita' Amministrativa). Lo scopo di questo e' di determinare quanto traffico una rete puo' sopportare, per vedere se la larghezza di banda disponibile deve essere aumentata, o se puo' gestire abbastanza traffico mentre fornisce servizi in modo affidabile.
Per cosa puo' essere usato ?
Puo' sovraccaricare, o inondare (flood) se preferisci, i collegamenti della rete. Manda pacchetti senza senso in modo che l'ammontare totale dei dati sia maggiore di quanto la rete possa gestire.
L'effetto e' che i bersagli non possono essere raggiunti dalla rete. Questo e' tutto.
Come funziona ?
Il concetto di base e' che tu installi una enorme quantita' di server DOS su diverse macchine.
Questi aspetteranno dei comandi da un client centrale. Un client centrale puo' mandare messaggi a tutti i server, e comunicargli di mandare tutto il traffico che possono verso un certo bersaglio. Il client distribuisce il lavoro di flooding del bersaglio tra tutti i server DOS disponibili, per questo e' definito come "distribuito" (distributed).
Prima che questi strumenti fossero disponibili, un attaccante (o collaudatore della penetrazione) doveva telnettare in tutti i computer che voleva usare, entrare come utente e manualmente lanciare un comando per floodare un bersaglio (questo su ognuna delle macchine da cui doveva partire il flood), per esempio usando il classico comando UNIX ping: "ping -f bersaglio".
II.
Quali sono le funzioni di un DDOS ?
Gli strumenti di attacco attuali non fanno un semplice flood, ma alcune variazioni di questo che comprendono l'utilizzo di debolezze nei protocolli per
a) rendere un attacco piu' potente
b) rendere un attacco piu' difficile da tracciare
Primo, gli attuali DDOS nascondono (spoof) l'indirizzo sorgente dei pacchetti. Mandano pacchetti IP grezzi, e a causa della natura del protocollo di internet l'indirizzo sorgente puo' essere alterato, e singoli pacchetti (non destinati ad una connessione) possono comunque raggiungere la loro destinazione. Questo e' quello che rende cosi' difficile tracciare l'attacco.
I DDOS sfruttano anche le debolezze dei protocolli, per esempio possono aprire delle mezze-connessioni usando la tecnica del SYN flooding. Questa e' una vulnerabilita' molto vecchia e ben conosciuta e le contromisure sono disponibili.
Per rendere un attacco piu' efficace, i DDOS possono usare qualsiasi debolezza dei protocolli che puo' essere sfruttaTa mandando pacchetti singoli (non destinati ad una connessione) ad un host (computer connesso in rete).
Quali saranno le funzioni future ?
Le cose che possono ancora essere implementate, ma non sono ancora state
pubblicizzate, sono le vulnerabilita' dei protocolli, come menzionato prima.
Uno di questi e' l'attacco "stream" (scoperto da Tim Yardley, stream.c e
spank.c dimostrano la vulnerabilita' e sono pubblici. L'attacco stream manda
pacchetti TCP con settati o il flag ACK oppure entrambi i flag SYN e ACK. Dato
che non sono parte di una connessione , questi confondono la macchina
bersaglio e richiedono un certo tempo per essere processati dal sistema
operativo. Se questo attacco e' usato in modo distribuito, l'attaccante puo'
sovraccaricare delle macchine con meno host
Per quello che ho sentito, gli attacchi stream distribuiti sono gia'
implementati in strumenti di tipo DDOS privati. E' molto facile
implementare questa funzione. La seconda possibilita' che non e' ancora stata
implementata sono gli indirizzi multicast. Gli indirizzi multicast sono
instradati (forwardati) soprattutto dai routers, che possono moltiplicare un
pacchetto in molti pacchetti. Il concetto
several ones. The concept e' quello di spedire pacchetti con un indirizzo
multicast (del tipo 224.x.x.x). Un bersaglio potrebbe rispedire un
messaggio di errore agli indirizzi del multicast, moltiplicando la
banda. Questa idea e' stata anche menzionata da Tim Yardley.
Un'altra idea potrebbe essere quella di spedire intenzionalmente stringhe
speciali nel traffico generato da un flood, stringhe che i sistema di
rilevamento delle intrusioni in rete (NIDS) potrebbero interpretare malamente
come tentativi di intrusione, l'impatto sarebbero falsi allarmi e i NIDS in
questione potrebbero andare in sovraccarico o crashare.
Come si stanno evolvendo i DDOS ?
Come ho detto, i primi tool (strumento) che eseguirono dei DDOS erano
strumenti commerciali di penetrazione. L'origine dell'utilizzo dei DOS
generali e' certamente IRC, dove i raggazzetti (kiddies) possono prendere il
controllo dei canali se riescono a bloccare temporaneamente delle macchine con
dei DOS. Il primo DOS che causava un flood coinvolgendo piu' machine e' stato
lo smurf. Lo smurfing si basava su reti malconfigurate che rispondevano ad un
indirizzo broadcast, mandando un pacchetto se ne ottenevano centinaia che
rimbalzavano indietro. Poi, la maggior parte di queste reti malconfigurate
sono state messe a posto, e gli attaccanti hanno compromesso parecchi host
(nodi della rete), con preferenze per quelli con una grande banda a
disposizione, facendo cosi' partire i flood manualmente da questi host.
Dato
che questo richiedeva un certo tempo, gli attaccanti hanno scritto dei server
che hanno installato sugli host che avevano compromesso. Non avevano piu'
bisogno di fare un login sull'host, bastava mandare messaggi al server. I toll
di attacco DDOS che io conosco sono, in ordine cronologico di apparizione:
fapi (privato, di ?), blitznet (pubblico, di phreeon), trinoo (privato,
di phifli), TFN (pubblico, mio), stacheldraht (privato, di randomizer),
shaft (privato, di ?), TFN2K (pubblico, mio), Trank (TRinoo + spANK.c?,
privato). I recenti sviluppi sono proseguiti in altri modi, dato che alcune
persone monitoravano il traffico alla ricerca di pacchetti specifici dei DDOS
(come stringhe di caratteri note, password conosciute, porte di default,
ci sono state molte piccole variazioni fatte al codice di questi
strumenti, dagli attaccanti, per evitare di essere rilevati.
III.
DDOS, un exploit o no?
No. Il DDOS di per se stesso non e' un exploit. Rende solo piu' semplice
quello che gia' esiste. Prendete il distributed.net RC5 challenge e i
password crackers distribuiti. Non sono exploit. Ma svelano una debolezza, che
molte password possono essere forzate piu' velocemente di quanto la gente
pensi. I DDOS mostrano che molte reti non sono cosi' robuste come
sembrere e possono essere sovraccaricate molto velocemente, In piu', ci sono
degli exploit attualmente implementati nei DDOS, che sfruttano buchi nella
sicurezza nei protocolli di rete correntemente usati in internet. Questi buchi
nella sicurezza non devono essere necessariamente sfruttati per rendere
possibili i DDOS, ma posono rendere l'impatto di un attacco DDOS molto piu'
forte. Questi exploit sono la possibilita' di spoofare in modo arbitrario un
indirizzo IP, il SYN flooding, gli attacchi allo stack IP con dei pacchetti
frammentati, spoofing IP addresses, SYN flooding, IP stack attacks with bad
fragmentation, header non corretti e altri "pacchetti magici", la
vulnerabilita' allo stream, la mancanza di autenticazioni e la sicurezza del
traffico conosciuto come connection-less (senza connessione) o stateless.
Dovrebbero essere resi pubblici ?
Questa e' una decisione che spetta a te. E 'la tua opinione personale. Ma le
persone continueranno a pubblicare le vulnerabilita'. Centinaia di analisti
della sicurezza pieni di talento stanno ricercando professionalmente delle
debolezze nei software, e annunciano gli exploit per questi programmi, che
possono spesso essere usati per compromettere istantaneamente a livello di
root un sistema su cui gira il programma vulnerabile. Il passato ha dimostrato
che, fin da quando le vulnerabilita' della sicurezza erano un problema su
internet, la gente ignorava gli avvisi che contenevano solo le informazioni
CHE qualcosa era vulnerabile ad un attacco, trascurandoli perche' "puramente
teorici". Solo quando la gente ha scritto e postato degli exploit pronti
all'(ab)uso, la gravita' delle debolezze e' divenuta chiara, e la gente ha
fatto uno sforzo per neutralizzare queste vulnerabilita'.
Qual'e' il problema principale ?
Il problema principale, che rende possibili gli attacchi contro siti grandi
quanto yahoo.com, e' la pessima sicurezza generale di internet. Con un
semplice strumento di DDOS in mano Giovanni Attaccante non puo' fare nulla. Ma
le debolezze della sicurezza sono omnipresenti sulla maggior parte degli host
della rete. Un enorme numero di questi host non si stanno preoccupando della
loro sicurezza, come risultato utilizzano dei programmi che si sanno essere
vulnerabili, e contro i quali esistono degli exploit pubblici. Un attaccante
deve solo lanciare uno di questi exploit per garantirsi un accesso completo al
sistema. E diverse persone sono state in grado di compromessere MIGLIAIA di
host con delle vecchie e ben note vulnerabilita'.
Anche le reti ad alta velocita' delle universita', che originariamente
cotruirono l'architettura fondante di internet, si sono mostrate insicure. Col
pieno controllo su migliaia di host, e' facile concentrare tutte le risorse di
questi host per attaccare qualunque cosa su internet.
IV.
Come puo' essere intercettato il traffico di un DDOS da un sistema di
rilevamento delle intrusioni (NIDS)?
L'errore che tutti hanno fatto e' di cercare delle stringhe di default, dei
DDOS tools, valori, porte, password di default etc. Per capire le capacita'
dei NIDS di scovare questi tools, che operano tramite dei semplici pacchetti
che non richiedono una connessione, si dovra' iniziare a cercare segnali
generali del traffico di un DDOS, segnali che sono ovvi e traffico che e'
molto anomalo e sospetto. Ci sono 2 tipi di traffico generato da un DDOS,
traffico di controllo (tra il client e il server del DDOS), e il traffico
del flood (tra il server DDOS e la vittima del DDOS).
Un riconoscimento a Dave Dittrich, e all'Axent Security Team per avermi
fornito alcuni suggerimenti iniziali per scrivere questo.
- Anomalia 0: Questo non e' un reale traffico DDOS, ma puo' essere un possibile
metodo per determinare l'origine di un attacco DDOS. come osservato da RFP,
una attaccante dovra' risolvere il nome dell'host della sua vittima prima di
iniziare l'attacco. I BIND name servers sono in grado di registrare queste
richieste. E' anche possibile mandargli un segnale con 'kill', oppure si puo'
specificare il logging delle richieste nella configurazione del BIND. Una
singola richiesta di tipo PTR prima di un attacco indica che la richiesta e'
stata fatta dall'host dell'attaccante, un grande numero di richieste PTR dalla
vittima di un DDOS prima di un attacco indica che ai server del flood e' stato
dato il nome di un host e ogni server sta risolvendo questo nome per conto suo.
- Anomalia 1: L'ammontare della larghezza di banda eccede una soglia massima che
ci si aspetta dal normale traffico di un sito. Oppure, la soglia puo' essere
la misura dell'ammontare dei diversi indirizzi di provenienza del traffico.
Questi sono chiari segnali di flood e delle regole ACL possono essere
implementate sui backbone routers (la spina dorsale di internet) che
rilevano questi segnali e filtrano il traffico.
- Anomalia 2: Pacchetti ICMP e UDP sovradimensionati. Le sessioni UDP usano in
genere dei piccoli pacchetti UDP, con un carico di non piu' di 10 bytes. I
normali messaggi ICMP non eccedono i 64 o 128 bytes. I paccheti che sono
ragionevolmente piu' grossi sono sospetti e possono contenere traffico di
controllo, soprattutto i bersagli criptati e altre opzioni per i server DDOS.
Una volta che il traffico di controllo (non fasullo) e' scovato, la posizione
di uno dei server DDOS e' rivelata, dato che i'indirizzo IP del destinatario
non e' spoofato nel traffico di controllo.
- Anomalia 3: Pacchetti TCP (e pacchetti UDP) che non fanno parte di una
connessione. I tools DOS piu' nascosti usano dei protocolli a caso, inclusi i
protocolli orientati alla connessione, per mandare dati su un canale non
orientato alla connessione. Usando dei firewall o dei link-state routing si
possono scoprire questi pacchetti. Inoltre, i pacchetti che indicano delle
richieste di connessione con porte di destinazione superiori alla 1024,
sulle quali nessun servizio e' registrato, sono altamenti sospetti.
- Anomalia 4: I packet payload contengono SOLO caratteri alfanumerici (quindi
no spazi, punteggiatura, caratteri di controllo). Questo puo' essere un
segnale che il packet payload e' encodato in formato BASE64, e quindi contiene
solo caratteri in base64. Il TFN2K manda questo tipo di pacchetti nel suo
traffico di controllo. Una stringa specifica del TFN2K (e dei suoi derivati)
consiste nella ripetizione di A (AAAA...) nel payload, dato che la dimensione
del buffer e' gonfiata dalla routine di crittazione. Se la codifica base64 non
e' usata, e il payload contiene traffico binario crittato, le A
diventeranno una scia di \0 binari.
- Anomalia 5: I packet payload contengono SOLO caratteri binari, high-bit.
Mentre questo puo' essere un trasferimento file (il traffico trasmesso sulle
porte 20, 21, 80 etc deve essere escluso se questa regola e' applicata),
specialmente se contenuto nel pacchetto non ci sono parti di un normale
traffico, e' sospetto se non e' encodato in base64, ma traffico di controllo
criptato che e' stato trasmesso nel packet payload.
- - Mixter
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1
iQEVAwUBOKdHVrdkBvUb0vPhAQGy2wf/XQ8d2VXKESzjyFzIqfRPd9S1RKXQZzGo
6yWnUADt3CuZRDmgJb9UYHJ/1Wf/J1V0PWik7GIJLD5zOXgUbgfdhYSOqJsPe14B
K3HaqraRFyMHXjb8A4TBC0RTEX3kepWFrMNePOge9rLPD8rwfhWdIrnJuyHmmNiS
rqVztFrPwfQl8FId5jjDjzXWlb5UuHgEpm1fNhrnjMh5XwFvVHN4MlJuuuk3ps9f
BVpBFJbSqmdb5GHTXCrw4tHHUHtpE7Iu586A6ODCERT1oM7i2SEroZ2x2xO2ssOx
cnyW3xFYcCNrJeJEzI9z+/VziYb1VqDl52MR7O1MSn/3SrAlVMvk2Q==
=GKzb
-----END PGP SIGNATURE-----
- Testo Originale
|
