¿Qué se debe tener en cuenta para virtualizar una PyME?

octubre 2, 2013 § 1 comentario

Por Damián Kalnins, Virtualization Presales Specialist de Softline

La virtualización es unde las soluciones a los problemas de continuidad más utilizadas en el mercado en los últimos años. Algunas de las preguntas que puede hacerse una PyME en el momento de migrar la infraestructura física hacia un entorno virtual son: ¿qué virtualizar?, ¿cuáles son los beneficios?, ¿hacia dónde vamos?. Se debe tener en cuenta que virtualizar es sinónimo de inversión, si se analiza como un gasto, estamos distantes de dar ese primer paso.

Cuando las Pymes deciden implementar tecnologías de vanguardia -como la virtualización- amplían su potencial comercial sin necesidad de una gran inversión en recursos. El uso de herramientas avanzadas de gestión permite transformar los procesos de negocio, aumentar la satisfacción del cliente, mitigar los riesgos y proteger la información de la empresa.

Cuando la cultura de la compañía es netamente física existe miedo al cambio. En estos casos, la desinformación es una de las principales barreras a superar. Por eso es clave que quienes estén involucrados en el proceso de migración analicen la situación actual del entorno físico y los beneficios que se lograrán con la virtualización, algunos de los cuales son:

  • Desarrollo de una nueva metodología de trabajo.
  • Mayores oportunidades de crecimiento comercial.
  • Garantía de continuidad del negocio.
  • Aumento de la competitividad de la Pyme, a partir de la optimización de los recursos.
  • Reducción de costos.

Asimismo, se obtendrá una mejor performance de la infraestructura de operaciones, la administración centralizada del centro de datos y la reducción de cantidad de servidores físicos, lo cual implica una disminución del espacio requerido para el datacenter, de los costos internos de administración y de los costos de soporte abonados a los proveedores de dichos equipos.

Si bien los primeros pasos requieren tiempo, compromiso y capacitación, la inversión que implica la virtualización nunca será mayor al beneficio de adoptar esta tecnología. Además, una infraestructura que no garantiza un alto nivel de servicio impacta negativamente en el negocio al generar pérdidas, insatisfacción de los usuarios y al obligar a los profesionales de sistemas a atender problemas en forma reactiva. Este impacto se genera a partir de paradas programadas de mantenimiento o caídas imprevistas, cuyo tiempo de recuperación podría mejorar significativamente mediante cambios de infraestructura.

Existen varios puntos relevantes que se recomiendan tener en cuenta a lo largo de este gran cambio:

1°) Considerar que una infraestructura adecuada debería garantizar: la reducción de cantidad de servidores físicos, la administración centralizada deldatacenter, la disminución de costos en la creación de ambientes de prueba y la provisión del espacio necesario para sumar más máquinas virtuales.
2°) Tener presente que, para virtualizar un ambiente por primera vez, es vital comparar entre servidores (Rackeables o Blades, dos estándares en el mercado) y Storage (iSCSI o SAS).
3°) En relación al licenciamiento, existen diversas opciones en el mercado que se ajustan a las necesidades de cada organización: la solución a elegir debe contrastarse con la criticidad del ambiente a virtualizar. Dependiendo de las aplicaciones, se requerirán capacidades como: movimiento de máquinas virtuales en caliente, alta disponibilidad, backup, entre otras. En este punto, también hay que considerar el precio y el tipo de soporte adecuado para cada plataforma.
4°) Luego de la elección del hardware y del producto a implementar, el siguiente nivel es la contratación de servicios de implementación de la solución. Los proveedores del mismo deben ser analizados con cuidado, ya que, una vez realizada la elección, son ellos quienes acompañarán a la empresa hasta el día en que la nueva plataforma virtual se encuentre operativa. Esta última fase posee diferentes etapas:

  • Planificación: El primer paso es una correcta planificación, lo que permitirá conocer el alcance, la metodología de trabajo y el calendario sobre los que se basará el proyecto.
  • Diseño: Se procede a definir la infraestructura virtual, relevar el equipamiento disponible, el cumplimiento de los requerimientos mínimos y el plan de pruebas que se llevarán a cabo una vez finalizada la implementación. El diseño es la plantilla que respalda los lineamientos del proyecto de virtualización.
  • Implementación: Definir la infraestructura virtual, relevar el equipamiento disponible, el cumplimiento de los requerimientos mínimos y el plan de pruebas que se llevarán a cabo una vez finalizada esta etapa. El diseño es la plantilla que respalda los lineamientos del proyecto de virtualización. La ejecución del proyecto culmina en la puesta en marcha de la plataforma de virtualización adoptada. Es un requerimiento prioritario que el equipo de TI se integre al proceso de implementación ya que es un error común que los técnicos pierdan presencia en las pruebas sobre el entorno virtual y se encuentren con un mundo desconocido cuando comienzan a administrarlo.

Fuente: CIOAL

Empleando técnicas Rookit para ocultar VirtualBox

septiembre 20, 2013 § Deja un comentario

‘Hand of the Thief’ es un troyano “comercial” que se ha estado moviendo por foros rusos. Este troyano está dirigido a sistemas Linux y su función principal es el robo de credenciales bancarias, aunque no se limita a este tipo de webs. Dicha función permite al troyano captar las credenciales a través de form grabbing. Curiosamente, a pesar de ser un troyano orientado a sistemas Linux, posee un sistema de manipulación de registros DNS en memoria. Es decir, el troyano no toca los archivos para modificar la resolución de nombres local.

El troyano ha sido probado con éxito en diversas distribuciones: Fedora, Arch Linux, Gentoo, Debian entre otras.

Una de las técnicas tradicionales para evitar su análisis por parte de las compañías antivirus es la detección de máquinas virtuales, esto es, cuando el troyano se está ejecutando en un entorno virtualizado su comportamiento pasa a ser inocuo o directamente finaliza su ejecución de manera prematura. ‘Hand of the Thief’ detecta máquinas virtuales VirtualBox, VMware, Power VM, IBM/S390, QEMU y Xen.

No vamos a describir aquí el comportamiento de este troyano, ya que esto daría para otro post y además existe un excelente análisis aquí. Lo que vamos a ver son técnicas concretas que podemos usar para esconder el entorno de virtualización, en concreto VirtualBox. Primero introduciremos los términos que vamos a usar y posteriormente veremos como el troyano intenta detectar la virtualización y como podemos evadir dicha funcionalidad.

Definiciones

Las técnicas rootkit permiten ocultar la presencia de un malware, explotar vulnerabilidades y escalar privilegios en un sistema (cuanto más altos, mayor control sobre el sistema). Un rootkit puede cargarse tanto en espacio de usuario como en el espacio del kernel (donde siempre tendrá más control).

Una llamada al sistema o system call, es una función que se efectúa en el espacio de usuario para transferir momentaneamente el control al kernel a través de una interrupción. Podemos ver una lista de las llamadas al sistema realizadas por un proceso a través del programa strace. El funcionamiento de una llamada al sistema es sencillo: Un proceso en espacio de usuario necesita ejecutar una llamada al sistema, mete en la pila su índice, parámetros y ejecuta una interrupción a través del código ensamblador INT 0x80. En ese momento el kernel recoge dicha petición, busca en el índice la función correspondiente, la ejecuta con los parámetros provistos por el usuario y retorna el resultado y el control de ejecución al proceso del usuario.

Un driver es un módulo del kernel. Un programa inyectado en el espacio del kernel teniendo acceso tanto a dicho espacio como al espacio del usuario. Dispone de una variedad de instrucciones más amplia que un proceso de usuario debido a los privilegios que dispone. Un módulo se carga en el kernel con el comando insmod o modprobe y se desinstala con rmmod.

Evitando la detección

Para detectar la máquina virtual VirtualBox, el troyano prueba la presencia de la cadena “VBOX” dentro del archivo “/proc/scsi/scsi” que lista los discos SCSI usados (disco duro, disco de DVD, etc.). Si lo encuentra, el troyano termina su ejecución. Como dijo P. Kalni, podemos evitar esta prueba quitando el modo lectura de este archivo para que el troyano no pueda leerlo. Sin embargo, este método es limitado y no puede generalizarse a otro troyano ya que éste podría probar si el archivo esta en modo lectura. Nuestra solución implica el uso de un rootkit para modificar el contenido del archivo leído. Es decir, que cuando el troyano lea el archivo, el rootkit va a buscar la cadena VBOX y la reemplazará por otra cadena. De esta manera, modificamos el contenido leído al vuelo y no el archivo. En este ejemplo, modificamos la cadena VBOX por “____”.

Cuando un programa lee un archivo, llama a la system call “read” de la biblioteca libc que ejecuta la función del kernel “sys_read” a través de la interrupción 0x80. En otras palabras, para modificar el contenido al vuelo de un archivo leído se necesita hookear la función del espacio de usuario “read” o del espacio del kernel “sys_read”. Hemos elegido hookear la función del kernel porque el programa podría escapar del hook de la función “read” llamando a la función “sys_read” directamente. Además, hookear la función “read” supone que el malware use la biblioteca libc para leer un archivo.

Hookear la función “sys_read” significa cambiar el modo lectura de la tabla de llamadas al sistema para poder escribir y cambiar el index en dicha tabla de la función “sys_read” para redireccionarla a nuestra función “new_sys_read”. Hemos creado un driver para hookear la función “sys_read” y crear la nueva función “sys_new_read”. Cuando la función “new_sys_read” sea llamada, ella va a (1) llamar a la función original “sys_read” para recoger una parte del archivo o la totalidad del archivo en un búfer, (2) reemplazará cada cadena VBOX por “____” del búfer y (4) devolverá el búfer modificado.

Sin embargo, necesitamos conocer la dirección de la función “sys_read” para llamarla desde “new_sys_read”, conocer la dirección de la tabla de llamadas al sistema para modificar la entrada “sys_read”, y también la dirección de la función “lookup_address” que nos permite obtener la página correspondiente a la tabla de llamadas al sistema para cambiarla del modo lectura y escritura. Estas direcciones variarán de un sistema a otro. Se pueden encontrar en el archivo /boot/System.map.

Esto es solo una de las múltiples técnicas que podemos emplear para evadir este tipo de detecciones. Por supuesto, ni es la única técnica que emplean los troyanos para evadir la ejecución sobre una plataforma virtualizada, ni es la única contramedida de las que disponemos.

Fuente: Hispasec

Spoon: ejecutar aplicaciones en Sandbox Online

abril 8, 2013 § Deja un comentario

El proyecto Spoon.net Browser Sandbox permite ejecutar cualquier navegador en una Sandbox y realizar pruebas de compatibilidad con versiones anteriores de los mismos… así como abrir páginas web que podrían ser peligrosas.

Los navegadores se ejecutan dentro de un entorno virtual aislado, lo que elimina la necesidad de instalaciones. Los navegadores virtualizados se comportan exactamente igual que los navegadores instalados y, debido a que se ejecutan localmente, se puede probar aplicaciones web alojadas en servidores internos. Simplemente basta con abrir el navegador de Spoon y escribir la dirección en la barra de navegación de prueba.

Spoon es compatible con componentes estándar como Applets de Java, controles ActiveX, y Flash, así como con plugins populares como Firebug, Developer Toolbar IE y consolas de depuración de CSS y JavaScript.

Adicionalmente Spoon permite ejecutar una lista muy grande de aplicaciones de escritorio virtualizadas y se puede instalar en modo servidor.

Cristian de la Redacción de Segu-Info

Virtual hacking, para jugar a ser hacker

febrero 8, 2013 § Deja un comentario

En Sourceforge se ha publicado una serie de máquinas virtuales de aplicaciones deliberadamente inseguras y con vulnerabilidades conocidas.
Estas máquinas se deben utilizar para entrenamiento, realizar pruebas de concepto de seguridad y con propósitos de aprendizaje.

Las imágenes ISO y máquinas virtuales pueden descargarse desde Virtual Hacking y como adicional también se puede descargar una serie de papers sobre Web Application Security

Cristian de la Redacción de Segu-Info

Ocultando entornos virtuales a malware y atacantes

diciembre 7, 2012 § Deja un comentario

Si recordáis hace tiempo repasamos una serie de técnicas para que nuestro malware de cada día pudiera detectar que está “dentro” de una máquina virtual o en un sandbox y así ejecutar inmediatamente un rutina de escape para dejar con un palmo de narices a los analistas (o al menos a los analistas más noveles).

Ahora vamos a cambiarnos de chaqueta y vamos a ponernos en la piel de quién tiene que realizar el análisis del software malicioso. Si antes la pieza de malware intentaba detectar el entorno dónde estaba para engañarle y no seguir ejecutando sus malignas acciones, ahora es el propio entorno el que intentará engañar al malware y hacerle creer que está campando a sus anchas en el sistema operativo de su víctima inocente.

Para ello nos viene al pelo un breve post de Hexacorn en el que se describen algunas maneras de ocultar que el sistema es realmente una máquina virtual (principalmente VMWare). Por supuesto no son las únicas medidas que se pueden tomar, pero es un excelente comienzo para ocultar ficheros, procesos, servicios y claves de registro de cara a evadir los controles anti-VM de algunos tipos de malware.

Contenido completo en fuente original HackPlayers

Código fuente de VMware ESX publicado en Internet

noviembre 6, 2012 § Deja un comentario

El código fuente que data de 2004, fue publicado ayer por una persona con el alias “Stun” en Twitter y con un enlace a su descarga directa. El responsable de seguridad de VMWare Ian Mulholland dijo que “es posible que existan más archivos y que puedan ser publicados en el futuro y por eso estámos investigando a fondo”.

Si bien el código de VMKernel fue escrito entre 1998 y 2004, los componentes principales de muchos programas no cambian demasiado sino que se amplían o adaptan por lo que gran parte de las funcionalidades originales podrían mantenerse en el código publicado.

El origen de la fuga se cree que se ubica en abril pasado cuando otro atacante con el nombre de “Hardcore Charlie”, que también publicó correos electrónicos internos de VMware y afirmó haber comprometido un sistema perteneciente a China Electronics Import-Export Corporation (CEIEC). A la vez, VMware, dijo que “la fuga no necesariamente representan un riesgo para los clientes, y que incluso comparte su código fuente y las interfaces con otros socios de la industria para permitir un ecosistema de virtualización más amplio”.

Como parte de las mejores prácticas en materia de seguridad, VMware recomienda encarecidamente a todos sus clientes aplicar las actualizaciones más recientes de sus productos así como los parches de seguridad disponibles para cada entorno específico. Asimismo, recomendamos a los clientes revisar su guías de seguridad y fortalecimiento de la plataforma.

Cristian de la Redacción de Segu-Info

Evitar y detectar máquinas virtuales

noviembre 1, 2012 § Deja un comentario

Desde hace bastante tiempo venimos escuchando y leyendo nuevos avances en cuanto a Malware se refiere. Uno de estos grandes avances, es a su vez una pesadilla para cualquier analista. Y es ver cómo un Malware que se intenta analizar en un entorno virtualizado, no realiza ningún tipo de acción.

A día de hoy ya es una realidad que muchas variantes de malware realicen comprobaciones para conocer en dónde se están ejecutando y en función del entorno o arquitectura, realizar un tipo de acción o no.

Personalmente, mis conocimientos de detección de entornos virtualizados bajo la platorma Windows se circunscriben a comprobar por ejemplo los drivers nativos de los fabricantes y algunas claves de registro. Tengo en casa una cantidad ingente de información esperando a ser devorada y lo más importante, comprendida.

Bajo esta premisa, me he encontrado con el proyecto pafish de Alberto Ortega que personalmente me ha parecido brillante. Se trata de una herramienta muy sencilla que intenta detectar varias características y entornos virtualizados en base a una serie de peticiones. Estos entornos van desde una SandBox a entornos virtualizados, y a nivel de características si se encuentra algún módulo de depuración (Debugging) activo.

Al ser Open Source, se puede ver todas las comprobaciones que la herramienta realiza. Sin duda algo muy práctico para el que quiera conocer con más detalle este tipo de labores, realizadas mayoritariamente por aplicaciones maliciosas.

Como soy un pirata, intenté hacer “sufrir” un poco a la herramienta de Alberto, probándola con algún tipo de aplicación que ocultase el entorno de virtualización. Por regla general, este tipo de aplicaciones enmascaran las peticiones que se realizan desde la capa de usuario, devolviendo en muchos casos respuestas erróneas o falseadas.

Una de estas aplicaciones se llama VMDetectguard. Esta aplicación entre otras funciones, intenta hacer creer a un Malware que se está ejecutando en otro entorno, mediante enmascaramiento de peticiones.

Fuente: Security by Default

¿Dónde estoy?

Actualmente estás explorando la categoría virtualización en Seguridad Informática.