Tips & Tricks. Crear imagen actual de nuestro sistema Windows 8.

Al igual que anteriormente disponíamos de la opcion Restaurar Sistema. Ahora tenemos la posibilidad de crear una imagen WIM personalizada con nuestra instalación de Windows 8 y programas. La ventaja sobre la anterior tecnología es que nosotros decidimos el momento de crear la imagen, y no al realizar un Update como con la opción de Windows Restore. Otra ventaja es que en todo momento controlamos la ubicación de la imagen WIM, por lo que podemos usarla en caso de perdida total del sistema.
Para realizar la imagen de nuestro sistema, basta con iniciar una consola CMD con permisos de administrador local, y ejecutar: recimg.exe /createimage "directorio donde guardar".

La manera más sencilla y directa de comprobarlo es borrar una aplicación después de crear una imagen, y restaurarla desde las opciones de configuración, Uso General, Restaurar tu PC sin afectar los archivos.

Sin duda, una alternativa útil para recuperar un PC de un problema de una manera sencilla.

Si ejecutamos este comando una vez al més en pc´s instalados sin virtualización, podemos tener una Copia de Seguridad funcional del estado total del sistema.

Como siempre, espero que os guste, y gracias por leerme.

Auditando tu política de actualizaciones con terceras partes. Nessus Home

En este artículo vamos a hablar de la auditoría de las actualizaciones de productos administrados bajo WSUS con una herramienta, Nessus.

La idea es sencilla. Si administras una infraestructura en la que dispones de sistemas operativos Windows, y algún que otro servidor... tendrás instalado WSUS, el servicio de actualizaciones para los productos Microsoft, como puedan ser el propio sistema operativo, Office, Sql Server, Sharepoint etc etc.
Constantemente hablamos de la necesidad de controlar los sistemas en profundidad Como halábamos en otra entrada, debemos considerar implementar una política de escaneo de vulnerabilidades continua, que nos permita tener una visión global del estado de nuestros sistemas, en lo que a nivel de parcheo, configuraciones por defecto y obtención de información se refiere, que es lo que considero que aporta un test de vulnerabilidades.

Vamos a usar Nessus en versión home para auditar un equipo, en cuanto a nivel de parcheo se refiere. No vamos a escanear el equipo en cuestión, sino que vamos a consultar al servidor WSUS el estado del equipo.
Si realizamos una auditoría autorizada a un equipo, y le pasamos las credenciales válidas para conectarse, Nessus trata de obtener la versión de la librería implicada en la actualización que trata de comprobar. Esta acción es directa contra el equipo, y puede que no sea 100% efectiva.

El por qué realizar una auditoría de este tipo? Se me ocurren muchas razones. Imaginemos el caso de una empresa en la que la administración de los servidores la lleva a cabo una empresa contratada. Imaginemos el caso de que tienen un acuerdo de nivel de servicio. Imaginemos que fallan las actualizaciones en un segmento de equipos y que por este motivo se produce una infección y se acaba el mundo... Contar con unos informes en los que se almacene el estado de las actualizaciones puede sernos útil.
Una razón sería usar esta información en un proceso de post-explotación en un test de intrusión en el que tenemos acceso a una cuenta local, en un servidor corriendo WSUS, y en el que sin duda obtendremos mucha información útil del estado de los equipos sin tener que actuar directamente contra ellos.
Otra razón simplemente sería la de tener un indicador más de rendimiento del servicio.

Lo primero que debemos hacer es configurar una Política o Policies. Como el propósito de este test no es saber los puertos abiertos, vulnerabilidades, etc desmarco todas esta opciones. En preferencias seleccionamos Patch Management: WSUS Server Settings y configuramos los datos del servidor WSUS. En Plugins, los que muestro. Un consejo, desmarcar todos los plugins, y mediante un filtro, buscar por "contiene la palabra Wsus".

Podemos incorporar el Plugin Bulletins. Este Plugin identifica el KB concreto de la actualización con toda su descripción. Sería el que usaríamos en un test normal, contra el equipo directamente, y proporcionándole credenciales. No es el caso. La única diferencia entre activarlo o no sería que en el resultado del Report, si lo incluimos, nos aparecerá una vulnerabilidad por cada actualización que no se encuentre aprobada pero no instalada, mientras que si no usamos el Plugin Bulletins, en el Report nos aparecerá solo una "vulnerabilidad" del tipo Info. con el resumen de actualizaciones no instaladas.
Es decir, veríamos esto con Bulletins:

Y esto como resumen si no añadimos ese plugin.

Como podéis ver, muestra en el resumen para ese equipo 58 Parches no instalados. Lo mismo que me dice WSUS.

Si está acostumbrado a usar WSUS sabrás que su fuerte no es el Reporting. Puede que en determinadas ocasiones saber si un grupo de equipos tiene instalada una actualización concreta puede ser ardua tarea.

A eso le sumamos la facilidad de usar Nessus para almacenar el estado de actualizaciones para un determinado momento.

Lo que no he podido hacer es configurar una programación para este escaneo, paralela a la política de Microsoft de segundos martes del mes...

Sin duda me parece necesario el control de parches de nuestros sistemas, y de esta manera, podemos controlar si lo estamos haciendo bien o tenemos algún problema con el servicio.

Como siempre, gracias por leerme y espero que te guste el artículo.

Test de vulnerabilidades As a CONTINOUS Services. Nessus Home.

Este concepto no me lo he inventado yo ni mucho menos, pero es algo sobre lo que llevo pensando desde hace tiempo. He visto varios artículos dándole vueltas al asunto, por lo que imagino que ya será una realidad en muchas organizaciones.

Como todos sabemos en el mundo de la seguridad, el ciclo de vida de los incidentes es muy corto. Pueden pasar horas, minutos, desde que un tipo en Kazajastan crea un exploit para un zero Day en un producto popular, y lo tenemos en la puerta de nuestra empresa probando infectar o atacar la vulnerabilidad. Los días que pasan desde que se publica la vulnerabilidad, hasta que el fabricante desarrolla la corrección pueden marcar la diferencia en el éxito o no de los ataques.

Desde el punto de vista clásico de un director TI, el contar con un informe de una empresa que le realiza un test de vulnerabilidades dos veces al año, sería una buena gestión. Pero entonces, confiamos en que nuestros sistemas están correctamente parcheados/configurados durante los 6 meses de diferencia entre auditoría y auditoría?.
 En el mundo de la calle, en el que los empleados apuntan claves en Post-it, en los que aún hay empresas que no se adaptan a una simple LOPD por no tener ni una infraestructura de directorio, en ese mundo no hay auditorías de seguridad.

Como siempre reivindico en Inseguros, existe el término medio. No todos podemos administrar sistemas/seguridad en MegaCorp. S.L. con recursos para hardware/software. Ni tampoco tenemos que ser participes con nuestra falta de profesionalidad de administrar una empresa con la clave "1234".

Vamos a intentar proporcionar a nuestra organización, o por qué no, red de ordenadores domésticos ( por eso de las licencias) de una aproximación a lo que entiendo como un servicio continuo de Test de Vulnerabilidades.

La idea es muy sencilla. Definimos una plantilla con la configuración de una auditoría para nuestros sistemas. Programamos la realización de este test en un horario que no deteriore mucho el rendimiento de los sistemas.
Monitorizamos el resultado de los informes y monitorizamos los informes de resultados obtenidos entre auditorías realizadas entre fechas.

La palabra continuo aquí tiene sentido cuando hablamos del problema de tener informes de resultados cada 6 meses, pero no tiene sentido si lo comparamos por ejemplo con la continuidad que ofrece lo que hace un IDP en tiempo real. Programar una auditoría "ligera" diariamente y otra un poco más completa mensualmente lo considero aceptable para una PYME que le preocupe la seguridad, pero que no tiene los medios para adquirir un producto específico.

Para realizar este laboratorio necesitamos tener instalado Nessus 5.2 o superior, que en la versión Home posibilita la programación de test y la notificación por correo. Si queréis revisar los artículos sobre Nessus en Inseguros podéis pinchar aquí, aquí y aquí.

Lo primero que vamos a hacer es en Configuration, introducir los datos de nuestro servidor SMTP que realizará el envío.

Para crear una plantilla de Test nos vamos a Scan Templates y creamos una nueva del tipo programada. Introducimos la política de Test que queremos realizar. Debemos configurar una seria de Plugins acorde con el sistema que vamos a auditar, y tenemos que tener en cuenta la perdida de rendimiento en el equipo a auditar. Yo para esta demo ya tengo mi Policie llamada "kino" :-) .
Configuramos la periodicidad del Test.
 Introducimos la lista de equipos que queremos auditar y configuramos una cuenta de correo de destino. En los filtros podemos indicar que resultados mostrar en el informe que enviaremos al correo. Considero oportuno filtrar algún tipo de información, por ejemplo, si estás de vacaciones y te llega el Report del Test no creo que te sea de utilidad saber que ha detectado " Windows Devices" o que hay un puerto 80 activo. En este informe no vamos a ver las diferencias entre el último Test, pero a mi me gusta ver estos informes en el correo en mi tiempo libre, por si detecto alguna anomalía. Para esta prueba he configurado que envíe los resultados en caso de encontrar algún resultado denominado Critical y por filtrar algún detalle más, que me muestre los que tienen algún tipo de exploit disponible.

Con esto lanzamos la programación para nuestro Test diario a las 21:30.
Este es un ejemplo de un Report enviado al correo.

Una vez tenemos generados suficientes informes como para poder comparar,  solo tenemos que seleccionar los informes en el panel de resultados y pinchar en Options. Diff Result.

El informe de resultados que nos presenta no se almacena, es labor del responsable el realizar la comparación y detectar variaciones no deseadas en los resultados.

Como podéis ver, podemos tener un sistemas más o menos continuo para realizar test de vulnerabilidades programados, dentro de las posibilidades de una herramienta como Nessus.
Profesionalmente hay sistemas que se encargan de esto, del fabricante de Nessus, pero para controlar un poco más este aspecto, nos puede servir este procedimiento.

Como siempre, espero que os guste el artículo, y gracias por leerme !!!.



Google +

VDI & Hiper -V en Windows Server 2012 R2. Parte II

Segunda parte del artículo sobre VDI & Hiper V en Windows Server 2012 R2.

Vamos a entrar en el complemento de Escritorio Remoto de nuestro servidor y vamos a editar las propiedades de la implementación, ya que en el anterior paso solo instalamos los servicios necesarios. El hacerlo en dos partes es para entender mejor los pasos del proceso.

Lo primero que nos propone a configurar es la puerta de enlace del escritorio remoto. Un componente necesario para proporcionar las funciones de Proxy para nuestros usuarios fuera de la red empresarial, como pueda ser su casa o un cliente externo. Para este primer despliegue vamos a obviar esta configuración, publicando solo a nuestros usuarios internos los servicios de escritorio remoto.
Lo que vamos a hacer es configurar las opciones de Active Directory para unir automaticamente los escritorios al dominio, y bajo una Unidad Organizativa previamente creada, por ejemplo, desde usuarios y equipos de Active Directory. Por ejemplo vamos a crear una UO para los usuarios del departamento comercial. Como comentaba en otro post, no se debe instalar los servicios de Escritorio Remoto en un controlador de dominio, por lo que me voy a un DC y creo la UO.

También creo un usuario para probarlo todo después. Indicamos en el editor de implementación la Unidad Organizativa.

En la parte de Colecciones, creamos una colección de escritorios virtuales.

-----------------------------------------------------------------------------------------------------
Hay dato curioso y es que las operaciones de aprovisionamiento de escritorios, Windows Server 2012 por defecto las hace de manera serializada, es decir, de una en una . Si calculamos un tiempo medio entre 5-15 minutos por máquina, deberíamos poder cambiar este comportamiento y establecer estas operaciones en paralelo. No se recomiendan valores por encima de 5. Pues aquí tenéis la clave del registro para cambiar este comportamiento.

---------------------------------------------------------------------------------------------------------

Ahora configuramos el modelo de implementación entre escritorios virtuales personales o agrupados. En nuestro caso vamos a trabajar con el modelo agrupado como decíamos en el primer artículo, ya que vamos a publicar un escritorio común para todo los usuarios de un departamento.

Nos detecta el único escritorio virtual existente en nuestro laboratorio de Hiper-V, la instalación que hicimos de Windows 8.

Ahora elegimos la ubicación donde guardaremos la VM del escritorio virtualizado. Lo conectamos a la unidad SAN, carpeta de red (algo nuevo en 2012) o disco duro tradicional :-)

Ahora toca configurar la opción de User Profile Disk. Es un disco duro, virtual, que almacenará la configuración específica de cada usuario. Como comentaba, estamos configurando un Managed Pooled, pero aún así, si el usuario no va a modificar aplicaciones instaladas, si puede tener acceso a su carpeta Mis documentos personal, configuración de cliente de correo y demás. Como podéis ver, debe ser una carpeta compartida. Tenemos que tener en cuenta que si publicamos varias Collections, por la necesidad de tener varios tipos de configuraciones de escritorios, los User Profile Disk no serán accesibles entre colecciones. Para implementar una solución de este tipo, en la que queremos total disponibilidad de la configuración de usuario, debemos optar por User Experiencie Virtualization. Posiblemente lo trabajemos en próximos artículos.

Podemos especificar qué contenido queremos que se guarde en el User Profile Disk, pero debemos hacerlo editando las propiedades de la colección una vez creada.

Con esto y un poco de paciencia en la creación de las máquinas, ya tenemos creada la granja de escritorios.

Si por alguna razón decides hacerlo por PowerShell.

Set-RDSessionCollectionConfiguration -CollectionName QuickSessionCollection -EnableUserProfileDisk -MaxUserProfileDiskSizeGB 20 -DiskPath \\ProfileSvr\UserProfileDisks 

Ahora solo tenemos que entrar por un navegador a la url del servidor RDS\rdweb y conectaros al escritorio.

Hay que tener en cuenta varias cosas a estudiar en esta implementación, de cara a los clientes.

Si trabajas con clientes ligeros basados en Windows no vas a tener problemas, pero debes comprobar que en el caso de disponer de una infraestructura previa de Think Clients, es compatible con este tecnología. Los equipos Wyse que comercializa DELL no están del todo mal.

Quiero decir que como comentaba el Sr. Pulgar en una red social, todo esta tecnología está muy bien, pero hay que ir con cuidado, estudiando muy en detalle los costes en materia de dinero y esfuerzo, y sobre todo su posterior mantenimiento. No soy vendedor de Microsoft, ni tengo una empresa que se dedique a esto, simplemente os pongo lo poco que sé a vuestra disposición.

Gracias Jose María por contribuir con tus opiniones.

Como siempre, espero que os guste y gracias por leerme.

Google +

VDI & Hiper -V en Windows Server 2012 R2.

VDI son las siglas de Virtual Desktop Infraestructure. Un entorno de escritorios virtuales para nuestros usuarios, es decir, sobre máquinas virtuales.
Todos los días podemos apreciar el crecimiento del entorno Cloud, nube, virtualización y demás. Microsoft ha hecho una apuesta fuerte por el "uso" del Cloud en Windows Server 2012 y en el resto de servicios que ofrece como pueda ser Intunes  Windows Azure o Hiper V.
Ya hablamos en este blog sobre la virtualización de aplicaciones pero la virtualización de escritorio da un paso más allá ofreciendo al usuario toda la experiencia de su escritorio, en cualquier dispositivo que use, dentro de la organización, o desde fuera de la misma. Independientemente del hardware empleado, tendremos nuestra máquina accesible. Una solución para el nuevo reto para los administradores de sistemas con el BYOD ( Bring Your Own Devices).Hay más tecnologías a implementar en Windows Server 2012 R2 como son la virtualización de la experiencia de usuario. Hoy crearemos algunas máquinas virtuales para usar escritorios.

Con esta seria de documentos voy a intentar explicar desde cero el uso de Virtualización de máquinas y despliegue de escritorios virtuales. Se supone que la infraestructura base de servicios de red, Active Directory y demás ya la tenemos montada. Os recomiendo que si no estáis familiarizados con estas tecnologías encaminadas al Cloud sigáis la serie.

Lo primero que tengo que hacer en mi caso es instalar Hiper-V en un servidor Windows 2012 R2 que corre sobre VMWare Esxi 5.1, es decir, instalar un Hipervisor dentro de otro, Virtualización anidada.
Lo que he hecho es instalar un Server normal, como cualquier otra máquina virtual, y he modificado el fichero de configuración VMX de la VM para escribir esto:

guestOS = "winhyperv"

y añadir esta línea al final.

featMask.vm.hv.capable = "Min:1"





Ahora ya puedo instalar el Role de Hiper V en la máquina virtual Windows Server 2012 R2.
Lo que vamos a hacer es crear una máquina virtual Windows 8.1 (versión Preview) para que sirva de base en nuestra implementación de escritorios virtuales.

Una vez instalado el Role de Hiper-V entramos en el complemento de administración. Podemos hacerlo como siempre de dos maneras. En el panel central, botón derecho o en Herramientas, como en todos los complementos en Windows Server 2012 R2.

Nos ubicamos en la raíz del servidor de Hiper-V a la izquierda y botón derecho, nueva máquina virtual.

No olvidemos indicar la ruta creada previamente para almacenar la configuración de máquina virtual.

El siguiente paso es seleccionar que tipo de máquina virtual vamos a crear, Generación 1 o Generación 2.

Esta es una de las mejoras que trae consigo Hiper V en Windows Server 2012. Es importante saber que si el sistema operativo que vamos a instalar en la máquina virtual es inferior a Windows 8/2012 no podemos configurarlo como Generación 2. El motivo es el arranque UEFI. Una de las ventajas que trae sin embargo es la posibilidad de utilizar PXE en el adaptador virtual, es decir, podemos usar la configuración inicial del adaptador de red para realizar un despliegue mediante los servicios de Windows Deployment Services. A nivel de Performance se estima un ahorro en el arranque de un 20% aunque el rendimiento una vez arrancado es el mismo que con un adaptador virtual IDE.

Seguimos con los pasos para terminar la creación de nuestra máquina virtual Windows 8.1 Preview que servirá de maestra para el despliegue de nuestra infraestructura.

En este punto indicamos el fichero de instalación ISO de Windows 8.1 que montará en un cd virtual para instalar el sistema operativo en la máquina virtual.

Ya tenemos instalado un sistema operativo Windows 8.1 en la máquina virtual.
Ahora vamos a realizar un SYSPREP para "difumir" los datos propios de esta instalación como son los Identificadores, licencias, datos de usuario etc. No vamos a unir la máquina al dominio aún ya que Sysprep trabajar sin esa configuración.

Usamos las opciones que podéis ver en la imagen.
Ahora es el turno de instalar el Role de Servicios de Escritorio remoto.

Vamos a realizar una instalación estándar con todas las opciones disponibles para configuración, en vez de usar la instalación rápida. En Inseguros nos gusta trastear las cosas, como vimos en el artículo de virtualización de aplicaciones.

Hasta este punto ya tenemos bastante avanzado el laboratorio para nuestras pruebas.

A la hora de implementar una solución de tipo VDI debemos analizar los requisitos de nuestra organización y los costes asociados a cada tipo de despliegue. Imagino que en todos los departamentos TIC de todo el mundo existe la necesidad de reducir costes operacionales. En un ambiente de trabajo de 50 usuarios/escritorios, sería ideal tener un servidor potente, con almacenamiento ilimitado, y crear una máquina virtual para cada usuario. Quizás en ese mismo ambiente, separados por departamentos, existan una, dos, tres máquinas tipo, con un conjunto de aplicaciones instaladas. La idea de compartir una granja de máquinas virtuales preconfiguradas, en las que no importa en cual trabaja el usuario, ya que los datos del usuario estarán almacenados en un disco virtual específico, y una vez cerrada la sesión contra su máquina virtual, esta no almacena los cambios. Sin duda, ahorraríamos en almacenamiento, ya que una máquina virtual completa con sistema operativo puede rondar los 30 GB, y para 50 usuarios... mientras que una máquina de 30 gb, con 50 discos duros de usuario de 1 GB nos facilitaría un ahorro más que considerable.
Estos dos escenarios se denominan Pooled VM & Personal VM.

Os dejo pendientes de la segunda entrega de VDI & Hiper -V en Windows Server 2012 R2.

Como siempre, gracias por leerme y espero que os guste.


Google +