Archivi tag: denial of service

Attacchi DoS e DDoS

Gli attacchi DoS (Denial of Service) e DDoS (Distribuited Denial of Service) rappresentano uno dei fenomeni più preoccupanti degli ultimi anni. Infatti, non è raro incappare in siti e portali di vario genere i cui tempi di risposta risultano mostruosamente alti, causando diversi problemi alla navigazione degli utenti legittimi e, in alcuni casi, l’irraggiungibilità del sito stesso.

Le motivazioni che stanno dietro a questa tipologia di attacco sono le più disparate:

1) motivazioni di tipo economico. Un’azienda potrebbe decidere di “investire” del denaro per cercare di arrecare danno al business di una società rivale, che magari opera nello stesso settore, soprattutto se la maggior parte dei proventi di quest’ultima derivano da un portale di e-commerce;

2) motivazioni di tipo logistico/strategico. Si potrebbe, ad esempio, costringere la comunità di un forum a “migrare” su un altro portale, promettendo in cambio la stabilità dei servizi offerti ed il ripristino della raggiungibilità del sito 24/7;

3) motivazioni di tipo politico/religioso. E’ sempre più frequente assistere ad attacchi di negazione del servizio diretti verso portali in cui viene manifestato un determinato orientamento politico/religioso.

Occorre precisare, inoltre, che con l’aumento della capacità di calcolo degli elaboratori e con l’incremento dell’ampiezza banda offerta dai vari ISP, gli attacchi DoS, ovvero quelli provenienti da un singolo host, stanno diventando obsoleti e del tutto inefficaci. Viceversa , gli attacchi di negazione del servizio distribuiti (DDoS) continuano a rappresentare una serie minaccia  nell’ambito dell’IT security, poichè riescono a saturare in pochissimo tempo le risorse dell’host vittima, causandone l’irraggiungibilità.

Classificazione degli attacchi e tecniche

Esistono diversi metodi per classificare gli attacchi DDoS ed uno di questi si basa proprio sul tipo di risorsa che l’attacco stesso tenta di consumare. Tale risorsa può essere rappresentata dalla CPU, dalla RAM o dalla memoria di massa su cui è installato il sistema operativo, oppure dalla capacità di tx/rx dell’host vittima. In quest’ultimo caso, una tecnica ampiamente utilizzata si basa proprio sulla struttura del protocollo TCP/IP e prende il nome di SYN-flood. Per capire bene come un attacco SYN flood viene perpetrato occorre fare un esempio:

Supponiamo che l’utente legittimo A voglia collegarsi al portale Web B.

1) Per prima cosa l’host A invia un pacchetto TCP/IP di tipo SYN, ovvero richiede la sincronizzazzione con il portale stesso, la quale si basa essenzialmente sullo scambio di un numero di sequenza iniziale (ISN – Initial Sequence Number). Il numero di sequenza iniziale è fondamentale, in quanto tutti gli altri pacchetti scambiati tra i due host in questione verranno identificati mediante un numero di sequenza incrementale, successivo all’ISN. Ma a cosa serve effettivamente il numero di sequenza? Serve semplicemente a ricostruire correttamente le informazioni ricevute, nel caso in cui esse non siano giunte a destinazione nel giusto ordine (ecco perchè il protocollo TCP è definito “affidabile”);

2) una volta che il portale Web, ovvero B, riceve il pacchetto SYN, risponde all’host A inviando un pacchetto SYN/ACK (leggasi riscontro di sincronizzazione);

3) infine, dopo aver ricevuto il SYN/ACK, l’host A invia al portale Web B un ulteriore pacchetto di riscontro, detto ACK, completando così la procedura di connessione (ecco perchè il protocollo TCP si dice “basato su connessione”).

L’insieme degli step 1), 2) e 3) rappresenta il cosiddetto three-way handshake, necessario affinchè una connessione TCP venga instaurata.

Supponiamo ora che un eventuale attaccante, ovvero C, voglia scagliare un DDoS verso il portale B. Esso per prima cosa forgerà dei pacchetti TCP/IP di tipo SYN, falsificando l’indirizzo IP mittente, magari inserendone uno inesistente. Il server Web risponderà ai pacchetti SYN inviando dei SYN/ACK verso l’IP inesistente, lasciando la connessione in buffer fino alla ricezione dell’ACK.

Ovviamente, tale ACK non verrà mai ricevuto, proprio perchè l’indirizzo IP a cui è stato inviato il SYN/ACK è inesistente (parliamo allora di connessioni mezze-aperte, dette anche half-open). Quindi, se il numero di pacchetti SYN inviati all’host vittima è abbastanza elevato e se i tempi di timeout delle connessioni TCP half-open sono troppo alti (per un errata configurazione del server), il portale Web si ritroverà con il buffer completamente saturo, e non sarà più in grado di accettare connessioni basate sul protocollo TCP, anche se legittime.

Recentemente, sono state sviluppate altre tecniche che puntano a saturare la capacità di tx/rx degli host vittima. Tra queste vi sono le connessioni half-closed e gli attacchi scan.

Nel primo caso, l’attaccante, ovvero C, crea delle connessioni legittime e di breve durata con il portale Web B. Successivamente, cerca di abbattere tali connessioni inviando dei pacchetti FIN all’host vittima. Quest’ultimo invierà all’attaccante un pacchetto FIN/ACK e successivamente rimarrà in attesa dell’ACK finale che causerà la disconnessione vera e propria. Se però, come nel caso delle connessioni half-open, l’ultimo ACK tarda ad arrivare ed il numero di pacchetti FIN è piuttosto elevato, il buffer tenderà ad esurirsi abbastanza velocemente causando disservizio.

Nel caso degli attacchi scan, invece, la negazione del servizio viene realizzata semplicemente usando i cosiddetti port-scan. Nella fattispecie, i port-scan vengono adoperati durante la fase preliminare di un attacco, detta footprinting o ricognizione, grazie alla quale è possibile identificare i tipi di servizi presenti sull’host vittima. Ogni servizio è in ascolto su una determinata porta ed in base a quest’ultima è possibile farsi un’idea di quali siano effettivamente i servizi pubblicati sul server che si sta scansionando. Ora, qui è necessario fare alcune precisazioni:

1) Esistono le cosiddette well-known port, che vanno dalla 1 alla 1023. Esse sono riservate a determinati servizi, come POP3 (110), SMTP (25), Telnet (23), FTP (20-21), SSH (22) e così via. Non è raro, però, che gli amministratori di sistema utilizzino delle porte non standard per la pubblicazione dei servizi (ad esempio mettendo in ascolto il server SSH su una porta > 1023 anzichè sulla 22). In questo modo si evita che script di scansione automatizzati individuino servizi in ascolto su porte standard e tentino automaticamente il login, perpetrando un attacco bruteforce basato su dizionario.

2) Alla luce di quanto appena detto, non è raro che i port-scan producano come risultato dei falsi positivi.

Ma vediamo adesso come funzionano i cosiddetti scan-attack. Quando viene effettuata una ricognizione mediante degli appositi tool (ad esempio nmap), vengono “simulate” delle connessioni sulle 1023 well-known port dell’host vittima, riuscendo in questo modo ad identificare su quali esso risulta effettivamente in ascolto. Ovviamente tale procedura genera del traffico e se i tentativi di scansione si ripetono ad intervalli di tempo brevissimi e se provengono da un numero abbastanza elevato di host (magari dotati di un’ampiezza di banda non indifferente), essi causeranno inevitabilmente un riempimento del buffer della vittima e quindi una probabile negazione del servizio. Inoltre, per aumentare ulteriormente la frequenza degli scan e quindi la mole complessiva degli stessi, può essere utilizzanto il protocollo UDP (mediente la flag -sU di nmap), il quale, a differenza del protocollo TCP, non prevede l’instaurazione di una connessione vera e propria, con tempi di tx/rx estremamente ridotti e quindi con maggiore probabilità di saturare il buffer.

Un altro criterio usato per la classificazione degli attacchi DDoS tiene conto della capacità dell’attaccante di “reclutare” nuove macchine dalle quali veicolare l’attacco vero e proprio. In particolare, parliamo di attacco DDoS diretto quando è proprio l’attaccante ad installare su alcune macchine vittima un software sviluppato ad hoc (solitamente un worm) che gli consentirà di ottenerne il controllo da remoto. Tali macchine diverranno quindi “zombie” ed andranno a far parte di un insieme di elaboratori infetti, chiamato botnet (o dosnet).

Sovente gli attacchi DDoS coinvolgono due livelli di macchine zombie: gli zombie master e gli zombie slave, dove i primi coordinano l’operato dei secondi. L’uso di due livelli di zombie rende più difficile l’identificazione della vera sorgente dell’attacco e fornisce una rete di host attaccanti più flessibile.

dos_figure_4.gif

Un attacco DDoS tramite riflettori (DRDoS) aggiunge un ulteriore livello di macchine, che andranno ad aggiungersi agli zombie master e slave.

drdos.gif

 

In questo caso, però, gli elaboratori che fungono da riflettori non sono delle macchine infette. Semplicemente, gli zombie slave, veicolati dagli zombie master, generano delle richieste contenenti come IP sorgente quello del portale Web vittima (B). Tali richieste verranno indirizzate verso i riflettori che risponderanno direttamente alla macchina bersaglio. Un attacco di questo tipo è sicuramente il più subdolo ed allo stesso tempo il più dannoso: subdolo perchè l’uso di macchine non infette come front-end dell’attacco rende ancora più difficile l’individuazione del vero attaccante, dannoso poichè a seconda del numero di macchine riflettori coinvolte, la mole di traffico diretta verso l’host vittima potrebbe essere di una portata tale da causare una negazione del servizio pressocchè immediata.

Costruzione di una rete di attacco

Durante la prima fase di un attacco DDoS, l’aggressore infetterà molte macchine tramite software zombie, in modo tale da ottenerne il controllo ed utilizzarle successivamente come teste di ponte durante l’attacco vero e proprio. Affinchè tale operazione vada a buon fine è necessario che vengano rispettate le seguenti condizioni:

1) il software che viene usato per infettare le macchine deve essere in grado di girare su un elevato numero di elaboratori, di nascondere la sua esistenza, di comunicare con l’attaccante oppure di essere dotato di un qualche tipo di meccanismo a innesco temporale, oltre, ovviamente, ad essere capace di veicolare l’attacco verso il bersaglio;

2) il software deve basarsi su una vulnerabilità molto diffusa ma che allo stesso tempo è stata trascurata da molti utenti/amministratori di sistema;

Inoltre, gli host vulnerabili vengono individuati mediante un’operazione di scansione, la quale può avere le seguenti caratteristiche:

1) potrebbe essere casuale, ovvero l’attaccante esamina degli indirizzi IP random, usando di volta in volta un seme differente;

2) potrebbe essere basata su una hit-list, ovvero su una lista di macchine potenzialmente vulnerabili;

3) potrebbe essere topologica, ovvero l’attaccante utilizza le informazioni contenute su una macchina già infetta per trovare altri host vulnerabili.

Nei prossimi giorni andremo ad esaminare in dettaglio quali sono le tecniche per mitigare, se non contrastare, attacchi di questo genere.

A presto.

Irrobustire le difese del nostro router Cisco SOHO

Abbiamo già visto nei precedenti post come configurare il nostro router per i protocolli PPPoA e PPPoE. Adesso vediamo quali sono le possibili tecniche per difenderlo da eventuali attacchi di bruteforce, IP spoofing o di tipo Denial of Service (DoS).

Messa in sicurezza delle connessioni Telnet

Il nostro router Cisco consente (per default) la connessione sulla porta 23 (Telnet) anche da host esterni alla nostra rete (ovvero da Internet), rendendolo soggetto ad eventuali attacchi di bruteforce.

Un modo per evitare che ciò avvenga è creare un ACL apposita che permetta la connessione al router via Telnet esclusivamente dagli host della nostra rete. Supponiamo quindi che la nostra LAN comprenda 6 indirizzi utilizzabili, ovvero 192.168.1.1 (il router), 192.168.1.2, 192.168.1.3, 192.168.1.4, 192.168.1.5, 192.168.1.6. Come avrete notato la subnet mask utilizzata è una /29 (255.255.255.248), la quale comprende in tutto 8 indirizzi di cui solo 6 possono essere assegnati agli host (il primo indirizzo indentifica la nostra rete, ovvero 192.168.1.0, mentre l’indirizzo 192.168.1.7 rappresenta il broadcast).

Detto ciò, non ci resta che definire l’ACL, digitando:

NightRouter(config)#access-list 1 permit 192.168.1.0 0.0.0.7

Tramite questo comando abbiamo creato l’ACL standard identificata dal numero 1 che permette l’accesso agli host appartenenti alla nostra LAN. Per fare ciò abbiamo dovuto specificare sia l’indirizzo di rete (192.168.1.0) che la wildmask (0.0.0.7). Quest’ultima rappresenta la parte fissa dell’indirizzo mediante degli zeri, mentre la parte variabile viene indicata attraverso il massimo valore intero rappresentabile dai bit che verranno utilizzati per formare l’indirizzo IP degli host.

Ad esempio, nel nostro caso, una /29 indica che su 32 bit (dimensione di un indirizzo IPv4) 29 costituiscono la maschera, mentre gli ultimi 3 concorrono a costituire gli indirizzi IP degli host. Sappiamo che il valore intero massimo rappresentabile mediante questi bit è pari a 7. Ergo la wildmask sarà pari a 0.0.0.7.

Discorso analogo va fatto per la classe A di indirizzi privati, ovvero la 10.0.0.0/8. In questo caso abbiamo 8 bit che costituiscono la subnet mask mentre gli altri 24 verranno utilizzati per assegnare gli indirizzi IP agli host. Dunque quale sarà la wildcard mask? Semplice: 0.255.255.255.

Per gli indirizzi di classe B privati, che vanno da 172.16.0.0/16 a 172.31.255.255/16 abbiamo la seguente wildcard: 0.15.255.255. Infine, per gli indirizzi privati di classe C, ovvero 192.168.1.0/24, 192.168.2.0/24 e così via possiamo utilizzare questa wildmask:

0.0.255.255

associata all’indirizzo 192.168.0.0, ovvero un indirizzo privato di classe C adattato a classe B, in modo tale che con una sola wildmask vengano interessate tutte le possibili reti private di classe C.

Questa spiegazione ci tornerà utilie quando andremo ad implementare le regole per difenderci dall’IP spoofing.

Tornando alla nostra ACL, è necessario che essa venga associata al servizio Telnet, che negli apparati Cisco prende il nome di vty. Per fare ciò basta digitare:

NightRouter(config)# line vty 0 4

NightRouter(config-line)# access-class 1 in

NightRouter(config-line)# exit

Come avrete facilmente intuito è il comando access-class che associa l’ACL standard 1 in ingresso al terminale Telnet.

Sicuramente a questo punto vi starete chiedendo: perchè ho definito un ACL che permette l’accesso via Telnet sul router agli host della mia LAN se poi non ho definito alcuna regola per vietare l’accesso a tutti gli altri host?

Semplice, ogni ACL nel momento in cui viene creata ha come regola implicita il deny any, quindi tutti gli altri host vengono automaticamente esclusi da ogni possibilità di accesso.

Misure contro L’IP Spoofing

Bene, il nostro terminale Telnet è finalmente al sicuro. Vediamo ora come fare per difenderci dall’IP spoofing, tecnica che prevede l’alterazione dell’IP sorgente presente all’interno dei pacchetti, in modo da aggirare i controlli effettuati dal router attraverso le ACL.

Una prima difesa contro questo attacco consiste essenzialmente nel creare un’ACL estesa in cui definire tutti gli indirizzi IP che non possono accedere al router mediante l’interfaccia connessa ad internet (Dialer0).

Passiamo quindi alla creazione dell’ACL:

NightRouter(config)# access-list 101 deny ip 10.0.0.0 0.255.255.255 any log

Mediante questo comando stiamo creando l’access list estesa (identificata dal numero 101) che nega qualsiasi pacchetto facente uso del protocollo IP proveniente dalla net 10.0.0.0/8 e diretto verso qualunque host della nostra rete.

Aggiungiamo altre regole alla nostra ACL:

NightRouter(config)# access-list 101 deny ip 172.16.0.0 0.15.255.255 any log

NightRouter(config)# access-list 101 deny ip 192.168.0.0 0.0.255.255 any log

NightRouter(config)# access-list 101 deny ip host 127.0.0.1 any log

NightRouter(config)# access-list 101 deny ip host 255.255.255.255 any log

NightRouter(config)# access-list 101 deny ip 224.0.0.0 15.255.255.255 any log

NightRouter(config)# access-list 101 permit ip any any log

Quest’ultima regola consente l’accesso a tutti gli altri host non esplicitamente negati nell’ambito delle regole precendenti.

Facciamo ora alcune piccole considerazioni:

1) Il termine “host” utilizzato nell’ambito delle regole 4 e 5 indica all’ACL che l’indirizzo da negare è soltanto uno, ovvero, rispettivamente, 127.0.0.1 (localhost) nel caso della regola numero 4 e 255.255.255.255 (broadcast) nel caso della regola numero 5. In alternativa avrei potuto usare la wildmask 0.0.0.0 immediatamente dopo l’indirizzo IP, ad esempio:

NightRouter(config)# access-list 101 deny ip 127.0.0.1 0.0.0.0 any log

NightRouter(config)# access-list 101 deny ip 255.255.255.255 0.0.0.0 any log

2) Per ciò che concerne, invece, la numerazione delle ACL, quelle standard vanno numerate da 1 a 99 e quelle estese da 101 a 199 (esistono comunque altri range utilizzabili per entrambe le tipologie di ACL).

3) Infine, è bene notare che le regole vengono applicate dal router in ordine sequenziale, ovvero dalla prima all’ultima. Quindi, se un dato pacchetto rispetta una regola, quelle immediatamente successive verranno ignorate. A tal proposito facciamo un piccolo esempio:

NightRouter(config)# access-list 101 permit ip any any

NightRouter(config)# access-list 101 deny 82.11.199.188 any any

Quest’ultima regola verrà palesemente ignorata dal router, in quanto abbiamo già permesso l’accesso indistinto a tutti i pacchetti.

PS: il termine log presente alla fine di ogni regola associata all’ACL indica al router di loggare tutti i pacchetti che sono stati scartati da essa.

Un piccolo trucco: quando definite il permit ip any any in un’ACL siate certi di aver negato tutti gli host ai quali non volete permettere l’accesso, anche perchè non è possibile (sia per le ACL standard che per quelle estese) andare a rimuovere una singola regola (se ad esempio digitiamo il comando no access-list 101 permit ip any any viene rimossa l’intera ACL).

Comunque, per sopperire a tale limitazione, le IOS più recenti hanno introdotto le ACL nominali, in cui è prevista la cancellazione di una o più regole specifiche.

Associamo tale ACL in ingresso all’interfaccia Dialer0, ovvero quella direttamente connessa ad Internet:

NightRouter(config)# int dia0

NightRouter(config-if)# ip access-group 101 in

Difesa contro gli attacchi di tipo DoS (Smurfing)

smurf-attack.jpg

 

Bene, ora non ci resta che difendere il nostro router dagli attacchi di tipo DoS. Per prima cosa occorre prendere delle contromisure contro lo smurfing. Tale tecnica coinvolge almeno tre tipi di attori: l’host dell’attaccante (A), uno o più host della nostra LAN (B) e l’host vittima (C). Nella fattispecie, l’host dell’attaccante, ovvero A, invia delle richieste di broadcast ad uno o più host della nostra LAN (B), contenenti come indirizzo IP sorgente quello dell’host vittima (C). Tali richieste di livello 3 (255.255.255.255) vengono convertite in richieste di livello 2 (FF:FF:FF:FF:FF:FF) (solitamente dal router) in modo tale che tutti gli host della LAN possano rispondere, generando un elevato ammontare di traffico. A questo punto, tutte le risposte così generate verranno inoltrate sotto forma di pacchetti ICMP verso l’host vittima, congestionandolo di conseguenza.

Per fare in modo che gli host della nostra LAN non vengano utilizzati come testa di ponte per attacchi di questo tipo basta lanciare il comando:

NightRouter(config)# int e0

NightRouter(config-if)# no ip directed-broadcast

Così facendo, le richieste di broadcast  (di livello 3) contenenti indirizzo sorgente fasullo, inoltrate da un attacker mediante l’interfaccia del router connessa ad internet (Dialer0) oppure attraverso un’interfaccia di rete interna (E0), non verranno tradotte in richieste di broadcast di livello 2 e non subiranno quindi il processo di amplificazione che sta alla base del successo di questo tipo di attacco.

NB: nei router che utilizzano IOS maggiori o uguali alla 12.0 tale comando è abilitato per default. Per indentificare la versione di IOS installata sul vostro router basta digitare:

NightRouter# sh ver

Difesa contro gli attacchi di tipo DoS (diretti verso i servizi di diagnostica)

Un altro tipo di attacco, di tipo DoS, a cui sono soggetti i router Cisco, consiste nell’invio di un grande numero di pacchetti  spuri UDP e TCP verso le porte echo, chargen, discard e daytime (quest’ultima si basa esclusivamente sul protocollo TCP). Tali porte vengono adoperate per operazioni di diagnostica sul router ed un attacco di questo tipo potrebbe causare la congestione della CPU, fino a portare allo stallo del dispositivo.

Per prevenire questa tipologia di attacco basta disabilitare i servizi di diagnostica sopra citati, attraverso i comandi:

NightRouter(config)# no service udp-small-servers

NightRouter(config)# no service tcp-small-servers

Difesa contro gli attacchi di tipo DoS (Land)

Un attacco di tipo “land” permette di inoltrare pacchetti TCP SYN (tipici dell’inizio di una connessione) con indirizzo IP sorgente e porta modificati e posti uguali all’indirizzo ed alla porta dell’host di destinazione, causando in alcuni casi anche il blocco del router.

Il problema è stato risolto nelle versioni più recenti di IOS, ma negli altri casi è necessario applicare un filtro che blocchi per ogni interfaccia la ricezione di questi pacchetti. Vediamo come fare (utilizzando delle ACL estese):

NightRouter(config)# access-list 102 deny ip <indirizzo della scheda ethernet0> 0.0.0.0 <indirizzo della scheda ethernet0> 0.0.0.0

Associamo dunque tale ACL all’intercaccia ethernet0:

NightRouter(config)# int e0

NightRouter(config-if)# ip access-group 102 in

Come avrete notato, non ho associato tale ACL anche all’interfaccia Dialer0, in quanto la maggior parte di noi utilizza IP dinamici che ci vengono assegnati direttamente dall’ISP. Nel caso in cui, però, usufruite di IP statico basta digitare:

NightRouter(config)# access-list 102 deny ip <indirizzo della scheda Dialer0> 0.0.0.0 <indirizzo della scheda Dialer0> 0.0.0.0

NightRouter(config)# int dia0

NightRouter(config-if)# ip access-group 102 in

Cifratura delle password

L’ultima parte di questa guida riguarda la cifratura delle password, in modo che uno sh run non permetta di visualizzarle in chiaro.

Per abilitare la cifratura occorre digitare:

NightRouter(config)# service password-encryption

Bene, ora il nostro router dovrebbe essere al sicuro contro gli attacchi più comuni. A presto.