Cortafuegos de Proxmox VE

El módulo PVE-Firewall de Proxmox VE

El pasado 10 de julio de 2015 pude superar [al fin] mi gran miedo al cortafuegos de Proxmox VE (el módulo PVE-Firewall).

Todo comenzó por dos motivos:

• Se acercaba una inminente inspección de Seguridad Informática de la OSRI en días posteriores.
• El deseo de acabar de configurar el cortafuegos de Proxmox, que era una tarea que tenía pendiente desde que salió en la versión 3.3.

Evidentemente el primer motivo genera mucha más preocupación que el segundo, cosa que nos pone a correr en un momento determinado. También está la característica que tienen muchas personas (entre las cuales me incluyo) de dejar las cosas para después.

Entonces me dí a la tarea de «meterle el pecho» al asunto y así acabar de derrumbar ese obstáculo de una vez por todas, de lo cual surgió el manual del que se nutre este post. En él verán que he omitido las partes más importantes (algunos nombres, direcciones IP, rangos, etc.) por razones obvias , lo cual no atenta contra el entendimiento del mismo.

Así que, sin más preámbulo, vayamos al asunto.

Según la parte del manual de Proxmox (la Wiki de Proxmox para ser exactos), el cortafuegos se aplica en tres niveles:

• A nivel de Clúster
• A nivel de Nodo o Host
• A nivel de máquina virtual

Pero para «allanar» un poco el camino, se explicará lo más detallado posible el proceso de puesta en marcha de esta maravillosa característica de Proxmox VE.

PVE-Firewall: Activación del control del acceso en las interfaces de las instancias virtuales

Primeramente aclarar que esto fue desarrollado en mi entorno de trabajo donde tengo varios hipervisores Proxmox, uno de ellos se ve así:

Entonces, cuando se crea una nueva máquina virtual o contenedor, ahora aparece una nueva opción: una casilla de verificación o check box llamada “Firewall”.

En un Contenedor se ve así:

NOTA IMPORTANTE: En los contenedores esta característica está activada solamente en las interfaces de red del tipo veth, las cuales son asociadas a los bridges que se hayan definido previamente.

En una Máquina Virtual se ve así:

Se debe marcar dicha casilla si se quiere que el cortafuegos de Proxmox controle el acceso a la nueva instancia de máquina virtual que se crea. En caso de que se haya creado previamente pasando por alto esta característica, es sencillo activarla, solamente hay que seguir la ruta en el menú del gestor de Proxmox.

En caso de un Contenedor o CT la ruta en el menú es la siguiente:

Gestor de Proxmox —> Datacenter —> (Host Específico donde se encuentra el Contenedor) —> (Contenedor específico a modificar) —> Pestaña “Network” —> [Marcar la Interfaz de Red que se desea modificar] —> Pulsar el botón “Edit”

Saldrá una ventana como esta:

En caso de una Máquina Virtual o VM la ruta en el menú es la siguiente:

Gestor de Proxmox —> Datacenter —> (Host Específico donde se encuentra el Contenedor) —> (Contenedor específico a modificar) —> Pestaña “Hardware” —> Dar doble click a la Interfaz de Red que se desea modificar

Saldrá una ventana como esta:

Ya teniendo esta primera parte completada, sólo queda configurar el cortafuegos de Proxmox.

PVE-Firewall: Configuración de los elementos del cortafuegos

Como se dijo anteriormente, la configuración del cortafuegos de Proxmox se realiza en tres niveles: Clúster, Host y Máquina Virtual. En muchos casos los administradores no activan o usan esta característica de Proxmox, ya sea porque no cuentan con la documentación y orientación suficiente o por ignorancia. No obstante, en los casos en que el cortafuegos está presente en el funcionamiento de los hipervisores, ya sea en modo independiente o en clústers, las configuraciones son diversas.

En el caso que nos ocupa se mostrará la configuración de uno de los hipervisores Proxmox que tengo acá funcionando.

Para ir entrando en materia primeramente mostraré varias imágenes de la configuración.

A nivel de Clúster:

• Pestaña “Reglas”

• Pestaña “Grupos de Seguridad”

•  Pestaña “Alias”

• Pestaña “Conjuntos de IPs”

• Pestaña “Opciones”

A nivel de Nodo o Host Hipervisor:

• Pestaña “Reglas”

• Pestaña “Opciones”

• Pestaña “Log”

A nivel de Contenedor o Máquina Virtual:

• Pestaña “Reglas”

• Pestaña “Alias”

• Pestaña “Conjuntos de IPs”

• Pestaña “Opciones”

• Pestaña “Log”

Imágenes muy elocuentes, ¿verdad? Pues, ahora vamos a explicar cómo es el proceso de configuración.

Nivel de Clúster

En este nivel se establecen reglas y datos que se aplican en los niveles inferiores, y según el manual de PVE-Firewall que se encuentra en la wiki de Proxmox, se deben configurar los elementos del cortafuegos siguiendo el orden siguiente:

• Aliases
• Conjuntos de direcciones IP
• Grupos de seguridad (de ser necesarios)
• Reglas
• Activar el cortafuegos

Más detalladamente:

• Aliases

Aquí se definen los aliases tanto de direcciones IP específicas como de rangos completos de direcciones IP. Dichos aliases permiten asociar direcciones IP o rangos de redes con un nombre, el cual más adelante se referirán tanto en los conjuntos de direcciones IP que se definan como en las propiedades “source” y/o “dest” de las reglas de cortafuegos.

Para cada una de ellas la ruta crítica para añadir o editar es la siguiente:

Pestaña “Alias” à Botón “Add”/”Edit”

Y saldrá una ventana como esta:

(Añadir)

(Editar)

NOTA: Claro está que, una vez modificados los campos (y que cumplan con las restricciones de los datos a proveer), se activará el botón “OK”. Sólo queda pulsarlo para confirmar la añadidura o el cambio de valores. Esto se cumple para cualquier elemento a configurar en el cortafuegos de Proxmox.

Entonces, una vez añadidos todos los aliases necesarios, la vista cambia y se ve de la siguiente manera:

•  Conjuntos de direcciones IP (IP Sets)

Aquí se definen los conjuntos de direcciones IP tanto de direcciones IP específicas como de rangos completos de direcciones IP. Estos conjuntos pueden ser usados para crear grupos de direcciones IP como rangos de redes, los cuales se pueden utilizar en los campos “source” y/o “dest” de las reglas de cortafuegos y se referencian como +nombre_del_conjunto_de_direcciones_ip.

Para cada elemento la ruta crítica para añadir o editar es la siguiente:

Pestaña “IPSet” à Botón “Create”/”Edit”

Y saldrá una ventana como esta:

(Añadir)

(Editar)

Creado el conjunto que direcciones IP/CIDR hay que llenarlo con valores, para esto se va a la parte derecha de la vista donde está la sección “IP/CIDR:” y presionar los botones “Add” o “Edit” según corresponda. Entonces saldría una nueva ventana con el aspecto siguiente:

(Añadir)

[De manera manual]

[Utilizando un alias previamente creado]

NOTA: Si se quiere definir que no incluya los valore seleccionados, basta con activar la casilla de verificación “nomatch:”.

(Editar)

Como se ve, una vez establecido el valor del campo “IP/CIDR”, no se puede editar posteriormente. Para ello será necesario eliminar el valor y añadir uno nuevo.

•  Reglas

Aquí se define la parte más importante de la configuración del módulo. Cualquier regla de cortafuegos consiste en la aplicación de una acción (ACCEPT, DENY o REJECT) para un sentido específico del tráfico de red (IN u OUT), más otras opciones especiales que pueden ser o no utilizadas también.

Para crear una regla, la ruta crítica es la siguiente:

Pestaña “Rules” à Botón “Add”/”Edit”

Y saldrá una ventana como esta:

(Añadir)

(Editar)

En ambos casos hay que proveer una serie de campos de datos para conformarla. Dichos campos son:

Direction: Dirección del sentido del tráfico de red

Action: Acción a realizar

Interface: Interfaz a la que se controlará el tráfico de red

Aquí hay que detenerse por obligación. La manera de referenciarse las interfaces de red tanto en contenedores (veth) como en máquinas virtuales (vinculación con un bridge específico) no es la misma.

En los contenedores la definición de una interfaz de red es más o menos así:

Ahí vemos que el nombre asignado a la interfaz es “eth0”, por lo tanto, es el nombre que se pondrá en el campo “Interface”. Si se establece uno incorrecto, dará el error que se muestra a continuación:

En las máquinas virtuales la definición de una interfaz de red es diferente totalmente:

En este caso, vemos que el nombre asignado a la interfaz es “net0”, por lo tanto, es el nombre que se pondrá en el campo “Interface”. Si se establece uno incorrecto, dará un error como este:

Source: Dirección IP o Rango de Red de donde se origina el tráfico de red

Aquí el valor de este campo se puede establecer o manualmente, o seleccionado un alias o conjunto de direcciones IP/CIDR previamente creado:

Destination: Dirección IP o Rango de Red de destino hacia donde va el tráfico de red

También aquí el valor de este campo se puede establecer o manualmente, o seleccionado un alias o conjunto de direcciones IP/CIDR previamente creado:

Comment: Una cadena descriptiva de la regla (este campo es opcional)

Enable: Activar o desactivar la regla

Macro: Configuración predefinidas de valores de protocolos y puertos de diferentes servicios

Aquí Proxmox nos da unos cuantos valores predefinidos:

Esto nos da cierta comodidad al establecer para qué servicio está orientada la regla en sí, dado que ya predetermina los demás campos que faltan (deshabilita los campos “Protocol”, “Source port” y “Destination port”). He aquí un ejemplo con la selección del servicio SSH (puerto 22/tcp)

Pero existe el caso en que tengamos servicios configurados para escuchar en otro puerto, ya no coincide con el preestablecido por Proxmox. He aquí el ejemplo en que se pone a escuchar al servicio SSH por el puerto 40497/tcp:

Se establece manualmente el tipo de protocolo (TCP), los puertos de origen de la conexión (entre 1024 y 65535) y el puerto destino al que se quiere conectar (40497).

Protocol: Protocolo del tráfico de red

Y no solamente el TCP y UDP que utilizamos cotidianamente, hay muchos más:

Y en esta imagen no se ven todos, pero la lista es bastante considerable.

Source post: Puerto(s) de origen de la conexión

Aquí se establece el(los) puerto(s) de origen de conexiones:

En este caso las conexiones se originan desde una estación de trabajo o servidor desde un puerto de solicitud de conexiones, los cuales están ubicados en en rango entre 1024 y 65535.

Dest. post: Puerto(s) de origen de la conexión

Aquí se establece el(los) puerto(s) hacia donde van dirigidas las conexiones:

En este caso las conexiones van dirigidas al servicio SSH (Administración Remota) de un servidor específico. Dicho servicio escucha a través de un puerto diferente al establecido en las RFC (que es el 22/tcp), o sea, el puerto 40497/tcp.

NOTA IMPORTANTE: Es válido aclarar que el proceso de añadir/editar las reglas de cortafuegos es igual en cualquier nivel que se trabaje. No obstante, estas modificaciones se realizan normalmente a nivel de nodo/host/hipervisor y/o a nivel de CT/VM, lo cual no quiere decir que no haya necesidad de aplicar reglas a nivel de clúster.

• Grupos de seguridad (Security Groups)

Aquí se definen los grupos de seguridad que se utilizarán. Un grupo de seguridad no es más que un grupo de reglas, definidas solamente a nivel de clúster, las cuales pueden ser usadas en cualquiera de los tres niveles, basta con insertarlas mediante el botón “Insert: Security Group”. Más adelante se verá un ejemplo de esto.

La creación de los grupos de seguridad sigue un orden similar al de la creación de reglas de cortafuegos, con la diferencia de que hay que crear previamente el grupo que las contendrá. Para ello la ruta crítica es la siguiente:

Pestaña “Security Group” à Botón “Create”/”Edit”

Y saldrá una ventana como esta:

(Crear nuevo)

(Editar)

Y para la creación de las reglas de cortafuegos, se sigue el mismo orden descrito anteriormente.

Ya, por último ir a la pestaña “Opciones”

y activar el cortaguegos:

NOTA: La política por defecto del tráfico entrante es siempre DROP, y la del tráfico saliente es ACCEPT.

Nivel de Nodo/Host/Hipervisor y CT/VM

En estos niveles la configuración del cortafuegos es similar, pero con ligeras diferencias:

• La pestaña “Opciones” en cada nivel es diferente

Nivel Nodo/Host/Hipervisor:

Como se muestra en la imagen anterior, existen varios parámetros a establecer. En el caso que nos ocupa, los valores que aparecen en dicha imagen son los establecidos (esto basándonos tanto en la información ofrecida en la wiki de Proxmox como en su foro de discusión).

Nivel CT/VM:

Aquí también los valores que aparecen en dicha imagen son los establecidos (esto basándonos tanto en la información ofrecida en la wiki de Proxmox como en su foro de discusión).

• Definición de aliases y conjuntos de IP/CIDR particulares a nivel de CT/VM

En la interfaz gráfica se puede ver que, a nivel de CT/VM también se pueden definir tanto aliases como conjuntos de IP/CIDR particulares para cada instancia CT/VM específica:

(Aliases)

(Conjuntos de IP/CIDR)

A modo de ilustración se muestran reglas establecidas en el cortafuegos de Proxmox.

Reglas a nivel de nodo/host/hipervisor:

Reglas a nivel de CT/VM:

Se pueden crear reglas por tantos servicios se alojen en una CT/VM específica, solamente hay que añadir más reglas.

PVE-Firewall: Muy bien todo esto, pero… ¿cómo se ve todo esto por debajo de la GUI?

Bien, ya hemos visto cómo se configura el cortafuegos de Proxmox a través de la interfaz de gestión, pero… una vez finalizadas todas estas operaciones, ¿qué queda reflejado en la configuración de Proxmox a nivel de Shell o CLI? Pues, Proxmox tiene un directorio donde se guardan las configuraciones, en /etc/pve, cuya estructura se ve así:

Donde en el subdirectorio /etc/pve/firewall se guarda la configuración del cortafuegos de dos niveles: clúster e instancias específicas de CT/VM:

En la imagen anterior se ve que están definidas la configuración general del clúster y la del contenedor con ID 107.

La configuración de cortafuegos referente al nodo/host/hipervisor se encuentra en el subdirectorio /etc/pve/nodes/<Nombre de host>:

Grupos de seguridad (revisitado)

Anteriormente vimos qué eran los grupos de seguridad, ahora veamos un ejemplo funcional.

Como punto de partida, retomemos la imagen siguiente:

Se ve que están establecidas dos reglas de cortafuegos:

• Regla 0

Con las especificaciones siguientes:

Activación: Sí

Tipo de tráfico: Entrante

Acción: Aceptar

Interfaz donde se aplica: vmbr2 (Dirección IP de gestión del Nodo)

Dirección IP/CIDR de origen: Alias que apunta a la dirección IP del equipo del Administrador de la Red

Dirección IP/CIDR destino: Subred donde están ubicados los hipervidores o nodos Proxmox

Protocolo: TCP

Puerto de origen: Rango de puertos que va desde 1024 hasta 65535 (solicitudes de conexiones)

Puerto destino: 40497 (SSH modificado)

• Regla 1

Con las especificaciones siguientes:

Activación: Sí

Tipo de tráfico: Entrante

Acción: Aceptar

Interfaz donde se aplica: vmbr2 (Dirección IP de gestión del Nodo)

Dirección IP/CIDR de origen: Alias que apunta a la dirección IP del equipo del Administrador de la Red

Dirección IP/CIDR destino: Subred donde están ubicados los hipervidores o nodos Proxmox

Protocolo: TCP

Puerto de origen: Rango de puertos que va desde 1024 hasta 65535 (solicitudes de conexiones)

Puerto destino: 8006 (Interfaz Web de Proxmox VE)

Dichas reglas indican que solamente desde el equipo de trabajo del Administrador de la Red se puede administrar el nodo.

Ahora bien, tenemos las dos preguntas siguientes:

• ¿Y por qué no hacemos un grupo de seguridad que englobe estas dos reglas?
• Bien, creado, pero… ¿qué diferencia tendría eso?

Las respuestas son sencillas:

• Primera: Nos quitamos de encima el tener que replicar estas dos reglas para cada nodo que se agrege al clúster.
• Segunda: solamente habría que insertar el grupo de seguridad, dado que ya las contiene.

En otras palabras, un grupo de seguridad se crea basado en el(los) tipo(s) de servicio(s) que se provea (que es lo común en estos casos para no complicarse tanto la existencia). Por ejemplo, agrupados por:

• Servidores Web: Puertos 80/tcp y 443/tcp
• Servidores Jabber: Puertos 5222/tcp, 5223/tcp y 5269/tcp
• Servidores LDAP: Puertos 389/tcp y 636/tcp
• Controladores Primarios de Dominio: Puertos 389/{tcp|udp}, 636/{tcp|udp}, 3268/tcp, 3269/tcp, 88/{tcp|udp}, 464/{tcp|udp}, 135/tcp, 5722/tcp, y el rango 1024-65535/{tcp|udp}

Y muchos otros. No obstante, también se pueden basar en otros criterios de selección, pero ya eso es a gusto del administrador o de cómo tenga creada su infraestructura (o de como lo obligue porque muchas veces las infraestructuras las heredan).

Entonces, para el ejemplo que vamos a hacer, se sigue el criterio a continuación:

• Administración de Hipervisores Proxmox: Puertos 40497 (SSH modificado) y 8006 (Interfaz Web)

Si ya tenemos el criterio escogido, pues, manos a la obra. Ir a:

Gestor de Proxmox —> Datacenter —> Firewall —> Pestaña “Security Group” —> Botón “Create”

Y crear un nuevo Grupo de Seguridad llamado “gestion_proxmox” (el nombre no debe exceder de 20 caracteres):

• Nombre: gestion_proxmox
• Comment: Administración remota de Hipervisores Proxmox

El cual quedaría así:

Una vez creado

Se procede a crear las reglas de cortafuegos:

• Regla 0

Datos a proveer:

Direction: in

Action: ACCEPT

Source: ip_equipo_administrador_red

Destination: +vlan_hipervisores

Comment: Gestion Remota de Proxmox a traves de CLI (SSH modificado)

Enable: Activado

Macro: <Vacío>

Protocol: TCP

Source port: 1024:65535

Dest. port: 40497

Gráficamente se ve así:

• Regla 1

Datos a proveer:

Direction: in

Action: ACCEPT

Source: ip_equipo_administrador_red

Destination: +vlan_hipervisores

Comment: Gestion Remota de Proxmox a traves de la Interfaz Web

Enable: Activado

Macro: <Vacío>

Protocol: TCP

Source port: 1024:65535

Dest. port: 8006

Gráficamente se ve así:

Terminadas todas estas operaciones, ya tenemos creado nuestro grupo de seguridad y, de paso, la respuesta gráfica de la primera pregunta:

Ah, pero sólo hemos recorrido la mitad del trayecto, falta vincular este grupo de seguridad anteriormente creado al cortafuegos del nodo o de los nodos Proxmox. Para ello la ruta que se sigue en el menú es mediante:

Gestor de Proxmox —> Datacenter —> <Nodo específico> —> Firewall —> Pestaña “Rules” —> Botón “Insert: Security Group”

Donde sale una ueva ventana donde se proveen los datos siguientes:

• Security Group: gestión_proxmox
• Enable: Activado
• Interface: vmbr2 (Interfaz de gestión del nodo)
• Comment: Gestion Remota de Hipervisores Proxmox

Como se ve en la imagen:

Con esto finalmente se tiene vinculado el grupo de seguridad a las reglas de cortafuegos del nodo:

No obstante, para cerciorarse de que funciona el cortafuegos, basta con probar desde una estación de trabajo o servidor cualquiera el acceso a los dos puertos (8006 y 40497) del nodo con la dirección IP correspondiente. En la siguiente imagen se muestra dos intentos de acceso a la interfaz CLI (SSH modificado) del nodo PRX-C0-2 desde dos orígenes: un servidor y la estación de trabajo del Administrador de la Red:

Y en esta otra el intento de acceso a la interfaz Web del nodo PRX-C0-2 desde los mismos orígenes:

Estas operaciones se pueden realizar también con otros tipos de servicios, solamente hay que pensar y planificar bien todas las reglas que sean necesarias y aplicarlas con cuidado y en el orden adecuado para lograr el efecto deseado.

NOTA: Normalmente las máquinas virtuales KVM, por sus características intrínsecas de aislamiento total del entorno virtual (virtualización completa), permiten la configuración del cortafuegos que provee el sistema operativo hospedero, lo cual da una seguridad adicional. No obstante, los contenedores no tienen esta facilidad (virtualización a nivel de sistema operativo) y ahí en donde entra el cortafuegos de Proxmox, para garantizar un buen nivel de protección a este tipo de entorno virtual.

A modo de conclusión, la configuración del cortafuegos de Proxmox puede parecer un poco compleja para el que se inicia en ella, pero una vez que se van adquiriendo los conceptos y habilidades, se hace mucho más fácil el proceso. La cuestión está en no cogerle miedo.

🙂