Configuración segura de sistemas de cifrado / MAC / Kex disponible en SSH

Ahora mismo , no hay debilidad conocida con el cifrado MD5 o CBC o el MAC de 96 bits , ya que se utilizan en SSH . De modo que, en sentido estricto, no existe ningún beneficio de seguridad al implementar las modificaciones de configuración que está proponiendo. Se podría argumentar que eliminar el soporte para algunos algoritmos podría provocar problemas de seguridad porque puede evitar que algunos clientes se conecten, lo que obliga al usuario a encontrar soluciones que podrían ser menos seguras (por ejemplo, si% co_de Ya no es posible%, envíe el archivo por correo electrónico ...).

El menos irracional de tus objetivos de diseño es la prohibición contra CBC. La seguridad CBC requiere una gestión adecuada de los vectores de inicialización; en el caso de SSH, el IV se extrae del último bloque del paquete anterior (consulte el estándar ), lo que está bien siempre que el atacante no esté en una situación de "ataque de texto sin formato elegido". En la práctica, los datos que van dentro del túnel SSH no son hostiles, al contrario de lo que ocurre en contextos HTTPS donde el código de cliente malintencionado (en Javascript) es una posibilidad definitiva. Del mismo modo, es difícil aprovechar los ataques oracle de relleno en SSH (suponiendo que el código del cliente o del servidor no esté adecuadamente protegido), ya que SSH está orientado a la conexión y no volverá a abrir la conexión automáticamente de nuevo, al contrario de lo que sucede con HTTPS).

De manera similar, HMAC / MD5 es, por lo que sabemos, tan sólido como siempre. Los ataques de colisión conocidos en MD5 no tienen ninguna relación con la seguridad de HMAC, excepto en los sentidos más confusos (que se pueden resumir como: "el olor del MD5"). En cuanto a truncar los valores HMAC a 96 bits, nuevamente no hay razón para discriminarlos: un atacante omitirá con éxito un valor MAC de 96 bits con probabilidad 2 ^-96 , que es extremadamente bajo e imposible para explotar en la práctica porque cualquier error de MAC en una única conexión SSH se informa con un mensaje de error bastante visible. De nuevo, esta es la forma en que se usa SSH, que lo protege contra el nivel de automatización de ataques que se puede aplicar a HTTPS.

Por lo tanto, se podría decir que dado que los algoritmos de eliminación de la lista son para el beneficio de sus sentimientos de seguridad, la lista correcta es la que lo hará sentir más seguro. Eso es subjetivo, por definición, por lo que usted es el único que puede definir esta "mejor" lista. En cuanto a mí, estoy bastante contento con los valores predeterminados.

En cuanto a orden , considere este extracto de sección 7.1 de RFC 4253 :

  encryption_algorithms
     A name-list of acceptable symmetric encryption algorithms (also
     known as ciphers) in order of preference.  The chosen
     encryption algorithm to each direction MUST be the first
     algorithm on the client's name-list that is also on the
     server's name-list.

Por lo tanto, el algoritmo elegido será el algoritmo preferido de cliente . El orden de preferencia del servidor es solo un comentario glorificado; no afectará qué algoritmo se elige realmente. Por lo tanto, el orden en scp no es importante.

Todos los que estén realmente preocupados por la seguridad de SSH probablemente quieran leer esta página:

enlace

Pasa por todos los intercambios de claves, autenticaciones de servidor, cifrados y MAC que OpenSSH soporta y luego arroja todo lo que ya no se puede considerar seguro, dando una justificación válida de todo lo que elimina. ¡Con esta configuración, eres una roca sólida!

TL; DR? Los ganadores de mayor seguridad son:

Intercambio de claves: curve25519-sha256
(fallback: diffie-hellman-group-exchange-sha256 )

Autenticación del servidor: Ed25519 with SHA512
(fallback: RSA with SHA1 4096 Bits )

Cipher: chacha20-poly1305
(fallback: aes256-ctr )

MAC: hmac-sha2-512-etm
(fallback: hmac-sha2-512 )

El respaldo es lo que encontrará en la mayoría de los servidores SSH, no tan seguro, pero lo suficientemente seguro para los estándares de hoy.

Solo un comentario de mi parte: si usa SSH también para copiar datos ( scp o rsync ) o para el reenvío de puertos X11 o VNC, el rendimiento y la latencia no son irrelevantes. En ese caso, aes128-ctr ofrecerá el mejor rendimiento (de los cifrados que se sabe que son seguros a partir de hoy) y puede considerar el uso de [email protected] , ya que incluso MD5 se ha roto, HMAC-MD5 no ha logrado hoy y MD5 supera a SHA-1 en velocidad y SHA-2 incluso con diferencia. Para tener una idea de las velocidades de los algoritmos, vea esa página:

enlace

En mi humilde opinión es una compensación aceptable: cambiar algo de seguridad por mucha más velocidad.

¿Qué hay de chacha20-poly1305 ? No tengo puntos de referencia para chacha20-poly1305 hasta ahora, ni puedo decir que se haya comprobado que sea seguro. Se supone que es un reemplazo de RC4 (también conocido como arcfour), por lo que probablemente sea incluso más rápido que aes128-ctr en software, pero las CPU Intel modernas pueden calcular AES128 en hardware, por lo que si su implementación SSH hace uso de eso, puede esperar que AES128 ser muy rapido Aún así, ChaCha puede ser más rápido, pero es la seguridad aún no probada lo que me preocupa un poco; se han probado muy pocos ataques y, aunque existe desde 2008, solo recientemente ChaCha se ha hecho popular cuando se reveló que la NSA puede romper las conexiones RC4 SSL / TLS en tiempo real. ChaCha reparará eso y reemplazará RC4 en TLS, pero eso no es una prueba de su seguridad.

Nunca se preocupe por el intercambio de claves o la autenticación del servidor, su velocidad solo juega un papel en la conexión inicial y cada vez que la clave necesita ser renovada (cuando eso sucede depende del cifrado elegido y de la cantidad de datos que transfiera). Cada cifrado tiene un límite de datos y una vez que se alcanza, se intercambia una nueva clave, ya que permanecer con el existente debilitaría el cifrado a partir de ese momento, pero las renovaciones no ocurren con tanta frecuencia, por lo que para estos dos Siempre ve por la seguridad más alta e ignora la velocidad por completo.

Y nunca use los hashes truncados (-96) para MD5 o SHA-1. No le brindan ningún beneficio real aparte de guardar un par de bytes por paquete (4 para MD5, 8 para SHA-1). El hash tardará igualmente en calcular / verificar (sin beneficios de velocidad) y el truncamiento solo debilita la seguridad (sin beneficios de seguridad). El truncamiento valdría la pena para SHA-2 ya que estos son mucho más grandes (32, 48, 64 bytes por paquete) y tales hashes grandes no tienen sentido considerando el tamaño máximo de un paquete de transmisión, pero para este truncamiento no es una opción. p>     

Para eliminar los cifrados de cbc, agregue o modifique la línea de "cifrados" en / etc / ssh / sshd_config como se muestra a continuación: Cifras aes128-ctr, aes192-ctr, aes256-ctr, arcfour256, arcfour128, arcfour

Para eliminar HMAC MD5 Agregue o modifique la línea de MAC en / etc / ssh / sshd_config como se muestra a continuación: MAC hmac-sha1, hmac-ripemd160

Reinicie SSHD para aplicar los cambios: service sshd restart