Viaje al centro del Cortafuegos de Proxmox (18/11/2015)

Saludos nuevamente.

El siguiente post lo considero como una segunda parte del post anterior, y el motivo por el cual lo confeccioné fué porque me sucedió algo muy curioso el pasado domingo 15 de noviembre de 2015.

Resulta que hace ya varios días vengo ayudando a un amigo mío, que es el Especialista de Seguridad Informática en su centro de trabajo, a configurar unos servidores para que así pueda aprovechar mejor el poco parque tecnológico de que tiene.

Durante el fin de semana pasado no pudimos adelantar mucho, así que aproveché que mi esposa había hecho ya las labores correspondientes al domingo (labores en las que también participé, aclaro) y se fue a arreglar, junto con mi hija, para el evento que tiene la semana entrante (o sea, esta semana que está transcurriendo). Me quedé solo en casa y para no aburrirme decidí simular en entornos virtuales lo que estaba haciendo, o sea, usé una plataforma de virtualización para reproducir el entorno del centro de trabajo del amigo mío.

Una vez que terminé de instalar el Proxmox VE 4.0 y los servidores virtuales (realmente el laptop se lo sentía feamente porque se puso muy lento), me dispuse a configurar el cortafuegos de Proxmox, inicialmente a nivel de cluster y host. Cuando activé el módulo PVE-Firewall para que se aplicaran las reglas, me di cuenta de un detalle.

Resultó que yo estaba utilizando una dirección IP diferente a las que definí para la administración a través de la WebGUI de Proxmox y estaba accediendo sin problemas a la gestión del hipervisor a través de la WebGUI. Eso me dejó casi sin dormir y temprano en la mañana del lunes arranqué para mi trabajo (6 de la mañana aproximadamente, 15 minutos me tomo cuando voy en modo Turbo) y escribí a la lista de usuarios de Proxmox VE (PVE-User) explicándoles lo que me había pasado.

Las respuestas llegaron rápido, pero la más contundente fue la primera respuesta de Dietmar Maurer, uno de los líderes del proyecto: el acceso tanto por la WebGUI como por SSH  (puerto 22/tcp) es permitido por defecto para toda la subred donde está ubicado el hipervisor Proxmox VE. En otras palabras, si los hipervisores están ubicados en la subred 172.16.1.0/24, por defecto TODOS los equipos que estén dentro de la misma tiene alcance a los servicios de gestión del hipervisor.

Eso acabó conmigo, dado que no me esperaba esa característica específica del cortafuegos de Proxmox VE. ¿Por qué? Pues, porque en mi caso yo controlo el acceso a la subred de mis hipervisores mediante un router a nivel de las capas IP y transporte. Por eso pasó inadvertida ante mis ojos.

Pero la realidad de muchos administradores es que solamente disponen de una sola subred donde, obligatoriamente, se ubican tanto servidores como estaciones de trabajo y por ello esa característica no cuadra mucho.

Entonces, volviendo al tema de las respuestas recibidas en la lista de distribución PVE-Users, como solución alternativa, en la mayoría de las mismas me sugerían añadir reglas al iptables del Proxmox restringiendo el acceso a los puertos 22/tcp y 8006/tcp, pero mi temor era que si modificaba algo, podía interferir con el funcionamiento correcto del módulo PVE-Firewall. En ese caso, Dietmar me dió luz verde, pero cuando ya me estaba afilando los dientes y las garras con una lima para meterle mano al hipervisor, me asaltó una duda: cómo rayos le inserto las reglas al iptables en la posición adecuada para que haga lo que quiero.

Bueno, hoy cuando volví nuevamente al trabajo del amigo mío hice una pausa en lo que estábamos haciendo y me dispuse a investigar un poco acerca del módulo PVE-Firewall de Proxmox VE y me encontré muchas cosas interesantes. La primera luz la encontré en el foro de Proxmox y las otras surfeando por Internet. De ahí salió la primera idea: obtener el código de las reglas de Iptables, modificarlas para luego “devolvérselas” con los cambios hechos.

Después de mucha navegación, al final, la respuesta adecuada la encontré muy cerca (donde menos me imaginaba): en el código fuente del módulo PVE-Firewall (créanme cuando les digo que me embargó un sentimiento de vergüenza porque primero pregunté a la lista antes de ponerme a investigar a fondo). No obstante, me puse a escudriñar un poco dicho código (que fué más bien un viaje al centro de ese interesante código fuente) y, de hecho, encontré cosas que en la mayoría de los casos no utilizamos. Más concretamente: los ipsets.

Poco a poco la solución del problema fue surgiendo, primeramente mirando las interioridades del módulo PVE-Firewall y luego la modificación en el lugar específico.

Interioridades del módulo PVE-Firewall:

• El módulo PVE-Firewall está hecho en Perl 5, o sea, los scripts que generan los conjuntos de IP y las reglas de iptables

• Se utilizan Conjuntos de direcciones IP (IPSets), los cuales añade PVE-Firewall cuando le especificamos IP Sets, aparte de los que son por defecto

Por debajo el módulo ejecuta el comando ipset para generar los conjuntos de direcciones IP, donde dichos conjuntos son utilizados por Iptables. De eso me di cuenta porque habían cadenas que aparecían en el código de Iptables a las que no encontraba su origen; de ahí fue que me tropecé con el comando ipset.

El módulo PVE-Firewall crea los nombres de los conjuntos con el prefijo «PVEFW-» concatenado con una cadena en hexadecimal resultado una función a la cual  se le pasa el ID del conjunto de direcciones IP creado a través de la WebGUI.

• PVE-Firewall crea por defecto dos conjuntos de direcciones IP «PVEFW-0-management-v4» y «PVEFW-0-management-v6»

El primero de estos dos conjuntos antes mencionados es la causa de mi preocupación, porque, hagamos lo que hagamos, siempre mantienen sus valores iniciales.

De todas maneras, si deseamos saber cuales son los conjuntos de direcciones IP que genera PVE-Firewall, podemos usar el comando ipset:

root@prx4-c0-1:~# ipset list

Name: PVEFW-0-management-v4

Type: hash:net

Revision: 6

Header: family inet hashsize 64 maxelem 64

Size in memory: 448

References: 4

Members:

172.16.1.0/24

Name: PVEFW-63C387DC

Type: hash:net

Revision: 6

Header: family inet6 hashsize 64 maxelem 64

Size in memory: 1152

References: 2

Members:

Name: PVEFW-573D4CFC

Type: hash:net

Revision: 6

Header: family inet6 hashsize 64 maxelem 64

Size in memory: 1152

References: 2

Members:

Name: PVEFW-0-management-v6

Type: hash:net

Revision: 6

Header: family inet6 hashsize 64 maxelem 64

Size in memory: 1152

References: 4

Members:

Name: PVEFW-593D5022

Type: hash:net

Revision: 6

Header: family inet hashsize 64 maxelem 64

Size in memory: 448

References: 3

Members:

172.16.1.240

Name: PVEFW-65C38B02

Type: hash:net

Revision: 6

Header: family inet hashsize 64 maxelem 64

Size in memory: 51

References: 2

Members:

172.16.1.7

172.16.1.6

root@prx4-c0-1:~#

Donde la relación de algunos nombres de ipset y los que definí en la WebGUI de Proxmox son las siguientes:

PVEFW-65C38B02 —> equipos_gestion_servidores

PVEFW-593D5022 —> hipervisores_proxmox_ve

• Las reglas de cortafuegos que genera el módulo PVE-Firewall siguen un esquema específico

Para que se entienda mejor la idea de lo que quiero transmitir, vamos de lo simple a lo complejo. Primeramente veamos el entorno y luego las reglas de iptables y cómo podemos modificarlas.

Entorno:

El entorno donde estamos trabajando es sencillo. Los detalles son los siguientes:

ID de Red: 172.16.1.0/24
Hipervisores Proxmox VE: 172.16.1.240 (v4.0), 172.16.1.241 (v3.4) [Interfaz vmbr0]
Estaciones de trabajo de Gestión de la Red y Servidores: 172.16.1.6, 172.16.1.7

Grupos de Seguridad:

172.16.1.6, 172.16.1.7 — (ACCEPT) —> {172.16.1.240 | 172.16.1.241}: {8006 | 40497}

Llevándolo a los Hipervisores Proxmox, la configuración es la siguiente:

Contenido del archivo /etc/pve/firewall/cluster.fw:

[OPTIONS]

enable: 1

[ALIASES]

ip_equipo_administrador_red 172.16.1.7 # Estacion de Trabajo del Administrador de la Red

ip_equipo_especialista_si 172.16.1.6 # Estacion de Trabajo del Especialista de Seguridad Informatica
ip_hipervisor_prx4-c0-1 172.16.1.240 # Hipervisor con Proxmox VE (PRX4-C0-1)

ip_hipervisor_prx4-c0-2 172.16.1.241 # Hipervisor con Proxmox VE (PRX4-C0-2)

[IPSET equipos_gestion_servidores]

ip_equipo_administrador_red
ip_equipo_especialista_si

[IPSET hipervisores_proxmox_ve]

ip_hipervisor_prx4-c0-1

ip_hipervisor_prx4-c0-2

[group gestion_hipervisores]

IN ACCEPT -source +equipos_gestion_servidores -dest +hipervisores_proxmox_ve -p tcp -dport 8006 -sport 1024:65535 # Gestion de Hipervisores Proxmox VE a traves de la Interfaz Grafica WEB (WebGUI)
IN ACCEPT -source +equipos_gestion_servidores -dest +hipervisores_proxmox_ve -p tcp -dport 40497 -sport 1024:65535 # Gestion de Proxmox VE a traves de SSH (CLI)

Contenido del archivo /etc/pve/nodes/prx4-c0-1/host.fw:

[OPTIONS]

nf_conntrack_tcp_timeout_established: 7875
nf_conntrack_max: 196608
log_level_in: debug
smurf_log_level: debug
log_level_out: debug
enable: 1
tcp_flags_log_level: debug
tcpflags: 1

[RULES]

GROUP gestion_hipervisores -i vmbr0
IN Ping(ACCEPT) -i vmbr0 -source +equipos_gestion_servidores -dest +hipervisores_proxmox_ve # Solamente desde los Equipos de Gestion de la Red se puede Pingear a los Hipervisores Proxmox VE

Reglas de Iptables generadas por el comando iptables-save y guardadas en el archivo /root/iptables.rules.pve-firewall:

El comando que se ejecutó fue:

root@prx4-c0-1:~# iptables-save > /root/iptables.rules.pve-firewall

Donde el contenido el archivo resultante es el siguiente:

# Generated by iptables-save v1.4.21 on Wed Nov 18 15:41:41 2015

*filter

:INPUT ACCEPT [0:0]

:FORWARD ACCEPT [22:1936]

:OUTPUT ACCEPT [0:0]

:GROUP-equipos_gestion_servidores-IN – [0:0]

:GROUP-equipos_gestion_servidores-OUT – [0:0]

:PVEFW-Drop – [0:0]

:PVEFW-DropBroadcast – [0:0]

:PVEFW-FORWARD – [0:0]

:PVEFW-FWBR-IN – [0:0]

:PVEFW-FWBR-OUT – [0:0]

:PVEFW-HOST-IN – [0:0]

:PVEFW-HOST-OUT – [0:0]

:PVEFW-INPUT – [0:0]

:PVEFW-OUTPUT – [0:0]

:PVEFW-Reject – [0:0]

:PVEFW-SET-ACCEPT-MARK – [0:0]

:PVEFW-logflags – [0:0]

:PVEFW-reject – [0:0]

:PVEFW-smurflog – [0:0]

:PVEFW-smurfs – [0:0]

:PVEFW-tcpflags – [0:0]

-A INPUT -j PVEFW-INPUT

-A FORWARD -j PVEFW-FORWARD

-A OUTPUT -j PVEFW-OUTPUT

-A GROUP-equipos_gestion_servidores-IN -j MARK –set-xmark 0x0/0xffffffff

-A GROUP-equipos_gestion_servidores-IN -p tcp -m set –match-set PVEFW-65C38B02 src -m set –match-set PVEFW-593D5022 dst -m tcp –sport 1024:65535 –dport 40497 -g PVEFW-SET-ACCEPT-MARK

-A GROUP-equipos_gestion_servidores-IN -p tcp -m set –match-set PVEFW-65C38B02 src -m set –match-set PVEFW-593D5022 dst -m tcp –sport 1024:65535 –dport 8006 -g PVEFW-SET-ACCEPT-MARK

-A GROUP-equipos_gestion_servidores-IN -m comment –comment «PVESIG:Ii/tmyf7IqlPh5x/xt7HDTEsSBY»

-A GROUP-equipos_gestion_servidores-OUT -j MARK –set-xmark 0x0/0xffffffff

-A GROUP-equipos_gestion_servidores-OUT -m comment –comment «PVESIG:nXYn/cekt5v3NY/34q2unJW+664»

-A PVEFW-Drop -p tcp -m tcp –dport 43 -j PVEFW-reject

-A PVEFW-Drop -j PVEFW-DropBroadcast

-A PVEFW-Drop -p icmp -m icmp –icmp-type 3/4 -j ACCEPT

-A PVEFW-Drop -p icmp -m icmp –icmp-type 11 -j ACCEPT

-A PVEFW-Drop -m conntrack –ctstate INVALID -j DROP

-A PVEFW-Drop -p udp -m multiport –dports 135,445 -j DROP

-A PVEFW-Drop -p udp -m udp –dport 137:139 -j DROP

-A PVEFW-Drop -p udp -m udp –sport 137 –dport 1024:65535 -j DROP

-A PVEFW-Drop -p tcp -m multiport –dports 135,139,445 -j DROP

-A PVEFW-Drop -p udp -m udp –dport 1900 -j DROP

-A PVEFW-Drop -p tcp -m tcp ! –tcp-flags FIN,SYN,RST,ACK SYN -j DROP

-A PVEFW-Drop -p udp -m udp –sport 53 -j DROP

-A PVEFW-Drop -m comment –comment «PVESIG:zfGV4KTPaxGVOCwRUVqqqbR0IhM»

-A PVEFW-DropBroadcast -m addrtype –dst-type BROADCAST -j DROP

-A PVEFW-DropBroadcast -m addrtype –dst-type MULTICAST -j DROP

-A PVEFW-DropBroadcast -m addrtype –dst-type ANYCAST -j DROP

-A PVEFW-DropBroadcast -d 224.0.0.0/4 -j DROP

-A PVEFW-DropBroadcast -m comment –comment «PVESIG:NyjHNAtFbkH7WGLamPpdVnxHy4w»

-A PVEFW-FORWARD -m conntrack –ctstate INVALID -j DROP

-A PVEFW-FORWARD -m conntrack –ctstate RELATED,ESTABLISHED -j ACCEPT

-A PVEFW-FORWARD -m physdev –physdev-in fwln+ –physdev-is-bridged -j PVEFW-FWBR-IN

-A PVEFW-FORWARD -m physdev –physdev-out fwln+ –physdev-is-bridged -j PVEFW-FWBR-OUT

-A PVEFW-FORWARD -m comment –comment «PVESIG:qnNexOcGa+y+jebd4dAUqFSp5nw»

-A PVEFW-FWBR-IN -m conntrack –ctstate INVALID,NEW -j PVEFW-smurfs

-A PVEFW-FWBR-IN -p tcp -j PVEFW-tcpflags

-A PVEFW-FWBR-IN -m comment –comment «PVESIG:Ka4S8B0HM4A1RRtoso/euMz41l8»

-A PVEFW-FWBR-OUT -m comment –comment «PVESIG:2jmj7l5rSw0yVb/vlWAYkK/YBwk»

-A PVEFW-HOST-IN -i lo -j ACCEPT

-A PVEFW-HOST-IN -m conntrack –ctstate INVALID -j DROP

-A PVEFW-HOST-IN -m conntrack –ctstate RELATED,ESTABLISHED -j ACCEPT

-A PVEFW-HOST-IN -m conntrack –ctstate INVALID,NEW -j PVEFW-smurfs

-A PVEFW-HOST-IN -p tcp -j PVEFW-tcpflags

-A PVEFW-HOST-IN -p igmp -j RETURN

-A PVEFW-HOST-IN -i vmbr0 -j GROUP-equipos_gestion_servidores-IN

-A PVEFW-HOST-IN -m mark –mark 0x1 -j RETURN

-A PVEFW-HOST-IN -s 172.16.1.7/32 -i vmbr0 -p icmp -m set –match-set PVEFW-593D5022 dst -m icmp –icmp-type 8 -j RETURN

-A PVEFW-HOST-IN -p tcp -m set –match-set PVEFW-0-management-v4 src -m tcp –dport 8006 -j RETURN

-A PVEFW-HOST-IN -p tcp -m set –match-set PVEFW-0-management-v4 src -m tcp –dport 5900:5999 -j RETURN

-A PVEFW-HOST-IN -p tcp -m set –match-set PVEFW-0-management-v4 src -m tcp –dport 3128 -j RETURN

-A PVEFW-HOST-IN -p tcp -m set –match-set PVEFW-0-management-v4 src -m tcp –dport 22 -j RETURN

-A PVEFW-HOST-IN -s 172.16.1.0/24 -d 172.16.1.0/24 -p udp -m udp –dport 5404:5405 -j RETURN

-A PVEFW-HOST-IN -s 172.16.1.0/24 -p udp -m addrtype –dst-type MULTICAST -m udp –dport 5404:5405 -j RETURN

-A PVEFW-HOST-IN -j PVEFW-Drop

-A PVEFW-HOST-IN -j NFLOG –nflog-prefix  «:0:7:PVEFW-HOST-IN: policy DROP: «

-A PVEFW-HOST-IN -j DROP

-A PVEFW-HOST-IN -m comment –comment «PVESIG:3oHJwRyuJ7ViwTu7yX6v1v6qs8U»

-A PVEFW-HOST-OUT -o lo -j ACCEPT

-A PVEFW-HOST-OUT -m conntrack –ctstate INVALID -j DROP

-A PVEFW-HOST-OUT -m conntrack –ctstate RELATED,ESTABLISHED -j ACCEPT

-A PVEFW-HOST-OUT -p igmp -j RETURN

-A PVEFW-HOST-OUT -o vmbr0 -j GROUP-equipos_gestion_servidores-OUT

-A PVEFW-HOST-OUT -m mark –mark 0x1 -j RETURN

-A PVEFW-HOST-OUT -d 172.16.1.0/24 -p tcp -m tcp –dport 8006 -j RETURN

-A PVEFW-HOST-OUT -d 172.16.1.0/24 -p tcp -m tcp –dport 22 -j RETURN

-A PVEFW-HOST-OUT -d 172.16.1.0/24 -p tcp -m tcp –dport 5900:5999 -j RETURN

-A PVEFW-HOST-OUT -d 172.16.1.0/24 -p tcp -m tcp –dport 3128 -j RETURN

-A PVEFW-HOST-OUT -d 172.16.1.0/24 -p udp -m udp –dport 5404:5405 -j RETURN

-A PVEFW-HOST-OUT -p udp -m addrtype –dst-type MULTICAST -m udp –dport 5404:5405 -j RETURN

-A PVEFW-HOST-OUT -j RETURN

-A PVEFW-HOST-OUT -m comment –comment «PVESIG:QsChcuYcJnndg75DtA9rW7rfS9M»

-A PVEFW-INPUT -j PVEFW-HOST-IN

-A PVEFW-INPUT -m comment –comment «PVESIG:+5iMmLaxKXynOB/+5xibfx7WhFk»

-A PVEFW-OUTPUT -j PVEFW-HOST-OUT

-A PVEFW-OUTPUT -m comment –comment «PVESIG:LjHoZeSSiWAG3+2ZAyL/xuEehd0»

-A PVEFW-Reject -p tcp -m tcp –dport 43 -j PVEFW-reject

-A PVEFW-Reject -j PVEFW-DropBroadcast

-A PVEFW-Reject -p icmp -m icmp –icmp-type 3/4 -j ACCEPT

-A PVEFW-Reject -p icmp -m icmp –icmp-type 11 -j ACCEPT

-A PVEFW-Reject -m conntrack –ctstate INVALID -j DROP

-A PVEFW-Reject -p udp -m multiport –dports 135,445 -j PVEFW-reject

-A PVEFW-Reject -p udp -m udp –dport 137:139 -j PVEFW-reject

-A PVEFW-Reject -p udp -m udp –sport 137 –dport 1024:65535 -j PVEFW-reject

-A PVEFW-Reject -p tcp -m multiport –dports 135,139,445 -j PVEFW-reject

-A PVEFW-Reject -p udp -m udp –dport 1900 -j DROP

-A PVEFW-Reject -p tcp -m tcp ! –tcp-flags FIN,SYN,RST,ACK SYN -j DROP

-A PVEFW-Reject -p udp -m udp –sport 53 -j DROP

-A PVEFW-Reject -m comment –comment «PVESIG:3gYHaSHlZx5luiKyM0oCsTVaXi4»

-A PVEFW-SET-ACCEPT-MARK -j MARK –set-xmark 0x1/0xffffffff

-A PVEFW-SET-ACCEPT-MARK -m comment –comment «PVESIG:+w0L1XZmxcTeIy7fBeEAzPUQMiY»

-A PVEFW-logflags -j NFLOG –nflog-prefix  «:0:7:PVEFW-logflags: DROP: «

-A PVEFW-logflags -j DROP

-A PVEFW-logflags -m comment –comment «PVESIG:M6AZ5liyPd5yBMzJkVe2pC3g4C8»

-A PVEFW-reject -m addrtype –dst-type BROADCAST -j DROP

-A PVEFW-reject -s 224.0.0.0/4 -j DROP

-A PVEFW-reject -p icmp -j DROP

-A PVEFW-reject -p tcp -j REJECT –reject-with tcp-reset

-A PVEFW-reject -p udp -j REJECT –reject-with icmp-port-unreachable

-A PVEFW-reject -p icmp -j REJECT –reject-with icmp-host-unreachable

-A PVEFW-reject -j REJECT –reject-with icmp-host-prohibited

-A PVEFW-reject -m comment –comment «PVESIG:KM/fOv4KvGn8XvMqxoiRCdvlji8»

-A PVEFW-smurflog -j NFLOG –nflog-prefix  «:0:7:PVEFW-smurflog: DROP: «

-A PVEFW-smurflog -j DROP

-A PVEFW-smurflog -m comment –comment «PVESIG:d9YbmH6rFEMMIfhSj79mnIalVtg»

-A PVEFW-smurfs -s 0.0.0.0/32 -j RETURN

-A PVEFW-smurfs -m addrtype –src-type BROADCAST -g PVEFW-smurflog

-A PVEFW-smurfs -s 224.0.0.0/4 -g PVEFW-smurflog

-A PVEFW-smurfs -m comment –comment «PVESIG:HssVe5QCBXd5mc9kC88749+7fag»

-A PVEFW-tcpflags -p tcp -m tcp –tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -g PVEFW-logflags

-A PVEFW-tcpflags -p tcp -m tcp –tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -g PVEFW-logflags

-A PVEFW-tcpflags -p tcp -m tcp –tcp-flags SYN,RST SYN,RST -g PVEFW-logflags

-A PVEFW-tcpflags -p tcp -m tcp –tcp-flags FIN,SYN FIN,SYN -g PVEFW-logflags

-A PVEFW-tcpflags -p tcp -m tcp –sport 0 –tcp-flags FIN,SYN,RST,ACK SYN -g PVEFW-logflags

-A PVEFW-tcpflags -m comment –comment «PVESIG:CMFojwNPqllyqD67NeI5m+bP5mo»

COMMIT

# Completed on Wed Nov 18 15:41:41 2015

De todo el código mostrado anteriormente, solamente hay que modificar 4 líneas (las que están en negritas y cursiva).

Modificando en el lugar específico:

• Modificación de las líneas en el código anterior referentes al acceso a la Gestión de Proxmox VE

Como se dijo anteriormente, se definió un IPSet en la WebGUI llamado equipos_gestion_servidores, donde su ID en la lista de los conjuntos de direcciones IP en el sistema es PVEFW-65C38B02.

Entonces, el truco consiste en lo siguiente:

– Crear una copia del archivo anterior con el nombre /root/iptables.rules.pve-firewall-modified

– Abrirlo con un editor y sustituir las ocurrencias de la cadena de caracteres «PVEFW-0-management-v4» por «PVEFW-65C38B02» (que también se puede usar el comando sed con los parámetros requeridos, así no habría necesidad del uso de un editor de textos) y luego guardar los cambios

Las líneas referenciadas quedarían así:

(…)

-A PVEFW-HOST-IN -p tcp -m set –match-set PVEFW-65C38B02 src -m tcp –dport 8006 -j RETURN

-A PVEFW-HOST-IN -p tcp -m set –match-set PVEFW-65C38B02 src -m tcp –dport 5900:5999 -j RETURN

-A PVEFW-HOST-IN -p tcp -m set –match-set PVEFW-65C38B02 src -m tcp –dport 3128 -j RETURN

-A PVEFW-HOST-IN -p tcp -m set –match-set PVEFW-65C38B02 src -m tcp –dport 22 -j RETURN

(…)

– Proporcionale este nuevo archivo a Iptables mediante el comando:

# iptables-restore < /root/iptables.rules.pve-firewall-modified

Así los cambios quedarán guardados en el iptables.

NOTA: Para hacer esto más eficiente, yo aconsejo crear un script donde se haga todas las modificaciones descritas anteriormente y cada vez que se haga alguna modificación en el módulo PVE-Firewall o se reinicie el servicio pve-firewall, se ejecute dicho script tras la operación.

Y hasta aquí este pequeño viaje que hice al centro del Cortafuegos de Proxmox. Claro está que puede encontrarse una mejor solución al problema del acceso permitido por defecto a la gestión de Proxmox VE a toda la subred donde está ubicado. Yo solamente encontré una alternativa diferente a la que me sugirieron.

🙂