Come mitigare gli attacchi DDoS basati su SSL?

Esaminiamo un paio di idee sbagliate:

• I partner di mitigazione DDoS non possono funzionare a meno che non possano decrittografare il traffico

Sì, possono - ma non possono farlo anche perché il contenuto non è visibile, quindi le soluzioni che funzionano sul flusso di traffico continueranno a funzionare.

• Consegnare la tua chiave a una terza parte è una cosa negativa

Non necessariamente. In realtà questo è estremamente comune per le grandi aziende - che in genere hanno la loro infrastruttura gestita da terze parti comunque. Quello che fa è richiedere che tu sostituisca alcuni dei tuoi controlli tecnici con i controlli contrattuali e che tu assuma maggiori responsabilità di supervisione / controllo sulla terza parte.

Attenuare la minaccia della terza parte che abusa la chiave, o non proteggerla è semplice da valutare e quindi fornire una soluzione per.

Gli attacchi SSL DDoS dovrebbero essere divisi in due:

• Attacchi impropri al protocollo - Tali attacchi sfruttano il protocollo in uso e possono causare un effetto denial of service senza completare la creazione di una connessione sicura (SSL nel nostro caso). Un buon esempio può essere il THC-SSL-DOS che può essere utilizzato per creare la "rinegoziazione" ripetuta nella stessa connessione, senza però completare la creazione di un canale sicuro.
  Gli attacchi al protocollo, come quello sopra menzionato, non richiedono l'uso di chiavi. Possono essere mitigati con misure di protezione relativamente semplici come la firma IPS, l'applicazione delle impostazioni del server, o persino le appliance DDoS dedicate Pravail / Riorey / DefensePro / NSFocus / etc.

• Flood di traffico SSL - Qui mi riferisco ai dati che vengono passati sul canale sicuro creato. Senza ulteriori informazioni, questi magnifici dispositivi di mitigazione non sono in grado di distinguere tra connessioni valide a connessioni dannose. Non riescono nemmeno a pubblicare una sfida sul Web nel tentativo di valutare la legittimità della fonte. Quindi non sei bloccato con niente o con una protezione dai limiti di velocità - incline a false azioni.

Quindi, cosa si può fare - Alcuni apparecchi possono essere alimentati con i certificati o essere connessi a un altro dispositivo della stessa famiglia (DefensPro-Alteon / Pravail-VSS) - dove il prodotto sorella apre la crittografia e il dispositivo ddos fa quello che fa e il flusso è permesso di continuare o è bloccato. Radware può lanciare una sfida sulla richiesta crittografata iniziale (e solo su di essa). Arbor può ispezionare continuamente il traffico crittografato e bloccare il traffico sospetto (nessuna sfida). Finché mantieni queste macchine al tuo posto, i rischi sono piuttosto bassi.

Alcuni servizi cloud ti offrono di dare loro le tue chiavi. Pratica non molto raccomandata Tuttavia, recentemente la Prolexic ha pubblicato che possono vivere con chiavi temporanee a breve durata per ottenere lo stesso risultato. Questa potrebbe essere una soluzione sufficiente, considerando tutte le altre limitazioni e restrizioni quando si tratta di traffico protetto (crittografato).

E ultimo - è male fornire la chiave? In un modo molto semplice - La tua chiave è importante per proteggere le tue comunicazioni. Se qualcuno ha la tua chiave, può teoricamente "leggere" le tue comunicazioni o impersonarti mentre comunichi con gli altri. Tuttavia, come qualcuno ha risposto prima di me, puoi esercitarti a condividere o avere copie delle tue chiavi in posti diversi. Dipende dalla tua infrastruttura, da chi gestisce la tua rete, ecc. Soprattutto si riferisce alla FIDUCIA. Se ti fidi di questa protezione DDoS "nata ieri" nel servizio cloud, fai un salto, dai loro le chiavi :). Ci sono aziende di cui ci si può fidare e che si impegnano a rispettare tutti i requisiti normativi. Non fornisce un'assicurazione al 100%, ma francamente, nulla lo fa.

Tutti i fornitori ti daranno la stessa risposta: devi consegnare la chiave a loro sia per un prodotto di sicurezza basato su cloud, sia per una scatola che forniscono che si trova nella tua rete. In ogni caso, non è possibile mitigare completamente la minaccia di avere le chiavi.

L'alternativa è quella di attenuare le minacce poste dai singoli attacchi di:

• Mantenimento dei sistemi e delle applicazioni aggiornati: molti attacchi ddos precedentemente gravi sono stati eliminati dagli aggiornamenti del sistema operativo e del software
• Modifica delle configurazioni: spesso è possibile ottimizzare il sistema operativo e le applicazioni per renderle molto più resilienti
• Offload computations SSL: ci sono diverse soluzioni in quest'area, spesso i load balancer hanno motori criptati che possono fare il lavoro

Quello che devi veramente fare è eseguire (o fare eseguire qualcuno) un'analisi delle minacce per scoprire le tue maggiori preoccupazioni, quindi cercare soluzioni a quelle. Può essere una soluzione di venditore è la tua migliore strada da seguire, o potresti essere in grado di fare bene usando soluzioni tattiche, a zero oa basso costo.

La risposta di Ichilov è più pertinente.

Due attacchi SSL non vulnerabili

1. Invia i dati inutili al posto del segreto pre-master (flooding SSL Handshake)
2. Riaffronta continuamente il segreto per maestro dall'handshake di nuovo & ancora una volta

Spero che l'esplosione di Ichilov sia abbastanza

Mitigazione:

• Il puzzle del client può aiutare a mitigare gli attacchi DDoS. Il cliente si puzzle meccanismo potrebbe essere sviluppato per il protocollo. È basato su Sistemi di prova della manodopera. Per SSL è disponibile un Draft IETF all'indirizzo link . Il meccanismo Puzzle-Puzzle è un meccanismo di sicurezza basato sull'intento che non elimina semplicemente i client dannosi, ma aumenta il costo dell'attaccante. Anche questi meccanismi sono più efficaci contro mitigazione basata su firma, che impiega sistemi IDS / IPS con enorme quantità di regole.

• L'altro metodo è esternalizzare il calcolo dell'esponente modulare, un'operazione ad alta intensità di risorse. Un calcolo parziale può essere esternalizzato a un sistema demone. Altrimenti, un sistema con può essere usato crypto-chip. L'outsourcing può migliorare le prestazioni di il server, ma non elimina il client dannoso.

Ho già sviluppato un meccanismo client-puzzle per lavorare con HTTP. Inoltre ho pianificato di sviluppare per SSL. Spero, potresti sentire l'articolo interessante. link

Esistono modi e mezzi per monitorare gli handshake TCP e SSL per determinare un comportamento errato prima di decrittografare / scaricare effettivamente.

Guarda il client / server ciao per la conformità non RFC e considera la limitazione della frequenza per le inondazioni 'ciao' basate su questo.

HTH.