Ridurre l'impatto dell'attacco DoS su login cpu-costosi?

Questo è un seguito alla mia domanda precedente: Impedisci il DOS contro l'autenticazione RSA . Questa domanda riguarda anche un problema simile: Prevenire il rifiuto di attacchi di servizio contro le funzioni di hashing lente? .

La mia configurazione è client-server con socket semplici e un protocollo personalizzato. I programmi client sono forniti con una chiave RSA pubblica e i server hanno la controparte della chiave privata.

In generale, le connessioni sono permanenti, quindi gli accessi sono in realtà rari, tranne durante i riavvii del server, problemi di rete e altri problemi che potrebbero causare la disconnessione e la riconnessione di una grande quantità di client. In altre parole, un attacco "DDoS" potrebbe semplicemente essere un tentativo di riconnessione dei client ...

The current (DoS-friendly) handshake works as follows:

1. Client sends [protocol-version] [public-key encrypted nonce].
2. Server unpacks nonce.
3. Server generates its own nonce and uses PBKDF2 to derive a key using the client nonce and its own nonce.
4. The server responds with [reply-code] [server-nonce] [AES encrypted packet + HMAC]
5. Client checks the reply-code. If ok, takes the server-nonce and derives the key and checks that everything is ok by decrypting the encrypted payload using the new key.
6. Encrypted communication commences using this newly created key.

Il problema è che una grande quantità di connessioni consumerà molte risorse della CPU. Ciò influenzerà entrambi gli utenti già registrati, ma rallenterà anche gli accessi, causando il timeout degli accessi, che a sua volta causerà ancora più disconnessioni e accessi.

È facile vedere che anche senza intenti malevoli, i server non sono stabili con un carico di accesso ragionevolmente alto se la decrittografia è costosa.

Al fine di mitigare questo, ho posto la domanda di cui sopra: Prevenire il DOS contro RSA autenticazione , che ha suggerito ECDH di ridurre il costo degli accessi.

Questo è un buon inizio, ma potrebbe non risolvere correttamente il problema, in cui un DoS non solo previene gli accessi, ma anche peggiora l'esperienza degli utenti già registrati.

Ho provato a elaborare alcune strategie che potrebbero essere di aiuto indipendentemente dall'algoritmo di handshake utilizzato, e mi piacerebbe sentire quali sarebbero consigliate, e se trascuro qualche strategia utile.

1. Limita l'utilizzo della CPU di accesso accodando i decrittografi su un singolo (o pochi) thread a bassa priorità. Se la coda è grande, i clienti possono essere rifiutati o tenuti in attesa con aggiornamenti periodici.
2. Aggiungi un server di login, che serve i client con le chiavi, simile all'handshake in alto, ma al client viene anche assegnato un identificatore con questa chiave. Il client può quindi accedere ai normali server presentando l'identificatore, in quanto il server sarà in grado di recuperarlo. (La presentazione dell'identificatore e il recupero della chiave dal server di login sostituiscono 1-3 nel protocollo di handshake). Qualsiasi DoS influirebbe solo sul server di login.
3. Ancora un server di login, ma utilizzando HTTPS anziché lo schema RSA personalizzato per la distribuzione della chiave + identificatore al client.
4. Login server come (2) ma richiede al client di presentare un hashash con la richiesta (e il server di login non elabora i dati crittografati a meno che non sia valido)
5. Accedi al server come (2), ma usa invece un enigma del client emesso dal server.

Meriti e svantaggi (come li ho capiti):

(1) Può essere utilizzato sia con i normali server che con un server di login.

L'uso di (2) complicherà un po 'l'accesso, ma rende banale il fatto che i giocatori non siano influenzati da un attacco DoS sull'algoritmo di autenticazione.

Ho il sospetto che (3) renderebbe più facile l'uso con un sistema DDoS come Cloudflare, tuttavia è a mia conoscenza che (4) e (5) è impossibile da usare con HTTPS, che è uno svantaggio.

Indipendentemente da ciò, qualsiasi schema deve essere abbinato ai meccanismi standard che impediscono attacchi DoS per singola macchina, come il divieto di riconnettere rapidamente gli IP. Anche selezionare un algoritmo di autenticazione più economico ti aiuterà molto.

Modifica

Per riepilogare

• La mia attuale stretta di mano non può gestire una quantità sufficiente di connessioni simultanee perché la decifrazione RSA consumerà quantità eccessive di CPU.
• Mi piacerebbe conoscere i soliti metodi per ridurre questa vulnerabilità, sia a livello di handshake (algoritmi più economici, puzzle del client, CPU limitata per la decrittazione, ecc.) sia a livello di server (servizi di accesso separati ecc.). I collegamenti a documenti / libri sarebbero fantastici.
• Inoltre, sarei grato se potessi ottenere una valutazione positiva / negativa delle strategie (1-5) sopra menzionate.

EDIT 2

Queste sono connessioni persistenti che eseguono un protocollo personalizzato. Ciò significa che migliaia di clienti legittimi possono essere connessi contemporaneamente.

Se un utente malintenzionato riesce a soffocare temporaneamente la larghezza di banda e a causare timeout della connessione, può essere utilizzato per sfruttare riconnessioni client legittime per arrestare il server, indipendentemente dai ritardi di riconnessione del client.