Quali tecniche usano i firewall avanzati per proteggere da DoS / DDoS?

Questi sono davvero due diversi, sebbene simili, attacchi.

Il "normale" DoS si basa sul tentativo di bloccare il server / firewall, attraverso una sorta di bug o vulnerabilità. Per esempio. i ben noti attacchi SYN Flood . La protezione contro questi, sono ovviamente specifici per il difetto (ad esempio i cookie SYN) e la codifica / progettazione sicura in generale.

Tuttavia, DDoS cerca semplicemente di sopraffare il server / firewall sommergendolo di masse di richieste apparentemente legittime.
Sinceramente, un singolo firewall non può davvero proteggersi da questo, poiché non esiste un modo reale per contrassegnare i client "cattivi". È solo una questione di "best-effort", come la limitazione stessa, quindi non si blocca, carica i sistemi di bilanciamento e di failover, tenta di inserire nella lista nera gli IP (se non secondo "cattiveria", quindi in base all'utilizzo ) e, naturalmente, notificando attivamente gli amministratori.
Quest'ultima potrebbe essere la più importante, poiché nei casi di apparente DDoS (dico apparente, perché l'uso regolare di picco potrebbe apparire come DDoS - storia vera) ci vuole davvero un umano per differenziare il contesto del situazione, e capire se chiudere, miglior sforzo, fornire un'altra scatola, ecc. (o impiegare un contrattacco ... ssshhh !!)

La mia esperienza di attacchi DoS e DDoS è basata sull'essere un ingegnere Cisco per un ISP e successivamente come Security Manager per un Global molto grande. Sulla base di questa esperienza, ho scoperto che per affrontare in modo efficace attacchi su larga scala e complessi è necessaria una buona collaborazione tra l'organizzazione sotto attacco e il loro partner di mitigazione ISP o DDoS (Sì, ci sono ora aziende dedicate a questo, in sostanza sono molto grande ISP a pieno titolo ma utilizzare la propria rete globale per assumere il traffico aggiuntivo generato durante un attacco).

Di seguito sono riportate alcune considerazioni se affronti un attacco che è al di fuori della tolleranza della larghezza di banda (ovvero il consumo di larghezza di banda) e hai bisogno di aiuto per rispondere.

Dove non esiste un partner di mitigazione: Stabilire una relazione strong con il proprio ISP. Identifica i team e i contatti giusti che ti serviranno in caso di attacco.

Usa il tuo firewall (o altro dispositivo di registrazione) per ottenere prove dell'attacco (IP sorgente, protocollo, lunghezza del pacchetto, ecc.) in quanto queste informazioni possono essere estremamente preziose per l'ISP nel decidere come rispondere. Non è divertente cercare di intrappolare il traffico su un dispositivo di routing Cisco dalla linea di comando alle tre del mattino! Quindi ogni aiuto è apprezzato. : -)

Con questo approccio il tuo probabile approccio sarà filtrare il traffico all'interno del cloud dell'ISP. Se sei stato in grado di fornire informazioni sufficienti e il traffico è tale, l'ISP potrebbe essere in grado di filtrare il traffico dannoso e lasciare libero traffico di rete valido per accedere alla rete. Tuttavia, se si stanno causando problemi di latenza per l'ISP, è probabile che bucheranno l'intero percorso al loro gateway BGP e scompariranno dalla rete. Ulteriori filtri di routing causano il carico sui gateway, quindi non aspettarti che il tuo ISP aggiunga più filtri in quanto ciò potrebbe avere un impatto sugli altri utenti.

Utilizzo di un partner di mitigazione:

Posso solo parlare dell'esperienza di un fornitore per questo, quindi dovrai fare i compiti per decidere se hai bisogno di questo e, in caso affermativo, chi sarebbe la persona più adatta a fornire.

Il servizio era basato sulla pubblicità del percorso BGP e sul monitoraggio degli attacchi. Una volta identificato un attacco, il partner di mitigazione pubblicizza il percorso per passare attraverso la rete, dove i router principali vengono utilizzati per filtrare il traffico dannoso prima di passare all'organizzazione.

Il mio ruolo in tutto questo è stato quello di testare l'implementazione di un approccio collaborato alla mitigazione DDoS. Ciò ha comportato l'utilizzo di un team globale di ingegneri della sicurezza per generare abbastanza traffico da effettuare per un test valido. Stavamo testando sia la capacità di identificare un attacco e quindi di rispondere in modo efficace. Sulla base di ciò, siamo rimasti molto colpiti dal loro approccio generale e la soluzione ha funzionato.

Un tipo di protezione contro DDOS non eseguita direttamente dai firewall consiste nel distribuire i contenuti della pagina in tutto il mondo in modo che tutte le richieste provenienti da un paese vengano eseguite contro un server locale e le richieste da un altro paese, allo stesso URL o dominio, vengono eseguiti contro altri server locali che distribuiscono il carico tra server locali e non sovraccaricano un server univoco. Un altro punto di questo sistema è che le richieste non viaggiano troppo lontano.

Questo è un lavoro per i DNS e l'infrastruttura si chiama Content Delivery Network o CDN .

Aziende come CloudFlare offre questo tipo di servizi.

Di solito il DDOS viene inviato inviando una quantità enorme di pacchetti al server, in cui il server cercherà freneticamente di processare, naturalmente. Una volta che un firewall rileva un possibile DDOS, può essere configurato per inserire in blacklist qualsiasi client con PPS abbastanza elevato (pacchetti al secondo).

I filtri possono essere attivati e disattivati in qualsiasi momento, in modo che se si verifica un DDOS è possibile attivare un filtro con un set di regole molto severo.

Mi piace rispondere alla prima parte della domanda che è " utilizzare un server con molte risorse (ad es. CPU e memoria) per ridimensionare l'applicazione ". Si consiglia di eseguire il ridimensionamento dell'applicazione prima di eseguire il ridimensionamento del server. Il profilo dell'applicazione può essere suddiviso nei seguenti passaggi:

1. Caricamento test: esegui test di stress sull'applicazione tramite strumenti di test del carico come pylot.
2. Ottimizzazione della query: la seconda attività è l'ottimizzazione della query della query i.e che può funzionare in modo efficiente per un database di piccole dimensioni ma non riesce a scalare per database di grandi dimensioni.
3. Sharding delle applicazioni: distribuzione della maggior parte dei contenuti di accesso sul disco più veloce.

C'è molto da aggiungere a questo elenco e una buona lettura è " Come scalare un'applicazione web "