El firewall nativo de Proxmox VE permite filtrar tráfico en distintos niveles: todo el Datacenter, un nodo específico o una máquina virtual/contendor. La protección no consiste en bloquear por bloquear; consiste en permitir solo las comunicaciones necesarias y conservar evidencia de lo que se decidió.
1. Qué es el firewall de Proxmox VE
El firewall integrado se apoya en reglas del sistema —la infografía menciona nftables— para filtrar tráfico de red. Puede controlar conexiones entrantes y salientes y aplicar políticas en diferentes ámbitos. La regla por defecto de tipo DROP bloquea lo que no haya sido permitido explícitamente, pero solo debe activarse cuando ya existe una lista de accesos necesarios.
El firewall de Proxmox es una capa de control. No reemplaza el firewall perimetral, la segmentación, el endurecimiento del sistema operativo ni la seguridad de las aplicaciones.
2. Los tres niveles de aplicación
| Nivel | Alcance | Ejemplo de decisión |
|---|---|---|
| Datacenter | Política común del clúster | Permitir administración desde la red de gestión |
| Node | Un host Proxmox concreto | Restringir servicios propios de ese nodo |
| VM / CT | Una máquina o contenedor | Permitir HTTPS a una aplicación y bloquear el resto |
Las reglas se combinan según el nivel y la configuración. Por eso conviene documentar el objetivo de cada regla y evitar duplicar permisos sin necesidad.
3. Tráfico de entrada y salida
Las reglas IN controlan lo que intenta entrar al ámbito protegido; las reglas OUT controlan lo que sale. Un servidor web puede necesitar entrada TCP 443, pero también salida DNS, NTP o actualizaciones. Permitir una dirección no implica automáticamente permitir la respuesta de cualquier otro servicio.
4. Preparar el entorno sin perder acceso
- Accede a la interfaz web y confirma conectividad de red.
- Realiza backup de la configuración antes de activar políticas restrictivas.
- Conserva acceso físico o consola fuera de banda para recuperar el control.
- Identifica IPs, redes de gestión, clúster, almacenamiento y servicios necesarios.
- Prueba primero en una VM de laboratorio o en una ventana autorizada.
La red de administración debe estar explícitamente permitida antes de cambiar la política por defecto. El acceso por SSH, HTTPS, DNS, NTP, clúster y almacenamiento puede requerir reglas específicas según el diseño.
5. Modelo de diseño de reglas
Una regla bien escrita responde: quién se conecta, desde dónde, hacia qué destino, por qué puerto/protocolo, en qué dirección y con qué vigencia. Evita reglas abiertas como “any-any” salvo una prueba temporal y documentada.
Los grupos IP o aliases permiten reutilizar una lista de administradores, servidores de monitoreo o redes de respaldo sin repetir direcciones en cada regla.
6. Los 12 pasos de la infografía
- Entender el firewall: filtra tráfico mediante reglas y políticas.
- Definir por qué usarlo: proteger nodos, VMs/CTs y servicios.
- Elegir el nivel: Datacenter, Node o VM/CT según el alcance.
- Preparar el entorno: comprueba red, acceso físico/consola y backup de configuración.
- Activar el firewall: habilítalo en el nivel correcto y confirma el estado.
- Configurar reglas IN: permite solo lo necesario, por ejemplo SSH 22, HTTPS 443 o DNS 53 según el caso.
- Configurar reglas OUT: controla actualizaciones, DNS, NTP y demás tráfico de salida.
- Proteger una VM: aplica reglas específicas en VM/CT Firewall.
- Crear grupos IP: reutiliza aliases para simplificar y mantener consistencia.
- Proteger servicios: restringe por origen, protocolo, puerto y necesidad.
- Probar y validar: prueba desde una IP externa y revisa bloqueos y logs.
- Endurecer: conserva DROP por defecto, revisa reglas y monitorea eventos.
7. Servicios y ejemplo de matriz de acceso
La siguiente matriz es ilustrativa; los puertos reales deben confirmarse con la arquitectura desplegada.
| Servicio | Dirección | Origen recomendado | Motivo |
|---|---|---|---|
| Panel HTTPS | IN | Red de administración | Gestionar Proxmox |
| SSH | IN | Salto administrativo | Acceso operativo controlado |
| DNS / NTP | OUT | Servidor o red definida | Resolución y sincronización |
| Aplicación HTTPS | IN | Proxy o usuarios autorizados | Publicar solo el servicio necesario |
8. Ejemplo empresarial: publicación segura de una aplicación
Una empresa aloja una aplicación web en una VM. El panel Proxmox solo debe estar disponible desde la red de administración; los usuarios externos llegan a la aplicación por HTTPS a través de un proxy.
- En Datacenter se permite la administración desde la red interna.
- En Node se restringen servicios propios del host.
- En la VM se permite IN TCP 443 desde el proxy y OUT DNS/NTP hacia resolutores autorizados.
- Se crea un grupo IP para los servidores de monitoreo y se permite únicamente su acceso necesario.
- Se prueba acceso válido, acceso no autorizado, actualización y conectividad del clúster.
El resultado no es solo “la web funciona”: también se confirma que el panel y los servicios de gestión no quedaron expuestos.
9. Ejercicio práctico
Diseña reglas para una VM de pruebas que ofrece HTTPS y necesita actualizaciones:
- Indica qué red puede administrar la VM.
- Define la regla IN de HTTPS y su origen.
- Define las reglas OUT mínimas para DNS, NTP y actualizaciones.
- Explica cómo probarías un acceso permitido y uno bloqueado.
- Describe cómo revertirías la configuración si pierdes conectividad.
10. Buenas prácticas y errores frecuentes
Buenas prácticas
- Aplicar mínimo privilegio y política DROP por defecto cuando esté preparada.
- Usar grupos IP y nombres descriptivos.
- Revisar reglas periódicamente y eliminar excepciones temporales.
- Habilitar logs y correlacionarlos con monitoreo.
- Probar desde redes permitidas y no permitidas.
- Mantener Proxmox VE actualizado y documentar cambios.
Errores frecuentes
- Activar DROP sin permitir primero la administración.
- Aplicar reglas al nivel equivocado.
- Permitir any-any “solo por mientras” y olvidarlo.
- Confundir seguridad del firewall con seguridad de la aplicación.
- No contemplar tráfico de salida y actualizaciones.
- No conservar consola o backup para volver atrás.
Preguntas frecuentes
¿El firewall de Proxmox reemplaza al firewall perimetral?
No. Es una capa adicional para proteger nodos, VMs y contenedores. La arquitectura puede necesitar también firewall perimetral, segmentación, VPN y controles del sistema invitado.
¿Dónde debo crear una regla?
En el nivel que corresponda al alcance: Datacenter para una política común, Node para un host o VM/CT para una carga concreta. Si dudas, documenta la dependencia y prueba primero en laboratorio.
¿Qué significa DROP por defecto?
Que el tráfico no permitido explícitamente se descarta. Es una postura restrictiva que requiere una lista previa de accesos de administración, clúster y servicios.
¿Por qué una VM puede perder Internet después del cambio?
Porque sus reglas OUT no permiten DNS, NTP, actualizaciones o el gateway necesario. Revisa dirección, protocolo, destino, logs y dependencias antes de abrir permisos amplios.
¿Cómo valido que una regla es segura?
Prueba desde una fuente autorizada y otra no autorizada, revisa logs, confirma el servicio esperado y verifica que el resto permanezca bloqueado. Registra fecha, resultado y responsable.
Conclusión
El firewall de Proxmox VE protege cuando las reglas se diseñan desde el flujo real de la infraestructura: niveles claros, entradas y salidas justificadas, grupos reutilizables, pruebas y revisión continua. La seguridad mejora no por tener más reglas, sino por permitir exactamente lo necesario y poder demostrar que funciona.
Continúa con la Temporada 2
Explora los episodios anteriores sobre monitoreo, automatización, PBS y replicación.
Ver temporada →