Despliegue de Maquinas Virtuales usando SysPrep y discos de diferenciacion

Siguiendo al hilo de la Virtualización, hay una situación que todo el mundo encuentra tarde o temprano: Necesitamos desplegar unas cuantas máquinas virtuales de laboratorio, y no podemos permitirnos el lujo de esperar durante 1 hora a que terminen de instalarse y configurarse. Las necesitamos para ayer. Y necesitamos que sean instalaciones “limpias”. ¿Qué hacer?

A nuestro rescate vienen dos herramientas poderosas: SysPrep y los Discos de Diferenciación. Antes de entrar en materia, vamos a resumir qué es y qué hace cada una de ellas:

¿Qué es SysPrep (System Preparation)?

Es una herramienta que prepara una instalación de Windows (tanto de escritorio como Windows Server) para crar una imagen, permitiéndonos captuar una instalación personalizada. Esto lo consigue eliminando información específica del PC donde se ha instalado, “Generalizando” la instalación para que así se pueda instalar en otro PC. Con SysPrep se puede configurar el PC para que arranque la “Out-of-Box Experience” para que se encienda como si Windows estuviese recién instalado. Incluso se puede especificar un archivo xml con los datos necesarios para realizar una instalación desatendida. Básicamente, es la herramienta que los fabricantes de portátiles usan para llenar con su software una instalación de Windows, y luego la generalizan para que podamos personalizarla como si estuviese recién instalada.

¿Qué es un Disco de diferenciación?

Es un disco virtual que se utiliza para aislar cambios en los datos del disco o del sistema operativo instalado en él, manteniéndolos en un archivo separado. En este caso, un disco diferencial consta de dos partes: El disco “base”, que se utiliza como datos origen que no van a cambiar (por ejemplo una instalación actualizada de Windows), y el disco de diferenciación, que es básicamente un disco de tamaño dinámico en el que se escriben todos los nuevos datos. Una cualidad de especial interés es que podemos crear múltiples discos de diferenciación a partir del mismo disco base.

Seguir leyendo Despliegue de Maquinas Virtuales usando SysPrep y discos de diferenciacion

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

Conversión Físico-A-Virtual

Imaginemos que nos encontramos con máquinas antiguas, que usan un software obsoleto e incompatible con los últimos SSOO, y que son absolutamente imprescindibles. Y para rizar el rizo, se sufre el riesgo de sufrir un fallo hardware a corto/medio plazo.

Si queremos asegurarnos de que un problema físico no nos vaya a provocar una parada de servicio o si deseamos mejorar el rendimiento del servicio más allá de los límites físicos impuestos por hardware obsoleto, una de las opciones más asequibles para conseguirlo es convertir el servidor en una máquina virtual, proceso conocido como P2V (Physical-to-Virtual).

Hay productos que nos permiten hacer esto de forma sencilla, como SCVMM 2012 (Microsoft System Center Virtual Machine Manager), que ofrecen un asistente capaz de convertir casi cualquier máquina física en una máquina virtual (mediante la instalación de un asistente en dicha máquina). O podemos optar por usar un software algo más limitado, pero igualmente útil. Además, hay que tener en cuenta que en SCVMM 2012R2 no se permite la conversión P2V.

Estoy hablando de una herramienta que forma parte de la colección de SysInternals: Disk2VHD. Esta pequeñísima herramienta nos permite convertir fácilmente cualquier disco duro físico en un disco VHD (o vhdx). Tiene ciertas limitaciones, pero es perfectamente válida para el P2V.

Seguir leyendo Conversión Físico-A-Virtual

AAD Sync

Con este título tan críptico, en este post queremos aprovechar y hablaros sobre la última versión de Azure Active Directory Sync, más conocido anteriormente como Dirsync.

La beta 3 que salió hace menos de un mes y que tenéis disponible a través de Connect, ya permite vislumbrar tanto la interfaz como las nuevas funcionalidades que traerá el sincronizador gratuito de Microsoft para Azure Active Directory.

AAD Sync

Entre las funcionalidades más destacables, nosotros queremos resaltar las siguientes:

1.   Sincronización desde multi-forest: de manera muy sencilla vamos a poder añadir bosques de AD en el propio asistente y definir qué atributos del usuario se encuentran en cada uno de ellos.

MultiForest

AttributeMapping

2.   Sincronización desde otros directorios (LDAP, SQL,…): aunque en la beta 3 no tenemos todavía disponible la opción, en la versión final se podrán sincronizar usuarios desde directorios que no sean AD como puede ser un LDAP en Linux, una base de datos SQL, etc. Desde luego esta será una de las características más apreciadas por multitud de clientes con entornos heterogéneos, como pueden ser las Universidades.

3.   Password write-back: dar la posibilidad a un usuario de que se cambie la contraseña de dominio cuando quiera, incluso fuera de la red corporativa, muchas veces puede resultar complicado. La necesidad de conectarse a la VPN, montar un portal web con ADFS, utilizar FIM, son algunas de las opciones más comunes. Con esta nueva versión de Dirsync, y apoyándonos en Azure Active Directory Premium, podremos utilizar el propio portal de Azure accesible por el usuario para resetearse la contraseña local. Podemos utilizarlo tanto con la sincronización de passwords que ya teníamos con Dirsync como en un entorno federado con ADFS.

Password write-back

Recordar que debéis tener habilitado Azure Active Directory Premium para el directorio en cuestión, sino recibiréis un error:

Error AAD Premium

4.   Filtrado de atributos por aplicación: permite sincronizar a Azure Active Directory únicamente los atributos del usuario que sean necesarios para poder trabajar con ciertas aplicaciones. De esta manera podemos limitar la información que nos llevamos arriba así como mantener más limpio el entorno.

AAD App filter

Una vez terminada la configuración ya podríamos arrancar la sincronización, siendo ésta por defecto la de todos los usuarios, grupos y contactos del forest especificado. Si queremos restringir la sincronización por ejemplo por OU (Unidad Organizativa), debemos seguir el procedimiento tradicional de arrancar la “UI Avanzada” ejecutando el msiiclient.exe y editar los contenedores que nos queremos llevar de nuestro AD local.

Container filter

Para terminar, arrancamos la sincronización desde la misma consola o ejecutando de nuevo el asistente de AAD Sync, y ya tendremos nuestros usuarios en la nube.

FI/FS

Espero que os hayan parecido interesantes todas las novedades que nos esperan con nuestro querido DirSync.

¡Hasta la próxima!

Compatibilidad de CPU en Hyper-V

¿Quién no ha utilizado aunque sea de manera provisional esta herramienta de virtualización de Microsoft? Como sé que es algo que seguramente os hayáis encontrado en el día a día, creo que me voy a estrenar en este blog hablando un poco sobre el tema, más en concreto de algún problemilla que nos podemos tropezar. Una de las funcionalidades que nos encontramos en Hyper-V es la de exportar-importar máquinas virtuales. Esto nos va a permitir realizar una copia de nuestra máquina en otra ubicación con todas sus configuraciones y puntos de restauración, para así importarla en otra máquina, si queremos.

Hasta aquí todo perfecto, pero algo que no debemos olvidar y que quizá puede pasar desapercibido es: ¿qué pasa si la máquina donde queremos importar la virtual tiene características de procesador diferentes a la origen? En este caso deberemos haber activado la configuración de compatibilidad a nivel de procesador dentro de la configuración de máquina (opción que por cierto, por defecto está deshabilitada). Esta opción tendrá que estar activada antes de crear cada checkpoint, así como cuando exportemos la máquina si queremos evitar futuros problemas.

compatibility-procesor

Vamos a ver el por qué de todo esto, ya que hasta ahora sólo hemos visto el resultado de esta acción. Cuando arranca una máquina, en este caso, una máquina virtual, ésta revisa el set de instrucciones disponibles del procesador y las aplica. Por ello en una máquina arrancada no se podría migrar o importar a no ser que tenga el mismo set de instrucciones. La función de compatibilidad  lo que hace es ocultar el set de instrucciones del procesador y así poder emplearlo en equipos en el que sea diferente. Habilitando esta característica que está disponible a partir de Windows server 2008 R2, vamos a poder realizar live migration (procesadores del mismo fabricante). También podremos importar la máquina con sus checkpoint  siempre que la compatibilidad estuviera activada antes de realizarlo (no se puede cambiar un estado salvado y un  checkpoint es a fin de cuentas un saved state).

Y, sin mas dilación concluyo diciendo que al aplicar la compatibilidad, es posible que cause una disminución del rendimiento de nuestro equipo pero sólo si el set de instrucciones es empleado para alguna aplicación en concreto que tengamos, sino el funcionamiento será el normal.

¡Hasta la proxima entrega!