Un attacco di Denial-of-Service (DoS) è scritto per intralciare o bloccare il normale funzionamento di un sito, di un server o di una risorsa di rete. Ci sono svariati modi in cui gli hacker possono realizzare un attacco DoS.
Un metodo comune è quello di inondare un server inviando verso quest’ultimo più richieste di quelle che è in grado di gestire. Ciò provocherà un rallentamento nel funzionamento del server (e le pagine web impiegheranno molto più tempo ad aprirsi), e può anche causare un collasso totale del server (provocando l’abbassamento di tutti i siti sul server).
Un attacco DDoS (distributed-Denial-of-Service), a differenza del DoS, viene condotto coinvolgendo più di un computer. L’hacker di solito sfrutta un computer compromesso come “maestro” e coordina l’attacco attraverso altri apparecchi cosiddetti “zombie”. Sia il computer “maestro” che quelli zombie vengono compromessi sfruttando una vulnerabilità in un’applicazione del computer, grazie alla quale installare un Trojan o un altro codice malware.
Per perpretare i loro attacchi, i gruppi hacker utilizzano in genere diversi tipi di tecniche e strumenti, più o meno sofisticati. Non è ovviamente nostra intenzione esaminarli tutti, o fornire un manuale per gli stessi; piuttosto, può essere utile e interessante esaminare le tecniche usate più frequentemente: in fondo molti di noi hanno e gestiscono un proprio sito web, per cui può far comodo sapere in anticipo se questo può avere delle falle a livello di sicurezza e se può essere facilmente violato. Le tecniche di attacco più diffuse sono fondamentalmente due: il DDoS – (Distributed) Denial of Service, e l’SQLI – SQL Injection: vediamo in cosa consistono.
Attacco Distributed Denial of Service (DDoS)
Questo tipo di attacco si verifica quando un sistema, tipicamente un web server, riceve contemporaneamente un numero così elevato di richieste da causare un sovraccarico del server stesso, che può arrivare a bloccarsi o addirittura a eseguire lo shutdown. L’obiettivo di questo tipo di attacco sta proprio nel suo nome (“diniego del servizio”): cioè far sì che un sito o un servizio web non sia più raggiungibile/utilizzabile dagli utenti e dai visitatori. La negazione del servizio, per molti tipi di applicazioni e attività commerciali, rappresenta una potenziale perdita economica non trascurabile (si pensi, ad esempio, a un sito per la prenotazione dei viaggi in aereo o in treno). Storicamente, questo tipo di attacco ha sempre riscontrato un notevole successo, in quanto per un server web è virtualmente impossibile sapere se una richiesta di accesso arriva da un utente legittimo oppure da un attacco hacker – quest’informazione sarà infatti disponibile solo quando la richiesta sarà già stata processata. Il termine “Distributed” sta inoltre a indicare che l’attacco è condotto simultaneamente da più hacker, sparsi in diversi paesi del mondo, che si sincronizzano per coordinare ed attuare l’attacco ciascuno con un proprio computer collegato a Internet. Non solo, data la sua natura di attacco “brutale”, il DDoS si presta ad essere eseguito non solo da computer controllati dall’uomo, ma anche e soprattutto da applicazioni software che eseguono autonomamente e automaticamente l’attacco (si parla in questo caso di computer “zombie”). Se poi un’applicazione zombie fosse in grado di installarsi su una vasta quantità di computer in giro per il mondo (magari a insaputa degli ignari utenti), si potrebbero facilmente comprendere gli effetti devastanti (e a costo “quasi zero”) di questo tipo di attacco. Questo è uno dei tanti motivi per cui è conveniente utilizzare un antivirus e un programma in grado di rilevare applicazioni malware.
Attacco SQL Injection (SQLI)
Questo tipo di attacco sfrutta la vulnerabilità di alcune tecniche web comunemente adottate, combinate tipicamente con una scarsa sicurezza a livello di database. L’SQLI può portare a conseguenze assai disastrose, dall’utilizzo non autorizzato di un account esistente, fino alla violazione di informazioni contenute su un database.
Particolare interesse ha destato un attacco di questo tipo condotto dal gruppo Lulz Security (LulzSec) ai danni della Sony Pictures (link alla notizia riportata sul sito BBC). Il sito della Sony è stato attaccato da questo gruppo di hacker almeno tre volte, inclusa la rete di utenti SonyPlaystation, con la compromissione dei dati di almeno 77 milioni di utenti. Come può avvenire ciò? E’ molto semplice. Ogni volta che ci si connette a un sito fornendo la propria login e password, l’applicazione web eseguirà una query SQL molto simile alla seguente per verificare le credenziali dell’utente (ricordiamo che l’SQL è un linguaggio utilizzato per interrogare, “query” in inglese, o modificare un database):
SELECT UserID FROM Users WHERE UserName=’mioutente’ AND Password=’miapassword’;
Solo se la UserName e la Password inserite sono presenti nel database, verrà restituito un opportuno UserID. Ad una prima occhiata, questa query sembrerebbe avere un’aria innocente, niente di più di una semplice e tranquilla istruzione per validare l’utente. Tuttavia, operando una semplice sostituzione dei valori inseriti dall’utente, anche questa semplice query è potenzialmente in grado di portare un attacco SQLI. Supponiamo, infatti, che come nome utente sia inserita la stringa “mioutente’–-” e come password la stringa “passworderrata”. La query diventerebbe la seguente:
SELECT UserID FROM Users WHERE UserName=’mioutente’–’ AND Password=’passworderrata’
Sapendo ora che nel linguaggio SQL una sequenza di due trattini (“–”) indica l’inizio di un commento, tutto che ciò che appare dopo i due trattini (inclusi gli stessi) verrà ignorato. La query effettiva diventerà così la seguente:
SELECT UserID FROM Users WHERE UserName=’mioutente’
Il risultato è lampante: nella query non è più presente il controllo sulla password! Si è così potenzialmente in grado di eseguire il login con il nome utente “mioutente” senza aver inserito (e quindi senza conoscere) la sua password! Questo è probabilmente l’esempio più semplice ed evidente di come si possa sferrare un attacco SQL injection (SQLI).
Ma ci si può premunire nei confronti di un attacco SQLI?
La risposta è affermativa: gli attacchi SQLI, quando vengolo portati a termine con successo, sono sempre attribuibili a negligenze e/o a uno sviluppo poco responsabile delle applicazioni software. Tuttavia, i danni portati da questi attacchi possono anche essere consistenti, a seconda dei privilegi di lettura/scrittura che il database sul web server assegna alle applicazioni web. Riferendosi sempre all’esempio precedente, supponiamo che come nome utente si inseriscano i valori “utentepippo’–”, “admin’–”, o qualunque altro nome utente: se questi utenti sono effettivamente nel database, si può eseguire istantaneamente il login con queste utenze senza conoscerne la password ed eritando i “privilegi” assegnati a quell’utente (se tra questi privilegi c’è quello in scrittura, gli effetti possono essere facilmente immaginabili). Supponiamo ora che nel database esista l’utente “Gianni” (o un altro nome utente qualsiasi, sceglietene un altro, se preferite), e che esista la tabella “Users” (molto plausibile come ipotesi). Modifichiamo a questo punto la query precedente nel modo seguente (il “;” in SQL permette di separare due istruzioni):
SELECT UserID FROM Users WHERE UserName=’Gianni’; DROP TABLE Users;–’ AND Password=’passworderrata’
che equivale a:
SELECT UserID FROM Users WHERE UserName=’Gianni’ DROP TABLE Users
DROP in SQL equivale all’operazione di cancellazione, per cui il risultato di quest’attacco SQLI è quello di eliminare la tabella degli utenti. Poco simpatico, non vi sembra? Ovviamente, le combinazioni sono infinite, e si può lasciare spazio alla propria fantasia per immaginare cosa si potrebbe fare con questo tipo di attacchi.
Come si può prevenire un attacco SQLI?
Prevenire è meglio che curare, come dice il proverbio, e ciò è assolutamente possibile anche in questo caso. Come? Basta applicare la cosiddetta “sanitizzazione degli input” (è un brutto termine, ma è la migliore traduzione disponibile per il verbo anglosassone “sanitize”). Il processo di sanitizzazione è abbastanza semplice: esso tratta ogni singolo carattere apice (‘) in modo appropriato, in modo tale che esso non possa terminare prematuramente una stringa all’interno di un’istruzione SQL. Il concetto è quello di far precedere ogni carattere (‘) da un backslash, esattamente come si fa nelle sequenze di escape. L’esempio mioutente’– / passworderrata viene sanitizzato nel modo seguente:
SELECT UserID FROM Users WHERE UserName=’mioutente\’–’ AND Password=’passworderrata’
Poichè il carattere apice dopo mioutente è preceduto da un backslash, il database cercherà l’utente con nome “mioutente’–”. Inoltre, poichè i trattini sono inclusi nella stringa e non nell’istruzione SQL, essi non verranno interpretati come commento SQL.
Per quanto concerne l’altro caso (Gianni’; DROP TABLE Users;– / passworderrata) avremo:
SELECT UserID FROM Users WHERE UserName=’Gianni\’; DROP TABLE Users;–’ AND Password=’passworderrata’
In questo caso sia il punto e virgola che i trattini saranno inclusi all’interno della stringa di ricerca e verranno utilizzati per la ricerca senza essere interpretati come comandi SQL.
Ricordiamo che il noto gruppo hacker LulSec, di cui si sa poco o nulla, ha portato i propri attacchi ai siti di Sony Pictures proprio con una semplice e singola SQL injection. Allo stesso gruppo sono attribuibili attacchi ad altri siti negli Stati Uniti, come Fox, PBS e XFactor. Questa tecniche sono largamente utilizzate anche dal gruppo Anonymous (la cui “bandiera” è mostrata nell’immagine di apertura dell’articolo), che ha sferrato una consistente campagna di attacchi rivolta a diversi siti governativi americani dopo la recente chiusura di Megavideo e Megaupload decisa dall’FBI (giudicata dal gruppo hacker come una vera e propria limitazione al libero scambio dei contenuti digitali).
In sintesi, possiamo dire che per quanto riguarda gli attacchi SQLI un rimedio c’è e gli stessi si possono prevenire (sanitizzare l’input, soprattutto il login!); per quanto riguarda invece gli attacchi DDoS, la situazione è più complessa e più difficile da risolvere (esistono comunque tecniche che possono limitare gli accessi provenienti da certi IP).
vi posto un tipica protezione windows contro un ddos:
Hai un pieno accesso di amministratore per il VPS. È possibile installare qualsiasi applicazione di terze parti sul vostro VPS per proteggere il vostro VPS da attacchi DDOS.
Per bloccare IP sul server tramite Windows seguire le istruzioni che vi darò ..
Fare clic su 'Start' 'Esegui'> tipo> 'MMC' premere OK.
Nella console clicca> 'File'> 'Aggiungi / Rimuovi snap in'
Nella 'scheda Autonomo' cliccare sul pulsante 'Aggiungi'
Seclect 'IP Security Management Policy'> 'AGGIUNGI'> 'Local Computer'> 'finire'> 'stretta'> 'ok'
Ora dovrebbe essere di nuovo alla console.
In 'politiche di sicurezza IP sul computer locale' il click destro del frame di sinistra> 'Crea criterio di protezione IP'
Fare clic su Avanti e poi il nome 'IP bloccati' la vostra politica e digitare una descrizione.
Fare clic su 'Avanti' poi lasciare 'attivare' spuntato quindi fare clic su 'Avanti'
lasciare il 'Modifica proprietà selezionata e fare clic su' Fine '
Si dovrebbe ora avere la finestra delle proprietà aperta.
Fare clic su 'Aggiungi' quindi fare clic su 'Avanti' per continuare.
Lascia 'Questa regola non specifica un tunnel' selezionato e fare clic su 'Avanti'
Lasciare 'tutte le connessioni di rete' selezionato e fare clic su 'Avanti'
Ora dovrebbe essere sulla lista dei filtri IP. È necessario creare un nuovo filtro, quindi non selezionare nessuno di quelli di default. Fare clic su 'Aggiungi'
Digitare un nome per l'elenco, lo chiamano 'lista del blocco IP'
Digitare una descrizione in, può essere lo stesso nome.
Fare clic su 'Aggiungi' quindi fare clic su 'Avanti' per continuare.
Nella casella Descrizione digitare una descrizione. Come il suo il primo IP che stanno bloccando la chiamano 'IP1' o 'IP Range 1'
Lasciare spuntato il 'mirroring. Individua i pacchetti con l'esatta origine opposto e gli indirizzi di destinazione '
Fare clic su 'Avanti'
Il 'indirizzo sorgente' dovrebbe essere lasciato come fare clic su 'Il mio indirizzo IP' 'Avanti'
Ora è possibile selezionare 'un indirizzo IP specifico' o 'di una sottorete specifica' per l'indirizzo di destinazione.
Digitare l'indirizzo IP da bloccare, e se il blocco di un tipo di sottorete nel blocco sottorete. Fare clic su 'Avanti'
Lasciare il tipo di protocollo come 'Tutti' e fare clic su 'Avanti' e poi 'Fine'
Ora avete bloccato prima gamma di IP o IP.
Vari tipi di attacchi dDos
Il punto di partenza è questo. Esistono svariate tipologie di attacchi dDos. Generalmente contro quelli più potenti si può fare ben poco se le risorse sono ridotte al lumicino. Sei disposto a comprare un firewall hardware da 200 dollari per un server dedicato che ne vale 60? Ecco il punto è proprio questo, a richiedere assistenza contro gli attacchi dDos ci sono anche persone che hanno un semplice blog a scopo di hobby e non sono in grado di poter spendere dieci volte quello che costa un server dedicato per poter acquistare una protezione adeguata. Piuttosto preferiscono chiudere i battenti e cambiare dominio. Dominio? Si, contro un attacco dDos diretto al tuo dominio non servirà cambiare l’indirizzo ip del tuo sito web.
Quali sono gli attacchi dDos che possono essere fermati
In generale gli attacchi dDos a saturazione, con svariati Gb di banda passante diretti contro il tuo server sono anche quelli più pericolosi. In questo caso per fronteggiare l’attacco dovresti disporre di un’apertura di banda maggiore rispetto a quella che ha in mano l’attaccante. O mettere in null route. Molte compagnie infatti consentono di inserire temporaneamente l’ip del cliente colpito in null route, il tempo necessario a far passare l’attacco. In casi come questo vince chi è disposto ad avere più pazienza: l’attaccante può attendere anche mesi prima di colpire nuovamente oppure può desistere e passare ad un altro bersaglio. Gli attacchi a saturazione sono quelli più difficili da fermare. A meno di non dotarsi di una protezione di livello alto come quella offerta ad esempio da Black Lotus le speranze di uscire indenni da un dDos a saturazione sono molto basse.
Syn Flood e attacchi dDos agli applicativi
Discorso diverso per gli attacchi di tipo Syn Flood ed a livello applicativo. I dDos a livello applicativo sono quelli che colpiscono i singoli servizi del tuo server come ad esempio Apache o Sendmail. In situazioni come queste è abbastanza semplice elaborare una veloce strategia di difesa anche in virtù del fatto che non è necessario l’intervento del datacenter ma è possibile attivare direttamente a livello server la barriera protettiva. In questo caso specifico ServerManaged.it può difenderti dall’attacco.
Attacchi dDos applicativi contro Apache
L’attacco di tipo Slow Headers, che trova incarnazione nel tool Slowloris e l’attacco di tipo Slow Request Bodies. Entrambi sfruttano due vulnerabilità di Apache, non direttamente causate da errori di implementazione del codice ma dal modo in cui il demone si comporta di fronte a determinati tipi di richieste HTTP. Curiosità: nonostante l’attacco di tipo Slow Headers sia passato di moda non è raro trovare il tool Slowloris nascosto da qualche parte su alcuni siti web infetti, segnale che in quel caso il tuo server è stato usato o verrà usato presto per lanciare un attacco dDos. Una situazione molto comune di cui parleremo fra poco.
Slow Headers
L’attacco Slow Headers consiste essenzialmente nell’invio di un numero molto elevato di richieste di connessione da parte dell’attaccante a cui non fa seguito nessuno scambio di dati. Apache rimane in attesa di poter servire una richiesta di dati, che però non arriverà mai. In questo modo è possibile portare il demone al collasso con l’invio di migliaia di connessioni “vuote”.
Slow Request Bodies
L’attacco di tipo Slow Request Bodies consiste invece nell’invio di un determinato numero di richieste HTTP verso Apache. La procedura di scambio dati verrà inizialmente portata a termine con successo ma a questo punto l’attaccante inganna Apache inviando numerose request body in modo estremamente lento, nell’ordine di 1 byte ogni 100 secondi. Considerando che la quantità massima di dati che Apache può gestire per il request body è di 2GB, è facile capire come può essere possibile saturare completamente il servizio HTTP.
Non tutti i dDos sono commissionati dal tuo concorrente
Una delle leggende metropolitane più chiacchierate è quella secondo la quale il tuo server è sotto attacco dDos per mano dei tuoi diretti concorrenti. Nonostante la frustrazione durante un attacco sia davvero tanta non è questo il modo giusto di considerare la situazione nel suo complesso. Un attacco dDos “importante” lanciato da una botnet degna del suo infame nome ha un costo. Un costo che nella maggior parte dei casi non è nell’ordine delle decine di euro/dollari. Inoltre non è affatto semplice entrare in contatto via internet con chi vende servizi di questo tipo (almeno non con chi offre dDos di qualità). Per farla breve non immaginare che il tuo concorrente alzi la cornetta ed ordini un dDos come si ordina un caffè al bar. La questione è su un livello completamente diverso. Non puoi additare la concorrenza come responsabile dell’attacco dDos contro il tuo server. Piuttosto potresti non essere un obiettivo mirato ma un obiettivo preso a caso. E non è affatto raro essere vittima di dDos anche senza motivi che potrebbero giustificare questa situazione. Per farla breve l’attacco dDos su commissione è una cosa abbastanza seria e nella realtà trova applicazione in pochi casi.
Traffico anomalo che parte dal tuo server
Sapevi che non esistono solo gli attacchi dDos in entrata? Anche il tuo server può lanciare attacchi dDos e potrebbe far parte di una botnet. Ciò accade quando uno dei tuoi siti web subisce un contagio ed al suo interno vengono caricati quelli che chiamiamo “gli strumenti del male“. Gli strumenti del male in questo caso sono i cosiddetti bot, che si presentano principalmente sotto due forme: bot Perl/Php e bot Irc. I bot Perl/Php possono contaminare i tuoi siti web in seguito ad una vulnerabilità su uno dei componenti del tuo CMS, mentre i bot Irc propriamente detti possono essere caricati su un server in seguito ad una violazione di uno o più account di sistema. Questi ultimi per funzionare hanno bisogno di essere compilati perchè nascono sotto forma di codice sorgente. Anche per questo motivo è sempre necessario disattivare i compilatori di sistema per gli utenti non privilegiati. I bot Perl/Php hanno sempre e comunque funzionalità di connessione Irc e sono utilizzati per collegare il sito web infetto ad una botnet. In entrambi i casi i bot comunicano con un canale Irc da cui ricevono istruzioni per fare seguito ad attacchi dDos contro bersagli remoti. In questa situazione puoi osservare una grande quantità di traffico anomalo che parte dal tuo server con un conseguente blocco di tutte le funzionalità della macchina a causa del sovraccarico.
Puoi difenderti da un attacco dDos?
Devi capire se il gioco vale la candela e devi guardare prima di tutto il tuo budget. Se puoi valutare l’acquisto di protezioni blasonate contro gli attacchi dDos a saturazione allora non aspettare altro. Se il tuo problema invece è localizzato a livello di applicativo puoi richiedere un intervento più economico.