Scarica Adesso 1.4 MB

Transcript

Guida Completa al Denial of Service
1
Indice
0) Prefazione
0.1) A chi è rivolto questo DOC
0.2) Come leggere questo DOC
0.3) Licenza d’Uso
1) Fondamentali
1.1) Il Computer
1.2) Reti
1.2.1) Sistema Client Server
1.2.2) Servizi e Porte
1.2.3) Pacchetti
2) Denial of Service
2.1) La teoria del DoS
2.2) Negazione del Servizio
2.2.1) I pericoli del DoS
2.2.2) Sistemi vulnerabili ai DoS
2.2.3) Conseguenze di un attacco DoS
2.3) Tipologie di attacchi DoS
2.3.1) Categorie di DoS
2.3.2) Attacchi DoS Volumetrici/Protocollo
2.3.2) DDoS e DrDoS
2.3.2.1) Distributed Denial of Service
2.3.2.2) Distributed Reflected Denial of Service
2.4) UDP/ICMP Flood
2.4.1) Simulare un attacco UDP/ICMP Flood
2.4.2) Mitigare un attacco UDP/ICMP Flood
2.5) SYN Flood
2.5.1) Simulare un attacco SYN Flood
2.5.2) Mitigare un attacco SYN Flood
2.6) HTTP Flood
2.6.1) Simulare un attacco HTTP Flood
2.6.2) Mitigare un attacco HTTP Flood
2.7) Slowris
2.7.1) Simulare un attacco Slowris
2.7.2) Mitigare un attacco Slowris
2
Autore
Stefano > murdercode < Novelli, 24 anni, programmatore e
ricercatore di sicurezza informatica.
Fondatore della community www.inforge.net e ideatore
dell’ebook.
Collaboratori
Marco > ecvz < Padovan, 29 anni, programmatore e sistemista
informatico.
Fondatore dell’hosting www.hiperz.net
> Max Fridman <, 23 anni, membro Staff di www.inforge.net
Francesco > Nhoya < Giordano, 19 anni, membro Staff di
www.inforge.net
Claudio > Sharu < Sciortino, 16 anni, membro Staff di
www.inforge.net
> B4ckdoor <, programmatore e creatore del B4ckself
3
Questo ebook è distribuito da
INFORGE.NET
4
0) Prefazione
In questa primo capitolo parleremo dell’etica e dei motivi che ci hanno spinto a scrivere questo documento. Si
consiglia la lettura così da fruire nel migliore dei modi delle informazioni riportate in seguito.
0.1) A chi è rivolto questo DOC
L’obiettivo di questo documento è quello di spiegare, attraverso concetti semplici e alla portata di
tutti, il fenomeno del Denial of Service e di tutto ciò che lo circonda.
0.2) Come leggere questo DOC
Questo documento è stato scritto usando un linguaggio il più semplice e chiaro possibile.
Ciò potrebbe tuttavia far storcere il naso agli esperti di settore; sappiamo quanto loro ci tengano ad
essere tecnicamente incomprensibili.
Consigliamo quindi a tutti di non limitarsi in buona fede delle nostre parole ma di informarsi sempre
e comunque su ciò che diciamo, di confrontarlo e di discuterlo all’interno del forum
http://www.inforge.net/ .
Il documento è strutturato in modo da poter essere letto sia in maniera lineare (dall’inizio alla fine)
sia “a pezzi”. Ciò nonostante, consigliamo perlomeno la lettura dei “Fondamentali” (cap. 1), per
riuscire a cogliere appieno tutta la terminologia e i tecnicismi del caso.
5
Leggenda delle Icone
Questa icona rappresenta un argomento di natura tecnica che potrebbe non essere
comprensibile a chi non è esperto del settore.
Le parti tutte in corsivo saranno invece scaglioni di codice di programmazione.
Verranno tutte commentate, ma si da per ipotesi che il lettore conosca un minimo di
programmazione.
0.3) Licenza d’Uso
GUIDA COMPLETA al DENIAL OF SERVICE è un ebook ideato e curato da Stefano murdercode
Novelli.
Le azioni e le informazioni che otterrete sono da riternersi per puro scopo informativo e
illustrativo.
Qualunque atto vada contro la legge informatica n.23 art. 1,2,3,4,5,6,7,8,9,10,11,12,13 è
perseguibile e punibile penalmente.
Le azioni riportare nel documento sono state testate su macchine di proprietà.
6
1) Fondamentali
In questo capitolo cercheremo di riportare tutte le informazioni fondamentali per apprendere al meglio gli argomenti
più avanzati della lettura.
1.1) Il Computer
Iniziamo ovviamente dal concetto più essenziale: il Computer.
Non limitiamoci però a vederlo come il computer fisso o il portatile che tutti noi abbiamo in casa (si
spera!) ma più come a un qualunque dispositivo in grado di eseguire calcoli matematici, restituendo
un output grazie al risultato delle istruzioni che elaborano i dati proveniente da un input esterno..
Ok un attimo: cosa significa?
Un input può essere un valore o una serie di valori che vengono inviati al nostro computer.
Possono essere valori numerici, parole, azioni compiute.
Un esempio può essere il movimento del mouse: nella sua versione analogica (quella con la palletta
insomma) il mouse invia dati in input al computer; questi dati sono i due assi verticale e orizzontale,
e sono valori numerici.
L’istruzione invece è il software che elabora il dato: senza l’istruzione, i valori inviati dal nostro
mouse sarebbero completamente inutili. L’istruzione invece raccoglie i dati, li riconosce come valori
del mouse e li prepara per mostrare il risultato.
L’output è appunto il risultato dell’unione input+istruzione: possiamo quindi dire che l’output è il
cursore che si muove all’interno del nostro schermo.
Tutto chiaro?
Bene, torniamo a noi.
Dicevamo che non dobbiamo limitarci a vedere il computer come al PC Desktop o il Notebook ma a
7
qualunque dispositivo in grado di elaborare un input e mostrare un output.
Quindi teniamo conto anche dei tablet, degli smartphone e dei router: insomma, allarghiamo i nostri
orizzonti.
1.2) Reti
La rete informatica è un insieme di computer collegati tra di loro, rendendoli in grado di trasmettersi
informazioni e condividersi periferiche e risorse.
La rete può avere uno o più seguenti di questi scopi:
●
Condividere delle risorse (file, applicazioni o hardware, connessioni a internet etc...)
●
Comunicare fra persone (email, chat etc...)
●
Lavorare sullo stesso progetto
●
Videogiocare
●
… e tanto altro.
Le reti possono poi essere classificate in base alla loro dimensione geografica:
●
LAN: reti di superficie ridotta (una stanza o un edificio) caratterizzata da alte prestazioni e
mezzi di trasmessione molto veloci.
●
WAN: reti di superficie media
●
MAN: reti di grandi dimensioni, ai livelli di un’area urbana (es. fibra ottica)
Le reti possono essere di due tipi di gerarchie: Client/Server e P2P (Peer to Peer).
8
Internet, la più grande rete mai creata, attualmente fa affidamento ad entrambe le tipologie di
gerarchia.Tuttavia nella navigazione nel World Wide Web (www, con protocollo di comunicazione
http) si fa affidamento principalmente alla struttura Client/Server, che tratteremo in questo
documento.
1.2.1) Sistema Client Server
La tipologia Client-Server indica un’architettura di rete nella quale genericamente un computer
(Client) si collega ad un altro computer (Server).
Il Client, collegandosi al Server, potrà fruire di tutti i servizi che gli vengono concessi.
Tali servizi possono essere:
●
Pagine Web
●
Invio/Ricezione Mail
●
Server di trasferimento dati
●
Server di gioco
●
… e, ovviamente, molto altro.
Ricapitoliamo:
Client riceve servizi dal Server
9
Questo concetto dovete tenerlo a mente, poichè sarà la base di tutto quello che diremo in questo
documento.
Sia i server che i client hanno inoltre un indirizzo identificativo nella rete chiamato IP.
Tale indirizzo è unico e rappresenta il computer nella rete (un pò come un numero di cellulare che
rappresenta la SIM).
1.2.2) Servizi e Porte
Come abbiamo già accennato, i servizi di un server possono essere svariati (pagine web, email, chat,
server di gioco etc...).
Per poter smistare e riconoscere tutti i servizi, il Server utilizza le porte.
Possiamo immaginarle come a delle corsie di un’autostrada; ogni corsia è dedicata ad un solo tipo di
autovettura. Allo stesso modo, ogni servizio viaggia all’interno della propria corsia (la porta,
appunto).
NB: sia Server che Client hanno porte di comunicazione, tuttavia i client spesso le hanno chiuse e/o
filtrate.
10
Le porte sono spesso standard, eccone una lista delle più comuni di un Server:
Porta Protocollo
Porta Protocollo
21 FTP
465 SMTP (SSL)
22 SSH
993 IMAP (SSL)
23 TELNET
995 POP3 (SSL)
25 SMTP
1080 SOCKS Proxy
53 DNS
1994 OpenVPN
80 HTTP
3306 MySQL
110 POP3
5432 PostgreSQL
137 NetBIOS
6667 IRC
443 HTTPS
8080 HTTP (web cache)
Lista completa su Wikipedia
Come è possibile vedere, ad ogni porta corrisponde un protocollo.
I protocolli di comunicazione sono regole utilizzate da due computer per comunicare tra di loro: come
un giapponese ed un italiano, due computer che non parlano la stessa lingua difficilmente
riusciranno a capirsi.
Tutti questi protocolli sono definiti dal modello di riferimento OSI (Open System Interconnection).
Il modello OSI contiene le regole e gli standard che consentono a qualsiasi sistema di
comunicare con altrettanti sistemi. Questi protocolli sono strutturati in sette livelli, e
ognuno ha un compito ben preciso.
I sette livelli OSI sono:
1. Livello Fisico: trasmissione di flussi di dati raw
2. Livello data-link: trasferimento di dati da due punti
3. Livello di rete: indirizzamento e trasferimento dati
4. Livello di trasporto: trasmissione affidabile dei dati
5. Livello di sessione: stabilimento e mantenimento della connessione
11
6. Livello di presentazione: presentazione dati, cifratura e compressione
7. Livello di applicazione: esecuzione delle applicazioni
1.2.3) Pacchetti
I pacchetti sono contenitori di dati che viaggiano all’interno di una rete, sfruttando il metodo di
trasferimento a commutazione di pacchetto (approfondimento pacchetti di rete).
Ve lo rispiego in linguaggio volgare: un pacchetto contiene le informazioni da passare a un altro
computer. Meglio? :)
Essi sono formati da tre parti:
●
Header: contiene tutte le informazioni necessarie alla trasmissione (mittente, destinatario
etc...).
●
Data: contiene le informazioni da scambiare
●
Checksum: è un codice di controllo per la verifica dell’integrità del pacchetto
I pacchetti viaggiano continuamente da un computer ad un altro.
Viaggiano quando siamo connessi in una LAN (magari tra uno switch e un notebook), viaggiano
quando siamo connessi su Skype oppure quando stiamo navigando su Facebook.
E’ possibile che il vostro router di casa invii pacchetti al vostro tablet per vedere se è ancora
connesso.
Nello specifico, ogni pacchetto contiene implementazioni dei protocolli dei 7 livelli
OSI.
Ogni livello viene avvolto dal livello soprastante a mò di cipolla, definendo così degli
strati livello; questo serve per permettere la lettura di alcune informazioni solo a chi
ne ha necessità (es. il router avrà bisogno di leggere solo le informazioni del Livello 3
aka Livello di Rete).
Tale processo viene definito incapsulamento.
Ogni pacchetto ha una lunghezza massima di dati (MTU) e una lunghezza minima.
In caso di superamento della lunghezza massima, il pacchetto verrà frammentato in più segmenti.
In caso di non raggiungimento di una lunghezza minima, il pacchetto verrà riempito (padding).
12
2) Denial of Service
Negazione di servizio: dalle sue prime versioni a quelle attuali. Metodi di attacco e di difesa di uno delle tecniche di
cyber-terrorismo più in voga negli ultimi anni.
2.1) La teoria del DoS
Immaginate una lunga coda al casello dell’autostrada; come molti di voi sapranno, ogni corsia è in
grado di contenere e gestire una macchina per volta.
Ora, tutti i caselli delle autostrade sono il vostro server.
Gli utenti (i Client) sono le macchina sono in coda.
Immaginiamo a questo punto di prendere 10.000 macchine e farle andare tutte assieme a fare la fila.
Qual è il risultato? Che la fila si intasa.
E proprio come in un’autostrada, dove ogni corsia corrisponde ad un servizio, se si effettua una
richiesta massiccia di quel servizio (come la coda), tale servizio si blocca.
2.2) Negazione del Servizio
Ora che abbiamo capito il concetto base del DoS (Denial of Service, appunto Negazione del Servizio)
entriamo un pò più nel vivo dell’argomento.
Prima abbiamo parlato di 10.000 persone, ma cosa sono queste persone? Sono Computers?
13
No, sono richieste e, come ben sappiamo, una richiesta si fa attraverso l’invio e la ricezione di un
pacchetto (vedi 1.2.3).
La teoria dell’attacco vuole quindi che generando milioni e milioni di richieste ad un server, questo
cessa di erogare servizi.
2.2.1) I pericoli del DoS
Come può una tipologia di attacco avere un così grande successo a distanza di anni dalla sua
“ideazione”?
Sono stati creati anti-virus, anti-trojan, anti-malware, anti-qualunquecosa ma non è mai stato
inventato un anti-ddos, neanche dopo il boom del DoS nel 2011 (e in continua crescita).
Cosa si può fare per fermarli?
La soluzione al problema varia di caso in caso, tuttavia più avanti cercheremo di trattare a fondo il
tema.
Purtroppo però non possiamo assicurarvi nulla: è la rete stessa ad avere un sistema marcio, che non
garantisce l’affidabilità di ogni informazione scambiata.
Essendo progettata come rete “affidabile”, Internet permette alla maggior parte dei dispositivi di
scambiare qualunque informazione senza un controllo sulla veridicità dello scambio di informazioni.
Come mai gli attacchi DoS sono in rapida crescita?
Con la disponibilità sempre maggiore di nuovi computer, ma anche (e soprattutto) di VPS sempre più
potenti e meno costose (così come anche le linee di connessione), chiunque può effettuare attacchi
massicci.
Inoltre, gli attacchi di basso livello sono alla portata di tutti: basterebbe fare una piccola ricerca su
qualunque motore di ricerca e restare meravigliati dalle varianti dei software che permettono di fare
ciò, il tutto ovviamente senza avere un briciolo di conoscenza sul tema.
2.2.2) Sistemi vulnerabili ai DoS
Come già accennato, la tipologia più comune di attacco DoS consiste nell’inondare le risorse di un
server con tante richieste. Questo tipo di attacco sovraccarica la coda di gestione delle risorse di un
14
server, o nei casi più blandi, rallenta i tempi di risposta in modo significativo.
Per adesso però ci siamo limitati a parlare di Server, ergo si suppone che solo questi siano vulnerabili
agli attacchi di DoS.
In realtà è possibile attaccare un computer specifico, una porta o un servizio, un’intera rete o il
componente del sistema; può anche avere come obiettivi sistemi di comunicazione fra persone
(telefoni, portatili, allarmi, fax, stampanti etc...)
2.2.3) Conseguenze di un attacco DoS
Come ovviamente avrete intuito, lo scopo di tale attacco è quello di non permettere più ad un
dispositivo di inviare e/o ricevere informazioni all’interno di una rete (locale o internet).
Di per sè l’attacco non causa alcun danno permanente all’interno della struttura del sistema vittima:
tuttavia le conseguenze causate da tale attacco possono ripercuotersi nelle altre aree dei gestori del
servizio.
Un esempio avvenuto recentemente è quello dell’attacco subito ai danni di Mt.Gox, cambio valute di
livello internazionale, famoso soprattutto per la vendita e l’acquisto di bitcoin, la più utilizzata valuta
elettronica.
Dopo un attacco di ben 12 ore la valuta perde il 40% del suo valore reale.
Ciò nonostante, i server una volta riavviati erano rimasti così come erano stati lasciati.
Ok, forse intasati dai log di accesso, tuttavia i database, le password e i dati sensibili non erano stati
compromessi. Nessun danno strumentale ma un danno enorme a livello economico.
Quindi se la vostra domanda è: “si può distruggere un computer, un server o qualunque altra cosa
connessa a Internet con un DoS?”, la risposta è no, ma ciò non significa che il disservizio non crei
danni.
2.3) Tipologie di attacchi DoS
Nel corso degli anni sono state ideate nuove tipologie di attacco che sfruttano la teoria del Denial of
Service.
15
Alcune di queste sono state già risolte poichè facevano affidamento a tecnologie superate, altre
invece sono nate grazie all’introduzione di nuove tecnologie.
2.3.1) Categorie di DoS
Come già accennato, il DoS consiste nell’inondare un target di richieste.
Tuttavia le richieste non sono limitate ad una sola tipologia, ma possono far parte di migliaia di
varianti che dipendono ovviamente dal tipo di target che si tenta di attaccare.
Diamo per scontato che il computer target sia di vostra proprietà e pertanto ne conosciate già gli
strumenti installati.
Possiamo allora suddividere i tipi di attacchi in 3 grandi categorie:
●
Attacco Volumetrico: tipologia riferita ad attacchi che consistono nell’inondare il target con
enormi quantità di traffico. L’obiettivo finale dell’attacker è quello di saturare la banda del
server.
Si misura in bits per secondo (Bps).
●
Attacco a Protocollo: include attacchi SYN, pacchetti frammentati, Ping of Death, Smurf DDoS
e altro. Questi tipi di attacchi consumano le risorse di sistema e tutti quei dispositivi che
fanno da tramite tra Client e Server, come ad esempio i routers.
Si misura in pacchetti per secondo.
●
Attacco a Livello Applicazione: include Slowloris e tutti gli 0day che colpiscono software e
sistemi operativi installati. Sono i più pericolosi (e i più complessi) poichè non vengono
riconosciuti da firewall o strumenti di difesa.
Si misura in richieste al secondo.
Gli attacchi a Protocollo viaggiano nel Livello 4 della pila ISO/OSI mentre gli attacchi a
livello Applicazione agiscono al livello 7.
La differenza consiste nel fatto che mentre nel Livello 4 (Transport Level) vi è una
saturazione di servizio mediante grosse quantità di dati (e quindi più facili da
identificare), nel Livello 7 (Application Level) per arrivare alla saturazione del servizio
bastano poche quantità di dati in ingresso, che non sono riconoscibili poichè
considerate legittime dal sistema.
16
Insomma, quante varianti esistono? Infinite.
Affinchè il nostro documento (e il lettore) non vadano a finire in uno stato confusionale,
approfondiremo solo alcune di queste tecniche, tralasciando quelle obsolete e oramai inefficaci.
2.3.2) Attacchi DoS Volumetrici/Protocollo
L’incubo di ogni hoster (e di ogni webmaster!), l’attacco DoS di tipo volumetrico ha lo scopo di
saturare la banda disponibile di un host.
Come già saprete i siti web e i server in generale vengono affittati mensilmente; i loro prezzi
vengono ovviamente scelti in base alle loro caratteristiche: CPU, RAM, Spazio etc...
Un’altra caratteristica però importante (e spesso nascosta dallo stesso venditore) durante la scelta di
un server è la banda. Questo numero ndica la quantità di dati (in Gb o più) che un server può ricevere
o trasmettere in un determinato periodo (solitamente un mese).
Assieme al traffico bisognerebbe prendere in considerazione anche la velocità di traffico, ossia la
velocità di trasferimento dei dati (in Mbit/s).
Ora, sappiamo che l’attacco DoS di tipo volumetrico punta a saturare la banda, quindi la quantità di
dati che un server può erogare.
Se per esempio il limite di banda mensile di un server viene superato possono accadere due
situazioni:
1. alcune società a pagamento, e tutte quelle gratuite, bloccano il server.
2. le altre società limitano la velocità di traffico.
Nella prima situazione capirete che è un grandissimo disagio per il webmaster non poter accedere al
suo server fino al mese successivo.
In questo caso le società che erogano il servizio (chi vi affitta il server insomma) fanno presssioni
affinchè voi acquistiate pacchetti di categoria superiore (passando da un hosting a una vps o
addirittura a un dedicato).
Nella seconda situazione solitamente vi è un rincaro dei prezzi di banda. Solitamente i limiti sono
abbastanza alti, e le società più serie prendono a carico una notifica di attacco (vedi Hetzner), ma
molti altri preferiscono che ve la sbrighiate da soli.
17
La scelta delle tipologie di attacco verrà basata sul seguente diagramma a torta, prodotto da
Kaspersky Lab, che si riferisce al secondo quadrimestre degli attacchi DoS/DDoS dell’anno 2011.
Diagramma di Securelist.com
Come è possibile notare, la fetta maggiore è detenuta dagli attacchi HTTP (88.9%); le richieste
effettuate al server sono per un breve periodo, il che non permette di filtrare le richieste “cattive” da
quelle “buone”.
In seconda posizione troviamo il SYN Flood (5,4%). Durante questo attacco vengono inviati molteplici
pacchetti al web server al fine di effettuare una connessione TCP. Nell’attacco, questo pacchetti
vengono manipolati, in modo da lasciare semi-aperta la connessione. Poichè un server può manetere
un numero limitato di connessioni nello stesso momento, e una botnet (vedremo poi cos’è) può
generarne moltissime in breve tempo, il server sarà costretto a bloccare le connessioni dall’esterno.
In ultimo posto troviamo i DDoS su DNS (0,2%). Pochi, ma pericolosi.
Il DNS ha il compito di convertire i domini in indirizzi IP, quindi se cade giù un server DNS, tutti i
computer connessi al server DNS non potranno più navigare. Gran figata eh?
18
2.3.2) DDoS e DrDoS
Fino ad ora abbiamo spiegato la teoria dell’attacco ma ancora non abbiamo accennato all’evoluzione
degli attacker con tale tecnica.
Se da una parte si lavora notte e giorno per creare nuovi metodi sempre più efficaci per creare il
disservizio verso una macchina, dall’altra si cercano i modi per ampliare il numero di attacker ad una
macchina vittima.
Ipotesi
Un computer attacker manda un attacco ad un computer vittima di 500.000 pacchetti. Il server
potrebbe mantenere nonostante tutto i servizi attivi, in quanto riuscirebbe a vagliarli tutti.
Se i computer attacker fossero 10, l’attacco si moltiplicherebbe con la semplice funzione matematica:
10 x 500.000 = 5.000.000
E’ probabile che la macchina server non riesca a vagliare tutti questi servizi e quindi sia costretto a
bloccare ogni uscita.
La domanda è: dove diavolo si trovano 10 macchine capaci di attaccare per 500.000 pacchetti?
2.3.2.1) Distributed Denial of Service
L’attacker ha bisogno di 10 dispositivi che attacchino ma ciò significherebbe avere 10 computer
dislocati in 10 reti diverse.
Che si può fare?
Si possono infettare 10 computer, ad esempio.
Il controllo remoto di una macchina ci permetterebbe di inviare ciò che vogliamo a chi vogliamo.
Pacchetti, ad esempio...
I target possono essere computer client ma gli obiettivi più succulenti sono server, VPS e tutte quelle
macchine in grado di generare tanta potenza di calcolo e richieste via internet senza troppi intoppi.
Una volta ottenuto il controllo delle macchine infette (che si identificano come zombie) si potrà
attuare l’attacco, da qui il nome di Distributed Denial of Service.
2.3.2.2) Distributed Reflected Denial of Service
Un attacco DrDoS utilizza la forza di calcolo di altri server per buttarne giù uno. In che modo?
19
Immaginate di fare un ordine di 100 pizze a nome di Guido la Vespa (nome a caso). Avete già capito.
Questo è il DrDoS, nè più nè meno.
Ci sono vari servizi sfruttati per lanciare DrDoS che vengono scelti in base a due fattori essenziali:
fattore di moltiplicazione (ad una domanda piccola i servizi possono rispondere con risposte più o
meno grandi) numero di host sfruttabili/vulnerabili.
Ad oggi il DrDoS più diffuso è quello che sfrutta il servizio DNS grazie all'ampissima disponibilità di
host vulnerabili e all'altissimo fattore di moltiplicazione offerto da tale servizio
Altro servizio spesso usato è chargen, tipico di macchine windows e alcune stampanti di rete.
il vantaggio dei DrDoS rispetto ad un DDoS tradizionale è che anche a fronte di una scarsa banda
disponibile permette di generare un volume di traffico molto alto (addirittura fino al 100x).
2.4) UDP/ICMP Flood
UDP è un protocollo di tipo connectionless, una pratica che rende l’operazione di comunicazione tra
due dispositivi molto veloce e che non richiede una connessione costante tra due elementi.
Ogni pacchetto UDP è quindi ipoteticamente un’informazione plausibile, ed è da lì che l’attacco ha
inizio.
L’attacco UDP Flood è un attacco di tipo protocollo che può iniziare con un gran
numero di richieste verso un host remoto e si verificheranno i seguenti processi:
- Controllo della presenza del servizio richiesto (tramite richiesta UDP)
- Verifica che il servizio non esiste
- Invio del messaggio di stato ICMP Destination Unreachable (Destinazione non
disponibile)
Il server, costretto a dover vagliare le richieste UDP e ad elaborare tantissime risposte
ICMP si intaserà con conseguente negazione del servizio in uscita.
Variante di UDP/ICMP Flood con IP Spoofing
L’ultimo passaggio, che prevede la risposta in ICMP, ovviamente arriverà al mittente che ha inviato le
richieste ICMP (cosa non buona, almeno per l’attacker!).
20
La variante di questo attacco prevede lo spoofing dell’IP.
Ok, fermi tutti: l’IP sappiamo già cos’è ma... cos’è lo spoofing?
E’ quella pratica che prevede la modifica della richesta con informazioni falsate.
Volete un esempio? Detto fatto.
Immaginate l’UDP Flooding come l’inviare centinaia di cartoline tutte insieme allo stesso
destinatario. Sapete già che il DoS prevede il riempimento della casella postale fino a che nessuna
lettera verrà recepita. Una lettera per essere consegnata deve avere due campi: Mittente e
Destinatario; lo stesso vale per un pacchetto UDP. Ma voi sareste così ingenui da scrivere il vostro
nome e cognome su tutte le cartoline? Ovviamente farete una firma falsa.
Analogalmente, in informatica farete lo spoofing del mittente (dell’indirizzo IP quindi) e lo
nasconderete al destinatario; da qui l’espressione IP Spoofing.
2.4.1) Simulare un attacco UDP/ICMP Flood
Per simulare un attacco UDP/ICMP Flood faremo affidamento a UDP Unicorn, un software sviluppato
per Win32 che utilizza le Winsock per creare socket UDP e floodare il target.
21
L’utilizzo è tanto semplice quanto scontato: basta indicare target e porta (random o scelta), la
grandezza dei pacchetti (gestibile anche qui in maniera random), il delay (il tempo tra un pacchetto e
l’altro) e il numero di socket inviati per thread.
Come vedete, UDP Unicorn non prevede lo spoofing dell’IP (pratica che è inutile ai fini di un
semplice testing) pertanto l’utilizzo del software è consigliato solo ed esclusivamente sulle macchine
di vostra proprietà (o dove ne avete il permesso). In caso contrario, sarete esposti a facili controlli dai
tecnici del server.
Dulcis in fundo, UDP Unicorn è un software opensource: se avete le conoscenze di programmazione
giuste potrete capirne il funzionamento dal codice sorgente. Inoltre ha una funzione di
multithreading che permette di sfruttare più thread del processore e quindi viaggiare più
velocemente.
2.4.2) Mitigare un attacco UDP/ICMP Flood
Come per tutti gli attacchi ci sono vari modi per mitigare.
Generalmente le strade sono due: o si possiede un importante know how sia lato applicativo che lato
22
sistemistico e si fa mitigazione direttamente prima che arrivi al servizio; se attacco è troppo
“pesante” o non si hanno le competenze per sviluppare in autonomia una struttura filtrante ci si
appoggia ad appliance hardware pronte.
In entrambi i casi filtrare UDP flood è molto banale quando si erogano servizi TCP (http, games etc...)
meno banale invece quando si erogano servizi UDP.
Generalmente la tattica usata per filtrare flood UDP è fingerprinting prima e, una volta individuato il
pattern usato, effettuare ratelimiting.
Non è chiaro? Andiamo con ordine.
Per fingerpriting intendiamo la pratica di riconoscere quali sono le fonti che stanno
effettuando l’attacco. Solitamente è possibile analizzarli direttamente nei log di
sistema; potremmo ritrovarci con una o più fonti d’attacco, in quel caso, è bene
stilare una lista degli ip attacker.
Il pattern è lo schema utilizzato dall’attacker per effettuare l’attacco. Un pattern può
essere composto da valori fissi o randomizzati: nel primo caso il riconoscimento
dell’attacco è semplice, in quanto se abbiamo tot. pacchetti inviati di grandezza fissa
riusciremo in un batter d’occhio a bloccarli. Diverso è invece il discorso dei random in
quanto si potrebbero avere delle difficoltà nel riconoscere l’attacker.
Per ratelimiting intendiamo la pratica di filtraggio delle connessioni al nostro
client/server che verranno applicate agli attacker riconosciuti durante la fase di
fingerprinting.
Gran parte degli UDP flood che vengono lanciati attualmente sono facilmente
identificabili e filtrabili, oltre al sempreverde DNS reflected (variante dell’attacco)
anche quello facilmente bloccabile senza aver bisogno di fare ratelimiting.
23
2.5) SYN Flood
Eccoci allora al SYN Flood, uno degli attacchi di tipo protocollo che hanno fatto la storia del web.
Quando si erogano servizi TCP (http e games per esempio) SYN flood è ancora un grosso pericolo in
assenza di protezioni.
Il problema maggiore dei SYN flood è generato dai SYN COOKIES che molti amministratori di sistema
attivano credendo che facciano miracoli mentre in realtà hanno effetto opposto facendo diventare la
macchina attaccata a sua volta attaccante (ma lo vedremo più avanti).
Per spiegarne il funzionamento dobbiamo prima conoscere il funzionamento di una connessione
TCP.
Una parte del collegamento TCP è composta da 4 passaggi fondamentali:
1) Il client richiede una connessione ad un server; per farlo, invia un messaggio SYN (sync o
synchronize)
2) Il server risponde a sua volta con un messaggio SYN-ACK
3) Il client, ricevuta la risposta, risponderà a sua volta con un messaggio ACK
4) Il client e il server possono comunicare
Tale processo si chiama TCP three-way handshake ed è alla base di ogni connessione
che utilizza il protocollo TCP/IP.
Come si applica il SYN Flood?
In questa tipologia di attacco, il client invia il SYN, il server risponde con SYN-ACK e il client non
invierà l’ACK, il quale chiuderebbe l’handshake e quindi darebbe inizio alla comunicazione.
Che succede quando non viene inviato l’ACK?
Il server mantiene attiva la connessione per un lasso di tempo e, solo dopo un tempo ragionevole,
deciderà di chiudere lo scambio dei messaggi.
Alcuni potrebbero pensare: scusa, ma se invio il pacchetto SYN il server mi rimanda il SYN-ACK e
quindi io sono costretto a bloccare gli ACK in uscita dal mio pc?
Vero, ma essendo una cosa altamente improbabile, perchè non spoofare l’indirizzo IP? (vedere
variante di attacchi UDP con spoofing ip).
24
2.5.1) Simulare un attacco SYN Flood
L’attacco si può fare in migliaia di modi (SynGUI per Windows è un esempio), quello che vedremo noi
è l’uso di un tool per i sistemi GNU/Linux chiamato hping3.
Diamo per ipotesi il seguente comando:
sudo hping3 -i u1 -S -p 22 192.168.2.1
Hping è uno di quei programmi che permettono una completa gestione delle connessioni in entrata
ed in uscita di un sistema operativo. A differenza di altri OS, siamo in grado di manovrare le
connessioni con i nostri parametri e, ovviamente, le nostre intenzioni.
Studiamoci questo comando.
sudo è il comando necessario per lanciare hping3 con i permessi di root, questo perchè hping3 ha
necessità di creare pacchetti raw (cosa fattibile solo con i privilegi più alti).
hping3 è ovviamente il nome del nostro tool.
-i u1 indica l’intervallo di tempo in millisecondi tra i pacchetti (in questo caso 1 millisecondo)
-p 22 indica la porta dove destinare l’attacco (ipotizziamo sulla 22, quindi sul servizio di default SSH).
192.168.2.1 è l’ip destinatario che riceverà l’attacco.
Esistono poi dei parametri come ad esempio -a che permettono lo spoofing dell’IP e la
randomizzazione di tutto quello che si vuole (facendo figurare l’attacco come se arrivasse da altre
infrastrutture).
Consigliamo lo studio del manuale avanzato del software alla pagina ufficiale
hping.org/manpage.html .
2.5.2) Mitigare un attacco SYN Flood
Anche in questo caso se si parla di rate bassi (sotto i 500mila pacchetti al secondo) basta fare un po' di
fingerprinting + relativo ratelimiting.
Generalmente sono tutti spoofed e quindi il fingerprinting risulta agevole e permette di indivuare
caratteristiche molto specifiche ed esatte generando pochi falsi positivi.
Se invece si parla di rate più alti (o non si hanno le competenze sistemistiche per gestire filtraggio
25
direttamente sulla macchina) ci si affida ad appliance hardware a parte che fanno da SYN proxy.
Prima si diceva che i SYN COOKIES potessero essere un’arma a doppio taglio, eppure sono stati
concepiti per essere un deterrente per questo attacco. Perchè?
Come dice il nostro esperto Marco Padovan: “I Syn Flood sono sempre spoofed e se tu usi i cookies
mandi syn ad ognuno degli ip spoofed, quindi le vittime potrebbero segnalarti al tuo operatore e
sospenderti il servizio”. Claro?
2.6) HTTP Flood
Benvenuti all’HTTP Flood, il denial of service creato appositamente per i servizi HTTP!
Questa tipologia di attacco va a complicare la vita al servizio più famoso e utilizzato del web,
sfruttandone la bontà di calcolo durante le richieste GET/POST e intasandone quindi la coda dei
processi vagliabili.
La teoria: il client HTTP (chiamato anche Web Browser) fa una richiesta al server HTTP (il Web Server)
e gli invia una richiesta che può essere di diversi tipi, i più importanti: GET e POST.
Una richiesta GET può essere riassunta con un link del genere:
http://sito.it/cerca.php?keyword=hacking
La parte in grassetto è un parametro che può essere inviato alla pagina vittima, la quale,
probabilmente la utilizzerà per eseguire un processo interno (ad esempio cercare nel proprio
database tutti i contenuti con la parola chiave “hacking”).
Se da una parte, e cioè dal client HTTP, il browser dovrà inviare una semplice richiesta di un url,
dall’altra parte, e cioè dal Web Server, il sistema dovrà effettuare calcoli interni per vagliare la
richiesta. Immaginate di chiedere a un server: “Mi cerchi 1.000.000 di parole chiave dentro il tuo
database?” - il server “Ma certo! Aspetta solo un momento …”
Ok, penso di aver detto tutto.
L’altro tipo di richiesta, denominato POST, fa affidamento allo stesso principio di richiesta con la sola
differenza che i dati non passano per la querystring (in gergo umano, l’indirizzo web).
Quindi se ipotizziamo il seguente url:
http://sito.it/cerca.php
E’ possibile inviare parametri arbitrari alla pagina senza dover inviarne i dati in chiaro ma all’interno
dell’intestazione dell’header.
26
Ovviamente, è possibile fare attacchi di tipo HTTP senza dover specificare parametri o quant’altro, in
quanto il Web Server già di suo deve vagliare una richiesta interna di recupero di una pagina web,
eseguirne il calcolo e i processi e rimandarli al mittente.
2.6.1) Simulare un attacco HTTP Flood
Per simulare un attacco HTTP Flood utilizzeremo il rinomato B4ckself, di cui l’autore ci ha fornito i
codici sorgenti (in parte) da poter esaminare e commentare assieme.
Il B4ckself è stato scritto in Python ed è presente alla pagina di download da Inforge.net, pertanto per
utilizzarlo occorrerà avere installato nel proprio terminale un interprete Python.
Sorvolando la parte sul Come si utilizza (che potete comunque trovare nella pagina di download)
studiamone il funzionamento interno.
Il software prevede l’inserimento di un parametro arbitrario da parte nostra (un url) e il numero di
27
threads da inviare al sito “vittima”.
Tale processo è riassunto in questo codice:
url = raw_input("Enter url to DoS (enter nothing to exit): ")
if url == "":
exit(1)
try:
urllib.urlopen(url)
except IOError:
print("Could not open url specified.")
Una volta ottenuti i parametri corretti andremo ad utilizzare la funzione che è il cuore del B4ckdoor:
def run(self):
global COMMAND
global CANCEL
global LOCK
LOCK.acquire()
print("Starting thread #{0}".format(self.num))
LOCK.release()
while COMMAND != CANCEL:
try:
urllib.urlopen(self.url)
except Exception:
pass
LOCK.acquire()
print("Exiting thread #{0}".format(self.num))
LOCK.release()
2.6.2) Mitigare un attacco HTTP Flood
Generalmente si può optare per un aumento del numero massimo di client web collegabili al server
web e limitare quindi il numero di connessioni che un solo IP può fare, imponendo restrizioni alla
velocità di trasferimento minimo di connessione e limitare il periodo di tempo di un client che può
rimanere in contatto.
28
In Apache esistono alcuni moduli che fanno tutto questo in automatico e sono:
●
mod_limitipconn
●
mod_qos
●
mod_evasive
●
mod_security
●
mod_noloris (dedicato a slowris)
●
mod_antiloris (anche questo solo per slowris)
2.7) Slowris
Slowris è uno di quei tipi di attacchi nati come PoC (proof of concept) e si evolve come un metodo
d’attacco denial of service.
Lo Slowris unisce la potenza degli attacchi a protocollo con quelli a livelli applicazione, creando
appunto una nuova variante di attacchi DoS.
Come funziona:
Slowris apre delle connessioni inviando richieste HTTP parziali e continua ad inviare le intestazioni
successive a intervalli regolari per mantenere aperta la connessione col web server.
L’attacco si potrà dichiarare concluso quando il server non avrà più slot per permettere di far
fuoriuscire tutte le richieste.
Slowris inoltre introduce una caratteristica di stealthing che permette all’attacker di inviare differenti
host header contemporaneamente: stando a quanto si evince dalla descrizione del software in
inglese, tale operazione non permette al virtual host di scrivere nei file log, così da garantire il
completo anonimato in fase di attacco.
Quando però una delle richieste scadrà, il server andrà a scrivere nei log il risultato dell’operazione
con stato di errore 400 (e relative fonti della richiesta).
Questo tipo di attacco non può essere definito TCP DoS in quanto non esegue una completa
connessione TCP ma esegue solo una connessione parziale tramite richiesta HTTP.
E’ l’equivalente di un attacco SYN Flood ma con il protocollo HTTP.
Slowris non è neanche un flooder HTTP in metodo GET in quanto fa solo richieste regolari HTTP per
29
lungo tempo.
Slowris è stato testato con successo sulle seguenti macchine:
●
Apache 1.x
●
Apache 2.x (la maggior parte dei web server nel mondo!)
●
dhttpd
●
GoAhead WebServer
mentre non sono affetti i seguenti web server:
●
IIS 6.0
●
IIS 7.0
●
lighttpd
●
Squid
●
nginx
●
Cherokee
●
Netscaler
●
Cisco CSS
Come specifica il sito del “produttore”, questa lista è solo indicativa e comunque rispecchia solo test
effettuati su webserver di prova.
Slowris potrebbe per via ipotetica essere modificato in qualunque modo si voglia per amplificarne
l’attacco e mandare in tilt diversi tipi di webserver e infrastrutture.
2.7.1) Simulare un attacco Slowris
Eccoci qui a spiegare brevemente il funzionamento di Slowris.
Una volta scaricato il tool dal sito ufficiale (e aver scaricato anche il compilatore perl, con cui Slowris è
stato costruito*) lanceremo il seguente comando:
perl slowloris.pl -dns example.com
* per una conoscenza approfondita sul tool è possibile lanciare il comando perldoc slowloris.pl
30
Il tool a sua volta risponderà con qualcosa del genere:
*Slowris funziona solo se sono installati anche i moduli IO::Socket::INET, IO::Socket:SSL e GetOpt::Long.
Inoltre, Slowris lavorerà meglio se è attivo il multithreading.
2.7.2) Mitigare un attacco Slowris
Attualmente non esistono configurazioni attendibili per i server web colpiti da Slowris, tuttavia ci
sono metodi per mitigare in parte o ridurre comunque l’impatto di un tale attacco.
Per Apache gli sviluppatori raccomandano inoltre il mod_reqtimeout come soluzione ufficiale per
ridurre il tempo di connessione ai client.
Altri metodi di mitigazione prevedono la costituzione di reverse proxy, firewalls, load balancers,
oppure (soluzione drastica) migrare a Web Server che non sono affetti da questo attacco, come ad
esempio lighttpd e nginx.
31
Il resto delle regole da adottare sono le stesse presentate nel capitolo “Mitigare un attacco HTTP
Flood”.
3) Considerazioni
La pratica del Denial of Service è una lotta che va avanti da decenni. Oggi il peso della bilancia è a
favore degli attacker e sono pochi i servizi che riescono a contrastare questo fenomeno ma forse
domani qualcosa cambierà.
Noi siamo white hats e difendiamo il web libero da ogni crimine.
Con questo libro speriamo che il fenomeno del Denial of Service venga a galla e che diventi un
argomento di cui parlare in futuro e non limitarlo ai soli “bulli del web”, spesso ragazzini adolescenti
che sfogano le proprie frustrazioni contro i più deboli.
Crediamo fermamente che la conoscenza sia un valore importante per la comunità e la condividiamo
per il benessere collettivo, non per il piacere e il gioco di pochi.
Lavoreremo sodo per contribuire ogni giorno a combattere per questi ideali, fuori da ogni
pregiudizio, perchè l’hacking non è un crimine. E’ conoscenza, ma soprattutto, è divertimento.
Stefano murdercode Novelli
32

Scarica Adesso 1.4 MB

Transcript

Documenti analoghi

1/1 Come posso scoprire un host che mette in atto un

Massimiliano Sbaraglia networking engineer UDP flood è un tipo di

Che Cos`è un attaCCo wateRIng hole

Scarica il documento completo

1 - Würth

Scheda tecnica DS 99.06

difesa nel jeet kune do - Tui

Cyber-war: il grande campo di battaglia digitale

serie 2n pneus serie 2n soft

MGS9/1A

I percorsi di attacco - Gabriele D`Angelo. Assistant Professor

Good Practice for Delivering Flood-Related Information