Diciamo che gestisci un negozio. Ogni giorno potresti ricevere centinaia di clienti.

Un giorno, ricevi decine di migliaia di persone che entrano nella linea del check-out, comperano un gingillo e poi tornano in fila per ripetere.

Ovviamente, stai perdendo affari da clienti autentici che devono aspettare ore in fila.

Ora assumi una guardia di sicurezza all'ingresso per verificare che questi clienti soddisfino alcuni criteri.

Tuttavia, ci sono ancora decine di migliaia di persone che vogliono entrare. L'unica differenza è che ora tutti devono passare attraverso la sicurezza.

Hai notato che, dal punto di vista del cliente autentico, stai ancora aspettando ore in fila, solo che ora è solo per superare la sicurezza!

TL; DR I molteplici IP di origine sono ciò che li rende così difficili da difendere.

Per la risposta più lunga guardiamo il nome. D attacco DoS. Quel primo D sta per distribuito. In altre parole, non esiste un IP da bloccare. O due, o tre o anche quattro .. Ci sono centinaia o migliaia di IP unici.

Solitamente gli attacchi DDoS provengono da un hacker che controlla una botnet o una rete di macchine zombi. L'attaccante invierà un comando a tutti i robot che li istruiscono a fare richieste per una particolare risorsa / URI. Il gran numero di richieste travolge il server e lo abbassa.

Oltre all'eccellente risposta di @ Hollowproc, gli "indirizzi" effettivi usati come fonti sono spesso falsificati in un attacco come questo. Un host attaccante può fingere di essere un numero qualsiasi di altri IP, specialmente in un attacco basato su UDP come viene usato contro i provider DNS.

C'è una soluzione per questo chiamato BCP 38 o Network Ingress Filtering. Se tutto il mondo si riunisse, avesse una coca cola e implementato i controlli per bloccare gli indirizzi spoofed in cui entrassero nella rete, questi attacchi non potevano più contraffare il traffico. Gli stessi Dyn hanno menzionarlo come utile difesa .

Si noti che l'implementazione di una difesa in molti punti sorgente ha il vantaggio di essere scalabile; i requisiti dei singoli blocchi non sono onerosi in termini di dimensioni. Tuttavia, sono onerosi nel fatto che più persone debbano fare la cosa giusta su qualcosa che non ha un impatto diretto e negativo su di loro ... la natura umana ha, per oltre un decennio, impedito a questa soluzione di raggiungere una massa critica.

È possibile che l'impatto crescente degli attacchi DDoS stimolerà una maggiore adozione di Network Ingress Filtering ... Internet considera il danno come una censura, e le rotte intorno a esso:)

Il problema con un DDoS è in due parti:

1) Poiché i robot sono così numerosi, non devono avere un throttle di richiesta all'altezza di un singolo bot e quindi non sono facili da riconoscere come bot.

2) Tutto ciò che vedi sono gli indirizzi IP (e User-Agent s a seconda di come filtri il traffico bot). Qualsiasi indirizzo IP potrebbe essere un bot DDoS e qualsiasi indirizzo IP potrebbe essere un visitatore legittimo. Alcuni indirizzi IP avranno sia un bot DDoS che un visitatore legittimo. Che cosa fai?

Diciamo che il tuo sito può gestire 1000 req / se un visitatore non fa mai più di 10 req / s. Un bot a 100 req / s è facile da bloccare, dieci bot a 100 req / s sono facili da bloccare. Ma 200 bot a 5 req / s sono difficili da bloccare, perché si comportano correttamente.

200 bot a 100 req / s sono difficili da bloccare, perché non possono nemmeno fare più di 5 req / s, facendo sembrare che si comportino correttamente. Questa situazione è di gran lunga peggiore di 200 bot a 5 req / s, perché un visitatore è ora 10 su 10010 richieste che cercano di spremere nella connessione piuttosto che 10 tra 1010 più gestibili che stanno raggiungendo con successo il server.

1000 bot a 100 req / s renderebbero improbabile per ogni visitatore reale connettersi al sito. E un attacco di questa portata causerà problemi anche altrove.

Una difesa strong per il tuo sito è un'arma strong per un attaccante:

Se il tuo sito blocca gli indirizzi IP (o anche i browser specifici sugli IP) se si comportano male, qualcuno potrebbe decidere di abusare della tua difesa per provocare un attacco DoS sul lato client.

Esempio: Mallory crea una pagina web che ha un centinaio di "immagini" con margin-left: -1000em; width: 1px; height: 1px; e tutte quelle immagini sono degli URL "sensibili" sul tuo sito. Quando un visitatore visita la pagina di Mallory, invierà 100 richieste abusive al tuo server e quindi verrà bloccato.

Quindi ottenere una difesa più aggressiva contro gli attacchi DoS (D) causerà anche un'altra vulnerabilità.

Una difesa "intelligente" come i CAPTCHA (per dare ai visitatori la possibilità di dimostrare che sono anche visitatori e non solo robot dannosi) avrà anche l'effetto collaterale di richiedere effettivamente risorse del server.

Caricare le immagini quando la connessione è intasata non sembra un'ottima idea. Non ricorda nemmeno un numero enorme di sessioni per i CAPTCHA, CAPTCHA a cui non verrà data risposta, parzialmente perché le immagini non possono essere inviate, in parte perché la maggioranza dei visitatori non è umana.

E su un sito dinamico (altamente o non assegnato), starai giocando a fuoco con la benzina.

Supponiamo che tu stia ospitando un servizio di qualche tipo, il cui scopo principale è quello di servire una particolare posizione geografica, e assumiamo che tu l'abbia fatto con alcune regole di accesso basate su indirizzi IP.

UDP

Ora, se UDP viene utilizzato in quel contesto, chiunque abbia una conoscenza di uno strumento di elaborazione dei pacchetti (ad esempio scapy) può falsificare l'IP legittimo a cui è consentito l'accesso e, se si opta per l'approccio di blocco, si bloccherà il legittimo utenti dall'accesso al servizio.

TCP Allo stesso modo, gli attacchi DDoS TCP simulati (ad esempio syn flood) possono far soffrire un vero utente se viene seguito l'approccio blacklist attivo.

Quindi per gestire DDoS è meglio applicare un filtraggio accurato, utilizzando dispositivi abbastanza intelligenti da distinguere tra traffico originale e attacco da DPI o altri algoritmi.

CDN, NAT, PROXY

Se gli utenti sono dietro una CDN o qualcosa del genere, il blocco di un utente può far soffrire l'intero gruppo dietro il proxy.

Inoltre, " indipendentemente dall'indirizzo IP o dal contenuto del messaggio o da qualcos'altro, " come hai detto, affinché i router siano in grado di filtrare in base al contenuto, ciò ostacolerebbe le sue prestazioni di routing. Ma sì, ci sono ancora dei router per farlo (ad esempio, NBAR), e tutto ciò che si può applicare all'interno dei suoi locali.

E il blocco dovrebbe essere su una base più specifica.

Altri hanno fornito ottime risposte riguardo alle sfide tecniche legate all'attenuazione del DDoS, la mia risposta qui si concentrerà su ciò che accade una volta che hai costruito la capacità di filtrare il DDoS bloccando un gran numero di indirizzi IP sul tuo sito.

Il blocco di un numero elevato di indirizzi IP non è sempre auspicabile. Bloccando un gran numero di indirizzi IP a causa di un DDoS di grandi dimensioni, si potrebbe bloccare un numero elevato di utenti legittimi che potrebbero condividere tali indirizzi IP come un effetto collaterale indesiderato (ad esempio Tor, utenti proxy, università, famiglie condivise, ISP che utilizzano NAT per salvare gli indirizzi IP pubblici).

Questo potrebbe non essere un problema per i piccoli siti personali, ma per un certo numero di siti in cui gli utenti hanno legittimo bisogno di un grave anonimato, affermano siti che si rivolgono ad attivisti politici, LGBT, servizi femminili nei paesi oppressivi, abusi domestici , ecc. Il semplice blocco IP sta essenzialmente cadendo nel trucco di chi attacca per questi siti. Negando il servizio di anonimato agli utenti che accedono al tuo servizio, potresti impedire agli utenti legittimi più vulnerabili di accedere in modo sicuro al tuo sito e raggiungere l'obiettivo dell'attaccante così come l'originale DDoS.

Non esiste una soluzione semplice o singola agli attacchi DDOS, perché possono essere eseguiti in molti modi diversi. La natura della tecnologia dietro Internet non si presta a nulla se non di essere completamente aperta. Ci sono un sacco di patch e soluzioni per aggirare la sicurezza e mitigare un sacco di problemi. In bilico, è molto più difficile proteggere un sito o una rete da un attacco piuttosto che attaccare. Questo è solo lo stato della sicurezza oggi.

Per l'attacco a livello di rete (come di nuovo il DNS più recentemente per Dyn), Network Ingress Filtering come accennato prima, sarebbe stato utile. Questo almeno aiuta con il problema dello spoofing.

Un problema più urgente con questo tipo di attacco, tuttavia, è la scala. Con il numero di sistemi infetti in una botnet per un attacco considerevole che raggiunge decine di migliaia, se non centinaia di migliaia di sistemi, fare il blocco basato su IP non è ragionevole. Sei in alto nella catena di rete hai bisogno di bloccare per sopravvivere se si blocca? L'attacco DDOS di Krebs è stato dichiarato essere nella gamma da 600 Gbs. Potete voi o il vostro fornitore gestirlo (o anche solo un più tipico nella mia esperienza 10-120 GB) In ogni caso, stai giocando a whack-a-mole a quel punto, poiché una volta bloccato l'attaccante probabilmente passerà a un altro set di macchine sfruttate con IP diversi.

Se decidi di giocare al gioco di reputazione IP < cough > CloudFlare < cough & gt ;, puoi fare cose stupide come bloccare il blocco di grandi fornitori, ad es. Pokemon Go fa cadere la maggior parte / tutto il traffico dal Belgio. Ancora una volta, questo è solo whack-a-mole e non una soluzione praticabile.

Parliamo più in alto nello stack. Gli attacchi ai servizi Web, come il riempimento di credenziali o lo scraping, spesso assomigliano al traffico legittimo. Gli script kiddie di Junior-league avranno la firma del browser whack che potresti cercare, ma cose come Sentry MBA o anche PhantomJS imiteranno i browser corretti che sconfiggeranno questa semplicistica stampa di intestazione HTTP / ID del browser HTTP. I migliori attaccanti simuleranno persino l'uso corretto del mouse e della tastiera, oscurando ulteriormente la loro natura automatizzata.

I captcha sono costosi sia dal punto di vista dell'implementazione (risorse sui server o outsourcing $$). Quelli semplici possono essere sconfitti con algoritmi ragionevoli di rilevamento delle immagini. I captcha più complessi iniziano a far incazzare gli utenti e possono causare problemi di accessibilità per gli utenti ipovedenti. Esistono anche sistemi che sconfiggono efficacemente i captcha tramite turk meccanico direttamente (casse di persone pagate pochi centesimi sul captcha) o indirettamente (captcha dal tuo sito riceve risposta da un utente ignaro su un altro sito).

In ogni caso, poiché gli attacchi sono su più fronti, è necessario un approccio su più fronti alla difesa. I grandi operatori sono addirittura passati all'offensiva, poiché Microsoft ha collaborato con l'FBI per prendere il controllo e bloccare i botnet. Sfortunatamente, l'IoT ha appena aperto un'intera nuova serie di sistemi che escono allo scoperto per essere sfruttati.

Il genio degli attacchi DDoS deriva dal fatto che il traffico proviene da IP potenzialmente LEGITTIMI di clienti reali.

Diciamo che una persona normale che vive negli Stati Uniti potrebbe aver compromesso il router e averlo usato per DDoS. La società vittima ha bloccato completamente l'indirizzo IP, ora quella persona non è in grado di connettersi al servizio Web dell'azienda perché la società ha bloccato l'IP interamente, eliminando un IP potenzialmente valido dall'accesso di nuovo ai propri server.

Questo era un semplice esempio, ma immagina che un'università abbia pochi IP NAT per la navigazione sul Web e che un'azienda abbia bloccato alcuni di questi IP NAT durante una mitigazione DDoS. Ora decine di migliaia di persone su quel campus potrebbero perdere la connettività con i server di quella società, il che è catastrofico per gli affari.

Per non parlare degli attacchi DDoS abbastanza grandi possono impiegare una quantità pazzesca di diversi indirizzi IP.

Non è facile distinguere tra un traffico normale e un traffico DDoS.

Gli DDoS possono essere spiegati in parole semplici come -
Come essere umano, posso solo discutere (fare una chiacchierata) di cose con una persona alla volta e se 10 di persone mi parlano allo stesso tempo, allora non lo farò essere in grado di rispondere a nessuno di loro e sarò nello stato non disponibile per tutti loro.

Gli attaccanti di solito generano l'attacco DDoS da macchine compromesse (noto anche come ** bot). Potrebbe essere il caso che al momento della stesura della risposta della tua domanda, la mia macchina possa coinvolgere in un attacco ddos verso qualche destinazione (se la mia macchina è compromessa, anche se il suo caso è molto inferiore).

Come spiegato, non esiste una soluzione in bianco e nero disponibile per il controllo (o bloccando) attacco ddos.

Come spiegato da @gowenfawr, se il pattern di attacco di ddos è di udp, l'implementazione di URF a livello di ISP su Internet può aiutare a bloccare il traffico spoofed e quindi aiutare a controllare l'attacco di ddos.

La vera storia qui

Vendevamo un piccolo sistema di telecamere. Era un marchio di grande nome e la fotocamera non era spettacolare, ma costava comunque una quantità decente. Un giorno, qualcuno ci ha chiamato per un addebito sulla loro carta di credito. Venuto fuori qualcuno l'aveva ottenuto e usato per comprare una di queste macchine fotografiche e l'aveva spedito a qualcuno che probabilmente le aggregava e le bloccava direttamente o le spediva alla folla.

Essendo un amministratore intraprendente, ho scavato nei log per capire da dove proveniva la frode. Ne ho trovato uno da un IP africano, ma il resto degli ordini sospetti aveva tutti IP americani. Di fatto, venivano tutti trasmessi tramite server compromessi nello stesso datacenter in cui si trovavano i nostri server Web. Oltre a segnalarlo all'host, non c'era nulla da fare. Chiunque ha fatto questo è stato tirando le corde tramite macchine compromesse. Non c'è modo di proteggersi da questo genere di cose guardando la fonte della rete stessa. Non sai mai dove o quando qualcuno verrà compromesso e il loro IP diventerà un'arma.

Il recente attacco su Dyn ha mostrato solo quanto è stupido ora

The botnet, made up of devices like home Wi-Fi routers and Internet protocol video cameras, is sending massive numbers of requests to Dyn's DNS service. Those requests look legitimate, so it's difficult for Dyn's systems to screen them out from normal domain name lookup requests.

E

They're tough attacks to stop because they often get channeled through recursive providers. They're not cacheable because of the random prefix. We started seeing random prefix attacks like these three years ago, and they remain a very common attack. If IoT devices are being used, that would explain the size and scale [and how the attack] would affect: someone the size of Dyn.

Con il decollo di IPv6, presto potresti avere miliardi di dispositivi, ciascuno con il proprio IP, con cui lavorare. L'ambito è troppo grande per filtrare efficacemente.

Un protocollo che consente a "qualcuno" di dire alle infrastrutture internet / backbone di smettere di accettare / inoltrare il traffico da determinati indirizzi significa semplicemente che questo "qualcuno" non avrebbe nemmeno bisogno di impiegare tecniche DDOS per mettere fuori linea chiunque desideri. Senza una "autorità centrale che non esiste", sarebbe difficile trovare un accordo su chi dovrebbe avere fiducia in questo tipo di potere.