Indice dei contenuti dell'articolo:
Nelle ultime due settimane anche alcuni dei nostri clienti sono stati presi di mira da quella che sembra essere una moda destinata a diffondersi sempre di più, attacchi DDOS a cui far seguire richieste di riscatto in Bitcoin al fine di far terminare l’attacco.
Quel che sembrava un caso sporadico infatti che per primo ha colpito il sito di un nostro cliente, nei giorni a seguire si è dimostrato una ricorrenza, avendo infatti avuto a che fare con ben 5 tentativi di attacco DDOS Layer 7 e altrettante richieste di estorsione e pagamenti in Bitcoin.
Confrontandoci con nostri clienti Webmaster e altri operatori di Hosting infatti abbiamo potuto constatare che il trend di questi attaccanti è in forte salita, avendo avuto conferma dello stesso modus operandi con addirittura la stessa somma da pagare se si volesse interrompere l’attacco, ovvero 250€ in Bitcoin.
Puoi trovare nella fotografia di seguito la mail minacciosa con la richiesta di riscatto :
Come si può notare dall’indirizzo del portfolio Bitcoin, è lo stesso hacker che ha attaccato un altro sito di un nostro cliente cercando di estorcere lo stesso importo e addirittura lamentandosi che il gestore (ovvero noi) stesse limitando l’attacco andando ad escludere alcuni paesi attaccanti dove presumibilmente l’attaccante aveva grandi botnet ed era in grado di generare un elevatissimo numero di richieste di tipo GET e POST al sito del nostro cliente, provocando un down che in terminologia tecnica di definisce Denial Of Service o più semplicemente DOS.
Salve,
attualmente noto che il vostro gestore continua ad ostacolarmi tentando di bloccare le richieste in arrivo dagli altri paesi. Attualmente solo l’Italia ha accesso al vostro sito web. Il che è una cosa piuttosto fastidiosa per voi, dato che secondo alcune mie ricerche, il vostro pubblico non abbraccia solo gli Italiani: infatti il 20% dei visitatori al vostro sito NON provengono dall’Italia.
Quello che vi consiglio è di far vedere questa e-mail al vostro gestore e fargli capire che posso benissimo “giocare” con le sue scarse protezioni (geoblock, ipban, recaptcha, jschallenge).Per il resto auguro un buon NON lavoro come sempre, e aspetto la mia somma di €250 nel mio portafoglio BITCOIN all’indirizzo:
1HHFxKeVk35FCnd36bV7LYyk3CNT6avFRT
Esigo una risposta nell’arco delle 24h
P.S. : E’ inutile cloudflare per camuffare l’ip del server: (78.47.X.X)
Riesco facilmente a trovare il backend. Ma non mi serve ancora. Mi limito ad attaccare il frontend. Good luck !
Il messaggio ci è stato girato direttamente da un nostro cliente Webmaster tramite Whatsapp come potete vedere nello screen seguente :
Alcune ipotesi sull’identità dell’attaccante.
I due messaggi, sia il primo che il secondo sembrano scritti in un’italiano perfetto pertanto viene da ipotizzare che l’attaccante sia italiano o quantomeno madre lingua italiano. La cosa ovviamente non è certa ma è ragionevole e pacifico pensarlo.
Sicuramente il fatto che chieda espressamente un pagamento menzionando gli Euro piuttosto che dollari fa ancora più pensare che stiamo di fronte ad un attaccante europeo quasi sicuramente italiano.
La cifra richiesta sebbene possa sembrare bassa, è un costo intelligentemente ponderato, non troppo alta da essere ignorata, ne troppo bassa rispetto al costo di mitigazione di un DDOS. Verosimilmente è un’estorsione ben pesata che potrebbe invitare l’attaccato a pagare la somma indicata pur di vedere cessare l’attacco DDOS e avere di nuovo il sito online.
La tipologia dell’attacco.
L’attacco sferrato è un attacco Layer7 (a livello applicativo dunque) focalizzando sull’inondazione di richieste di tipo GET e POST al sito vittima.
Gli IP sorgenti avevano come geolocalizzazione a livello mondiale con paesi internazionali ed europei, tra cui anche l’Italia. L’attacco aveva molti fornitori consumer ADSL pertanto si presume che la presunta botnet in realtà non fosse altro che un redirect di traffico legittimo di browser di utenti reali.
Infatti non essendo delle semplici e banali richieste di tipo GET e POST messe in atto dai “soliti” toolkit degli hacker della domenica, riuscivano a superare il challenge mode della modalità UNDER ATTACK di CloudFlare, nostro prezioso partner nella mitigazione del DDOS.
Ciò significa essenzialmente che il client che faceva richieste verso i server di CloudFlare erano in grado di eseguire codice Javascript, dato che la tecnologia di validazione del browser di CloudFlare prevedere appunto un challenge (una risoluzione di un problema matematico) tramite l’interprete Javascript di cui sono forniti tutti i browser ma pochissimi o nessun tool per effettuare il flooding (inondazione) di richieste di tipo GET o POST.
Molte richieste arrivavano ad esempio da referrer come reddit.com, baidu.com, yahoo.com e simili, come potete vedere in questa schermata seguente andando a filtrare direttamente nel log del webserver NGINX access.log
Non cedere al ricatto e non pagare mai il riscatto.
Sebbene un down possa essere preoccupante per i mancati introiti anche nel breve termine (pensiamo solo alla mancanza di monetizzazione di Advertising pubblicitarie, banner o semplici mancate vendite) e la cifra da pagare tutto sommato economica, dobbiamo sempre ricordarci che cedere al ricatto significa essere da ora in poi disponibili ad essere dei “bancomat” personali per l’attaccante.
Se paghi una volta preparati a pagare una seconda, e poi una terza e così via. Pagherai sempre, perchè lo hai già fatto una volta e sarai considerato psicologicamente debole e sempre una persona incline a pagare e ad essere ricattata.
Non bisogna mai pagare o cedere al ricatto, piuttosto rivolgiti a personale competente e qualificato come noi per risolvere una volta per tutte le problematica.
In questi casi la regola è semplice : mai sanguinare davanti agli squali.
Cos’è CloudFlare ?
CloudFlare è reverse proxy con funzioni di CDN (Content Delivery Network). In pratica, è un server che si interpone tra il server dove è ospitato il tuo sito ed i visitatori, svolgendo inoltre anche funzioni di caching, velocizzando ulteriormente le performance del tuo sito. Non si limita alla distribuzione dei contenuti statici (come un normale CDN), ma offre numerose funzionalità per aumentare la sicurezza, ottimizzare un sito, velocizzare i DNS e proteggere dagli attacchi DDOS.
Quando arriva una richiesta da parte di un utente, CloudFlare (in un arco di tempo minimo), controlla prima di tutto se il visitatore è affidabile, ed in caso positivo, dopo aver preso i contenuti statici (immagini, css, javascript) dalla cache, li restituisce al visitatore stesso.
Tralasciando le funzionalità di CDN e ottimizzazione del delivery dei contenuti tramite minifizzazione, conversioni immagini webp e tanto altro ancora, in questo articolo ci focalizzeremo sull’utilizzo di CloudFlare al fine di mitigare un attacco DDOS.
Come mitigare un DDOS di tipo Layer7 tramite CloudFlare ?
La prima cosa da capire sugli attacchi di livello 7 è che richiedono una maggiore comprensione del sito Web e di come funziona. L’attaccante deve fare alcuni compiti e creare un attacco appositamente realizzato per raggiungere il suo obiettivo. Per questo motivo, questi tipi di attacchi DDoS richiedono meno larghezza di banda per abbattere il sito e sono più difficili da rilevare e bloccare.
Il modo migliore per fermare un DDOS Layer7 è quello di utilizzare un servizio di sicurezza come CloudFlare che lavorando in reverse proxy, ci offre delle importanti funzionalità per filtrare il traffico a monte.
In parole povere come si può vedere dall’immagine sopra, quando l’attaccante proverà a contattare il nostro sito (o il suo traffico malevolo) dovrà passare tramite CloudFlare che ci permette tramite una piacevole e comoda interfaccia Web di impostare delle regole per filtrare il traffico malevolo e dunque bloccarlo restituendo codici di errore 500 ed evitando che le richieste random o parametriche possano letteralmente impallare il nostro web server, interprete PHP o Database fino a farlo crollare.
Per fare ciò ci si può affidare tranquillamente a CloudFlare che anche nella versione Free (dunque gratuita) permette di avere a disposizione tutti gli strumenti necessari per fare filtering intelligente su diversi fattori.
Successivamente una volte confermato il piano gratuito, il sistema intelligente di scansione dei record DNS andrà a riprodurre la ZONA DNS attuale del nostro attuale nameserver autoritativo per il dominio in questione (in questo caso per esempio pippo.it) al fine di ritrovare tutti i record della ZONA sui nameserver di CloudFlare.
NOTA IMPORTANTE : Attenzione, il sistema intelligente di CloudFlare sebbene molto evoluto non è spesso in grado di individuare record “nascosti” come domini di terzo livello e simili e pertanto è sempre vostro compito e premura accertarvi che tutte le voci utili dell’attuale ZONA DNS siano riportare anche sulla nuova ZONA dei nameserver CloudFlare, preoccupandovi di aggiungere eventuali record che non sono stati individuati.
Vi troverete di fronte una lista di record di questo tipo che rispecchia (o almeno dovrebbe) la vostra attuale ZONA DNS.
La nuvoletta di tipo arancione che può essere attivata o disattivata con un semplice click del mouse sta a significare se per il tipo di record in questione CloudFlare deve concedere l’accesso diretto all’IP del sito reale, quindi svolgendo una normalissima funzionalità di nameserver, oppure se il traffico deve passare attraverso CloudFlare e dunque lavorare in modalità di Reverse Proxy.
Nella modalità di Reverse Proxy, il browser di un eventuale visitatore contatterà l’IP del server di CloudFlare e in base a determinate regole che vedremo in seguito CloudFlare avrà la facoltà di far contattare il sito del cliente o rifiutare la connessione con un codice di errore.
E’ dunque ragionevole qualora si attaccato tramite richieste di tipo GET o POST il webserver, andare a filtrare tutti i record che riconducano al webserver stesso, così come possiamo vedere di seguito il nome a dominio nudo senza www, quello con www e il relativo ftp consapevoli che molto spesso l’indirizzo dell’FTP combacia con quello del webserver e lasciando visibile l’IP dell’FTP l’attaccante potrebbe risalire all’IP originale della macchina che attualmente è dietro CloudFlare.
La configurazione avrebbe pertanto un aspetto così :
Successivamente avanzando nella configurazione e cliccando su continua, CloudFlare inviterà l’utente a cambiare gli attuali nameserver dell’attuale REGISTRAR con quelli forniti da CloudFlare stessa.
Nell’immagine qui sopra ad esempio CloudFlare mi invita a sostituire i nameserver autoritativi attuali alicom.com con i due di cloudflare.com preceduti da un nome che sono spessi univoci per ogni singolo account utente.
Per fare questo dovete avere accesso normalmente al pannello di controllo del vostro fornitore dove avete registrato il dominio e scegliere di sostituire i nameserver originali con questi nuovi, solo una volta propagati a livello mondiale i nuovi nameserver di CloudFlare potrete allora ritenervi sicuri che il traffico Web passi attraverso i sistemi di CloudFlare e non arrivi direttamente al vostro sito senza nessun intermediario in grado di proteggervi e filtrare il traffico malevolo.
NOTA IMPORTANTE : Il cambio nameserver sebbene sia un’operazione estremamente facile, non è un’operazione immediata. Cambiare un nameserver in molte configurazioni può impiegare ore o persino giorni. Per questo motivo sarebbe intelligente qualora abbiate a cuore il vostro sito web di sostituire sin da subito i nameserver del vostro fornitore con quelli di CloudFlare, ottenendo tra l’altro una velocità di risposta alle richieste DNS molto maggiore e avendo la possibilità sin da subito di essere pronti ad attivare le funzionalità di filtering qualora avvenisse un attacco, senza dover aspettare la propagazione dei nuovi DNS e andando ad evitare tutta la procedura fino ad ora indicata.
Un sito web che produce ricchezza dovrebbe usare come nameserver solo i nameserver di CloudFlare.
Usare CloudFlare.
Filtrare un attacco DDOS in generale, ed in particolar modo un attacco Layer7 su un sito Web significa in primis avere una buona capacità di analisi dell’attacco per poter capire cosa filtrare tramite CloudFlare solo il traffico malevolo lasciando passare solo quello sano.
Uno dei maggiori motivi di fallimento nella mitigazione di un DDOS sta nell’adottare il giusto strumento (CloudFlare) ma limitarsi ad attivare l’Under Attack mode pensando che cliccando il bottone “sono sotto attacco” CloudFlare sia in grado di proteggervi facendo tutto da solo. Nulla di più sbagliato.
L’under attack mode di fatto è un sistema che ragiona in modo piuttosto grossolano, pensando che se arrivano molte richieste di tipo GET o POST al sito web, probabilmente queste richieste arrivano da tool di attacco installati su varie botnet che fanno finta di essere un browser web ma non sono di fatto un browser web.
Si aspetta che sia un client in grado di comunicare su protocollo TCP/IP, eseguire un handshake tramite il protocollo SSL o TLS per instaurare una comunicazione di tipo HTTPS e poi proseguire con l’inondare di richieste il target vittima.
Quello che normalmente questi toolkit di attacco non hanno è un’interprete Javascript e pertanto proporre un CHALLENGE (una sorta di quesito) in Javascript ad un client che non ha la possibilità di risolverlo in quanto sprovvisto di interprete Javascript fa si che il client non possa fornire la risposta corretta e così guadagnarsi un TOKEN (che di solito dura 30 minuti ma può essere aumentato dalle impostazioni di CloudFlare) per poter essere in whitelist e dunque raggiungere il sito.
Un sito che ha abilitato l’UNDER ATTACK mode lo riconosciamo facilmente da una schermata introduttiva iniziale come quella seguente e dal tempo di attesa di qualche secondo, tempo utile per risolvere il challenge.
Ma cosa succede se invece le richieste non vengono generate da client grossolani, ma da browser web reali come Firefox, Google Chrome, Internet Explorer, Safari, che sono a loro insaputa dirottati in un numero elevatissimo verso il sito dell’attaccante ? Succede che il loro browser essendo un browser dotato di Javascript a tutti gli effetti sarà in grado di risolvere il Challange, ottenere il token e riuscire a inondare di richieste il sito della vittima.
A questo punto dunque non ci si può più limitare a tenere abilitato l’UNDER ATTACK mode di CloudFlare senza fare null’altro e poi lamentarsi che CloudFlare non funziona. Semplicemente non lo sapete usare. Non basta avere lo strumento per essere padroni ma sopratutto saperlo usare. Questa regola vale in ogni campo della vita, sopratutto in quella professionale.
Cosa filtrare però ?
Quello che bisogna fare è capire come sta avvenendo l’attacco, da dove arrivano le richieste, quali sono i referral, i paesi, i provider, le richieste, le URL che vengono chiamate in modo da individuare con modo chirurgico il traffico malevolo da quello legittimo e lasciar passare solo quest’ultimo.
Per far questo abbiamo bisogno in primis di una certa esperienza nell’analisi delle richieste che arrivano al Webserver andando a spulciarci il log che normalmente si chiama access.log o access_log.
E’ tramite l’analisi di queste richieste che possiamo ad occhio percepire le anomalie di traffico malevolo e dell’attacco e andare a filtrare questo traffico.
Per far ciò abbiamo il modulo FIREWALL di CloudFlare che ci permette di utilizzare alcuni parametri per filtrare in base a delle condizioni tramite operatori logici.
Ad esempio potremmo verificare (matchare) il traffico tramite il paese e decidere di bloccare tutti gli IP che vengono dal Brasile, dall’Iran e dalla Russia, o magari far connettere solo IP che vengono dall’Italia, da San Marino e dalla Svizzera.
Oppure potremmo decidere di far connettere tutti gli IP Europei che non hanno come referral il sito reddit.com, oppure di far connettere tutti i paesi europei eccetto i client che stanno facendo ricerche sul sito con il parametro nella URL ?s=.
Sebbene il piano Free di CloudFlare permetta di definire solo 5 regole Firewall, la combinazione delle stesse tramite l’utilizzo degli operatori logici AND e OR ci permette di definire chirurgicamente qualsiasi pattern per poter decidere se bloccarlo o lascialo arrivare al nostro sito.
Le possibilità di utilizzo e le combinazioni possibili negli scenari reali sono talmente tanti che sarebbe impossibile esaminare tutte le possibilità in questo articolo, ma è bene sapere che tramite opportuna analisi e aggiustando il tiro con un pizzico di intuito, esperienze e bravura si riesce sempre a fermare un DDOS Layer7 riuscendo a tenere in piedi un sito che altrimenti sarebbe andato inevitabilmente down.
L’utilizzo di CloudFlare come soluzione di sicurezza applicativa ci permette di ottenere i seguenti importantissimi vantaggi e modalità di filtering :
1. Filtering a livello di Browser tramite Under Attack Mode
Tramite l’Under Attack Mode di CloudFlare è possibile sottoporre a challenge i browser dei visitatori per verificare se siano veri browser o semplicemente traffico HTTP/S di tool confezionati ad arte per portare DDOS a livello appliativo e forgiare richieste GET o POST malevole. In questa fase si va a discernere i browser degli utenti reali ai tool degli attaccanti bloccando quest’ultimi.
2. Filtering a livello di Referral
In questa modalità utilizzata in alcuni tipi di attacco tramite l’injection di contenuti su siti molto trafficati, possiamo decidere di filtrare l’attaccante andando a determinarne il referral. Qualora infatti l’utente reale provenga da un referral utilizzato come vettore dell’attacco, bloccando il referral con opportune regole firewall bloccheremo anche tutti gli utenti che provengono da quel referral.
3. Filtering a livello di URL pattern
Qualora una botnet decida di chiamare in modalità intensa dei pattern specifici nelle URL o usarne di parametriche per bypassare eventuali sistemi di cache possiamo individuare il pattern e bloccarne l’accesso.
4. Filtering a livello Geografico.
Possiamo abilitare una tipologia di filtering geografico a livello GeoIP che ci permette di sottoporre a blocco o a Challange tramite l’Under Attack Mode le connessioni originate da paesi sospetti. Qualora ad esempio il nostro business sia Italiano o magari Europeo, potremmo decidere di bloccare o sottoporre a Challenge IP Asiatici, Africani, Statunitensi, Russi e via dicendo.
La precisione di questa soluzione è superiore al 99% e permette di attuare politiche di filtering molto aggressive e restrittive qualora ci si trovi di fronte ad una soluzione estremamente complessa da risolvere nell’immediato.
5. Filtering sugli Autonomous System AS
Un sistema autonomo (in inglese Autonomous System), in riferimento ai protocolli di routing, è un gruppo di router e reti sotto il controllo di una singola e ben definita autorità amministrativa.
Qualora fossimo attaccati da Server Dedicati violati e utilizzati come zombie per sferrare l’attacco verso i nostri clienti, potremmo decidere di filtrare tutte quelle connessioni che non appartengono a fornitori che offrono servizi DSL consumer.
Per quale motivo un server di Digital Ocean o di AWS o di OVH dovrebbe fare richieste al nostro webserver dove magari abbiamo in hosting un ecommerce di articoli sportivi ?
Dato che apparentemente non ce ne sono i motivi e si sta subendo un attacco, un’altra possibilità è data da bloccare gli Autonomous System di Datacenter noti che possono essere violati e utilizzati contro.
6. Un MIX dei precedenti metodi in combo
L’utilizzo di operatori logici di inclusione ed esclusione come AND e OR ci permette di utilizzare tutti i precedenti metodi descritti andando ad utilizzare delle condizioni logiche molto complesse che ci permettono di essere chirurgici nell’applicazione di regole di filtering, escludendo falsi positivi e traffico legittimo dalle politiche di filtering e dl dropping che ne consegue.
7. SEO Oriented
Tutte le operazoini di filtering sono SEO Oriented, ovvero adeguate a non bloccare le attività legittime di crawling dei principali Motori di Ricerca come Google e Bing.
Se volete il nostro aiuto e la nostra esperienza per poter mitigare al meglio un attacco DDOS non esitare a contattarci.
