YV - YoVirtualizador 80 - Virtualización de dispositivos 6

El otro día me centré tanto en la parte de gestión y del balón que dejé de lado el resto de dispositivos internos de gestión que suelen pulular por máquinas virtuales y quería haber tratado todo esto de forma conjunta pero la urgencia surgió en aquel capítulo y este capítulo acabó siendo un tema con entidad suficiente como para separar el contenido.

Hoy toca en el resto de mecanismos de comunicación entre máquina virtual y host no creo que me deje ninguno puesto que a pesar de que está bien documentado por cada fabricante es algo que se toca muy poquito por parte del consumidor masivo y es más es algo que tampoco preocupa a cierta gente de seguridad que conozco y eso no es positivo. Vamos a por el resto de dispositivos.

Bienvenidos a Yo Virtualizador, tu podcast de referencia del mundo de la tecnología y de la virtualización. ¿Cómo habla una máquina virtual con su host de hipervisor? ¿Y si la máquina virtual no tiene red? ¿Y si la BIOS es virtual? Todas estas preguntas surgen muy al principio de usar máquinas virtuales, emuladores y cualquier género de hipervisores a quien viene de un mundo físico donde conocemos perfectamente los mecanismos de interacción con los dispositivos pero en virtual los dispositivos son de software igual que las interconexiones. El primer mecanismo que tengo apuntado es el VMCI de VMware.

De hecho es con el que más experiencia tengo. La definición dice que Virtual Machine Communication Interface permite una comunicación rápida y eficiente entre máquinas virtuales que residen en un mismo host SXI o entre una máquina virtual y el host que la ejecuta. Esto significa que una máquina virtual puede conocer a su anfitrión y a otros huéspedes. A mí todo esto me suena a riesgo puesto que desde una máquina virtual podría llegar a tener Named Pipes, tuberías nominales para acceder a otras máquinas. Es un tema de seguridad que tocaremos después.

Un VMCI no usa la red. De hecho un host puede comunicarse con la máquina virtual por Vsockets, por Virtual Sockets, equivalentes a los Named Pipes, sin necesidad de red. Y como esta comunicación se realiza directamente contra un driver que emula un dispositivo de administración PCI Express, es varias veces más rápida que la comunicación de red TCP y P.

Está claro que esto nos puede proporcionar ventajas. Eso de que una comunicación sea dos o tres veces más rápida por VMCI que por red es siempre interesante y sólo necesita que el dispositivo esté habilitado, que por defecto lo está, salvo algunas excepciones, y como limitante sólo funciona dentro del mismo host.

Precisamente esa funcionalidad que permite un tráfico no controlado entre las máquinas virtuales es la que representa el riesgo que quizás es asumible, quizás no sea asumible. Para mí no lo es. Bien por no ser controlable o porque existan otros requisitos de seguridad. ¿Sería posible comunicar una máquina virtual con otra en el mismo host aunque no tengan red o estereo nubelas diferentes? Sí, es perfectamente, por medio de Vsockets. Voy a hacer un artículo de blog, probablemente también un vídeo, puesto que ya tengo hecho algo en maqueta de hace mucho tiempo, pero tengo que rehacerlo y de memoria no me acuerdo de todo.

Pero vamos, es una cosa que bastó para dejar en evidencia en su día a varios departamentos de seguridad de sitios que son teóricamente seguros. Y bueno, ya que estamos en la VM, ¿puede hacer algo en el host? Pues puede representar un canal de comunicación no controlado si no se configura adecuadamente. Desde el punto de vista de seguridad es recomendable restringir VMCI si no se va a utilizar, para evitar este tipo de tráfico oculto entre máquinas virtuales. De todas formas, la capacidad para que una máquina virtual interrogue al host