Configuración de Red Hat Enterprise Linux 8 para cumplir la política criptográfica relacionada con el encadenamiento de cifrado por bloques

En esta publicación, analizaremos un ejemplo de una configuración de la política criptográfica de Red Hat Enterprise Linux 8 para eliminar el encadenamiento de cifrado por bloques (CBC), pero primero empecemos con un poco de contexto sobre el CBC y la política de cifrado del sistema.

En lo operativo, la mayoría de nosotros experimentó situaciones en las que hay una configuración compleja en un sistema, y demasiada información o muy poca para comprender todo. 

Por ejemplo, ¿alguna vez te encontraste con un mensaje, como "tu servidor admite cifrados CBC que ya no se recomiendan y son vulnerables"? ¿O te preguntaron si cuentas con protección contra un punto vulnerable nuevo y te enviaron una solicitud para informar lo antes posible si algunos de tus sistemas del entorno están afectados para solucionar el problema? 

¿Qué herramientas vas a utilizar? ¿Qué verificaciones vas a llevar a cabo? ¿Configuraste el sistema correctamente? ¿Tus servidores presentan puntos vulnerables conocidos?

Afortunadamente, estas preguntas se pueden responder con las tecnologías disponibles en Red Hat Enterprise Linux 8 para mejorar la eficiencia operativa y aumentar la confianza y la comprensión de las herramientas de políticas criptográficas. 

Análisis del problema

Demos un paso atrás y analicemos el problema en cuestión con la ayuda de esta entrada de Wikipedia. 

En ella se explica que el CBC es uno de los muchos modos para usar un cifrado por bloques, y este aplica la función XOR en el bloque de texto cifrado actual con el precedente antes de cifrarlo. También se lo denomina el "modo de operación más utilizado" y "uno de los dos modos de cifrado por bloques recomendados por Niels Ferguson y Bruce Schneier". 

Además, se aclara que se inventó en 1976, lo que podría indicar que está desactualizado y es inseguro. Sin embargo, su antigüedad no implica que sea riesgoso. El intercambio de claves Diffie-Hellman también data de 1976, pero aún se usa ampliamente y se considera seguro.

En realidad, toda esa información no ayuda a comprender cuál es el problema. Es muy probable que esta investigación se haya iniciado a partir de una alerta de análisis de puntos vulnerables automatizado que detectó que el servidor OpenSSH estaba dispuesto a usar los modos de cifrado CBC y citaba al CVE-2008-5161 como el motivo. Tal vez se hizo otra referencia a este documento o a algún otro igual de críptico. Pueden ser tranquilizadoras las frases como "por lo tanto, es muy poco probable que un ataque a una sesión interactiva sea útil con esta debilidad en el protocolo: un agente malintencionado tendría que llevar a cabo alrededor de 11 356 intentos de interrupción de la conexión antes de tener éxito". Pero ¿eso significa que este problema de seguridad que surgió hace una década no se abordó en Red Hat Enterprise Linux?

Afortunadamente, Red Hat trabaja de manera preventiva para controlar y reducir el impacto de los puntos vulnerables en sus productos. De hecho, en la página de NIST para el CVE-2008-5161 que se mencionó anteriormente, se destaca la declaración del proveedor Red Hat, que indica que el problema se corrigió desde Red Hat Enterprise Linux 5. La empresa también proporcionó una solución para deshabilitar los cifrados CBC de la configuración de SSHD.

En el artículo también se aclara que la disminución del impacto consistía en aplicar parches upstream, lo que reduce aún más las probabilidades de que el ataque se realice con éxito. Un análisis de puntos vulnerables no contiene esa información; solo verifica la presencia de las versiones específicas de los paquetes, las compara con versiones afectadas conocidas e informa el resultado. Esas herramientas no son perfectas y no pueden detectar tales estrategias para reducir el impacto. 

Si tienes dudas sobre la seguridad de un algoritmo en particular, podrías hacer un esfuerzo adicional y deshabilitarlo por completo. Estos cambios deben equilibrarse con los problemas de compatibilidad. 

Es posible que esos cifrados CBC sean el único lenguaje común en la interacción con clientes y servidores de SSH más antiguos, y los diseñadores de la distribución son los encargados de equilibrar los valores predeterminados más seguros con la compatibilidad. 

Por ejemplo, Fedora 33 deshabilita los cifrados CBC para su uso con SSH, como se ve en esta solicitud de fusión upstream. Al ser una distribución empresarial lanzada un año antes, se decidió que en Red Hat Enterprise Linux 8 se mantendrían habilitados de forma predeterminada por motivos de disminución del impacto y compatibilidad, como se ve en este Bugzilla: 1818103 – SSH Server CBC Mode Ciphers Enabled in RHCOS.

Es importante que los elementos predeterminados estén equilibrados, pero están hechos para cambiarse. La situación de cada usuario es única y depende de ellos tomar sus propias decisiones según lo consideren adecuado. A fin de satisfacer esa necesidad, en Red Hat Enterprise Linux 8 se adoptó un nuevo mecanismo concentrado para habilitar o deshabilitar el uso de algoritmos cifrados: las políticas criptográficas. Aprovechemos esta oportunidad y conozcamos la forma de usarlas para deshabilitar los cifrados CBC.

Funciones y configuraciones relacionadas con la política criptográfica de Red Hat Enterprise Linux 8

Si observas la política predeterminada en Red Hat Enterprise Linux 8, comprenderás mejor la situación:

sudo less /usr/share/crypto-policies/policies/DEFAULT.pol 
# A reasonable default for today's standards. It should provide 
# 112-bit security with the exception of SHA1 signatures needed for DNSSec 
# and other still prevalent legacy use of SHA1 signatures.

Existen otras políticas que se pueden configurar en el sistema operativo para cumplir con los requisitos de seguridad adicionales relacionados con las políticas criptográficas: 

• FIPS.pol: política que solo usa el algoritmo FIPS aprobado.

• FUTURE.pol: nivel que proporcionará seguridad de manera prudente, el cual se cree que resistirá cualquier ataque a corto plazo. 

• LEGACY.pol: proporciona configuraciones para garantizar la máxima compatibilidad con los sistemas heredados.

También hay flexibilidad para modificar estas políticas creando otras secundarias o una propia desde cero. Anteriormente, realizamos una publicación en el blog de Red Hat en la que presentamos la herramienta para actualizar las políticas criptográficas, sus funciones y una explicación sobre la manera de usarla.

En "Uso de políticas criptográficas en todo el sistema de Red Hat Enterprise Linux 8", encontrarás documentación adicional importante sobre este tema.

Configuración de la política criptográfica de Red Hat Enterprise Linux 8 para eliminar el CBC

Volviendo a nuestro problema inicial, el encargado de auditoría trae datos de respaldo adicionales, ya que la herramienta de evaluación de puntos vulnerables informó el problema: "Vulnerability Name: SSH CBC Mode Ciphers Enabled, Description: CBC Mode Ciphers are enable on the SSH Server".

Aquí tenemos que marcar una diferencia, ya que, según los comentarios en línea, muchos pueden configurar su sistema para, supuestamente, solucionar el problema después de pasar el análisis de puntos vulnerables. En la práctica, están configurando el proceso SSHD para que no use los cifrados relacionados con el cifrado CBC, lo que impide que SSHD los utilice. Incluso hay algunas instrucciones sobre la manera de aplicar ese tipo de alternativa. 

Esto es solo para el proceso SSHD, no para todo el servidor. Se actúa sobre el proceso en lugar del sistema. En otras palabras, si bien se pasaría la verificación en el modo SSH CBC, algunos cifrados CBC aún permanecerían en el servidor. Se recomienda realizar el cambio en el sistema, que justamente es lo que puede hacer la herramienta para la actualización de las políticas criptográficas.

Primero, podemos ver la política criptográfica que se usa actualmente en el servidor de Red Hat Enterprise Linux 8:

update-crypto-policies --show 
DEFAULT

Dado que establecimos que Red Hat Enterprise Linux 8 usa la política de cifrado DEFAULT, podemos buscar los cifrados relacionados con el CBC en /usr/share/crypto-policies/policies/DEFAULT.pol

tls_cipher = ... AES-256-CBC ...AES-128-CBC 
cipher = ... AES-256-CBC CAMELLIA-256-CBC AES-128-CBC CAMELLIA-128-CBC

(Se eliminaron los cifrados no relacionados para mayor claridad).

Hay seis cifrados relacionados con el CBC que se usan en la política DEFAULT.

Es aquí que las cosas se complican. Al momento de redactar este documento, no hay archivos de políticas que muestren ejemplos de una configuración de política criptográfica adicional ssh_cipher. Se menciona en la página del manual: man crypto-policies (... ssh_cipher: Optional; list of allowed symmetric encryption algorithms (including the modes) for use with the SSH protocol. If absent, the value is derived from cipher...). 

El ssh_cipher existe y, si bien no está explícitamente visible en la política DEFAULT, debe excluirse en la política secundaria si queremos eliminar de manera efectiva todos los cifrados relacionados con el CBC.

Podemos crear una que modificará la política DEFAULT en uso. Para ello, se debe generar un archivo de política secundaria.

 /etc/crypto-policies/policies/modules/DISABLE-CBC.pmod

Nota: La convención de denominación es importante. El nombre de la política secundaria debe estar en mayúsculas, seguido de .pmod en minúsculas para el nombre de la extensión.

Ese archivo debe contener las modificaciones que queremos implementar en la política DEFAULT.

Para eliminar los cifrados CBC del servidor, modificando el perfil DEFAULT, debemos agregar:

tls_cipher = -AES-256-CBC -AES-128-CBC 
cipher = -AES-128-CBC -AES-256-CBC -CAMELLIA-256-CBC -CAMELLIA-128-CBC 
ssh_cipher = -AES-128-CBC -AES-256-CBC

Para eliminar el algoritmo CBC del servidor solo para SSHD:

ssh_cipher = -AES-128-CBC -AES-256-CBC

Nota: Dado que no hay ejemplos de ssh_cipher, se podría suponer que el valor sería:

ssh_cipher = -AES-128-CBC -AES-256-CBC -CAMELLIA-256-CBC -CAMELLIA-128-CBC

En realidad, no especificamos -CAMELLIA, ya que, aparentemente, SSHD no lo ofrece ni lo usa, como se ve al implementar: man sshd_config | grep -i cbc

                   3des-cbc                    
                   aes128-cbc                    
                   aes192-cbc                    
                   aes256-cbc )

3des-cbc tampoco aparece en el servidor de Red Hat Enterprise Linux 8.2, como sucede con ssh -vv en "Their offer": aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr, aes128-gcm@openssh.com,aes128-ctr).

Se debe establecer la política secundaria con la configuración que elimina los cifrados CBC:

sudo update-crypto-policies --set DEFAULT:DISABLE-CBC

Podemos comprobar que esté configurado correctamente: 

sudo update-crypto-policies --show  
DEFAULT:DISABLE-CBC

El servidor debe reiniciarse para que la política principal y la secundaria sean efectivas.

En este punto, no debería haber ningún cifrado CBC en uso. Una forma sencilla de comprobar eso sería verificarlo con SSHD ejecutando este comando desde un servidor de Red Hat Enterprise Linux 8:

ssh -vv -oCiphers=aes128-cbc,aes256-cbc 127.0.0.1 

Debe mostrar la información de inicio de sesión, y el usuario debe poder conectarse con las credenciales válidas.

Cuando el cifrado CBC no está disponible para SSHD, debería aparecer el siguiente mensaje:

Unable to negotiate with 127.0.0.1 port 22: no matching cipher found. 

El proceso SSHD mostrará los cifrados que ofrece ese servidor, como: "Their offer: aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr"

Resumen

En este blog, explicamos la forma de configurar un servidor de Red Hat Enterprise Linux 8 para cumplir con un requisito de política criptográfica determinado. Mostramos la manera de eliminar los cifrados relacionados con CBC desde un servidor, después de validar el problema de seguridad. Usamos herramientas, como la de actualización de las políticas criptográficas, para cumplir con algunos requisitos de seguridad de manera adecuada en el servidor, en lugar de tener que trabajar con los elementos individuales.