Hablando el otro día con un amigo discutíamos la mejor manera de segmentar una red Active Directory para evitar ataques convencionales como propagación de Ransomware, ataques de obtención de contraseñas y demás bondades.
Volvió a sonar algo que lleva muchos años siendo una buena práctica, pero que no siempre se encuentra en las pymes. Hablo de esas empresas con 2 o 4 informáticos, con mucha carga de "otras" cosas y poco tiempo para ese cuidado fino del sistema. Al final si las cosas medio van... la seguridad siempre es un después, y está asociada a máquinas con nombres de star trek.
Hablo del host bastión. Esto es algo que empecé a leer allá por los 2000 con los primeros directorios. Si nos vamos a la RAE se define bastión como: Construcción o recinto fortificado para resistir ataques enemigos. En seguridad informática podría ser un equipo configurado con mucho nivel de seguridad. Podría ser igual que una DMZ, al final es lo mismo, es un equipo aislado. La cuestión es que suele emplear para usar este equipo como pasarela de administración del resto de servidores, por eso lo de salto.
Siendo más claros, es un Windows al que petas de seguridad, y solo administras tu red desde ese equipo.
Más o menos todos sabemos por dónde nos vienen los ataques en redes Windows, las tácticas suelen ser las mismas, cambian las técnicas concretas, pero las líneas maestras siempre son las mismas.
En este post voy a intentar describir algunos procesos de fortificación o más bien ideas sobre cómo acometer este proyecto.
Lo primero que vamos a hacer o deberíamos es segmentar la red de los "informáticos". Una vlan enrutada por un firewall para poder elegir qué puertos son accesibles para que redes. Ningún usuario de la empresa debería poder acceder a esta lan/vlan, pero nosotros a todas las redes si... o no?
Acceder a un servidor de nóminas con el pc con el que veo gatitos en Internet no es muy buena idea.
Si vas a las charlas de mi maestro Carlos o has visto el ciber kill chain one two three de Microsoft, verás como el primer paso suele ser comprometer un equipo, y realizar tanto escalado horizontal y vertical: de máquina y de permisos. El mejor sitio por donde empezar es tú equipo.
Con la red de administradores segmentada, vamos a montar un windows, mejor físico que virtual, pero en los tiempos que corren esto es inviable, que usaremos para administrar AD.
Configuramos las GPO locales para que SOLO los usuarios administradores puedan acceder al servidor, tanto por login como por RDP. Mejor enumerar los usuarios que pueden, y no hacerlo como se suele hacer por grupos administrativos. Al final, definir el usuario en vez del grupo da más granularidad y evita el despiste de usuarios que por cualquier motivo, son dios en AD.
A este equipo, le quitamos la navegación por Internet por supuesto. Bueno, lo suyo sería que ni fuera del dominio, pero esto es también inviable, porque si sois 4 tip@s administrando esto, gestionando los cambios de password (no vayas a usar un genérico que está prohibido por ley).
Ahora vamos con el firewall de Windows. Hay mil guías y recomendaciones para aislar equipos en una red WIndows a nivel de puertos. Esta guía es la buena: https://docs.microsoft.com/es-es/windows/security/threat-protection/windows-firewall/mapping-your-deployment-goals-to-a-windows-firewall-with-advanced-security-design Pero no voy a entrar en esto, porque reconozco que te puedes enjardinar, pero con el RDP SI.
Te vas a cualquier servidor, creas una regla que permita el RDP SOLO al equipo bastionado, al que va a hacer de máquina de la muerte xD y a alguno equipo más... no sea que la picies xD. Exporta la regla desde el menú. Ahora vete a tu editor de políticas y crea una política de seguridad específica para tus servidores miembro, no solo para los controladores de dominio, ya sabes. Aplica esa regla de seguridad al firewall de Windows.
En este punto, valoraría que la comunicación entre el host bastionado y los members servers fuera mediante IPSEC. Implementar IPSEC en una red Windows son dos clicks, porque usamos una directiva de seguridad relajada en la que los servidores hablan IPSEC siempre y cuando sea posible. De esta manera, si tienes sistemas no-Microsoft que no admitan el IPSEC, no hay problema.
Nuestra operativa diaria para administrar el DNS de la empresa no debe ser meternos en el DNS SERVER y administrarlo, al final, si tenemos una máquina bastión con las plantillas administrativas, me conecto a la consola DNS remotamente, nada de entrar al DC por RDP y dejar las claves en memoria...
Una de las cosas a nivel de máquina que podemos hacer, si hemos decidido usar un Windows 10 es pasar la guía básica de seguridad, en la que me va a detectar fallos o mejoras de seguridad.
Y hable de algo parecido en mi 4º artículo, hayá por el 2012.
Para proteger la gestión de las contraseñas, ya sabes, los ataques basados en pass-the-hash, y básicamente, mimikatz y compañía, podemos usar Credential Guard. Básicamente es un subsistema para LSA en el que se aprovecha de la tecnología de virtualización, la ISOLATION, para aislar el almacenamiento de la contraseña fuera del proceso LSA en memoria, lo que hace imposible dumpear las claves de LSASS.exe ...Como usa virtualización, necesita los mismos requisitos que para montar hyper-v, extensión de la CPU, y como dato negativo, el equipo debe ser físico, no contempla que haya virtualización nested...
Pablo González habló muy bien hace unos años de esta tecnología aquí.
Dentro de la seguridad del RDP, tenemos MIL COSAS por hacer.
Los nuevos Windows 10 en escenarios de directorio 2016 implementan el Hello Business, una solución de 2FA nativa para Microsoft pero requiere de despliegues mixtos en Azure y quizás algo más complejo que el propósito del post.
Una de ellas, algo viejo ya, es la seguridad a nivel de red NLA que establece una autorización previa basada en Kerberos ( si estás en dominio) o mediante TLS antes de realizar el login contra el RDP.
Ahora tenemos la posibilidad de elegir entre dos modos de conexión por RDP a nuestros servers, Windows Defender Remote Credential Guard o RestrictedAdmin
Como puedes comprobar, es más seguro Restricted Admin Mode ya que fuerza a NO usar NTLM y te impide mecanismos de SSO contra otros servicios. Por ejemplo, si usamos el Server Manager de 2016 para administrar un sistema con esta característica, no podremos. Tendremos que hacer login, es más tedioso, pero más seguro.
Al final, en la práctica, basta con activar el modo en el servidor miembro destino, y usar el delimitador mstsc /restrictedAdmin tal que así.
Otra cuestión básica de fortificación es eliminar servicios innecesarios en ese equipo de salto, como por supuesto spooler de impresión, tráfico de SMB, clientes DHCP y todo tipo de servicios que consideréis innecesarios. Esta guía es muy buena si el equipo es server.
Al final, queda claro el sistema bastión o de salto. Microsoft va un paso más allá, y añade el concepto de PAW, privileged Access Workstation en donde especifica una serie de guías detalladas a nivel de UEFI, GPO´s, hardware dedicado de criptología TPM y todo un conjunto de escenarios para desplegar este tipo de equipos bastionados. Dentro de una red Windows el equipo PAW sería el propio de salto, pero imaginaros un entorno de máxima seguridad en el que tengamos un entorno de salto para Amazon, añadiremos una escenario seguro de salto para el equipo de salto xD
Para entornos de máxima seguridad en el que tenemos directorios en Azure, se recomiendan estrategias avanzadas de host bastión o de salto, basadas en confianzas de dominios y dominios delegados para administración. Imagina el sysadmin de una sede regional tocando el erp de Azure internacional...
Al final, el objetivo de este post es que penseis en estos escenarios de seguridad, en el que cualquier que sea el caso, no es lógico usar el mismo equipo para bajar películas o ver videos, que para navegar por el banco, o administrar la red de la empresa.
Sea cual sea nuestro tamaño o recursos, debemos llegar a más o menos cotas de aislamiento.
Para cada tecnología o concepto he puesto un link con los pasos exactos y mejores explicaciones de las que pueda dar yo, al final, mi intención es transmitiros la necesidad y aglutinar un poco mi experiencia, los detalles, como siempre, los sacamos por ahí.
Gracias por leerme !!!