Siguiendo con la serie de posts sobre OpenvSwitch y OpenNebula en los que vamos viendo la integración de OpenNebula con Open vSwitch a través del driver, vamos a ver en esta última entrega cómo se aplica el control de MAC-Spoofing en openNebula y cómo añadir también control para IP-Spoofing que por defecto no viene en el driver de OpenNebula.
MAC-Spoofing
En caso de que una máquina se cambie la MAC, sabemos que se puede hacer un ataque de man-in-the-middle entre otros problemas derivados, para evitar esto OpenNebula añade una regla al Open vSwitch para fijar la MAC, el comando que se ejecuta és de la siguiente forma, donde <mac> es la MAC asignada por OpenNebula a la máquina virtual y <puerto> es el puerto que se ha creado sobre el bridge de OpenvSwitch:
# ovs-ofctl add-flow br32 in_port=<port>,dl_src=<mac>,priority=40000,actions=normal # ovs-ofctl add-flow br32 in_port=<port>,priority=39000,actions=drop
Los comandos anteriores lo que hacen es filtrar todo el tráfico por defecto en el puerto (prioridad 39000) y sólo dejar pasar el tráfico por el puerto que tenga la mac de la máquina virtual cómo destino/origen (prioridad 40000). Más prioridad indica que en caso de hacer match se ejecutará esta y no pasara a las siguientes.
En primer lugar vamos a probar que efectivamente si cambiamos la MAC de una máquina virtual el tráfico hacia esta es descartado . Hacemos dos máquinas virtuales con la IP 192.168.2.29 y 192.168.2.31 situadas en el mismo host físico , y cambiamos la MAC de la segunda con el macchanger :
# macchanger -r eth1
Seguidamente hacemos un ping entre las dos redes y vemos como efectivamente no llegan tanto los pings de la primera a la segunda como los de la segunda a la primera .
También hacemos un tcpdump en la segunda mientras hacemos el ping:
20:15:10.946400 ARP, Request who-has 192.168.2.31 tell 192.168.2.29, length 46 20:15:10.946409 ARP, Reply 192.168.2.31 is-at 10:c7:43:8a:dc:8d, length 28
Vemos como los broadcast de petición who-has si que nos llegan ya que estos no tienen ninguna MAC de destino asociada, pero al contestar la segunda máquina los paquetes son descartados y el mensaje anterior se repite ya que la primera máquina va repitiendo al no encontrar ninguna máquina que conteste con su MAC a la petición .
Si después de hacer el ping ejecutamos en la primera máquina lo siguiente:
# arp- a
Nos da la siguiente salida :
? (192.168.2.31) at <incomplete> on eth1
Lo cual nos confirma que los paquetes de respuesta de la IP en la petición ARP no está llegando a la primera máquina .
Vamos a hacer la misma prueba borrando las reglas de Open vSwitch que no permiten el tráfico más que en la MAC asignada , ejecutamos los siguientes comandos en la máquina física:
ovs-ofctl del-flows <bridge> dl_src=<mac> ovs-ofctl del-flows <bridge> in_port=<port>
donde <bridge> es el bridge sobre el que estamos poniendo las máquinas virtuales , <mac> es la MAC inicial de la segunda máquina y <puerto> es el puerto virtual sobre el que se ha creado la máquina virtual en el bridge .
Ahora hacemos un ping desde la primera a la segunda y viceversa y vemos cómo efectivamente llegan los pings después de haber falseado la MAC de la segunda . Si miramos la tabla ARP de la primera máquina :
# arp- a
Vemos lo siguiente:
? (192.168.2.31) at 10:c7:43:8a:dc:8d [ether] on eth1
Así pues vemos como efectivamente la máquina está viendo la MAC falseada.
En este apartado tan sólo hemos comprovado que efectivamente funciona el control de MAC-Spoofing en OpenNebula, en el próximo apartado vamos a ver cómo OpenNebula no tiene implementado el control de IP-Spoofing y como implementar éste.
IP-Spoofing
Si cambiamos la IP a una máquina con OpenNebula veremos cómo efectivamente és possible falsear las IPs que OpenNebula assigna a nuestra máquina virtual. Los comandos vistos en el anterior apartado para que no sea posible hacer MAC-Spoofing són los siguientes:
# ovs-ofctl add-flow <bridge> in_port=<port>,dl_src=<mac>,priority=40000,actions=normal # ovs-ofctl add-flow <bridge> in_port=<port>,priority=39000,actions=drop
Los comandos que se ejecutan para añadir los filtros, cómo vimos en la segunda entrega:
# ovs-ofctl add-flow <bridge> tcp,dl_dst=<mac>,tp_dst=<port>/<mask>,dl_vlan=<vlan>,actions=drop
y para añadir el filtro icmp:
ovs-ofctl add-flow <bridge> icmp,dl_dst=<mac>,dl_vlan=<vlan>,actions=drop
Vemos pues que no se está aplicando ningún filtro si la IP no corresponde a la que se ha definido, también hemos visto ya en el apartado anterior cómo el segundo comando del primer bloque nos filtra todo el tráfico que pase por la puerto virtual asignado a la máquina virtual , pero con una prioridad menor a la primera, que lo que hace es dejar pasar el tráfico del puerto en cuestión que coincida con la MAC de la máquina virtual.
Para el fin de que en el primer comando se filtre también lo que no coincida con la IP , necesitamos añadir el tag nw_src=<ip> , pero para añadirlo open vswitch nos obliga definir el protocolo cómo IP, ya que por ejemplo con el protocolo ARP no tiene sentido, para definir el protocolo como IP lo haremos añadiendo dl_type=0x0800
Así pues el primer comando queda de la siguiente forma:
# ovs-ofctl add-flow <bridge> dl_type=0x0800,in_port=<port_virtual>,dl_src=<mac>,nw_src=<ip>,priority=40000,actions=normal
Con este comando, pero vemos que mientras antes se dejava pasar el tráfico ARP, ahora no se está permitiendo, así pues necesitamos añadir una nueva regla que deje pasar el tráfico ARP para la MAC correspondiente. Para especificar el tráfico ARP se hace con dl_type=0x0806. Así pues, la regla quedará de la siguiente forma:
# ovs-ofctl add-flow <bridge> dl_type=0x0806,dl_src=<mac>,in_port=<port_virtual>,priority=40000,actions=normal
Una vez aplicada la regla se ha probado y funciona correctamente el control de IP-Spoofing.
Con este post terminamos la serie de Open vSwitch y OpenNebula. Para bajar el driver entero, se puede bajar de aqui.
Un saludo des del cloud! 😉