Hola a todos,
En el anterior post vimos los pasos finales de la metodología propuesta, en este post daremos unas pinceladas sobre diferentes recomendaciones propuestas para proteger el servicio de AD de los atacantes que hacen uso de las herramientas y vectores de ataque anteriormente vistos.
Contraseñas Débiles
La medida que debe tomar un administrador del sistema es establecer un convenio de contraseñas fuerte, con 8 caracteres o más, que incluya símbolos, números y alguna mayúscula y que no se pueda repetir en el tiempo. Esto servirá para que, en los ataques offline de fuerza bruta, sea más costoso obtener una contraseña.
Es posible mejorar el nivel de seguridad mediante diferentes medidas, algunas de ellas es posible aplicarlas directamente sobre Directivas de Grupo del Directorio Activo como:
El cambio regular de las contraseñas de todos los usuarios, es decir, se podría establecer una caducidad “corta”, de unos 3 meses, para que el usuario vaya cambiando la contraseña en cada uno de esos periodos.
Evitar la repetición de contraseñas, se puede establecer que el usuario no pueda repetir las últimas 10 contraseñas que ha utilizado como usuario del Directorio Activo
Por otro lado, es posible aplicar otras medidas mediante el uso de herramientas de terceros que pueden “fusionarse” con las operativas del Directorio Activo, entre ellas se pueden destacar:
El uso de un gestor de contraseñas, esto permite que el usuario solo tenga que acordarse de una única contraseña y que pueda establecer diferentes contraseñas para cada uno de los servicios, impidiendo que si se obtiene una de ellas no se pueda acceder al resto de los servicios. Aunque esto difiere con la tendencia actual de las compañías que se enfocan en la implementación del Single Sign-On (SSO), que se trata de un procedimiento que permite la autenticación a diferentes sistemas mediante un único proceso de identificación. Además, con la implementación de un gestor de contraseñas puedes delegar la seguridad de las contraseñas a ese proveedor.
Uso de la autenticación de dos factores que permite introducir un nuevo nivel de seguridad a la hora de generar una autenticación, esto se realiza mediante el requisito de identificación doble, el primero, la contraseña que conoce el usuario y el segundo un código alfanumérico que se genera de manera aleatoria en diferentes periodos de tiempo, esto impide que un atacante pueda acceder al sistema con solo contar con un hash de contraseña o la propia contraseña.
Nombre de equipos
Un error de seguridad de partida ha sido el nombre de los equipos, por lo que existen diferentes convenciones a la hora de establecer un nombre para los equipos, lo más recomendable es que no sean descriptivos en referencia a los servicios que albergan, es decir, no llamar a un servidor que contiene un Directorio Activo: “AD”, “Active Directory”, “Domain Controller”… o a un equipo que contenga la web de la empresa: “WebServer” , “hosting”, etc.
Existe un RFC destinado a este objetivo, entre los cuales destaca unas cuantas recomendaciones:
- No utilices nombres largos.
- Evita las grafías alternativas, como el intercambio de letras en una palabra, con el fin de hacer un juego de palabras.
- Evita los nombres de dominio.
- Evita los nombres parecidos al nombre dominio.
- No utilices nombres antagónicos o insultos.
- No utilices dígitos al principio del nombre.
- No utilices caracteres no alfanuméricos.
- No esperes que se mantengan las mayúsculas y minúsculas en el nombre.
El criterio que se debería seguir va a depender de las necesidades del entorno donde se despliega el equipo, aquí incluyo un ejemplo:
Marco:
Si es un marco local, es decir, con una única sede, no haría falta un concepto para este apartado.
Si es un marco provincial, con mas de una sede dentro de la misma provincia, podría establecerse un concepto en función de la sede, si el equipo se encuentra en la sede principal: 01, si es otra sede, 02-03-04-etc…
Si se trata de un marco nacional, sería posible establecer un código por cada una de las provincias, por ejemplo, asociado a los prefijos telefónicos de cada uno de ellos:
- Andalucía:95X
- Aragón:974/976/978
- Asturias:984/985
- Baleares:971
- …
Por último, si es una empresa internacional, se podría establecer un código de país:
- España: ES
- Francia: FR
- Portugal: PT
- Italia: IT
- …
Empleado
Generalmente los sistemas de gestión de empleados identifican a estos mediante indicativos numéricos, por lo que se podría incluir en el nombre del equipo.
Tipo de equipo
- SV: Si es un servidor.
- V: Virtual
- F: Físico
- L: Si es un portátil.
- D: Si es un ordenador de sobremesa.
Otros conceptos
Es posible añadir mas indicativos como el departamento al que pertenece al equipo o el sistema operativo que utiliza, sin embargo, para mantener una longitud lógica dentro del RFC, vista anteriormente, se puede mantener con los conceptos indicados en los apartados anteriores.
Con estos apartados definidos podríamos establecer la siguiente nomenclatura para el siguiente ejemplo: nombre de un equipo portátil (L) en una organización internacional que se encuentra en España (ES), ubicado en Madrid (91), que utiliza el usuario 1234 en la sede principal (01), podría definirse de la siguiente manera:
ES91011234L
Otro ejemplo, un único servidor físico (SVV), Ubuntu (U) de una organización que solo opera de manera local, se podría definir de la siguiente manera:
SVVU01
Administración de permisos de usuarios
Se debe mantener una política de denegación total a los usuarios y grupos, esto permitirá que solo se acceda a los recursos por petición expresa al usuario o a el grupo. Además, se debe realizar un mantenimiento continuo de los permisos que tengan los usuarios para poder eliminar los que ya no utilicen.
Evaluaciones continuas y periodicas
Es necesario mantener estudios continuos sobre la calidad de la red y los dispositivos conectados, esto se puede realizar mediante un SIEM que es un software que permite la recolección de información mediante logs de los equipos de la red y además permite actuar en tiempo real ante una amenaza.
También se puede hacer uso de honeypots, que establecen usuarios o equipos señuelo con servicios que son fácilmente vulnerables para que un atacante pueda entrar a ellos y genere una alerta que será evaluada. Algunos de ellos son:
- Delilah
- ESPot
- ElasticPot
- Elastic honey
- MongoDB-HoneyProxy
- NoSQLpot
- …
Kerberos Roasting
Para evitar el ataque de Kerberos, se puede utilizar Kerberos FAST, para proteger los datos que han sido previamente autenticados protegiendo los intercambios del servicio de autenticación (AS) con el KDC a través de un túnel seguro. También se puede eliminar el uso de protocolos inseguros como RC4 y realizar más fuertes como AES-256 para proteger los TGT. De esta manera se evita/complica la explotación de los hashes obtenidos por un atacante.
Samba Relay y NTLMRelay
Para intentar evitar este tipo de ataques será necesario ejecutar alguna de acciones (Fuente):
Deshabilitar LLMNR y NBT-NS: son los protocolos que permiten resolver nombres de hosts según sus IPs, logrando esto sin necesidad de que exista un servidor DNS local. El problema radica en que no tiene protección frente a suplantación, pudiendo facilitar ataques MitM. Fuente
Deshabilitar NTLMv1: esta versión de NTLM, utiliza un protocolo muy débil para realizar el hasheo de las contraseñas y es posible obtener la contraseña mediante fuerza bruta de forma sencilla.
Deshabilitar IPv6: por defecto, toda la comunicación de los equipos Windows se realiza por IPv6, al desactivar este protocolo, se impide los ataques por esta vía, ya que no suele ser configurado y realizado un hardening adecuado.
Configurar SMB con firmas digitales: es necesario firmar todos los equipos y servicios, pero especialmente SMB, ya que, si no se firma, cualquier intruso puede envenenar la red haciéndose pasar por el recurso solicitado y robar las credenciales de los usuarios que solicitan recursos en el protocolo SMB.
ASREPRoast
Se debe establecer la pre-autenticación de Kerberos en todos los usuarios con el fin de evitar la fuga de los hashes (Fuente), ya que los atacantes buscan usuarios que tengan en su registro la etiqueta DONT_REQ_PREAUTH, es decir, los que no se les requiere pre-autenticación en kerberos.
El problema reside en que sin la autenticación previa por parte del servicio de Kerberos el atacante puede enviar una solicitud de autenticación a un servicio, en nombre de un usuario, sin necesidad de conocer sus claves, lo que hace que el KDC devuelva el TGT cifrado con la contraseña de ese usuario, dando la oportunidad al atacante de crackearla.
Golden Ticket
Una vez obtenido un Golden ticket es muy difícil deshacerse de él (Fuente), por lo que lo más recomendable es prevenir el robo de credenciales, capacitando a los usuarios para reconocer enlaces maliciosos. Además, de instalar protección de terminal para que los atacantes no carguen módulos de malware, por último, se puede crear una conexión administrativa explicita con una sola terminal para que nadie pueda acceder a la administración del AD.
Conclusión
Esto sería una pequeña pincelada de las posibles defensas que podría establecer el encargado de la seguridad del entorno para poder protegerse de los ataques que se han ido viendo durante los anteriores post.
En el siguiente y último post, indicaremos los resultados obtenidos tras el seguimiento de la metodología y una pequeña conclusión.