Seguridad o funcionalidad: El dilema

Hoy quiero relatar un problema muy común a la hora de administrar nuestros sistemas informáticos: qué hacer cuando tenemos que elegir entre funcionalidad y seguridad.

Muchos pensaréis “¡pues claro que la seguridad!”, pero a la hora de gestionar miles de equipos informáticos que dependen de según qué protocolos, puertos o servicios, no es tan fácil. A más seguridad siempre perderemos funcionalidad, y hay un límite en el que ciertas recomendaciones carecen de sentido.

Máxima seguridad sin conexión

Pongamos por ejemplo que un servicio secreto quiere montar su entorno hipersecurizado con sus sistemas Windows activados y actualizados a la última versión. Pero dentro del “búnker” no hay ni conexión a Internet ni ningún tipo de comunicación con el exterior. ¿Cómo activamos y actualizamos esos equipos? Tiene que haber al menos un teléfono disponible para activar las licencias, y las actualizaciones tendrán que descargarse de Internet en algún momento. No es necesario que todos los equipos dispongan de conexión a Internet, pero sí al menos nuestro servidor interno de actualizaciones.

Este es un ejemplo muy básico y sencillo,pero hay muchos otros que se dan en el día a día del IT. Por ejemplo, en este artículo Ned Pyle explica muchas de las consecuencias de exigir autenticación para comunicaciones RPC: https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/restrictions-for-unauthenticated-rpc-clients-the-group-policy/ba-p/399128

En dicho contenido, el autor lanza un mensaje final con el que no puedo estar más de acuerdo, que vendría a resumirse como: “una consultora de seguridad te va a decir que quites esto y pongas aquello otro, pero a la hora de la verdad no va a estar ahí para ayudarte cuando hayas roto tu entorno por todos esos cambios”.

Filtrando sólo cifrados TLS fuertes

Un ejemplo típico es cuando estas consultorías de seguridad le sugieren a sus clientes que retiren el soporte de cualquier cifrado de TLS considerado como “débil”. Muy buena sugerencia, pero si el certificado de un servidor está cifrado con TLS_RSA_WITH_AES_256_GCM_SHA384, ¿qué hacemos? ¿Prohibimos toda comunicación con ese servidor? Habrá que admitir alguna excepción, teniendo siempre en mente una futura retirada del cifrado TLS débil. Pero exploremos un poco más el ejemplo a continuación: https://ciphersuite.info/cs/TLS_RSA_WITH_AES_256_GCM_SHA384/

En la información de este cifrado, se menciona que no soporta PFS (forward secrecy). En otras palabras: en caso de que alguien se haga con la clave privada de dicho certificado, toda comunicación pasada o posterior con ese servidor podrá ser traducida. Ah, pero para poder darle utilidad a esta vulnerabilidad primero se tiene que haber “esnifado” tráfico de red entre nuestros clientes y ese servidor, y luego se tiene que haber conseguido la clave privada de un certificado. Si el método de obtención de dicha clave es por “fuerza bruta”, los atacantes requerirán de muchos recursos y tiempo (años) para obtener lo que desean. Muy probablemente el certificado del servidor sea renovado antes de que eso ocurra. Y eso sólo para un certificado.

Por supuesto, tomar una decisión u otra dependerá de lo crítica que sea la información que transmitamos a dicho servidor. Ni que decir que si el servidor es nuestro, podemos evitar un mal mayor emitiendo un nuevo certificado más seguro. Pero en caso contrario, nuestro cliente Windows siempre puede acudir al comportamiento por defecto de Windows, que utiliza un listado de cifrados TLS que va ordenador de más seguro a menos para realizar la comunicaciones que van a través de schannel. Aquí podemos ver dicho listado para Windows 11 22H2: https://learn.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-11-v22h2

¿Qué significa esto? Pues que si el servidor, además de aceptar el cifrado “débil” también acepta uno de los “fuertes”, Windows siempre escogerá el fuerte por defecto. Nuestra comunicación con servidores siempre será posible con el cifrado TLS común más fuerte que tengamos.

Con esto podemos hacer mucho “testing”: aplicar una GPO a un solo equipo de prueba, configurando sólo unos pocos cifrados TLS muy seguros para ver si hay problemas de conectividad en el día a día. O también podemos recolectar una traza de red con Wireshark, en la que se nos indicará qué cifrados TLS utilizan los servidores a los que nos conectamos.

Sé que a algunas personas esta explicación no les va a valer, “quiero la máximo seguridad, sea cual sea el coste” y es legítimo pensar así. Ahora bien, voy a plantear otra pregunta: ¿Todos sus clientes utilizan Windows 11 y sus servidores Windows Server 2022? Porque si no es así, no van a poder comunicarse por TLS 1.3, que es la versión más avanzada y segura de dicho protocolo.

El problema de los account lockouts (bloqueos de cuentas)

Otro caso similar es cuando se tiene habilitado el “threshold” (umbral) para bloquear cuentas de usuario con múltiples fallos de introducción de credenciales. A veces hay aplicaciones que pueden producir dichos fallos por diseño, y un umbral bajo, de 3 o 5 fallos, puede ocasionar una denegación muy fácil del servicio. Normalmente no se quiere subir el umbral “por seguridad”, aunque sólo se recomiende subirlo a 50.

“Ah, pero si le dejo 50 va a ser mucho más fácil que me robe la cuenta”. Sí, pasará de ser 1 entre un billón de posibilidades a 1 entre cien mil millones solamente. Ah, pero si añadimos 1 carácter más al mínimo de nuestra política de contraseñas, la seguridad mejorará igualmente. En el artículo público de Microsoft se menciona que se puede quitar el bloqueo de cuentas si contamos con contraseñas fuertes y un robusto sistema de auditoría: https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/account-lockout-threshold

Por otra parte, todo esto en sí es una mala práctica (con los bloqueos de cuentas se facilitan los ataques DDoS); el hecho de seguir prescindiendo de contraseñas es en sí un problema de seguridad mucho mayor que permitir introducir varias veces mal la contraseña. La solución ideal para este problema es disponer de un sistema de autenticación sin contraseña, como puede ser Windows Hello for Business, y obligar a los usuarios de nuestra empresa a utilizarlo. La contraseña sólo se utilizará la primera vez para enrolar el usuario al dispositivo, y a partir de ahí obligar a que se use smart card logon.

“Oh, ¿pero cómo un PIN de 6 dígitos puede ser más seguro que una contraseña?” Realmente el PIN sólo funcionará en nuestro ordenador, nunca viaja a través de la red, he ahí la gran seguridad que aporta. Aparte, que el PIN puede ser de más dígitos, usar letras, o también se permite optar por usar autenticación biométrica o MFA. Al final para las comunicaciones lo que usa WHFB es un certificado (ligado a nuestro pin, huella dactilar...), lo cual es muchísimo más seguro que una contraseña. Y todo guardado en un chip TPM (nada de mantener las contraseñas en memoria).

Probablemente esta segunda solución no sea bien vista tampoco, y es que requiere de varias horas de implementación, aparte de un pequeño coste. Y entonces llegamos a la contradicción: por un lado la primera solución (subir el umbral) no nos vale porque es insegura, pero la segunda que es más segura no nos vale tampoco porque nos lleva mucho tiempo.

Software antiguo sin actualizar

Otro caso curioso es cuando nos encontramos con lo contrario: administradores de sistemas que quieren mantener operativo sus Windows Server 2003 8 años después de recibir sus últimas actualizaciones de seguridad. O con sistemas de terceros antiguos que no utilizan sellado RPC o sólo pueden usar tickets de Kerberos encriptados con RC4. Las actualizaciones de Noviembre de 2022 trajeron de cabeza estos problemas.

Especialmente lo primero es algo muy preocupante: ¿Cómo puede un administrador de sistemas querer mantener un servidor con un sistema operativo altamente inseguro? Llevar 8 años sin soporte de actualizaciones no es ninguna broma; miles de vulnerabilidades podrían ser utilizadas para robar información o hacerse con el control del dominio. Ni que decir tiene la enorme carga legal que podría recaer sobre nuestras espaldas, de ocurrir un hackeo. Lo primero que debe hacer un administrador de IT en estas situaciones es comunicar a sus superiores que hay unos Sistemas Operativos que deben ser retirados inmediatamente. Si al final ocurre lo que nadie desea, que no sea sin haber informado debidamente a nuestros superiores.

Sinceramente, no me gustaría verme en esa situación. Quien ordene continuar usando software altamente inseguro y sin soporte se expone a una posible pena económica o de cárcel, en los peores casos.

Protocolos y puertos necesarios

Afortunadamente, lo más habitual (y razonable) es lo contrario, que una empresa se empeñe en querer usar el software más actualizado y seguro. Como mencioné más arriba, a veces se llega a lo absurdo: hay quien quiere bloquear todas las comunicaciones NTLM y que todo funcione con normalidad. O bloquear el puerto 389 para que todas las comunicaciones LDAP usen certificado (LDAPS y 636), pero los Sistemas Operativos están hechos de otra manera: permiten la máxima compatibilidad y ofrecen la máxima seguridad siempre que sea posible.

Entre los requisitos de Windows está poder usar tanto Kerberos como NTLM y tener abiertos los puertos necesarios para los servicios que utilicemos, independientemente de que queramos sólo utilizar los medios más seguros. Es un buen momento para recordar todos esos puertos que son necesarios: https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements

Hay quien, por querer securizar su entorno al máximo, quiere que todas las tareas de administración de un dominio OnPremises se lleven a cabo desde máquinas unidas solamente a dominio de Microsoft Entra ID con usuarios híbridos. Partiendo de la base que esas cuentas híbridas tendrían unos privilegios especiales, lo cual no es muy recomendado, nos encontramos conque la autenticación de máquinas de Microsoft Entra en OnPremises no existe, y por lo tanto, es esperable que algunas utilidades que requiren de dicha autenticación fallen.

La seguridad es lo más importante pero, ¿estamos poniendo el foco en el lugar correcto?

Para terminar (el rollo), sólo querría lanzar algunas preguntas más, que creo que vendría bien hacerse antes de pensar si en realidad nos debería importar tanto ese cambio que mejorará muy mínimamente la seguridad a cambio de una pérdida de funcionalidad. No vaya a ser que le estemos prestando poca importancia a otras cosas que sí la tienen, y que en algunos casos no nos harán perder funcionalidad:

• ¿Hay algún equipo que use OS fuera de soporte?

• ¿Tengo todos los equipos actualizados a la última versión?

• ¿Cuántos administradores de dominio tengo?

• ¿Confío totalmente en las personas que administran mis sistemas?

• ¿Hay una sala sólo para administradores? ¿Está cerrada con llave? ¿Hay cámaras de seguridad?

• ¿Mis empleados bloquean la pantalla cada vez que salen de su puesto?

• ¿Los usuarios se conectan a la red corporativa por VPN?

• ¿Utilizan mis usuarios autenticación sin contraseña (WHFB)?

• ¿Los servicios utilizan cuentas GMSA? ¿Delegación o Impersonación?

• ¿Utilizo cuentas diferentes para cada servicio?

• ¿Qué información comparto con la consultora de seguridad?

• ¿Utilizo un modelo organizado en niveles (tiers) para limitar el acceso a servidores?

• ¿Están mis discos encriptados con BitLocker?

• ¿Usan los equipos cliente Credential Guard para proteger las contraseñas?

• ¿Tengo Windows Defender funcionando a lo largo de mi dominio?

• ¿Uso un sistema de auditoría como Microsoft Sentinel para estar al día de las amenazas que hay en mi dominio?

• ¿Estoy al tanto de las últimas noticias concernientes a la seguridad?

Seguro que se me olvidan decenas de preguntas importantes, pero a modo de ejemplo creo que es bastante visual. ¡Espero que os haya gustado!