Archivo de la etiqueta: seguridad

Azure AD Privileged Identity Management

Dentro de la suite de seguridad que nos proporciona Azure EMS, encontramos la solución ante una de las dudas que muchos usuarios y administradores del servicio han tenido.

¿Cómo concederíamos acceso administrador o de servicio a nuestro tenant de Office 365 o Azure Active Directory durante un tiempo limitado o mediante revisiones teniendo un registro de auditoría de todo el proceso?

La solución a ese problema se denomina: Azure AD Privileged Identity Management.

En primer lugar, para realizar un deployment de la aplicación en nuestro servicio de Azure AD, son necesarios los siguientes requisitos:

  • Acceso administrador global.
  • Licencia Azure Active Directory Premium Plan 2, la cual podemos activarla de forma independiente o a través del paquete de Azure EMS E5.

Caso de uso

Procedemos a su búsqueda en el portal de Azure y activación. Al realizar el primer acceso, automáticamente aparecerá el Security Wizard, el cual nos guiará para activar los administradores de PIM (Privileged Identity Management), revisar el acceso permanente para los administradores de los diferentes servicios como actualmente o cambiarlos a elegibles, en caso de optar por ésta segunda opción, su administración se realizará a través de diferentes peticiones y con un tiempo limitado.

Una vez que tenemos todo configurado, veremos lo siguiente en nuestro portal:

Vamos a explicar cada uno de las opciones por pasos:

  • Activate my roles: En caso de ser un administrador elegible, podremos activar los roles de administrador al servicio que nos hayan proporcionado indicando la razón de esta necesidad y por defecto, es obligatorio hacer uso de MFA para que los roles puedan ser activados.

Una vez activado, podremos observar la fecha de espiración del rol asignado:

  • Managed privileged roles: Desde esta sección podremos ver un resumen de los diferentes roles de administración que tenemos asignados en nuestro directorio, así como alertas en caso de que los valores en las políticas que hayamos definido se hayan superado, un resumen de auditoría y las diferentes opciones presentes para modificar las políticas que debe de cumplir cada rol.

Desde el historial de auditoría podremos ver el número de activaciones de roles que se ha producido durante el día, así como diferenciar por colores los diferentes roles que tenemos activos en nuestro directorio, pudiendo exportar en todo momento esta auditoría a un fichero .csv para analizar los datos mejor en nuestro cliente preferido:

Desde el apartado de configuración, podremos modificar las políticas de acceso a un determinado rol, en este caso seleccionaremos el de administrador global desde el cual podremos indicar el número de horas que vamos a permitir de acceso (mínimo 30 mins.), enviar emails de las activaciones que se producen por los administradores elegibles a los administradores actuales del directorio, requerir un número de ticket para el usuario que quiere escalar sus privilegios en el directorio y por último y de manera obligatoria, requerir MFA.

En las configuraciones de alertas podremos definir por ejemplo, el trigger con el cual queremos que nos alerte de que nuestro directorio cuenta con > X administradores, etc.

Por último, en las configuraciones de revisiones de acceso podremos definir, notificaciones de emails, recordatorios, requerir una razón para aprobar o denegar el acceso y la duración en días que una revisión de acceso estará disponible.

  • Review privileged access: Desde este último punto, podremos revisar los roles que tenemos pendientes de los usuarios elegibles en caso de que así lo hayamos configurado previamente, podremos seleccionar quién o quiénes serán los revisores y deberemos de aprobar o denegar el acceso de esos administradores elegibles con una razón, por defecto nos enviará emails recordatorios y hemos marcando un tiempo máximo de 30 días.

Conclusiones

Viendo la versatilidad del producto, es importante tenerlo en cuenta para aumentar la seguridad en nuestro directorio activo de Azure, alertarnos de diferentes aspectos de administración e incluso establecer políticas de revisiones de acceso para escalar un rol determinado en nuestro entorno.

Esperemos que os haya gustado el ejemplo de uso en un entorno real.

Alerta de Seguridad: Ejecución remota de código MS15-078

https://technet.microsoft.com/library/security/MS15-078

Esta semana se ha desplegado un parche de seguridad crítico que corrige una vulnerabilidad de ejecución de código remoto. Esta vulnerabilidad afecta a todas las ediciones de Windows. El vector de ataque se basa en la apertura de documentos diseñados específicamente a tal efecto, o la visita a páginas web que contenga tipografías OpenType incrustadas que hayan sido diseñadas para explotar el fallo.

La vulnerabilidad se produce por la forma en que la “Windows Adobe Type Manager Library” gestiona las fuentes OpenType.

Formas de explotación: Se requiere interacción por parte del usuario objetivo, que ha de abrir un documento con una fuente openType  incrustada que haya sido diseñada a tal efecto, o bien visitar una página web que contenga la tipografía OpenType.

Acciones a realizar: Toda máquina que se haya actualizado y necesite un reinicio debe ser reiniciada lo antes posible para evitar posibles infecciones que sucedan durante la navegación web en sitios de poca confianza. En las máquinas que no tengan configurado Windows Update para que descargue e instale automáticamente las actualizaciones, el sistema debe ser actualizado manualmente y reiniciado para que la actualización tenga efecto.

Asegura la legitimidad de tu email con los registros SPF

Los que nos dedicamos a la mensajería y la colaboración tenemos bien presente que el SPAM y el phishing son dos de los grandes enemigos a los que debemos enfrentarnos, dos tipos de amenzadas que tienen el denominador común de la legitimidad del email, entendiendo por email legítimo aquél que se ha generado por parte de una persona al cargo de un buzón que se encuentra en el dominio del remitente que indica.

Desde hace ya más de una década hay esfuerzos más o menos coordinados para luchar contra el correo basura a través de múltiples estrategias entre las que podemos comentar:

  • Crear listas negras que incluyan servidores SMTP que se encuentren configurados como open relay,una configuración que permite que un tercero pueda utilizar esa máquina para enviar correo usando a su vez identidades falsas.
  • Establecer una regulación de las listas de distribución y correos masivos por parte de organizaciones e individuales que garantice que la recepción de dichos mensajes es autorizada por parte de sus correspondientes destinatarios, que a su vez pueden anular su suscripción en cualquier momento.

Sin embargo, las distintas estrategias planteadas con anterioridad no han sido suficientemente prácticas para erradicar completamente estas malas prácticas. Es por ello que en este artículo os vamos a hablar del Sender Policy Framework (SPF), que es una solución eficaz a estos problemas a medida que se va implementando cada vez más en los servidores SMTP de todo el mundo.

El SPF es un sistema de validación de email extremadamente sencillo que se apoya en la infraestructura DNS de las distintas organizaciones. El concepto es bien sencillo: a través de nuestro DNS vamos a declarar qué servidores están autorizados a enviar email a nombre de los dominios que tenemos en nuestra propiedadComo la información de los DNS es pública, cualquier sistema SMTP puede consultarla para cotejar si el servidor desde el que el correo electrónico ha sido enviado figura como autorizado por el listado.

La sintaxis y la forma de operar con el registro es bien sencilla. Veamos un ejemplo real con el SPF de Plain Concepts:

Sin ser demasiado expertos podemos ver una serie de IPs declaradas. En efecto, todas ellas constituyen direcciones que potencialmente pueden tener la capacidad de enviar correos electrónicos a nombre de plainconcepts.com y que nosotros estamos declarando como legítimas.

¿Cómo construimos un buen SPF para nuestro dominio?

La sintaxis es tremendamente sencilla. El concepto clave es: si el mensaje no está gestionado o enviado por cualquiera de las cosas que declaremos, entonces especificamos una política por defecto. Para ello, seguimos los siguientes pasos para… imaginemos el dominio cantoso.com:

  1. Creamos un nuevo registro TXT en cantoso.com. Si quisiéramos declarar SPF en subdominios, deberemos crear una entrada por cada uno de ellos.
  2. El valor del registro debe comenzar por v=spf1 donde especificamos que vamos a declarar un SPF y su versión.
  3. Lista de máquina autorizadas a enviar correo en nombre de nuestro dominio. Para ello podemos usar las siguientes palabras clave:
    • A: si vamos a declarar un nombre declarado como registro A ó AAAA. Ejemplo: a:mail.plainconcepts.com
    • IP4: si vamos a declarar una dirección IPv4 o un rango. Ejemplo: ip4:2.212.170.67 ó ip4:192.168.0.0/24
    • IP6: similar al anterior, pero usando direcciones o rangos IPv6.
    • MX: si vamos a usar una resolución de registro MX. Ejemplo: mx:plainconcepts.com.
    • INCLUDE:  que utilizaremos si vamos a usar las políticas SPF declaradas en otro dominio, muy usada en entornos cloud. Ejemplo: include:spf.protection.outlook.com.
    • ALL: esta palabra clave hace match con todo.
    • La palabras clave A, MX, e INCLUDE implican resolución de nombres DNS. SPF limita a 10 consultas DNS, por lo que debemos tener cuidado de no abusar de los registros que hacen uso de ellas.
  4. Cerramos nuestra cadena con -all. Usando -all especifica que todo lo que no haya cumplido con los elementos anteriores, fallará la validación SPF. Una alternativa común es usar ~all que nos indica que los mensajes serán aceptados pero etiquetados.

Así, volvamos a echar un vistazo a la cadena de plainconcepts.com y el significado de cada elemento:

Examinemos los elementos:

  • v=spf1 es la declaración del registro SPF.
  • include:spf.protection.outlook.com deriva de nuestro uso de Office 365, por lo que incluimos sus servidores SMTP como autorizados para nuestro dominio.
  • include:sendgrid.net es similar al anterior, pero relativo a los servicios de SendGrid.
  • ip4: todas estas entradas están autorizadas a enviar correo en nuestro nombre.
  • -all: si la dirección IP del remitente no entra dentro de ninguna de las reglas anteriores, especificamos que la validación falla.

¿Sólo con establecer este registro estamos protegidos?

Lamentablemente no, aunque hemos hecho la parte que nos toca en relación a la declaración del SPF. El registro como tal sólo proporciona información a los MTA y es decisión de cada uno hacer validación mediante este mecanismo o no.

Si un servidor SMTP usa SPF, su flujo sería parecido al siguiente:

  1. mail.plainconcepts.com recibe un email de jorge@cantoso.com desde la IP 193.153.214.55.
  2. mail.plainconcepts.com coteja la IP 193.153.214.55 con el SPF declarado por cantoso.com, que resulta ser “v=spf1 ip4:2.213.33.45 -all”.
  3. La IP no coincide con ninguna de las declaradas y la validación falla.
  4. mail.plainconcepts.com considera el correo ilegítimo y lo marca como tal.

Si jorge@cantoso.com envía un email a paco@fabrikam.comFabrikam no implementa validación SPF, de poco sirve a cantoso.com tener publicada esa información en el DNS para ese caso concreto.

¿Cómo activo el SPF en Office 365?

Por defecto Office 365 tiene DESACTIVADA la validación SPF. Sin embargo, activarlo es un proceso realmente sencillo:

  1. Iniciamos la sesión como administrador de Exchange Online.
  2. Vamos a Protección -> Filtro de contenido.
    spf1
  3. Seleccionamos la política por defecto y la editamos.
  4. Nos dirigimos a Opciones avanzadas -> Registro SPF: error
    spf2
  5. A partir de este momento Office 365 empieza a realizar validaciones SPF.

Espero que este artículo os haya servido para aprender una forma sencilla y eficaz de proteger y legitimar tanto la identidad de vuestro correo electrónico saliente, como de aquellos mensajes entrantes que pasan por vuestras estafetas SMTP.

Happy mailing!

Enlace relacionado: RFC 7208 – Sender Policy Framework
Enlace relacionado: SPF – Wikipedia