Muchos de nosotros estamos trabajando ahora con firewalls virtuales. Hice un post anterior sobre la fortalezas y debilidades de la seguridad en el mundo virtual , pero hoy quiero hablar de las posibilidades de cortafuegos con VMware. Ha habido mucho entusiasmo en relación con relativamente nuevo de VMware VMsafe API . En concreto, todo el mundo está luchando para crear / instalar firewalls rápido camino. Pero son todas las implementaciones de vía rápida creados iguales? ¿Hay preocupación por la seguridad de 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 en un entorno vSphere al permitir que los proveedores se integren directamente en el hipervisor en el anillo 0. VMsafe consta de tres componentes:
- VDDK - inspección de bloques de disco. API ha sido públicamente puesto en libertad.
- vCompute - CPU y la memoria de la API. No ha sido revelado. Desconocido que terceras personas puedan acceder, en su caso.
- vNetwork - API para controlar / filtro entre el vNIC y vSwitch. No ha sido revelado. A lo mejor de mi conocimiento, sólo Altor Networks y Sistemas Reflex tienen acceso (dos proveedores que participaron en el desarrollo de la API).
En concreto, quiero hablar con el API vNetwork. Cuando se controla el flujo de tráfico de la red en un host ESX, hay dos posible implementación, "vía lenta" y "vía rápida".
Camino lento
Marcha lenta, es la implementación más sencilla y la que hemos estado utilizando durante años. Efectivamente, esto es sólo un invitado de VM, de forma similar a cualquier otro invitado VM, que se ejecutan en el host ESX. Normalmente, cada invitado se conecta a un único vSwitch, y cada uno de estos conmutadores virtuales está conectada a un vNIC único en el firewall. Esto es similar a una configuración de firewall 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
Vía 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. Porque un controlador de vía rápida se ejecuta en el contexto del núcleo, se añade una sobrecarga mínima en 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 (de ahí el VMware convención de nomenclatura para cada contexto). De carga en el host ESX se reduce al mínimo, por lo que el resultado final es que se puede ejecutar huéspedes mucho más virtual.
Rápido Vs lento
Por lo tanto, suena como si quisiera hacer todo lo posible vía rápida, pero hay una serie de cuestiones. Vía rápida es un controlador del núcleo no se conecta en un mínimo hipervisor, un completo sistema operativo 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, somos la conexión de un controlador del núcleo por lo que debe ser la seguridad de que no se hinche 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 vía rápida antes de su liberación. Así que si en teoría podría poner en práctica todo mi código en el camino rápido, 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" de apoyo es, en realidad va a terminar la aplicación de una parte de su código como vía rápida, una porción de vía lenta, y luego crear un nexo de unión entre los dos. ¿Cuánta carga se coloca en el sistema dependerá de la cantidad de código se implementa en el camino rápido y cuánto de ello se ejecuta en el camino lento.
Posibles implementaciones de Fast Path
Por ejemplo, un vendedor puede optar por escribir un controlador de vía rápida que simplemente túneles todos los paquetes a un servidor de seguridad implementado vía lenta. El código de marcha lenta, a continuación, determina si el tráfico se debe pasar o se cae, con los paquetes pasan de ser enviado de nuevo al código 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 al 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 legado, ya que requieren la menor cantidad de modificaciones a su código existente sin dejar de ser capaces de reclamar "apoyo vía rápida".
Otra opción sería utilizar el espacio de vía lenta de las funciones administrativas con el controlador de ruta de acción rápida como el motor de firewall. Así, por ejemplo, el administrador del cortafuegos crearía la política mediante una interfaz que se ejecutan en una máquina virtual vía lenta, que a su vez impulsará la política de bajar a un conductor 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 se pueden implementar de inmediato. El resultado es más rápido manejo de tráfico con una carga mínima del sistema. La compensación es más voluminoso código en el anillo 0.
También es posible llevar a cabo una mezcla de los dos. Por ejemplo, yo podría utilizar el controlador de vía rápida para poner en práctica la política de firewall, pero luego pasa a todos "aceptado" los paquetes de vuelta al sistema vía lenta para comprobar la intrusión, detección de virus, o lo que sea necesario. Paquetes aceptable que luego pasan de nuevo al controlador de vía rápida para la inserción. Así que en esta configuración a todos "caído" 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 al considerar todas las implementaciones vNetwork, no sólo a los cortafuegos. El 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 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 estrictamente 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 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 reclamos de apoyo vía rápida, hay que cavar un poco más profundo para analizar la puesta en práctica con el fin de identificar las ventajas de rendimiento real.
