Muchos de nosotros estamos trabajando ahora con firewalls virtuales. Hice un post anterior con respecto a las fortalezas y debilidades de la seguridad en el mundo virtual , pero hoy quiero hablar acerca de las posibilidades de cortafuegos con VMware. Ha habido un montón de entusiasmo con respecto a relativamente nuevo de VMware VMsafe API . En concreto, todo el mundo está luchando para crear / instalar cortafuegos rápido camino. Pero son todas las implementaciones de ruta rápidos creados iguales? ¿Existen problemas de seguridad con ir con una solución de vía rápida? Vamos a bucear y ver.
Desglose de VMsafe
Con el lanzamiento de la API VMsafe de seguridad, VMware ha mejorado las opciones disponibles para la implementación de seguridad dentro de un entorno vSphere al permitir que los vendedores se integren directamente en el hipervisor en el anillo 0. VMsafe consta de tres componentes:
- VDDK - Inspección de bloque de disco. API ha sido públicamente puesto en libertad.
- vCompute - API de la CPU y la memoria. No ha sido revelado. Desconocidos que terceros tengan acceso, en su caso.
- vNetwork - API para controlar / filtrar entre el vNIC y vSwitch. No ha sido revelado. A lo mejor de mi conocimiento, sólo Altor Networks y sistemas reflejos tienen acceso (dos vendedores que colaboraron en el desarrollo de la API).
En concreto, quiero hablar con el API de vNetwork. Cuando se controla el flujo del tráfico de red dentro de un host ESX, hay dos posible aplicación, "vía lenta" y "vía rápida".
Lento camino
Vía lenta es la implementación más sencilla y la que hemos estado utilizando por años. En efecto, esto es sólo un invitado de VM, de forma similar a cualquier equipo virtual invitado otra parte, se ejecuta en el servidor ESX. Típicamente cada invitado está conectado a un vSwitch único, y cada uno de estos conmutadores virtuales está conectada a un vNIC único en el firewall. Esto es similar a una configuración de cortafuegos legado, pero implementado de forma virtual. El beneficio de la ejecución en la vía lenta es que se puede ejecutar un sistema operativo completo con cualquier golpe bibliotecas o servicios necesarios para apoyar el firewall.
Fast Path
Trayectoria rápida es efectivamente un conductor de 0 anillo que se conecta directamente en el núcleo del hipervisor. Esto permite que un proveedor de terceros para aprovechar el hipervisor para la inserción entre cada conexión vNIC / vSwitch. Debido a que un controlador de ruta de acceso rápido se está ejecutando en el contexto del kernel, que añade una sobrecarga mínima para el sistema. El resultado es la ejecución de código dentro de vía rápida es considerablemente más rápido que el mismo código que se ejecuta dentro de vía lenta (por lo tanto la convención de nomenclatura de VMware para cada contexto). Carga en el servidor ESX se reduce al mínimo, por lo que el resultado final es que se puede ejecutar huéspedes mucho más virtuales.
Rápida frente a lenta
Por lo tanto, suena como si quisiera hacer todo lo posible vía rápida, pero hay una serie de cuestiones. Ruta de acceso rápido es un controlador del núcleo no se conecta en un mínimo hipervisor, un sistema operativo completo de golpe. Esto limita las bibliotecas y los servicios del servidor de seguridad tiene a su disposición para controlar el flujo de tráfico. Además, estamos conectando un controlador del núcleo por lo que debe ser la seguridad de que no hinchan el hipervisor, aumentar la superficie de ataque o interferir con otras funciones de hipervisor. VMware lleva a cabo una revisión de código en todos los controladores de ruta de acceso rápido antes de su excarcelación. Así que si teóricamente podría poner en práctica todo mi código en la vía rápida, que iba a necesitar la aprobación de VMware antes de cada parche o función de liberación.
Con esto en mente, un vendedor de reclamar "vía rápida", el apoyo es en realidad va a terminar la aplicación de una parte de su código como vía rápida, una parte como un camino lento, y luego crear un nexo de unión entre los dos. ¿Cuánta carga se coloca en el sistema dependerá de la cantidad de este código se implementa en el camino rápido y cuánto de ello se ejecuta en la vía lenta.
Posibles implementaciones de Fast Path
Por ejemplo, un vendedor puede optar por escribir un controlador de vía rápida que simplemente túneles de todos los paquetes de vuelta a un camino lento cortafuegos. El código de vía lenta a continuación, determina si el tráfico se debe pasar o se ha caído, con los paquetes pasaron de ser enviadas de vuelta al código de vía rápida para su inserción en el canal de control del hipervisor. Si bien este sería el método más fácil de implementar vía rápida, y sin duda la más segura, que proporcionaría los beneficios mínimos de rendimiento. La carga del sistema, probablemente no sería mucho mejor que una aplicación plena vía lenta. Yo veo esta opción como muy atractiva para los vendedores de firewall existentes, ya que requeriría la menor cantidad de modificaciones a su código existente sin dejar de ser capaz de reclamar "apoyo vía rápida".
Otra opción sería utilizar el espacio de vía lenta para las funciones administrativas con el controlador de ruta de acción rápida como el motor de firewall. Así, por ejemplo, el administrador del servidor de seguridad podría crear la política de uso de una interfaz que se ejecuta en una máquina virtual vía lenta, que a su vez impulsará la política de baja a un controlador de vía rápida. En esta configuración del controlador de vía rápida tiene una copia de la póliza para el control del tráfico puede ser implementado de inmediato. El resultado es más rápido el tráfico de manipulación con la carga mínima del sistema. El descuento comercial es más voluminoso código en el anillo 0.
También es posible implementar una mezcla de los dos. Por ejemplo, yo podría utilizar el controlador de ruta rápida para poner en práctica la política de firewall, pero a continuación, pasar todos los paquetes de "aceptados" de vuelta al sistema vía lenta para la intrusión de control, detección de virus, o lo que sea necesario. Paquetes aceptables se pasa de nuevo al controlador de vía rápida para la inserción. Así que en esta configuración todos los "cayó" paquetes se manejan a través de vía rápida, mientras que los paquetes aceptados interactuar con un componente de trazado lento.
Como nota al margen, es necesario mantener la información anterior en mente cuando se consideran todas las implementaciones vNetwork, no sólo a servidores de seguridad. La API vNetwork también se puede utilizar para la aplicación de la política, calidad de servicio, la recolección de estadísticas de red, etc Por ejemplo, la puesta en práctica vNetwork primera fue en realidad Manager de VMware Lab. Esta herramienta se utiliza para el aprovisionamiento de autoservicio y no contiene un componente de servidor de seguridad (esto se realiza a través vShield).
Resumen
Mientras que un producto que se integra con VMware VMsafe estricta puede ser una "vía lenta" puesta en práctica, es muy poco probable que cualquier producto puede ser considerado sólo una "vía rápida" puesta en práctica. Cualquier producto de vía rápida es más probable que va a ser un híbrido. Es sólo una cuestión de la cantidad de código en la "vía rápida", el espacio frente a la "vía lenta" del espacio. Cuando un producto reclama apoyo vía rápida, es necesario ahondar un poco más profundo para analizar la puesta en práctica con el fin de identificar las ventajas de rendimiento real.
Puestos relacionados con:
