Impedir DOS contra la autenticación RSA

4

En mi configuración actual, los clientes están agrupados con la clave pública del servidor. El cliente encripta un nonce y lo envía al servidor que usa su propio nonce y el nonce recibido del cliente para configurar una clave de cifrado simétrica y envía el nonce encriptado + una respuesta encriptada.

Desafortunadamente, esto hace que el servidor esté abierto a ataques DOS deliberados y accidentales.

Como ejemplo de lo último, digamos que un servidor se desactiva y todos los clientes intentan volver a conectarse. Eso significa que 100-1000 (no malintencionados) se conectan / s de diferentes ips.

¿Cuáles son mis opciones además de reducir el tamaño de la clave RSA?

Editar

¿Qué pasa con cualquiera de estas estrategias:

  1. Mueva la autenticación a un servidor separado, que distribuye de forma segura las claves de cifrado con fecha de caducidad. Al iniciar sesión en un servidor, el cliente presenta un identificador que el servidor puede usar para recuperar la clave de cifrado que debe usar.

  2. Coloque el descifrado RSA en una cola ilimitada con una prioridad de subproceso suficientemente baja. Cuando un cliente inicia sesión, se conectará automáticamente (si hay recursos suficientes) o se pondrá en una cola de inicio de sesión. Hasta que se programe el descifrado, el cliente obtendrá información actualizada sobre qué tan cerca están de completar su inicio de sesión.

  3. Coloque el descifrado RSA en una cola en cola limitada con una prioridad de subproceso suficientemente baja. Si la cola está llena, entonces se rechaza la conexión con un mensaje que indica que se alcanzó el límite de la cola de inicio de sesión y que el cliente puede volver a intentarlo más tarde.

pregunta Nuoji 26.04.2013 - 18:35
fuente

2 respuestas

4

Podrías cambiar a un algoritmo más rápido. RSA está bien, pero Elliptic Curve Diffie-Hellman es más rápido. Tomemos mi máquina actual, una computadora portátil con una CPU AMD A8-4555M (1.6 GHz, no un procesador muy rápido):

$ 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

Por lo tanto, el ECDH de 256 bits, posiblemente más fuerte (o al menos tan fuerte) como el RSA de 2048 bits, también es aproximadamente cuatro veces más rápido. Este rendimiento es para un núcleo; ya que esa CPU específica es de cuatro núcleos, podría manejar dos mil conexiones por segundo. Un procesador servidor probablemente lo haría sustancialmente mejor.

Entre otras posibles técnicas de mitigación, puede implementar algunos retrasos del lado del cliente. En su escenario de "DoS accidental", todos los clientes intentan volver a conectarse simultáneamente. Posiblemente, podría hacer que los clientes esperen un tiempo aleatorio antes de volver a conectarse, cuando se pierda la conexión (en lugar de conectar inmediatamente , hacer que esperen un tiempo aleatorio entre 0 y 60 segundos, y luego intentarlo de nuevo). Esto ayudará a repartir la carga.

También puedes comprar más servidores. El hardware es barato.

    
respondido por el Tom Leek 26.04.2013 - 19:08
fuente
-1

En el lado accidental (aquellos que usted controla), puede hacer que sus clientes realicen una comprobación exhaustiva de recursos del arrendador (como solo un ping) del servidor antes de iniciar el procedimiento relacionado con el protocolo y grabar más recursos. Pero nunca podrá detener totalmente el control de sus clientes, tienen que poder hacer algo para iniciar el proceso de conexión.

En lo no accidental, todos los sistemas tienen que lidiar con DOS y usted lo hace de la misma manera. Tienes tus detectores en capas, tus redes / sistemas redundantes (para que puedas reinvertir) y monitores como nunca habías imaginado.

    
respondido por el Tek Tengu 26.04.2013 - 18:49
fuente

Lea otras preguntas en las etiquetas