Mejores prácticas de security y VLAN para Proxmox en un home lab

Problema

En muchos home labs la seguridad se queda en “activar 2FA y listo”. Cuando el número de VMs crece, esa capa mínima deja expuestos puntos críticos: la interfaz de gestión de Proxmox, los servidores de almacenamiento y, sobre todo, los backups. Un atacante que compromete una VM puede saltar a la red de gestión, robar credenciales SSH o cifrar los snapshots si los backups no son inmutables. El patrón recurrente es la falta de segmentación de tráfico y de controles de acceso estrictos, lo que convierte a un entorno doméstico en un objetivo fácil para ransomware o para movimientos laterales dentro de la red.

Causa

1. Red plana – La mayoría de los routers domésticos manejan una única LAN. Todas las máquinas, incluido el host de Proxmox, comparten la misma subred, lo que permite que cualquier VM alcance el puerto 8006 (interfaz web) o el puerto 22 (SSH) sin restricciones.

2. SSH por defecto – Muchos usuarios dejan el puerto 22 abierto, habilitan login con contraseña y permiten root. Eso brinda un vector de fuerza bruta y de escalada de privilegios.

3. Firewall integrado insuficiente – El firewall de Proxmox es útil, pero no sustituye a una política de filtrado basada en VLAN. Sin separación física o lógica, un firewall VM (pfSense, OPNsense) se apaga junto al host y corta todo el tráfico externo.

4. Backups en el mismo segmento – Almacenar snapshots o backups en un NAS accesible desde la misma LAN permite que un ransomware los sobrescriba o los elimine antes de que el operador intervenga.

5. Ausencia de inmutabilidad – Los discos de backup sin WORM (Write‑Once‑Read‑Many) o sin separación de escritura pueden ser modificados por cualquier proceso con permisos de escritura.

Solución

Una arquitectura basada en segmentación VLAN combinada con hardening de SSH y backups inmutables cubre la mayoría de los vectores de ataque.

1. Diseño de VLAN

Una topología de 5 VLAN suele ser suficiente para un home lab con varios servidores y VMs:

Los switches gestionados deben soportar 802.1Q y permitir “tagging” en los puertos del host Proxmox. En el host, se crean interfaces de puente (vmbrX) que llevan cada VLAN a los contenedores/VMs correspondientes. El tráfico entre VLAN se controla con reglas de firewall en el router o en un firewall dedicado (pfSense/OPNsense) que permanezca en una VLAN separada (por ejemplo, 60 – Firewall).

2. Hardening de SSH

• Cambiar puerto: mover SSH a un puerto no estándar (por ejemplo, 2222) reduce ruido de bots.
• Desactivar root: PermitRootLogin no.
• Forzar autenticación con clave: PasswordAuthentication no.
• Limitar usuarios: AllowUsers adminuser.
• Aplicar rate‑limit: usar iptables o nftables para limitar intentos por IP.

3. Firewall VM vs. hardware

Si el host Proxmox no está 24/7, un firewall VM muere con él y corta Internet. La solución más robusta es:

• Firewall físico (router con OpenWrt, EdgeRouter, etc.) que mantenga la conectividad externa.
• Firewall VM como capa adicional en la VLAN 60, con reglas de inspección profunda para tráfico interno. En caso de caída del host, el firewall físico sigue operando.

4. Backups inmutables

• Almacenamiento air‑gapped: montar un disco externo que solo se conecte una vez al mes para copiar snapshots.
• WORM: habilitar la característica “immutable” en ZFS (zfs set readonly=on pool/dataset) o usar S3 con versión y política de retención.
• Rotación fuera de línea: mantener al menos 3 copias en diferentes medios (NAS, disco externo, cloud) y rotar según la regla 3‑2‑1.

5. Políticas de acceso a la interfaz web

• Restricción por IP: permitir solo la subred 10.0.10.0/24 en el puerto 8006.
• HTTPS obligatorio: usar certificados auto‑firmados o Let’s Encrypt (si el host tiene dominio interno).
• Timeout de sesión: configurar session.timeout en /etc/pve/datacenter.cfg.

Cuándo aplicar esta solución

• Síntomas: VMs que pueden “ping” la IP del host Proxmox, usuarios que acceden a la UI desde la red de invitados, backups que desaparecen tras un ataque ransomware.
• Entorno: Más de 3 VMs simultáneas, uso de almacenamiento compartido (NFS, iSCSI) y exposición de servicios al exterior (VPN, web).
• No aplica: Laboratorios temporales con un solo nodo y sin datos críticos; en esos casos la sobrecarga de VLAN puede ser innecesaria.

Código

# 1. Cambiar puerto SSH y desactivar root
sed -i 's/^#Port 22/Port 2222/' /etc/ssh/sshd_config
sed -i 's/^#PermitRootLogin prohibit-password/PermitRootLogin no/' /etc/ssh/sshd_config
sed -i 's/^#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
echo "AllowUsers adminuser" >> /etc/ssh/sshd_config
systemctl restart sshd

# 2. Crear bridges para VLAN en /etc/network/interfaces
cat <<EOF >> /etc/network/interfaces

auto vmbr0
iface vmbr0 inet static
    address 10.0.10.1/24
    bridge_ports eth0
    bridge_stp off
    bridge_fd 0
    post-up ip link set vmbr0 up
    post-up ip link set vmbr0 type vlan id 10

auto vmbr1
iface vmbr1 inet static
    address 10.0.20.1/24
    bridge_ports eth0
    bridge_stp off
    bridge_fd 0
    post-up ip link set vmbr1 up
    post-up ip link set vmbr1 type vlan id 20

# Repetir para VLAN 30, 40 y 50 según tabla
EOF
systemctl restart networking

# 3. Regla iptables para limitar intentos SSH (ejemplo)
iptables -A INPUT -p tcp --dport 2222 -m conntrack --ctstate NEW -m recent --set
iptables -A INPUT -p tcp --dport 2222 -m conntrack --ctstate NEW -m recent --update --seconds 60 --hitcount 5 -j DROP

Verificación

1. Aislamiento VLAN

   • Desde una VM en VLAN 30, intenta ping 10.0.10.1. Debería fallar.
   • Desde la VLAN 10, verifica que puedes acceder a https://10.0.10.1:8006.

2. SSH hardening

   • Ejecuta ssh -p 2222 [email protected]. La conexión debe solicitar clave y rechazar login de root.
   • Usa nmap -p 2222 10.0.10.1 para confirmar que solo el puerto 2222 está abierto.

3. Firewall

   • Desconecta el host Proxmox y comprueba que el router sigue proporcionando Internet a los dispositivos en VLAN 30.
   • Reinicia la VM firewall y verifica que el tráfico interno sigue fluyendo.

4. Backup inmutabilidad

   • En el dataset ZFS configurado como readonly, intenta crear un archivo nuevo; el comando debe fallar con “operation not permitted”.
   • Restaura un snapshot desde el disco externo y verifica que la VM vuelve al estado esperado.

Notas adicionales

• Firewall VM en modo HA: si decides usar una VM firewall, considera replicarla en otro nodo Proxmox y habilitar HA para que el failover sea automático.
• Actualizaciones de firmware: los switches gestionados deben recibir firmware reciente para evitar vulnerabilidades en la capa de VLAN tagging.
• Monitorización: una herramienta ligera como Netdata o Zabbix puede alertar sobre tráfico inesperado entre VLAN, lo que suele ser la primera señal de movimiento lateral.
• Documentación interna: mantén un diagrama actualizado de la topología VLAN y de los puertos de bridge en Proxmox; facilita la resolución de incidentes y la incorporación de nuevos dispositivos.