Come eseguire un corretto test DDoS in modo sicuro e controllato?

Se si sta eseguendo il test di carico ad alte velocità di pacchetti, il modo più sicuro è isolarlo completamente dal resto della rete. Ad esempio, puoi collegare due server tramite il collegamento diretto da 10 GBps senza switch e utilizzare un'altra connessione LAN sul server di benchmarking su ssh su un server per eseguire il test.

Un altro modo è eseguire il provisioning dei server in Public Cloud come AWS per un breve periodo di tempo ed eseguirlo lì. Non rischi di avere un impatto sulla tua infrastruttura. Va bene farlo, le infrastrutture cloud sono resilienti, quindi se invadete il vostro server con pacchetti è solo un po 'più di traffico. Ovviamente, se fosse opportuno eseguire il provisioning di una macchina grande, veloce o addirittura dedicata, in modo da poter vedere realmente quanto carico il software impiega.

Riguardo al software, puoi usare generico ab che è "Apache Bench" e fa parte dei pacchetti Apache. Puoi testare la resilienza del tuo server web (file statici da httpd) e server delle applicazioni (quelli dinamici da PHP, Ruby, Java). Potresti cercare altri software di test di carico professionali per protocolli specifici che potrebbero includere test di streaming di API e video. Ce ne sono molti a seconda del protocollo che si sta utilizzando (come REST, ecc.)

Quindi procedi con la normale messa a punto dello stack di rete e l'ottimizzazione delle applicazioni per ottenere maggiori prestazioni (lo stesso sul lato client come ulimit ). Tieni traccia dei tuoi risultati. Inoltre, prova ad analizzare correttamente i log con entrambi i software gratuiti come AWStats o Sawmill commerciale. Evita l'uso di grep ;-) Analytics ti mostrerà risultati reali. Tieni inoltre presente che ab è valido per httpd , ma a volte ha problemi con altri server web. E in AWS puoi usare Load Balancer che mostra anche le statistiche in tempo reale. Registra le statistiche di rete con Nagios, Zabbix, ecc. Per vedere come viene eseguito lo stack di rete (ad esempio connessioni interrotte, velocità dei pacchetti, utilizzo della CPU, ecc.)

Non assumere mai attacchi DDoS poiché si tratta di bande criminali e rischi molto, non solo legalmente per te stesso ma anche per il tuo ISP, la tua azienda e i tuoi clienti.

Il singolo piano migliore non è quello di fare questo. Raramente serve a qualcosa, dato che DDoS funzionerà contro di te. Questo è un dato. È così facile creare un attacco ad alto volume ora che non vale nemmeno la pena provare a fare più dei soliti test di carico.

Sei molto meglio servito implementando la mitigazione DDoS.

Se, tuttavia, è necessario eseguire un test, provare quanto segue:

• prova una copia non di produzione
• costruisci un moltiplicatore in test di carico durante l'esecuzione di OAT / UAT prima di go-live

Fondamentalmente, il modo in cui un Denial of Service distribuito funziona è inondando la larghezza di banda di una società con molto traffico. Gli attacchi effettivi potrebbero differire in base all'origine e allo stile, ma condividono lo stesso obiettivo. Non ha senso testare un attacco DDoS, perché non importa quanta larghezza di banda hai è sempre possibile che sia sopraffatta. Dipende interamente dalle capacità fisiche dell'hardware.

Ora, questo non vuol dire che non c'è modo di mitigare un DDoS. È possibile acquistare servizi da varie società in grado di rilevare un DDoS e inviare il traffico a un centro di lavaggio per consentire solo il traffico legittimo. Tuttavia, questi servizi sono ancora limitati dalla quantità di larghezza di banda che scorre nelle loro apparecchiature. A differenza di altri attacchi di tipo Denial of Service, non esiste una correzione software per un DDoS.

Non cercare di assumere servizi per DDoS sulla tua rete. Questi servizi sono nel migliore dei casi legalmente discutibili, e nel peggiore dei casi sono il crimine organizzato. Se insisti a testare la tua rete, altre risposte forniscono modi perfettamente ragionevoli per farlo.

Oltre a chiedere al come dovresti considerare di chiedere al perché .

Caso 1: volete verificare in che modo il vostro servizio sarà influenzato da un DDoS - questa è probabilmente una cosa ragionevole da fare. Direi che questi sono test di carico portati all'estremo.

In tal caso è necessario testare un clone dell'intero servizio, compresa l'infrastruttura. Non si sa cosa fallirà tra il frontend del servizio in una DMZ e il database di back-end in una LAN. Può essere l'applicazione, un firewall sulla strada, il database, ... Come puoi immaginare, non sarà un compito semplice e il risultato potrebbe non essere interessante.

Non hai bisogno di un DoS D per quello - sarà sufficiente un DoS multiplo (sei interessato solo dal carico)

Caso 2: vuoi valutare le tue capacità di resettare un DDoS - in tal caso il test è inutile.

Se l'attacco è basato sul volume (al contrario di qualcosa come SLOWLORIS ) allora il momento in cui rilevi un pacchetto in arrivo, è troppo tardi. Ci sono aziende che vendono alcuni apparecchi vaporosi che risolvono magicamente il problema ma non funzionano ^* .

Devi bloccare questo attacco a monte, quindi

• dovresti parlare con il tuo ISP per il black-up del traffico a monte (utile passivamente, forse per evitare un crash più avanti nell'applicazione)
• o cercare soluzioni basate su cloud che possano funzionare o meno - sono in pratica la tua unica soluzione (il tuo ISP può fornire anche questa soluzione).

^* l'idea è che saranno abbastanza veloci (= molto più veloci delle capacità di elaborazione del servizio) per decidere se un pacchetto è "abbastanza buono" o non essere accettato. Oltre alla capacità di decidere correttamente, la premessa si interrompe quando la tua pipe di rete è piena.