come mitigare un DDoS da botnet sul tuo sito web che proviene da IP casuali

7

Mi chiedo come si mitiga un attacco ddos proveniente da una botnet e che colpisce URL casuali su un sito web.

Se ci fosse un URL coerente che stava colpendo, sarebbe abbastanza semplice, e non importa che provenga da IP casuali.

Come prevedi un attacco che presenta indirizzi IP e URL casuali?

    
posta Zippy Zeppoli 05.02.2013 - 23:44
fonte

6 risposte

9

La parte difficile è distinguere tra le richieste provenienti dalla botnet e le richieste degli utenti che effettivamente vogliono leggere le pagine. Non esiste un modo affidabile al 100% per farlo in generale, perché alcuni strumenti DDoS sono abbastanza bravi a imitare gli umani, e anche perché la maggior parte degli umani sembra essere abbastanza brava a comportarsi come droni senza cervello. Tuttavia, questo è il nocciolo del problema: devi trovare una caratteristica distintiva tra le richieste botnet e le richieste non di botnet (e se ne trovi una, la botnet del mese prossimo si sarà adattata - questa è una gara senza fine).

Una possibile difesa è richiedere una Prova di lavoro dai clienti. Incorpora nel tuo sito un codice Javascript che esegue un calcolo relativamente complesso, il cui output viene incorporato nella successiva richiesta da quel client. Se fatto correttamente, allora potreste assicurarvi che la botnet abbia bruciato almeno una parte considerevole della CPU nel processo; l'idea è che se DDoSing il tuo server è troppo costoso, allora il botnet master dirigerà la sua ira su un altro bersaglio. Dopo tutto, è un uomo d'affari ...

Non ho visto PoW distribuito in un contesto Web e le idiosincrasie di Javascript potrebbero renderlo difficile (un browser con un interprete Javascript non produrrà molto "lavoro" al secondo), ma il concetto sembra valido.

    
risposta data 06.02.2013 - 00:51
fonte
7

Fai un po 'di lavoro per capire se ci sono dei punti in comune - intestazioni comuni che identificano in modo univoco i bot, ecc. Non dimenticare di cercare le cose che i non hanno - un numero omette campi come Host e Accept-Encoding perché si concentrano sulla richiesta HTTP minima per massimizzare la loro efficacia.

Stai andando a colpire una larghezza di banda o un limite di calcolo - stabilisci contro cui ti trovi di fronte perché probabilmente sei in grado di scambiare uno contro l'altro.

Da lì, hai alcune opzioni. Immagino che le modifiche al DNS non siano abbastanza veloci, che tu stia usando l'hosting che rende difficile cambiare IP e che i load balancer, ecc. Sono fuori dalla fascia di prezzo (altrimenti probabilmente conoscerai le tue opzioni di coping ):

  1. Parla con il tuo ISP; possono avere opzioni di mitigazione che possono abilitare per te. Se puoi dare loro una firma, potrebbero semplicemente bloccarla. Potrebbero essere in grado di aumentare temporaneamente la larghezza di banda disponibile per assorbire semplicemente il DDoS.
  2. Imposta un cookie su ogni pagina legittima. Controlla il cookie sulla pagina 404. Se non vedi quel cookie, la lista nera (se sei a un cap calcolatore) o il blackhole (se è la larghezza di banda che stai esaurendo) l'IP.
  3. Metti in blacklist interi paesi che non hai mai visto nei tuoi registri.
  4. Proof Of Work è un'idea; potrebbe essere molto semplice: calcolare l'ora del giorno in JavaScript in UNIX e impostare un cookie con quel valore. Controlla su ogni pagina per quel cookie, se sei entro 600 secondi, ripristina il cookie sull'ora corrente. Se non lo sei, esegui mentre (1); nel tuo back-end alla fine della tua pagina. Impatto minimo per l'utente (la pagina è funzionale, ma sembra caricarsi per qualche motivo per sempre).
  5. Ottimizza le tue pagine. Se è possibile, passare temporaneamente a una configurazione HTML totalmente statica (è abbastanza buona pratica avere un interruttore che lo faccia comunque su un sito grande, in caso di improvvisa popolarità). Ciò potrebbe ridurre il tempo di elaborazione a sufficienza, in modo che il DDoS non bruci il server. Ciò elimina il tempo di elaborazione a favore della larghezza di banda, quindi aumenterà il throughput.
  6. Fai il contrario di 5 - se disponi di molto tempo di calcolo disponibile, rallenta la risposta 404. Aggiungi un sonno di 60 secondi a quello che stai usando per generare la pagina, mantieni il socket aperto il più a lungo possibile. Ciò elimina la larghezza di banda in favore del tempo di elaborazione, quindi diminuirà l'utilizzo della larghezza di banda e aumenterà il carico.
risposta data 06.02.2013 - 08:47
fonte
3

Gli attacchi DDoS riescono principalmente esaurendo la larghezza di banda, non evitando il rilevamento dall'applicazione o dall'infrastruttura. Il modo migliore per sconfiggere gli attacchi DDoS, quindi, è catturarli a monte, e molti ISP offrono prodotti di attenuazione DDoS specificamente progettati per questo.

    
risposta data 06.02.2013 - 02:26
fonte
1

Se gestisci il tuo DNS, "views" (o DNS split-horizon ) può essere molto utile come prima difesa, devi comunque avere una whitelist, che è dove il tuo storico i registri del server web entrano. Potresti anche creare una lista nera, se puoi riconoscere i problemi dei client . I client sospetti o non autorizzati ottengono 127.0.0.1 (o in qualche modo non rintracciabile) con cui parlare, tutti gli altri ricevono gli indirizzi IP reali.

Il prossimo passo è assicurarsi di aver letto questi:

A seconda della piattaforma, potresti anche essere in grado di ottimizzare il tuo sistema (cookie SYN, filtro HTTP accetta,% co_de di Apache o opzioni di terze parti come mod_reqtimeout ).

    
risposta data 06.02.2013 - 01:55
fonte
0

Sarebbe meglio se potessi usare un firewall hardware. Altrimenti, avrai bisogno di un'opzione software come questa link

    
risposta data 06.02.2013 - 00:43
fonte
0

Alcune persone hanno suggerito uno schema di prova del lavoro Javascript.

In realtà ho visto uno schema di prova di lavoro in natura. Il supermercato britannico Sainsbury ne usa uno su www.sainsburys.co.uk .

Il grosso problema è che gli hacker sono liberi di utilizzare qualsiasi strumento che preferiscono, in modo che possano scrivere uno strumento di cracking che funzioni a velocità nativa. Nel frattempo, gli utenti legittimi potrebbero essere bloccati utilizzando una versione obsoleta di IE.

Sul sito di Sainsbury, i cracker nativi erano circa 100 volte più veloci di IE6, quindi non è un gran vantaggio.

Ci sono altre informazioni su questo post del blog .

    
risposta data 01.03.2013 - 18:49
fonte

Leggi altre domande sui tag