Certificados con Subject Alternative Name

Buenas,

Hoy me gustaría hablaros sobre cómo generar certificados para sitios web o similares que contengan el alias dns del sitio al que nos conectamos en el subject alternative name debido a que si el nombre del sitio web apararece solo en el nombre del certificado, algunos navegadores como puede ser Chrome a partir de la versión 58 muestran un warning indicando que el sitio web no es seguro.

Podéis encontrar información más detallada acerca del warning de seguridad mostrado por chrome a partir de la versión 58 en la siguientes enlaces:

https://communities.ca.com/thread/241776307

https://community.tenable.com/thread/11586

Una vez hecha esta breve introducción procederemos a detallar el procedimiento que debemos seguir para generar una csr (Certificate Signing Request) que contenga el subject alternative name, para ello seguiremos los siguientes pasos:

1- Generar un fichero de configuración con extensión cnf el cual contendrá el subject alternative name o los subject alternative name que queremos que contenga el certificado. El formato de este fichero será muy similar al siguiente:

2- Seguidamente con openssl crearemos la clave de nuestro certificado usando el siguiente comando
openssl genrsa -out mykey.key 4096

3- El último paso que debemos hacer para generar la csr usando la clave y el fichero de configuración creados anteriormente será ejecutar el siguiente comando de openssl
openssl req -out sslcer.csr -key mykey.key -new -sha256 -config san.cnf

Una vez generada la csr procederemos a firmarla con nuestra entidad certificadora y observaremos como el certificado generado incluye el subject alternative name definido

Espero que sea de utilidad.

Un saludo

Como detectar si tu Windows server están protegidos frente Wannacry

Buenas,

Este post no pretende explicar al detalle que es el ransomware Wannacry ni tampoco los devastadores efectos que este malware está creando en números empresas del el pasado viernes 12 de mayo de 2017 asumiendo que los lectores de este post ya se han pegado la pechada de trabajar en el parcheo de sus servidores con las actualización de seguridad MS17-010 la cual protege nuestros sistemas frente a este malware y que se puede encontrar en la siguiente página:

https://technet.microsoft.com/en-us/library/security/ms17-010.aspx

Una vez hemos estado mucho de nosotros parcheando y reiniciando servidores como locos durante el fin de semana, toca hacer el ejercicio de analizar cuales de nuestros sistemas tienen el parche de seguridad y por lo tanto están protegidos y en cuales tenemos que instalarlo.

A fin de automatizar esta tarea Mahesh Chandraiah ha creado el script de powershell detallado a continuación el cual parte de una modificación de siguiente script, el cual está públicado en la Microsoft script gallery y nos permite detectar si una determinada una update está instalada en un sistema remoto haciendo un query de WMI.

Las modificaciones que he realizado en el script por mi parte son minimas, tan solo he añadido los kbs de los parches que protegen de esta vulnerabilidad en las distintas versiones de Windows server y he modificado un poco la lógica para preguntar por un kb u otro dependiendo del sistema operativo de servidor.

Este script sigue usando un fichero de texo como entrada el cual por defecto será c:\temp\computers para leer el hostname de los equipos a chequear.

Y genera una salida en formato Excel, la cual nos permite identificar fácilmente si nuestros sistemas están protegidos o no.

Los requisitos para correr el script son dos y bastante básicos.
– Ejecutar powershell en el equipo que realizamos la comprobación con una cuenta de servicio que pueda enviar querys wmi a los servidores en los que pretendemos detectar si el parche están instalado o no
– Tener Excel instalado en la máquina que ejecutamos el script.

Una vez explicado todo esto solo me queda pegaros el código del script.

 

Espero que os resulte útil

Un saludo

 

Buenas Prácticas para Securizar nuestros Domain Controllers (2 de 2)

Hola,

Seguimos hoy con esta segunda entrada de la serie en la que detallaré otras 5 buenas practicas que debemos seguir para garantizar un nivel de seguridad aceptable de nuestros controladores de dominio y por lo tanto de nuestro Active Directory.

Primero que todo me gustaría dirigiros a la lectura de primer artículo de la serie el cual podéis acceder en el siguiente link antes de continuar con la lectura de este.

Una vez hecha está breve introducción pasamos a detallar las siguientes 5 medidas de seguridad las cual recomiendo su adopción.

6– Instala un software de antivirus en los controladores de dominio y configura las opciones del mismo siguiendo las best practices de Microsoft recogidas en el siguiente enlace. En este caso será de igual importancia instalar el software antivirus como configurar de manera pertinente las exclusiones, de lo contrario el rendimiento de nuestro controladores de dominio se puede ver seriamente afectado

7– El cifra el disco de los controladores de dominio usando bitlocker o cualquier otra tecnología de cifrado de datos, de lo contrario la base de datos de nuestro directorio activo y otros archivos sensibles podría ser comprometidos si un atacante obtiene acceso al disco físico del controlador de dominio o al disco duro virtual si este corre sobre un hypervisor.

8– Despliega siempre más de un controlador de dominio en cada dominio de directorio activo y asegúrate de que los mimos se ejecutan sobre distinto hardware. En el caso donde los controladores de dominio corran en físico será muy asegurar este requerimiento, sin embargo también debemos ser capaces de garantizarle cuando los controladores de dominio se ejecuten en un entorno de virtualización definiendo reglas de antiafinidad en el cluster con el objectivo de asegurar que todos nuestros dcs no se encuentran en ejecución en el mismo nodo.

9– Es de vital importancia realizar backup de nuestro directorio activo y probar que somos capaces de realizar una recuperación completa en un entorno controlado al menos una vez por año, igualmente es importante mencionar que la estrategia de backup debe estar basado en Windows server backup haciendo backup del system state, aunque si bien es cierto que posteriormente podemos exportar los backups del system state a cinta u otra localización este siempre debe ser el primer mecanismo de backup al ser el 100% soportado y recomendado por Microsoft. Igualmente recomendaremos habilitar la papelera de reciclaje de directorio activo y realizar backup de gpos mediante script para poder recuperar fácil y rápidamente objetos y políticas.

10– Despliega Read only domain controllers en las localizaciones donde los controladores de dominio no están en una infraestructura totalmente securizada y pueden ser comprometidos, idealmente desplegaremos read only domain controllers en cualquier sucurla fuera de los los datacenter y permitiremos la replicación de password unicamente de los usuarios y máquinas que normalmente autentican contra ese RODC.

Espero que os resulte de utilidad.

Un saludo

Buenas Prácticas para Securizar nuestros Domain Controllers (1 de 2)

Buenas,

Comenzamos hoy una serie de 2 artículos en los que me gustaría exponer una serie de buenas prácticas o recomendaciones para mejorar la seguridad en nuestros controladores de dominio, lo cual será un elemento fundamental para mejorar de manera sustancial la seguridad del dominio.

Estos articulo pretende dar una serie de recomendaciones pero no ir paso a paso al detalle de cómo implementar las mismas puesto que por el contrario los artículos serían demasiado largos y bastante complejos de leer y seguir.
Una vez hecha esta breve introducción y definido el ámbito de los articulos paso a detallar las buenas prácticas que yo considero fundamentales para mejorar la seguridad de nuestros controladores de dominio.

1– Parchear los controladores de dominio: Aunque pueda parecer muy básica no todo el mundo lo hace. Los parches de seguridad de Microsoft corrigen números vulnerabilidades en los controladores de dominio y es muy importante mantener los mismos actualizados.

2– Reducir el número de Domain Admins al mismo posible y usar las credenciales de Domain Admins solo cuando es necesario: Para proteger nuestros controladores de dominio y nuestro dominio en general debemos tener en el grupo Domain admins únicamente las cuentas de adm de los administradores del dominio y no ninguna otra persona de it de nuestra organización y por supuesto ningún usuario estándar. Igualmente es importante remarcar que los administradores de dominio también tendrán una cuenta estándar para su trabajo rutinario y que solo usarán la cuenta de domain admin para realizar tareas administrativas en el dominio.

3– Proteger las cuentas de servicio con permisos de Domain Admins: Si por algún motivo tenemos la necesidad de que una cuenta de dominio tenga permisos de Domain admins debemos proteger la misma. Intentando definir Manged service accounts siempre que sea posible o definir contraseñas complejas (más de 25 caracteres) y asegurar que el cambio de la misma sucede al menos 2 veces por año.

4– Implemente fine grained password para los Domain Admins: Los requisitos de complejidad y vigencia de la password de un Domain Admins no puede ser nunca los mismos que los de un usuario estándar, por lo tanto es muy recomendable define políticas de fine grained password policy con complejidad alta y vigencia de password corta para los Domain Admins

5– Configurar inactive log-off sesión para Domain Admins: en las cuentas de Domain Admins también será una muy buena práctica forzar el logoff de la sesión tras 10 minutos de inactividad con el objetivo de asegurar que no dejamos sesiones de administador inactivas las cuales podrían ser comprometidas.

En el siguiente artículo de la serie detallaré otras 5 buenas prácticas para mejorar la seguridad en nuestros domain contollers.

Espero que resulte de utilidad

Un saludo

Premium Assurance – Extensión de soporte para Windows Server y Sql 2008

Buenas,

Hoy me gustaría hacer eco de una noticia que publico Microsoft a finales del 2016 la cual tiene una gran relevancia de cara a la planificación de actualización o migración ya sea on-premises o al cloud de los sistemas actuales corriendo bajo Windows server y sql Server 2008. Está noticia la cual creo que es bastante relevante, creo que también es general desconocida para la mayoría de los administradores de la plataforma Wintel.

Como todos o la mayoría de nosotros sabemos, el soporte extendido de Sql server 2008 termina en julio del 2019 y el soporte extendido de Windows server 2008 R2 termina en Enero de 2020, lo que nos llevaba a la necesidad de comenzar a pensar y planificar en la actualización o el remplazo de los sistemas corriendo bajo estas versiones.

Sin embargo Microsoft a finales del pasado año anuncio Windows server Premium assurance y sql server Premium assurance, lo cual es un paquete que estará disponible para los clientes de software assurance el cual permitirá ampliar el soporte de Windows server 2008 y sql server 2008 hasta 6 años más como podéis ver en la imagen adjunta.

Igualmente debemos saber que Premium assurance evidentemente tendrá un coste el cual comenzará con 5% de la licencia y se irá incrementando de manera anual hasta un máximo de un 12% de licencia del producto habilitado con esta funcionalidad y que durante este periodo Microsoft proporcionara parches críticos y high y posibilidad de abrir casos de soporte.

Creo que con lo mencionado anteriormente quedaría bastante claro este tema, no obstante adjunto el enlace al anuncio oficial de Microsoft.

https://blogs.technet.microsoft.com/hybridcloud/2016/12/08/introducing-windows-server-premium-assurance-and-sql-server-premium-assurance/

Espero que resulte de utilidad

Un saludo

Funcionamiento del AdminsdHolder en Directorio Activo

Buenas,

A raíz de una consulta que he recibido esta semana por mail me gustaría aprovechar para comentar que es AdminsdHolder y como está relacionado el mismo con la consulta que he recibida esta semana.

En la consulta que recibí me preguntaban sobre la manera para delegar un grupo de directorio activo para que los miembros del mismo pudieran agregar y eliminar miembros del grupo account operators puesto que definían los permisos editando la seguridad del grupo account operators y al rato se deban cuenta de que las acls del mismo habían vuelto a tener los valores iniciales.

La explicación de todo esto se basa en el Adminsdholder, puesto que este es un mecanismo de seguridad que se ejecuta cada hora en los dcs el cual define los permisos de los grupos de protegidos con la misma definición de permisos definida el Adminsdholder con el objetivo de garantizar la seguridad de los grupos protegidos de directorio activo como pueden ser Enterprise admin, domain admins, schema admins, account operators y server operators.

Como normalmente las imágenes suelen ser más explicativas que las palabras pasamos a realizar una demostración.

1- En un entorno de demo he añadió la cuenta testsam con permisos de control total en la cuenta del Enterprise admin

2- Al volver a comprobar un poco más tarde podemos observar que la acl de seguridad de la cuenta del Enterprise admin se ha vuelto al valor inicial.

3- Si Abrimos la consola de usuarios y equipos de directorio activo y vamos system, adminsdholder y accedemos a sus propiedades para ver la opciones de seguridad observamos que son las misma que se han definido al usuario del Enterprise admin

Con esto quiero explicar que si por algún motivo queremos modificar los permisos de las grupos a las cuentas protegidas debemos de modificar los permisos del adminsdholder y siempre aplicarán a todas las cuentas y grupos protegidos, por lo que será muy recomendable dejar estos valores por defecto y definir la de otra manera sin usar cuentas y grupos protegidos.

Espero que resulte de utilidad.

Un saludo

Servicios de directorio activo gestionado en la nube: AWS Directory Service for Microsoft Active Directory & Azure Active Directory Domain Services

Buenas,

Hoy me gustaría hacer el último post de año hablando de AWS directory services for Microsoft active directory y Azure domain services.

Los servicios de directorio en la nube es algo que cualquier empresa mediana/grande en la actualidad debe considerar, sobre todo teniendo en cuenta la tendencia actual en la que la empresas actuales están consolidando cada vez más servicios en el public Cloud.
Si bien es cierto que tanto Amazon con Azure proveen una capa de servicios básicas de directorio en la nube la cual nos permite básicamente proveer de autenticación a nuestras aplicaciones modernas y servicios Cloud, hoy me gustaría ir un paso más adelante y hablar del servicio de directorio activo gestionado que proveen tanto Amazon como Azure bajo los nombres de AWS de Directory Services for Microsoft Active Directory & Azure Active Directory Domain Services. La diferencia principal entre el servicio de directorio básico y el servicio gestionado de directorio activo reside en que el servicio básico de directorio activo nos permite proveer de autenticación a aplicaciones modernas (cloud), sin embargo si queremos realmente disponer del servicio de directorio activo gestionado en la nube y autenticar en aplicaciones legacy con kerberos, ldap o NTLM y disponer de funcionalidades como domain join o gpos nuestra opción pasará por contratar y usar un servicio de directorio activo gestionado en la nube.

Una vez resumidas las diferencias entre un servicio de directorio básico en la nube y un servicio de directorio activo gestionado, me gustaría dar algo más de detalles acerca de la funcionalidades soportadas tanto por AWS Directory services for Microsof Active Directory como por Azure Active Directory domain services, ambos productos son muy similares por no decir iguales en cuanto a funcionalidades, soportando ambos las siguientes funcionalidades:

– Monitoring: Ambos proveedores de cloud proveen monitorización de la disponibilidad y del rendimiento del servicio.

– Alta disponibilidad: Ambos servicios gestionados despliegan dos controladores de dominio para proveer alta disponibilidad a la solución

– Backup: Se realizan backup periódicos del servicio gestionado y tenemos posibilidad de realizar una recuperación

– Domain Join: Nos permite conectar los servicios corriendo en la nube a los servicios de directorio activo gestionado

– Ldap, NTLM & keberos support: Quizas la funcionalidad que nos haga decantarnos por los servicios de directorio activo gestionado la cual posibilita el movimiento de aplicaciones legacy al public cloud.

– Creación de relaciones de confianza: Ambos soluciones nos permiten crear relaciones de confianza con nuestro dominio on-premises.

– Extensión de Esquema: Si tenemos aplicaciones que requieren de una extensión de esquema para funcionar podremos realizar dicha extensión de esquema a nuestro directorio activo gestionado en el cloud

– GPos y DNS: Ambos servicios de directorio nos permiten crear gpos e interactuar con el servicio de dns

– Uso de las herramientas de administración tradicionales:
La administración/gestión del servicio de directorio gestionado en la nube se realiza principalmente con las herramientas tradiciones de administración como son la consola de usuarios y grupos de directorio activo, la consola de dns y la de gpos.

Como podéis observar ambos servicios son iguales en lo referente a funcionalidades y desde mi punto de vista los factores determinantes a la hora de decantarnos por uno u otro serán el precio y el proveedor en el que se ejecuten nuestra vms corriendo en el cloud en un módulo de Infrastructure as a service.

Espero que resulte de utilidad.

Un saludo

Mejoras de DNS en Windows Server 2016

Buenas,

En este post me gustaría explicar las principales ventajas incluidas en el role de DNS incluidas en Windows Server 2016. Como todos sabemos DNS es un servicio clave en cualquier red empresarial el cual nos permite realizar la resolución de nombres en nuestro dominio, o lo que es lo mismo convertir nombres en ips e ips en nombre si tenemos la resolución reversa activada. Igualmente es importante recordar que los servicios de Directorio Activo se basan y tienen una dependencia total del servicio de DNS, por lo tanto de una manera o de otra las nuevas funcionalidades de DNS incluidas en Windows Server 2016 también tendrán un beneficio colateral para Directorio Activo.

Bien, una vez hecha esta breve introducción pasamos a detallar las mejoras principales que trae dns en Windows Server 2016.

– DNS policyes: O políticas de DNS, nos permiten controlar la forma en la que los registros DNS responden a las querys de DNS, permitiéndonos por ejemplo controlar el bloqueo para solicitudes DNS conocidas como maliciosas.

-Response Rate Limit: Como su propio nombre indica nos permitir configurar un ratio de respuestas a las querys DNS en nuestros servidores, el objetivo principal de esta funcionalidad es proteger el servidor DNS contra ataques de denegación de servicio permitiendo limitar el número de veces por segundo que un servidor DNS puede responder a las querys de un determinado cliente.

– IPAM: Aunque esta funcionalidad ya estaba disponible en Windows server 2012 ha sido mejorada de una manera muy notable en Windows Server 2016. Dentro de las funcionalidades incluidas en IPAM 2016 destacaremos las dos siguientes:
– Incluye gestión del servicio de DNS e inventario de los registros host
– Soporta Gestión de más de un forest de directorio activo con una sola plataforma de IPAM: Como requerimientos mencionaremos la necesidad de tener una relación de confianza entre los forests y desplegar un servidor de ipam dentro de la plataforma en cada forest.

Espero que resulte de utilidad.

Un saludo

Azure Active Directory Group Self-service Request

Buenas,

Hoy me gustaría hablar de Azure Active Directory Self-Service request, esta funcionalidad dentro del portal de Azure nos permitirá que nuestros usuarios de Azure active directory pueden solicitar acceso a las aplicaciones de Azure configuradas de esta manera. Evidentemente igual podremos configurar que los administradores de la aplicación sean los encargados de aprobar o denegar dicho acceso.

De manera teórica creo que esta funcionalidad no requiere mucha más explicación, por lo tanto procedemos a explicar de manera práctica como configurarla.

1– Primero que todo nos logamos en el portal de azure y accedemos al directorio que usamos para publicar nuestras aplicaciones

2– Seguidamente pinchamos en configure.

3– Dentro del apartado de configure accedemos al apartado de group management y habilitamos “delegated group management” y en nuestro caso configuraremos en “some” users who can use self-service for security groups

4– Posteriormente accedemos a aplicaciones y concretamente a la aplicación donde queremos configurar el self service en nuestro ejemplo será para twitter el cual tenemos renombrado como corp_twitter y lo configuramos según aparece en el pantallazo

5– Seguidamente y al igual dentro de la aplicación pinchamos en en assign account para definir las cuentas que pobran acceder a la aplicación

6– En este caso en particular definiremos el grupo de selfservice definido en el paso anterior

Una vez llegados a este punto ya tendríamos la configuración lista, por lo tanto procederemos ahora a testear la funcionalidad y ver la experiencia de usuario, para ellos realizaremos los siguientes pasos.

1– Accedemos a https://myapps.microsoft.com y en mi caso me logaré con un usuario de prueba que creado el cual se tstselfserviceuser

2– Como podemos ver el usuario no tiene aplicaciones asignadas y pincharemos en obtener aplicaciones

3– Posteriormente buscamos la aplicación sobre la queremos tener acceso, en nuestro caso corp_twitter y hacemos click sobre la misma

4– Posteriormente pinchamos en agregar

5– Una vez realizado este paso se nos notifica que la aplicación está pendiente de aprobación

6– El administrador aprobara el acceso a la aplicación en el portal de azure

7– Por ultimo comprobamos que la aplicación nos aparece en myapps y que podemos acceder a la misma

Espero que os resulte de utilidad

Un saludo

Azure Active Directory Password Rollover

Buenas,

Hoy me gustaría hablar de la funcionalidad Azure Active Directory Password Rollover la cual está aún en preview. Esta funcionalidad nos permite no solo almacenar las password de las cuentas de uso compartido que toda organización usa como Facebook, twitter y linkedin sino que también incorpora la funcionalidad de cambiar las password de estas redes sociales en nuestro ejemplo de una manera automática usando una periodicidad definida por nosotros. Evidentemente estos cambios de password realizados de manera automática hace que el acceso a las redes sociales de la empresa sea más seguro y 100% gestionado por Azure.

Una vez realizada esta breve introducción de la funcionalidad pasamos a ver de manera práctica cómo funciona la misma.

1- Accedemos al portal de azure y al directorio donde queremos habilitar esta funcionalidad

2- En este caso en particular voy a créate un nuevo usuario en el directorio para mostrar el proceso completo, para ello pinchamos en “Add user” y seguimos las tres pantallas detalladas a continuación del wizard de creación de usuario

3- Posteriormente vamos a la pestaña de “applications” y pinchamos en add para añadir una nueva aplicación

4- En este caso añadiremos una aplicación desde la galería

5- Buscamos y selecciones twitter en este ejemplo como aplicación para añadir definiendo el nombre que queremos mostrar a los usuarios en el campo Display Name

6- Pinchamos en configure single sign on

7- Posteriormente pinchamos en Assign Accounts

8- Seleccionamos la cuenta que hemos creado y seleccionamos en Assign

9- En este pantalla será en la que habilitaremos password rollover, seleccionando primero que queremos que azure sea quien introduzca las credenciales de la aplicación en lugar de los usuarios y posteriormente habilitando password rollover

10- Por último definimos con que periodicidad cambiará Azure la password de la aplicación definida en la política de password rollover

Espero que resulte de utilidad

Un saludo