Impedisci il DOS contro l'autenticazione RSA

4

Nella mia attuale configurazione, i client sono in bundle con la chiave pubblica del server. Il client crittografa un nonce e lo invia al server che utilizza il proprio nonce e il nonce ricevuti dal client per impostare una chiave di crittografia simmetrica e restituisce il nonce non crittografato + una risposta crittografata.

Sfortunatamente, questo rende il server completamente aperto agli attacchi DOS intenzionali e accidentali.

Come esempio di quest'ultimo, diciamo che un server è disattivato e tutti i client cercano di riconnettersi. Ciò significa che 100-1000 (non dannoso) connette / s da diversi IP.

Quali sono le mie opzioni oltre a ridurre le dimensioni della chiave RSA?

Modifica

Che ne è di una di queste strategie:

  1. Spostare l'autenticazione su un server separato, che distribuisce in modo sicuro le chiavi di crittografia con una data di scadenza. Quando si accede a un server, il client presenta un identificatore che il server può utilizzare per recuperare la chiave di crittografia da utilizzare.

  2. Inserisci la decodifica RSA in una coda illimitata con priorità thread bassa. Quando un client esegue l'accesso, verrà automaticamente eseguito l'accesso (se ci sono risorse sufficienti) o inserito una coda di accesso. Fino a quando la decrittografia non è pianificata, il cliente riceverà informazioni aggiornate su quanto sono vicini per completare il login.

  3. Metti la decifrazione RSA in una coda in coda limitata con priorità thread bassa. Se la coda è piena, la connessione viene rifiutata con un messaggio che viene raggiunto il limite della coda di accesso e il client può riprovare più tardi.

posta Nuoji 26.04.2013 - 18:35
fonte

2 risposte

4

Potresti passare ad un algoritmo più veloce. RSA va bene, ma Elliptic Curve Diffie-Hellman è più veloce. Prendiamo la mia macchina attuale, un laptop con una CPU AMD A8-4555M (1,6 GHz, non un processore molto veloce):

$ openssl speed rsa2048 ecdhp256
Doing 2048 bit private rsa's for 10s: 1468 2048 bit private RSA's in 9.99s
Doing 2048 bit public rsa's for 10s: 47384 2048 bit public RSA's in 9.98s
Doing 256 bit  ecdh's for 10s: 5847 256-bit ECDH ops in 9.99s
OpenSSL 1.0.1c 10 May 2012
built on: Tue Mar 19 19:10:34 UTC 2013
options:bn(64,64) rc4(8x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx) 
compiler: cc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_NO_TLS1_2_CLIENT -DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50 -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.006805s 0.000211s    146.9   4747.9
                              op      op/s
 256 bit ecdh (nistp256)   0.0017s    585.3

Quindi ECDH a 256 bit, probabilmente più strong (o almeno altrettanto strong) di RSA a 2048 bit, è anche circa quattro volte più veloce. Questa performance è per un core; poiché quella specifica CPU è quad-core, potrebbe gestire due migliaia di connessioni al secondo. Un processore server probabilmente farebbe sostanzialmente meglio.

Tra le altre tecniche di mitigazione possibili, è possibile implementare alcuni ritardi sul lato client. Nello scenario "DoS accidentale", tutti i client provano a riconnettersi contemporaneamente. Forse, potresti fare in modo che i client attenderanno un tempo casuale prima di riconnettersi, quando la connessione viene persa (invece di connettere immediatamente , farli attendere un tempo casuale compreso tra 0 e 60 secondi, quindi riprovare). Ciò contribuirà a diffondere il carico.

Potresti anche comprare più server. L'hardware costa poco.

    
risposta data 26.04.2013 - 19:08
fonte
-1

Sul lato accidentale (quelli che controlli), potresti far eseguire ai tuoi clienti un controllo approfondito delle risorse di locatore (come un semplice ping) prima di avviare la procedura relativa al protocollo e bruciare più risorse. Ma non sarai mai in grado di interrompere completamente alcuni controlli da parte dei tuoi clienti: devono essere in grado di fare qualcosa per avviare la procedura di connessione.

Sul non-casuale, tutti i sistemi hanno a che fare con DOS e tu li gestisci allo stesso modo. Hai i tuoi rilevatori a strati, i tuoi sistemi / reti ridondanti (in modo da poter eseguire il rollover) e controlli come non hai mai immaginato.

    
risposta data 26.04.2013 - 18:49
fonte

Leggi altre domande sui tag