92 es la mitad de 99

Parte 4 de las mejores prácticas de Proxmox – Seguridad: Protección de los sistemas frente a diversas amenazas

Actualizaciones del sistema y gestión de parches: La Fundación de Seguridad

Por qué las actualizaciones son tan críticas

El software obsoleto es una de las puertas de enlace más comunes para los atacantes. Cada día se descubren y publican nuevas vulnerabilidades: un sistema sin parches es como una casa con puertas y ventanas abiertas. Además, Proxmox es una plataforma de virtualización compleja que tiene acceso directo a los recursos de hardware. Un hipervisor comprometido con éxito significa que los atacantes pueden obtener acceso completo a todas las máquinas virtuales y contenedores que se ejecutan en él. Este peor de los casos debe evitarse a toda costa.

Los mayores riesgos de los sistemas sin parches son las vulnerabilidades de ejecución remota de código (RCE), los ataques de escalada de privilegios o incluso los marcos de explotación conocidos como Metasploit, que buscan automáticamente sistemas vulnerables. Se vuelve especialmente crítico cuando los exploits de día cero se hacen públicos: los administradores a menudo solo tienen horas o días antes de que comiencen los ataques automatizados.

Configuración del repositorio: Estabilidad vs. puntualidad

Elegir el repositorio correcto es un conflicto clásico entre seguridad y estabilidad. Proxmox ofrece diferentes opciones de repositorio, cada una con diferentes pros y contras.

Enterprise Repository – The gold standard for production environments:

El Enterprise Repository pasa por un proceso de garantía de calidad de varias etapas. Las actualizaciones se prueban primero internamente, luego se validan en entornos controlados y solo se publican después de extensas pruebas. Esto minimiza el riesgo de que las propias actualizaciones provoquen fallos en el sistema, un escenario que puede ser devastador en entornos de producción críticos.

La principal desventaja, por supuesto, no es el factor de costo, sino el retraso en la disponibilidad de las actualizaciones de seguridad. En casos extremos, los parches críticos pueden tardar semanas en estar disponibles. Sin embargo, para las organizaciones con estrictos requisitos de cumplimiento o sistemas de producción críticos, este retraso también puede ser una compensación aceptable para una estabilidad adicional.

#v8 # Habilitar Enterprise Repository cat > /etc/apt/sources.list.d/pve-enterprise.list << 'EOF' deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise EOF

#v9 #Archivo #/etc/apt/sources.list.d/pve-enterprise.sources Tipos: deb URIs: https://enterprise.proxmox.com/debian/pve Suites: Componentes de trixie: pve-empresa Firmado por: /usr/share/keyrings/proxmox-archive-keyring.gpg

Repositorio sin suscripción: el acto de ponderación entre coste y riesgo:

El repositorio gratuito recibe actualizaciones más rápido, pero estas pasan por pruebas menos rigurosas. Aquí es donde pueden producirse los denominados «errores de regresión»: actualizaciones que dañan las funcionalidades existentes o introducen nuevas vulnerabilidades de seguridad. Para entornos homelab o sistemas de prueba, esto suele ser aceptable, ya que la falla no es crítica para el negocio.

Un riesgo particular radica en el hecho de que el repositorio sin suscripción a veces incluye características experimentales. Estos pueden conducir a fallas de seguridad o inestabilidades inesperadas. Los administradores deben prestar especial atención aquí y validar primero las actualizaciones en entornos de prueba. Sin embargo, una compensación que vale la pena, especialmente con las brechas de ZeroDay. Por esta razón, el repositorio sin sub está definitivamente disponible más rápido cuando está en llamas.

v8 # Habilitar Repositorio sin suscripción cat > /etc/apt/sources.list.d/pve-no-subscription.list << 'EOF' deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription EOF # Repositorios predeterminados de Debian para actualizaciones de seguridad cat > /etc/apt/sources.list << 'EOF' deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware deb http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware deb http://deb.debian.org/debian bookworm-updates main contrib non-free non-free non-free-firmware EOF

v9 # Habilitar tipos de repositorio sin suscripción: URI deb deb-src: http://deb.debian.org/debian/ Suites: trixie trixie-updates Componentes: Firmado principal no-libre-firmware-Por: /usr/share/keyrings/debian-archive-keyring.gpg Tipos: URI deb deb-src: http://security.debian.org/debian-security/ Suites: Componentes de seguridad trixie: Firmado principal no-libre-firmware-Por: /usr/share/keyrings/debian-archive-keyring.gpg

Actualizaciones de seguridad automáticas: Comodidad vs. control

Las actualizaciones automáticas son una espada de doble filo. Por un lado, reducen significativamente la ventana para los ataques: la mayoría de los compromisos exitosos del sistema se basan en vulnerabilidades para las que ya se disponía de parches. Por otro lado, las actualizaciones automáticas pueden provocar interrupciones no planificadas si una actualización es incompatible con las configuraciones existentes.

El mayor riesgo de las actualizaciones automáticas radica en la falta de control sobre el tiempo. Una actualización podría bloquear una aplicación importante durante el horario comercial crítico. Esto es particularmente problemático para las actualizaciones del kernel que requieren un reinicio o para las actualizaciones de servicios críticos como Proxmox Cluster Stack.

Por lo tanto, la configuración presentada aquí también adopta un enfoque bastante conservador: Solo las actualizaciones de seguridad se instalan automáticamente y los reinicios automáticos están deshabilitados. Esto proporciona un buen compromiso entre la seguridad y el control.

# Instalar y configurar actualizaciones desatendidas apt update && apt install -y desatendidas-upgrades apt-listchanges # Crear configuración detallada cat > /etc/apt/apt.conf.d/50unattended-upgrades << 'EOF' // Actualizaciones automáticas solo para parches de seguridad Unttended-Upgrade::Origins-Pattern { "origin=Debian,codename=${distro_codename},label=Debian-Security"; «origin=Proxmox,nombre en clave=${distro_codename}"; }; // Reiniciar servicios importantes del sistema después de actualizaciones Actualización desatendida::Reinicio automático "falso"; Actualización desatendida::Automatic-Reboot-WithUsers "false"; Actualización desatendida::Eliminar paquetes de kernel no utilizados "true"; Actualización desatendida::Eliminar las dependencias no utilizadas "verdaderas"; // Actualización desatendida de notificaciones y registro::Mail "admin@example.com"; Actualización desatendida::MailReport "on-change"; Actualización desatendida::AutoFixInterruptedDpkg "true"; Actualización desatendida::MinimalSteps "verdadero"; // Depuración en caso de problemas Actualización desatendida::Depurar "falso"; EOF # habilitar actualizaciones automáticas cat > /etc/apt/apt.conf.d/20auto-upgrades << 'EOF' APT::Periodic::Update-Package-Lists "1"; APT::Periódico::Actualización desatendida "1"; APT::Periódico::AutocleanInterval "7"; EOF # Iniciar y activar service systemctl enable --now sin supervisión-upgrades

Consideraciones importantes para las actualizaciones automáticas:

Las notificaciones por correo electrónico son esenciales: los administradores deben ser notificados de las actualizaciones instaladas para poder responder rápidamente a los problemas. La opción MailReport "en el cambio" garantiza que los correos electrónicos se envíen solo en caso de cambios reales, lo que reduce el spam.

Eliminación automática de los bultos no utilizados (Eliminar dependencias no utilizadas "verdadero") reduce la superficie de ataque, pero en casos raros puede conducir a problemas inesperados si las dependencias se detectan incorrectamente. ¡Asegúrate de vigilarlo!

Configuración del firewall: Defensa en Profundidad

El concepto de defensa multicapa

Una sola capa de firewall ya no es suficiente en los entornos de TI modernos. El principio de defensa en profundidad requiere múltiples capas de seguridad que se complementan y aseguran entre sí. En Proxmox, tenemos tres capas de firewall naturales: Centro de datos (en todo el clúster), nodo (específico del host) y VM/contenedor (específico del huésped).

La ventaja de este enfoque radica en la redundancia: Incluso si una capa está comprometida o mal configurada, las otras capas aún proporcionan protección. Al mismo tiempo, permite un control granular: diferentes máquinas virtuales pueden tener diferentes políticas de seguridad sin comprometer la seguridad en todo el clúster.

Cortafuegos a nivel de centro de datos: La pared protectora exterior

El firewall del centro de datos actúa como la primera línea de defensa y define las políticas de seguridad básicas para todo el clúster. Aquí aplicamos el principio de denegación por defecto: Todo está bloqueado de forma predeterminada, solo se permite el tráfico explícitamente permitido.

Ataques que se previenen:

  • Escaneo de puertos por atacantes externos
  • Acceso no autorizado a interfaces de gestión
  • Movimiento lateral entre racimos
  • Exfiltración de datos a través de puertos inusuales

Posibles desventajas: La política restrictiva estándar puede causar problemas de conectividad al agregar nuevos servicios. Los administradores deben crear deliberadamente nuevas reglas, que pueden llevar mucho tiempo al principio. En caso de configuración incorrecta, los administradores pueden bloquearse, por lo que los cambios en el firewall siempre deben realizarse utilizando una segunda ruta de acceso (por ejemplo, IPMI / iLO). 

# Habilitar el firewall del centro de datos a través de CLI pvesh set /cluster/firewall/options --enable 1 # Establecer la política predeterminada (Arrastrar por defecto, permitir explícitamente) pvesh set /cluster/firewall/options --policy_in DROP pvesh set /cluster/firewall/options --policy_out ACEPTAR # pvesh create /cluster/firewall/rules --pos 0 --action ACCEPT --type in --proto tcp --dport 22 --comment "SSH Management" pvesh create /cluster/firewall/rules --pos 1 --action ACCEPT --type in --proto tcp --dport 8006 --comment "Proxmox Web Interface" # VNC/SPICE para consolas de VM (opcional, solo si es necesario) pvesh create /cluster/firewall/rules --pos 2 --action ACCEPT --type in --proto tcp --dport 5900:5999 --comment "VNC Console Access" # Comunicación de clúster (solo entre nodos conocidos) pvesh create /cluster/firewall/rules --pos 3 --action ACCEPT --source 192.168.1.0/24 --type in --proto tcp --dport 22000:22050 --comment "Comunicación de clúster" # ICMP for Network Solución de problemas pvesh create /cluster/firewall/rules --pos 4 --action ACCEPT --type in --proto icmp --comment "ICMP Ping"

Consideraciones especiales sobre la regla VNC: El acceso VNC (puertos 5900-5999) permite el acceso de la consola a las máquinas virtuales, pero también es un riesgo potencial para la seguridad. El tráfico VNC no está cifrado de forma predeterminada y se puede tocar. En entornos de producción, VNC solo debe usarse a través de VPN o con cifrado TLS adicional.

Cortafuegos a nivel de nodo: Seguridad especializada

Cada nodo Proxmox puede tener funciones específicas: nodo de almacenamiento, nodo de cómputo, nodo de copia de seguridad, etc. El firewall a nivel de nodo permite que estas funciones se reflejen en las políticas de seguridad.

Beneficios de seguridad:

  • Aislamiento de servicios específicos de nodos
  • Control granular sobre el acceso al almacenamiento
  • Mejor contención al comprometer los nodos individuales

Riesgos de complejidad: A medida que aumenta el número de nodos, la administración del firewall se vuelve compleja. Las reglas inconsistentes entre los nodos pueden conducir a problemas de red que son difíciles de diagnosticar. La documentación central y los procesos de implementación automatizados se vuelven esenciales.

# Habilitar el conjunto de pvesh de firewall específico para nodos /nodos/$(nombre del host)/firewall/opciones --enable 1 # Reglas específicas de nodos (ejemplo para servidores de copia de seguridad) pvesh create /nodes/$(hostname)/firewall/rules --action ACCEPT --type in --proto tcp --dport 8007 --comment "Proxmox Backup Server" # Acceso al almacenamiento (NFS, iSCSI, etc.) pvesh crear /nodos/$(hostname)/firewall/rules --action ACCEPT --source 192.168.1.0/24 --type in --proto tcp --dport 2049 --comment "NFS Storage"

Cortafuegos a nivel de máquina virtual: Microsegmentación

El cortafuegos a nivel de máquina virtual implementa la microsegmentación: cada máquina virtual se trata como una zona de seguridad independiente. Esto es especialmente importante en entornos con múltiples inquilinos o en el aislamiento de aplicaciones críticas.

Protección contra el movimiento lateral: Cuando un atacante compromete una máquina virtual, el firewall a nivel de máquina virtual evita la propagación automática a otros sistemas. Este es uno de los mecanismos de protección más efectivos contra los ataques modernos de APT (Amenazas Persistentes Avanzadas).

Consideraciones de rendimiento: Cada regla de firewall causa carga adicional de CPU. En entornos con muchas máquinas virtuales y conjuntos de control complejos, esto puede afectar el rendimiento. El motor de firewall de Proxmox está optimizado, pero con cientos de máquinas virtuales cada una con docenas de reglas, esto se puede sentir.

# Habilitar firewall de VM (para ID de VM 100) qm set 100 --firewall 1 # Reglas del servidor web pvesh crear /nodos/$(hostname)/qemu/100/firewall/rules --action ACCEPT --type in --proto tcp --dport 80 --comment "HTTP" pvesh create /nodes/$(hostname)/qemu/100/firewall/rules --action ACCEPT --type in --proto tcp --dport 443 --comment "HTTPS" pvesh create /nodes/$(hostname)/qemu/100/firewall/rules --action DROP --type in --comment "Denegar todo el resto del tráfico"

Autenticación avanzada: Más que contraseñas

El problema con la autenticación basada en contraseña

Las contraseñas por sí solas son completamente inadecuadas en el panorama actual de amenazas. La mayoría de las infracciones exitosas comienzan con credenciales comprometidas, ya sea a través de phishing, relleno de credenciales o ataques de fuerza bruta. Con un sistema como Proxmox que permite el acceso administrativo completo a la infraestructura crítica, el impacto de una cuenta comprometida es devastador.

Los atacantes modernos utilizan técnicas sofisticadas: Utilizan listas de miles de millones de contraseñas previamente filtradas (relleno de credenciales), implementan ataques impulsados por IA y tienen acceso a hardware especializado para ataques de fuerza bruta. Lamentablemente, una contraseña única —incluso compleja— no puede hacer frente a estas amenazas, al menos a largo plazo.

Autenticación multifactorial: El cambio de juego

La autenticación multifactor (MFA) es una de las medidas de seguridad más efectivas disponibles. Incluso si una contraseña está comprometida, un atacante no puede acceder sin el segundo factor. Proxmox VE es compatible con TOTP (contraseñas de una sola vez basadas en el tiempo) que funcionan con aplicaciones como Google Authenticator, Authy o andUOTP.

Beneficios de seguridad:

  • Protección de 99.9% Todos los ataques automatizados
  • Advertencia de compromiso (intentos fallidos de ayuda macrofinanciera)
  • Cumplimiento de la normativa (muchas normas exigen una ayuda macrofinanciera)

Retos operativos: MFA puede reducir la usabilidad y complicar los procesos de configuración inicial. Si se pierde el dispositivo MFA, los usuarios pueden bloquearse. Los códigos de emergencia o métodos alternativos de autenticación son esenciales, pero una vez más aumentan la complejidad.

# Habilitar 2FA para los usuarios (a través de la interfaz web o CLI) # Centro de datos → Autenticación → Dos factores # Ejemplo: Configurar TOTP para usuarios pvesh create /access/tfa --userid admin@pam --type totp --description "Admin TOTP Token"

Gestión central de usuarios: LDAP y Active Directory

En las organizaciones más grandes, la gestión descentralizada de usuarios es un riesgo de seguridad. Los empleados cambian de roles, abandonan la empresa o necesitan acceso temporal: todos estos cambios deben reflejarse en todos los sistemas de manera oportuna. La administración central de usuarios resuelve este problema con el inicio de sesión único (SSO) y el control central de derechos.

Beneficios de seguridad:

  • Bloqueo inmediato de los cambios de personal
  • Políticas uniformes de contraseñas
  • Auditoría central y cumplimiento
  • Reducción del número de cuentas a gestionar

Riesgos de aplicación: La administración central de usuarios crea un único punto de falla. Si el servidor LDAP/AD falla, los usuarios ya no podrán iniciar sesión. La partición de red entre Proxmox y el servidor de autenticación causa los mismos problemas. Por lo tanto, una cuenta de emergencia local con autenticación fuerte es esencial. Algunos de ustedes pueden conocerlo como una "Cuenta Oh-Shit" cuyo token / contraseña / tarjeta inteligente está en una caja fuerte. ??

# Integración LDAP vía CLI pvesh create /access/domains --realm company.local --type ldap \ --server ldap.company.local --port 636 --secure 1 \ --base-dn "dc=company,dc=local" \ --user-attr sAMAccountName \ --bind-dn "cn=proxmox,ou=service-accounts,dc=company,dc=local" # Alternativamente: Integración de Active Directory pvesh create /access/domains --realm company.local --type ad \ --server ad.company.local --port 636 --secure 1 \ --domain company.local

Control de acceso basado en funciones: El principio del permiso mínimo

El principio del mínimo privilegio es fundamental para asegurar los sistemas. Los usuarios solo deben tener los derechos que necesitan para sus tareas, ni más ni menos. En Proxmox, el sistema basado en roles permite un control muy granular sobre los permisos.

Definiciones típicas de roles:

  • Operador de VM: Puede iniciar / detener / administrar máquinas virtuales, pero no crear otras nuevas
  • Administrador de almacenamiento: Acceso completo a la configuración de almacenamiento, pero sin derechos de VM
  • Usuario del monitor: Acceso de solo lectura para el monitoreo y la presentación de informes
  • Operador de copia de seguridad: Puede crear y restaurar copias de seguridad

Gestión de la complejidad: A medida que aumenta el tamaño de la organización, la gestión de roles se vuelve compleja. Las dependencias de rol a rol, los permisos temporales y el cambio de roles de trabajo requieren revisiones periódicas. La documentación clara y los procesos de aprovisionamiento automatizados son esenciales.

# Crear un rol personalizado para los operadores de VM pvesh crear /access/roles --roleid VMOperator \ --privs "VM.Allocate,VM.Config.Disk,VM.Config.Memory,VM.Console,VM.PowerMgmt,VM.Monitor" # Función restringida para monitorizar pvesh create /access/roles --roleid Monitor \ --privs "Sys.Audit,VM.Audit,Datastore.Audit" # Asignación de rol de usuario con restricción de ruta pvesh create /access/acl --path /vms/100 --users operator@company.local --roles VMOperator pvesh create /access/acl --path /nodes/proxmox1 --users monitoring@company.local --roles Monitor

Endurecimiento de SSH: El talón de Aquiles de muchos sistemas

Por qué SSH es el objetivo principal

SSH (Secure Shell) está habilitado de forma predeterminada en la mayoría de los sistemas Linux y proporciona acceso directo al shell con permiso de root. Para los atacantes, por lo tanto, es el objetivo más atractivo: El acceso SSH comprometido con éxito a menudo significa un control completo del sistema.

La mayoría de los ataques SSH ocurren a través de:

  • Ataques de fuerza bruta contra contraseñas débiles
  • Relleno de credenciales con bases de datos de contraseñas filtradas
  • Explotación de vulnerabilidades SSH conocidas
  • Ataques Man-in-the-middle en conexiones no cifradas
  • Ingeniería Social para Obtener Claves SSH

Las estadísticas muestran la realidad: Los servicios SSH desprotegidos son atacados a los pocos minutos de estar en línea. Las botnets automatizadas escanean continuamente Internet en busca de puertos SSH abiertos e inmediatamente lanzan ataques con los nombres de usuario y contraseñas más comunes.

Configuración integral de seguridad SSH

La configuración predeterminada de SSH está optimizada para la compatibilidad, no para la seguridad. Una configuración endurecida elimina la mayoría de los vectores de ataque, pero requiere una planificación cuidadosa para evitar bloquear a los administradores.

Las medidas críticas de seguridad explican:

Prohibición de inicio de sesión raíz: El inicio de sesión root directo es un riesgo de seguridad masivo. Los atacantes conocen el nombre de usuario raíz y solo necesitan descifrar la contraseña. Con PermitRootLogin no Los atacantes deben conocer un nombre de usuario y una contraseña válidos y luego realizar una escalada de privilegios.

Autenticación de clave pública: Las claves SSH son criptográficamente mucho más fuertes que las contraseñas. Una clave RSA de 2048 bits es aproximadamente equivalente a una contraseña de 256 caracteres. Las llaves no pueden ser agrietadas por la fuerza bruta, pero son vulnerables al robo cuando se almacenan de manera insegura.

Limitaciones del algoritmo: Los algoritmos SSH más antiguos tienen vulnerabilidades conocidas. La configuración se limita a algoritmos modernos y seguros como Curve25519 y ChaCha20-Poly1305.

# Copia de seguridad de la configuración original cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup # Crear configuración segura de SSH cat > /etc/ssh/sshd_config << 'EOF' # Protocolo y cifrado Protocolo 2 Puerto 22 #Puerto 2222 # Alternativa: Utilice un puerto no estándar # HostKeys (solo algoritmos seguros) HostKey /etc/ssh/ssh_host_ed25519_key HostKey /etc/ssh/ssh_host_rsa_key # Ajustes criptográficos KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group16-sha512 Cifras chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,ac-sha2-256,hmac-sha2122-5126-etm@openssh.com # Autenticación PermitRootLogin no PubkeyAuthentication yes PasswordAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication no UsePAM yes # Configuración de teclas autorizadas PubkeyAcceptedKeyTypes ssh-ed25519,rsa-sha2-256,rsa-sha2-512 AuthorizedKeysFile .ssh/authorized_keys # Gestión de sesiones MaxAuthTries 3 MaxStartups 3:30:10 LoginGraceTime 60 ClientAliveInterval 300 ClientAliveCountMax 2 MaxSessions 2 # PermitirUsuarios admin@192.168.1.0/24 operador@192.168.1.0/24 # AllowGroups ssh-users # Registro y monitoreo SyslogFacility AUTH LogLevel VERBOSE # Características de seguridad StrictModes yes IgnoreRhosts yes HostbasedAuthentication no PermitUserEnvironment no AllowAgentForwarding no AllowTcpForwarding no X11Forwarding no PrintMotd no TCPKeepAlive no Compression no EOF # Prueba de configuración de SSH sshd -t && systemctl reload sshd

Consideraciones importantes para el curado SSH:

Cambio de puerto: Cambiar el puerto SSH de 22 a un puerto no estándar reduce significativamente los ataques automatizados. Sin embargo, es seguridad por oscuridad y no proporciona protección contra ataques dirigidos. Los escáneres de puertos encuentran puertos alternativos rápidamente.

Ajustes de tiempo de espera: ClienteAliveInterval 300 y ClienteAliveCountMax 2 Cierre las conexiones inactivas después de 10 minutos. Esto evita que los atacantes secuestren conexiones a largo plazo, pero puede ser perjudicial para los administradores con tareas de mantenimiento largas.

Restricciones de reenvío: PermitirTcpReenvío no y AllowAgentReenvío no evitar que SSH se utilice indebidamente como túnel para otros servicios. Sin embargo, esto puede obstaculizar las tareas administrativas deseadas, como las conexiones seguras de bases de datos a través de túneles SSH.

Autenticación SSH basada en tokens: El estándar de oro

El método más seguro para el acceso SSH es el uso exclusivo de claves SSH (tokens) combinadas con la desactivación completa de la autenticación de contraseña. Este método elimina prácticamente todos los ataques de fuerza bruta y proporciona una seguridad significativamente mayor que incluso las contraseñas más fuertes.

Por qué la autenticación de token es superior:

Las claves SSH se basan en criptografía asimétrica con longitudes de clave de 2048-4096 bits (RSA) o algoritmos modernos de curva elíptica como Ed25519. Una clave RSA de 2048 bits equivale aproximadamente a una contraseña de 617 dígitos, una complejidad que es prácticamente imposible de descifrar con fuerza bruta. Las teclas Ed25519 son aún más seguras y mucho más potentes.

Ataques que se previenen:

  • Relleno de credenciales: Las bases de datos de contraseñas filtradas no valen nada
  • Phishing: Las llaves SSH no pueden ser capturadas por la ingeniería social
  • Registrador de teclas: El malware en los sistemas cliente no puede registrar claves
  • Fuerza bruta: Matemáticamente imposible con la longitud correcta de la clave
  • Ataques de mesa Rainbow: Los ataques pre-computados no funcionan contra llaves

Consideraciones de seguridad operativa:

La mayor desventaja de la autenticación de tokens es la administración de claves. Si un administrador pierde su clave privada, queda bloqueado permanentemente. Al mismo tiempo, la clave privada debe mantenerse absolutamente segura: una clave comprometida proporciona acceso completo inmediato.

La mejor práctica es el uso de módulos de seguridad de hardware (HSM) o al menos claves privadas protegidas con contraseña. YubiKeys o tokens de hardware similares proporcionan seguridad adicional ya que la clave privada nunca sale del dispositivo.

# Generación segura de claves SSH (en el sistema cliente) # Ed25519 - curva moderna y segura ssh-keygen -t ed25519 -C "admin@company.com" -f ~/.ssh/proxmox_ed25519 # Alternativamente: RSA con 4096 bits (para sistemas más antiguos) ssh-keygen -t rsa -b 4096 -C "admin@company.com" -f ~/.ssh/proxmox_rsa # Proteja la clave con una contraseña fuerte (recomendada) ssh-keygen -t ed25519 -C "admin@company.com" -f ~/.ssh/proxmox_ed25519 -N "$(openssl rand -base64 32)» # Transferir clave pública al servidor Proxmox ssh-copy-id -i ~/.ssh/proxmox_ed25519.pub admin@proxmox-server.local # Alternativamente: Cargar manualmente la clave pública cat ~/.ssh/proxmox_ed25519.pub ?? ssh admin@proxmox-server.local "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys && chmod 700 ~/.ssh"

Estrategias avanzadas de gestión de claves:

Para entornos de producción, las claves SSH deben gestionarse de forma centralizada. Esto permite un bloqueo rápido de las claves comprometidas y simplifica los procesos de rotación.

# Administración central de claves con opciones authorised_keys cat > /home/admin/.ssh/authorized_keys << 'EOF' # Clave de administrador de emergencia - solo desde la red de administración desde="192.168.100.0/24", no-port-forwarding, no-X11-forwarding ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILx... emergency-admin@company.com # Clave de administrador estándar - temporal desde="192.168.1.0/24",no-port-forwarding,command="/usr/local/bin/admin-shell" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAbc... admin@company.com # Tecla de Monitoreo - solo comandos específicos de="192.168.1.100",no-pty,no-port-forwarding,command="/usr/bin/monitoring-script" ssh-rsa AAAAB3NzaC1yc2EAAAA... monitoring@company.com EOF chmod 600 /home/admin/.ssh/authorized_keys

Se explican las opciones de authorised_keys:

  • from="IP/Red": Limita el uso de claves a IPs de origen específicas
  • comando="comando": Ejecuta solo el comando especificado, ignora las solicitudes del cliente
  • no-port-forwarding: Previene el túnel SSH
  • no-pty: Previene las sesiones de terminal interactivas
  • no-X11-transmisión: Deshabilita el reenvío X11

Control de acceso SSH basado en red: Defensa en Profundidad

Incluso con una configuración SSH perfecta, tiene sentido restringir el acceso a nivel de red. Esto proporciona una capa adicional de seguridad y reduce significativamente la superficie de ataque.

Restricciones geográficas:

Si los administradores solo acceden desde países o regiones específicos, se pueden implementar bloques geográficos de IP. Esto detiene la mayoría de los ataques automatizados, ya que a menudo provienen de ciertos países.

Ventajas de la segmentación de la red:

  • Superficie de ataque reducida: SSH solo está disponible para redes autorizadas
  • Detección temprana: Los accesos desde redes no autorizadas son inmediatamente sospechosos
  • Cumplimiento: Muchos frameworks requieren segmentación de red
  • Rendimiento: Menos intentos de conexión reducen la carga de la CPU

Desventajas y desafíos:

  • Movilidad: El trabajo remoto se hace más difícil
  • Emergencias: El acceso desde redes inesperadas puede ser bloqueado
  • IP dinámicas: Los cambios en el ISP pueden bloquear a los administradores
  • Esfuerzo de mantenimiento: Es necesario mantener las listas de PI
# 1. Restricción SSH basada en firewall (iptables/nftables) # Solo la red de administración permite iptables -A INPUT -p tcp --dport 22 -s 192.168.100.0/24 -j ACCEPT iptables -A INPUT -p tcp --dport 22 -s 10.0.0.0/8 -j ACCEPT # Administrador específico IPs iptables -A INPUT -p tcp --dport 22 -s 203.0.113.10 -j ACEPTAR # Admin Home Office iptables -A INPUT -p tcp --dport 22 -s 198.51.100.50 -j ACEPTAR # Administrador de copia de seguridad # Rechazar todas las demás conexiones SSH iptables -A INPUT -p tcp --dport 22 -j DROP # 2. Integración de Proxmox Firewall # Acerca de la interfaz web: Nodo → Firewall → Añadir regla # O a través de CLI: pvesh crear /nodos/$(hostname)/firewall/rules --type in --action ACCEPT \ --proto tcp --dport 22 --source 192.168.100.0/24 --comment "Management SSH" pvesh create /nodes/$(hostname)/firewall/rules --type in --action ACCEPT \ --proto tcp --dport 22 --source 203.0.113.10 --comment "Admin Home Office" pvesh create /nodes/$(hostname)/firewall/rules --type in --action DROP \ --proto tcp --dport 22 --comment "Bloquear todos los demás SSH"

Acceso SSH basado en VPN: La solución de seguridad definitiva

Para una máxima seguridad, SSH solo debe ser accesible a través de conexiones VPN. Esto combina los beneficios de la segmentación de la red con un fuerte cifrado y autenticación.

Ventajas de la arquitectura VPN SSH:

  • Doble cifrado: VPN + SSH ofrecen cifrado redundante
  • Autenticación central: El servidor VPN puede forzar MFA
  • Pista de auditoría: Todos los accesos se realizan a través de una puerta de enlace VPN controlada
  • Desconexión de emergencia: La conexión VPN se puede desconectar de forma centralizada

Opciones de aplicación:

# 1. Solución basada en OpenVPN # Permitir SSH solo a través de iptables de interfaz VPN -A INPUT -p tcp --dport 22 -i tun0 -j ACEPTAR # Interfaz VPN iptables -A INPUT -p tcp --dport 22 -i lo -j ACEPTAR # Loopback iptables -A INPUT -p tcp --dport 22 -j DROP # Todos los demás # 2. Solución basada en WireGuard (alternativa moderna) # Solo los pares de WireGuard permiten iptables SSH -A INPUT -p tcp --dport 22 -s 10.0.0.0/24 -j ACEPTAR # WireGuard net iptables -A INPUT -p tcp --dport 22 -j DROP # 3. Solución basada en IPSec (Enterprise) # SSH solo a través de iptables de túnel IPSec -A INPUT -p tcp --dport 22 -m policy --dir in --pol ipsec -j ACCEPT iptables -A INPUT -p tcp --dport 22 -j DROP

Restricciones geográficas de la PI: Integración de GeoIP

Para las organizaciones con ubicaciones geográficas claramente definidas, se pueden implementar restricciones basadas en GeoIP. Esto bloquea automáticamente el acceso desde países inesperados.

Implementación con GeoIP:

# Instalar bases de datos GeoIP apt install -y geoip-database-contrib xtables-addons-common # Los módulos GeoIP cargan modprobe xt_geoip # Permitir solo ciertos países (códigos ISO) iptables -A INPUT -p tcp --dport 22 -m geoip --src-cc DE,AT,CH -j ACEPTAR # Región DACH iptables -A INPUT -p tcp --dport 22 -m geoip ! --src-cc DE,AT,CH -j DROP # Bloquear el resto # Registro de países bloqueados iptables -A INPUT -p tcp --dport 22 -m geoip ! --src-cc DE,AT,CH -j LOG --log-prefijo "SSH-GeoBlock: "

Control de acceso dinámico SSH: Derribo de puertos

El derribo de puertos se puede implementar para entornos particularmente críticos para la seguridad. SSH está bloqueado por defecto y solo se abre después de una secuencia específica de paquetes de red.

Ventajas de golpeo de puerto:

  • Modo sigiloso: El puerto SSH es invisible para los escaneos de puertos
  • Autenticación adicional: La secuencia de Knock actúa como pre-autenticación
  • Tiempos de espera automáticos: El acceso se cierra de nuevo después de un tiempo definido

Desventajas:

  • Complejidad: Aumenta significativamente la complejidad administrativa
  • Punto único de falla: El golpeo incorrectamente configurado bloquea a todos
  • Depuración: Los problemas de red son más difíciles de diagnosticar
# knockd Instalación y configuración apt install -y knockd # knockd Configuration cat > /etc/knockd.conf << 'EOF' [opciones] Secuencia de UseSyslog [openSSH] = 7000,8000,9000 seq_timeout = 5 comando = /sbin/iptables -A INPUT -s %PI% -p tcp --dport 22 -j ACEPTAR tcpflags = syn [closeSSH] secuencia = 9000,8000,7000 seq_timeout = 5 comando = /sbin/iptables -D INPUT -s %PI% -p tcp --dport 22 -j ACEPTAR tcpflags = syn EOF # Activar el servicio systemctl enable --now knockd # Uso del lado del cliente knock proxmox-server.local 7000 8000 9000 # Abre SSH ssh admin@proxmox-server.local # Conexión SSH knock proxmox-server.local 9000 8000 7000 # Cerrar SSH

Monitoreo y alerta de sesiones de SSH

Además de las restricciones de acceso, todas las sesiones de SSH deben ser monitoreadas y reportadas actividades sospechosas.

# Extender el registro de sesiones de SSH cat >> /etc/ssh/sshd_config << 'EOF' # Registro detallado LogLevel VERBOSE SyslogFacility AUTH # Grabación de sesiones (si está permitido legalmente) ForceCommand /usr/local/bin/ssh-session-logger EOF # Guión del registrador de sesiones (ejemplo) cat > /usr/local/bin/ssh-session-logger << 'EOF' #!/bin/bash SESSION_ID=$(fecha +%Y%m%d_%H%M%S)_$ LOG_DIR="/var/log/ssh-sessions" mkdir -p "$LOG_DIR» # Registro de información de sesión echo "$(fecha): Inicio de sesión de SSH - Usuario: $USUARIO, Desde: $SSH_CLIENT, TTY: $SSH_TTY" >> "$LOG_DIR/sesión_$SESSION_ID.log» # Iniciar shell original (con grabación opcional) si [ -n "$SSH_ORIGINAL_COMMAND" ]; entonces ejecutivo $SSH_ORIGINAL_COMMAND de otro modo ejecutivo $SHELL fi EOF chmod +x /usr/local/bin/ssh-session-logger

Estas medidas de seguridad SSH avanzadas proporcionan defensa de múltiples capas contra varios vectores de ataque. La combinación de autenticación de tokens, segmentación de red y monitoreo crea una arquitectura de seguridad robusta que es notablemente resistente incluso a ataques sofisticados.

Detección de intrusión: Reconociendo al Enemigo

Fail2Ban: el gorila automático

Fail2Ban es un sistema de prevención de intrusiones que monitorea los archivos de registro en tiempo real y bloquea automáticamente las direcciones IP en caso de actividad sospechosa. Es particularmente eficaz contra los ataques de fuerza bruta, ya que bloquea a los atacantes después de algunos intentos fallidos.

Funcionalidad y beneficios: Fail2Ban analiza archivos de registro con expresiones regulares (Regex) y detecta patrones de ataque. Para SSH, estos son intentos de inicio de sesión fallidos, para Proxmox Web-Interface Authentication-Failures. Los atacantes detectados se bloquean durante un tiempo configurable, lo que detiene la mayoría de los ataques automatizados.

Limitaciones y desventajas: Fail2Ban es reactivo: el primer intento de ataque siempre tiene éxito. Por ejemplo, los atacantes también utilizan ataques distribuidos desde muchas direcciones IP, manteniéndolos por debajo de los umbrales de detección. Y no olvidemos: Fail2Ban también puede bloquear a los usuarios legítimos si ingresan contraseñas incorrectas varias veces.

# Fail2Ban install apt update && apt install -y fail2ban # Crear configuración específica de Proxmox cat > /etc/fail2ban/jail.local << 'EOF' [DEFAULT] # Ajustes básicos bantime = 3600 findtime = 600 maxretry = 3 backend = systemd ignoreip = 127.0.0.1/8 192.168.1.0/24 # Notificaciones por correo electrónico destemail = admin@example.com nombre del remitente = Fail2Ban mta = acción sendmail = %(action_mwl)s # Protección SSH [sshd] habilitada = modo verdadero = puerto agresivo = ruta de registro ssh = %(sshd_log)s banaction = iptables-multiport maxretry = 2 findtime = 3600 bantime = 86400 # Proxmox Web Interface Protection [proxmox] habilitado = puerto verdadero = https,http,8006 filtro = backend proxmox = systemd maxretry = 3 findtime = 3600 bantime = 3600 EOF # Crear filtro Proxmox cat > /etc/fail2ban/filter.d/proxmox.conf << 'EOF' [Definición] failregex = pvedaemon\[.*fallo de autenticación; rhost=<HOST> user=.* msg=.* ignoreregex = EOF # Fail2Ban iniciar y activar systemctl enable --now fail2ban # Comprobar el estado fail2ban-client

Las optimizaciones de configuración explican:

Estrategia de Bantime: Un confinamiento de una hora (bantime = 3600) es suficiente para la mayoría de los ataques automatizados. Las cerraduras más largas pueden volverse problemáticas si los usuarios legítimos se bloquean accidentalmente. SSH utiliza un bloqueo de 24 horas, ya que los ataques SSH suelen ser más específicos.

Política de escalada: La configuración utiliza bloqueos progresivos: los ataques SSH dan lugar a bloqueos más largos que los ataques de interfaz web, ya que SSH permite el acceso directo al sistema y, por lo tanto, es más crítico.

Gestión de la lista blanca: El ignoreip-La configuración evita que se bloqueen las direcciones IP internas. Esto es importante para las redes administrativas, pero también puede ser explotado por atacantes que ya están en la red interna.

Monitorización del sistema con auditado: El científico forense digital

Auditd (Linux Audit Daemon) es el subsistema oficial de Linux para la auditoría de seguridad. Registra llamadas al sistema, accesos a archivos, ejecuciones de procesos y otros eventos relacionados con la seguridad a nivel de kernel. Estos registros son esenciales para el análisis forense, la detección de cumplimiento y la detección avanzada de amenazas persistentes (APT).

Por qué auditado es especialmente importante en Proxmox: Proxmox administra la infraestructura crítica: máquinas virtuales, almacenamiento, configuraciones de red. Un hipervisor comprometido puede afectar a docenas o cientos de sistemas invitados. Auditado ayuda a detectar actividad sospechosa antes de que pueda propagarse.

Aspectos de cumplimiento: Muchos marcos de cumplimiento (PCI-DSS, HIPAA, SOX) requieren registros de auditoría detallados. Auditado puede cumplir con estos requisitos, pero también genera cantidades significativas de datos. Atención: Un sistema típico puede producir registros de auditoría gigabyte por gigabyte diariamente.

Impacto en el rendimiento: Auditado funciona a nivel de kernel y puede afectar el rendimiento del sistema. Especialmente las cargas de trabajo intensivas en E/S pueden volverse notablemente más lentas. La configuración presentada aquí se centra en eventos críticos para la seguridad con el fin de minimizar el impacto en el rendimiento.

# Instalación Auditado apt install -y auditado audispd-plugins # Crear reglas de auditoría para Proxmox cat > /etc/audit/rules.d/proxmox.rules << 'EOF' # Monitorización de archivos de configuración de Proxmox -w /etc/pve/ -p wa -k proxmox-config -w /etc/systemd/system/pve*.service -p wa -k proxmox-services # Monitorear las operaciones de VM/contenedor -w /usr/bin/qm -p x -k vm-management -w /usr/bin/pct -p x -k container-management # Monitorizar comandos privilegiados -a always,exit -F arch=b64 -S execve -F euid=0 -k root-commands -a always,exit -F arch=b32 -S execve -F euid=0 -k root-commands # Monitorizar la configuración de la red -w /etc/network/interfaces -p wa -k network-config -a always,exit -F arch=b64 -S socket -F success=1 -k network-socket EOF # Systemctl habilitar --ahora auditado augenrules --load

Normas de auditoría detalladas:

Monitoreo de archivos (-w): Estas reglas monitorean los cambios en los archivos de configuración críticos. /etc/pve/ contiene toda la configuración del clúster, /etc/red/interfaces la configuración de la red. Cada cambio se registra, incluido el proceso de activación y el usuario.

Monitorización de llamadas al sistema (-a siempre, salida): Estas reglas monitorean llamadas específicas al sistema. execve se solicita en cada ejecución del programa: seguimiento de las ejecuciones raíz (euid=0) Ayuda a detectar ataques de escalada de privilegios.

Desafíos de la gestión de registros: Los registros de auditoría crecen rápidamente y pueden agotar el espacio de almacenamiento. La rotación automática y el archivado son esenciales. Al mismo tiempo, los registros deben protegerse de la manipulación: una cuenta de administrador comprometida podría intentar desdibujar sus pistas.

Certificados TLS/SSL: Confianza en un mundo poco confiable

El problema con los certificados autofirmados

Proxmox crea automáticamente certificados TLS autofirmados para la interfaz web y la comunicación del clúster durante la instalación. Aunque proporcionan cifrado, no proporcionan autenticación: los usuarios no pueden verificar que realmente se están comunicando con el servidor Proxmox real.

Riesgos para la seguridad de los certificados autofirmados:

  • Ataques Man-in-the-middle: Los atacantes pueden crear certificados falsos y hacerse pasar por servidores Proxmox
  • Fijación de certificado imposible: Los clientes no pueden distinguir con seguridad entre certificados reales y falsos
  • Comportamiento del usuario: Las advertencias constantes del navegador hacen que los usuarios ignoren las advertencias de seguridad

Cuestiones de cumplimiento: Muchas políticas de seguridad y marcos de cumplimiento prohíben los certificados autofirmados en entornos de producción. PCI-DSS, por ejemplo, requiere explícitamente certificados de confianza para todos los servicios de acceso público.

Implementación de certificados de confianza

Hay varias opciones para los servicios internos: Autoridad de certificación propia (CA), Let’s Encrypt para servicios de acceso público o certificados comerciales para una máxima compatibilidad.

Vamos a cifrar la integración: Let’s Encrypt ofrece certificados gratuitos y renovados automáticamente. Proxmox tiene soporte ACME incorporado que automatiza todo el proceso. La desventaja: Let’s Encrypt requiere una resolución DNS pública o una accesibilidad HTTP, lo que no siempre es posible ni deseable.

CA propia para los servicios internos: Una autoridad de certificación independiente proporciona un control completo y también funciona en redes aisladas. Sin embargo, los certificados raíz de CA deben instalarse en todos los sistemas cliente, lo que se vuelve complejo en entornos grandes.

# Vamos a cifrar el certificado para la interfaz web de Proxmox # Primero configure el complemento ACME (a través de la interfaz web: Centro de datos → ACME) # Alternativamente: Incluye tu propio certificado de CA # 1. Copiar certificado y clave para /etc/ssl/certs/ # 2. Acerca de la interfaz web: Nodo → Certificados → Subir certificado personalizado # Configuración de TLS para pveproxy harden cat >> /etc/default/pveproxy << 'EOF' # Ajustes de seguridad TLS CIPHER_SUITE="ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256" PROTOCOLO="TLSv1.2,TLSv1.3" EOF systemctl restart pveproxy

El endurecimiento de la configuración de TLS explica:

Limitación de Cipher Suite: La configuración se limita a algoritmos de cifrado modernos y seguros. Se sabe que los cifrados más antiguos, como los algoritmos basados en RC4, 3DES o MD5, son débiles y están excluidos.

Restricción del protocolo: TLS 1.0 y 1.1 tienen vulnerabilidades conocidas y ya no deben usarse. Limitar a TLS 1.2 y 1.3 elimina estos riesgos, pero puede causar problemas de compatibilidad con clientes muy antiguos.

Seguridad de copia de seguridad: Protección contra lo peor

Por qué el cifrado de copia de seguridad es esencial

Las copias de seguridad contienen todos los datos sensibles del sistema original: contraseñas, configuraciones, datos de usuario, secretos comerciales. Las copias de seguridad no cifradas son un riesgo de seguridad masivo, especialmente cuando se almacenan en medios externos o almacenamiento en la nube.

Vectores de ataque en las copias de seguridad:

  • Robo físico: Los medios de copia de seguridad robados permiten ataques fuera de línea
  • Violaciones de la nube: Las cuentas de almacenamiento en la nube comprometidas exponen todas las copias de seguridad
  • Amenazas internas: Los administradores con acceso de copia de seguridad pueden extraer datos confidenciales
  • Ransomware: Las variantes modernas de ransomware destruyen específicamente las copias de seguridad antes del cifrado

Requisitos de cumplimiento: El RGPD exige explícitamente la protección de los datos personales también en las copias de seguridad. Las copias de seguridad no cifradas pueden resultar en multas significativas. Requisitos similares se pueden encontrar en HIPAA, PCI-DSS y otros marcos.

Estrategias de copia de seguridad cifradas

Proxmox ofrece cifrado de copia de seguridad integrado con AES-256. La implementación se lleva a cabo a nivel de trabajo de respaldo y es transparente para los sistemas invitados.

Principales retos de gestión: La clave de cifrado de copia de seguridad es el único punto de falla para todas las copias de seguridad. Si pierde la clave, todas las copias de seguridad son inútiles. Al mismo tiempo, la clave debe almacenarse de forma tan segura que los atacantes no puedan obtenerla. Se recomienda un módulo de seguridad de hardware (HSM) o un servicio de administración de claves (KMS) para entornos críticos.

# Crear clave de cifrado de copia de seguridad pvesm set <storage-id> --encryption-key /etc/pve/backup-encryption.key # Configurar copias de seguridad cifradas automáticas cat > /etc/cron.d/proxmox-backup << 'EOF' # Copias de seguridad de VM cifradas diariamente a las 2:00 am 0 2 * * root /usr/bin/vzdump --all --compress zstd --encrypt 1 --storage backup-storage EOF

Almacenamiento de copia de seguridad inmutable: Protección contra ransomware

Las copias de seguridad inmutables ya no se pueden modificar ni eliminar después de haber sido creadas. Esta es la protección más efectiva contra los ataques de ransomware, ya que incluso un administrador totalmente comprometido no puede destruir las copias de seguridad.

Opciones de aplicación:

  • Servidor de copia de seguridad de Proxmox: Proporciona características nativas de inmutabilidad
  • Almacenamiento de objetos: Almacenamiento compatible con S3 con Object Lock
  • Medios de comunicación WORM: Write-Once-Read-Muchas soluciones de hardware
  • Sistemas con gas de aire: Sistemas de copia de seguridad físicamente separados

Consideraciones de política de retención: Las copias de seguridad inmutables requieren una planificación cuidadosa de los tiempos de retención. Los tiempos de retención demasiado cortos ofrecen poca protección, demasiado largos causan altos costos de almacenamiento. La regla de copia de seguridad 3-2-1 (3 copias, 2 medios diferentes, 1 fuera del sitio) siempre debe seguirse.

# Configuración de Proxmox Backup Server con políticas de retención # (Acerca de la interfaz web de PBS: Almacenamiento de datos → Prune & GC) # Ejemplo de política de retención cat > /etc/proxmox-backup/prune-jobs.json < 'EOF' { "keep-diily": 7, "semanal": 4, "mensual": 6, "seguimiento anual": 1 } EOF

Auditorías de cumplimiento y seguridad: Mide lo que importa

Auditorías de seguridad automatizadas con Herramientas como Lynis

Los controles de seguridad manuales consumen mucho tiempo y son propensos a errores. Herramientas automatizadas Al igual que Lynis, pueden revisar sistemáticamente cientos de aspectos de seguridad e identificar vulnerabilidades que las personas pasarían por alto.

Lo que hace Lynis: Lynis realiza más de 300 pruebas de seguridad diferentes, desde parámetros del kernel hasta permisos de archivos y configuraciones de red. No solo detecta vulnerabilidades conocidas, sino también errores de configuración y violaciones de mejores prácticas.

Limitaciones de las auditorías automatizadas: Las herramientas automatizadas solo pueden detectar problemas conocidos. No entienden el contexto de la aplicación y, por lo tanto, pueden generar falsos positivos. Una regla de cortafuegos criticada por Lynis como «demasiado permisiva» podría ser correcta para el caso de uso específico.

# Lynis instalar apt instalar -y lynis # Análisis de seguridad completo del sistema de auditoría de lynis --cronjob --logfile /var/log/lynis.log # Analizar resultados grep "Sugerencia" /var/log/lynis.log

Integración en tuberías de CI/CD: Lynis se puede integrar en tuberías de implementación automatizadas. Las nuevas implementaciones del sistema se analizan automáticamente en busca de problemas de seguridad antes de que entren en producción. Esto permite la «seguridad desde el diseño» en lugar del endurecimiento posterior.

Aplicación de los índices de referencia de la CEI: Siga los estándares de la industria

El Centro de Seguridad de Internet (CIS) publica puntos de referencia de seguridad detallados para todos los sistemas operativos y aplicaciones comunes. Estos puntos de referencia se basan en el consenso de expertos en ciberseguridad y reflejan las mejores prácticas.

Por qué son importantes los índices de referencia de la CEI:

  • Protección jurídica: Muchas compañías de seguros cibernéticos exigen el cumplimiento de CIS
  • Marcos de cumplimiento: NIST, ISO 27001 y otros se refieren a los puntos de referencia de CIS
  • Enfoque sistemático: Más de 100 puntos de control específicos para sistemas Linux
  • Basado en el riesgo: Cada control se clasifica según el riesgo y el impacto

Desafíos de aplicación: El cumplimiento completo de CIS puede hacer que los sistemas sean inutilizables. Muchos controles son demasiado restrictivos para casos de uso específicos. Un enfoque pragmático selecciona los controles más importantes y documenta las excepciones deliberadas. Esto puede verse así:

# Parámetros del núcleo compatibles con CIS cat >> /etc/sysctl.d/99-cis-hardening.conf << 'EOF' # Seguridad de la red net.ipv4.ip_forward = 1 net.ipv4.conf.all.send_redirects = 0 net.ipv4.confault.default.send_redirects = 0 net.ipv4.conf.all.accept_source_route = 0 net.ipv4.confault.accept_redirects = 0 net.ipv4.conf.all.accept_source_route = 0 net.ipv4.confault.default.accept_source_route = 0 net.ipv4.conf.all.log_martians = 1 net.ipv4.icmp_echo_ignore_broadcasts = 1 net.ipv4.icmp_ignore_bogus_error_responses = 1 net.ipv4.confall.rpfilter = 1 net.v4.conf.confall_casts net.v= 1 net.v4.c.c.send_send_redirects = 1 net.ipv4.c.pookies= 1pookies. # IPv6 Seguridad (si está habilitado) net.ipv6.conf.all.accept_redirects = 0 net.ipv6.conf.default.accept_redirects = 0 net.ipv6.conf.all.accept_source_route = 0 net.ipv6.conf.default.accept_source_route = 0 EOF sysctl -p /etc/sysctl.d/99-cis-hardening.conf

Parámetros del núcleo en detalle:

Reenvío de IP: Proxmox debe net.ipv4.ip_forward = 1 Manténgase activo porque la funcionalidad del puente lo requiere. Las configuraciones CIS predeterminadas deshabilitarían esto.

Redirecciones de ICMP: Deshabilitar las redirecciones ICMP evita ciertos ataques de enrutamiento, pero puede causar problemas de conectividad en topologías de red complejas.

Filtrado de ruta inversa: rp_filter = 1 Permite pruebas estrictas de ruta inversa y evita ataques de suplantación de IP. Sin embargo, esto puede causar problemas con el enrutamiento asimétrico.

Seguimiento y respuesta a incidentes: Saber lo que está pasando

Estrategias centrales de explotación forestal

Millones de entradas de registro se crean todos los días en entornos de TI modernos. Sin agregación central y análisis inteligente, es imposible detectar eventos relevantes para la seguridad. Por lo tanto, una estrategia de registro bien pensada es fundamental para una seguridad efectiva.

Agregación de registros con Syslog: Syslog es el valor predeterminado para los sistemas Unix/Linux, pero la configuración predeterminada no está optimizada para el monitoreo de seguridad. Los eventos importantes pueden caer en la avalancha de mensajes de depuración. Una categorización estructurada de acuerdo con la gravedad y la facilidad es esencial.

Integración SIEM: Los sistemas de gestión de eventos e información de seguridad (SIEM) pueden correlacionar datos de registro y detectar anomalías. Sin embargo, son complejos de configurar y requieren procesos de sintonización continua para reducir los falsos positivos.

# Configurar Rsyslog para el reenvío central de registros cat >> /etc/rsyslog.conf << 'EOF' # Registro remoto para eventos de seguridad *.info;mail.none;authpriv.none;cron.none @@syslog-server.company.local:514 authpriv.* @@syslog-server.company.local:514 EOF systemctl restart rsyslog

Protección de datos y retención de registros: Los registros pueden contener datos personales y, por lo tanto, están sujetos a las regulaciones GDPR / GDPR. Una política de retención clara y estrategias de anonimización son legalmente requeridas. Al mismo tiempo, los registros deben permanecer disponibles para el análisis forense, un acto de equilibrio difícil. Probablemente podríamos crear varios artículos propios.

Monitoreo basado en métricas usando el ejemplo de Prometheus

Mientras que los registros documentan eventos, las métricas proporcionan información continua sobre el estado y el rendimiento del sistema. Las anomalías en las métricas pueden ser indicadores tempranos de problemas de seguridad. Como ejemplo, me gusta tomar una carga inusual de CPU aquí, esto podría indicar criptominería. Un tráfico de red anormal, por otro lado, indicaría la exfiltración de datos.

Ventajas de la arquitectura Prometheus:

  • Basado en el tirón: Prometheus consulta activamente las métricas, que son más robustas que los modelos push
  • Serie temporal: Los datos históricos permiten el análisis de tendencias y la creación de líneas de base
  • Alerta flexible: Reglas de alerta complejas basadas en múltiples métricas posibles

Desafíos de escala: Prometheus almacena todos los datos localmente, causando problemas de almacenamiento en entornos grandes. Las configuraciones federadas o las soluciones de almacenamiento remoto se vuelven complejas. Consultar grandes períodos de tiempo puede llegar a ser muy intensivo en recursos.

# Instalar exportador de nodos para métricas del sistema apt install -y prometheus-node-exporter # Exportar métricas específicas de Proxmox cat > /etc/systemd/system/pve-exporter.service << 'EOF' [Unit] Descripción=Proxmox VE Exporter After=network.target [Service] Tipo=simple ExecStart=/usr/bin/pve-exporter Restart=always User=prometheus [Install] WantedBy=multi-user.target EOF

Plan de Mantenimiento y Seguridad Operacional

El Ritmo de la Seguridad

Ya sabes, lo diré de nuevo: La seguridad no es un proyecto puntual, sino un proceso continuo. Sin mantenimiento y actualizaciones regulares, incluso el mejor concepto de seguridad degenera. ¡Su plan de mantenimiento estructurado garantiza que todos los aspectos se revisen regularmente!

Tareas diarias de seguridad: Estas tareas deben automatizarse o llevarse a cabo como parte de la rutina diaria. Sirven para la detección temprana de problemas antes de que se vuelvan críticos.

  • Revisión de Fail2Ban-Logs: Los patrones de ataque inusuales pueden indicar ataques dirigidos
  • Estado de la copia de seguridad: Las copias de seguridad fallidas son un riesgo de seguridad crítico
  • Seguimiento de los recursos: Las anomalías pueden indicar compromisos

Profundización semanal: Las tareas semanales requieren más tiempo y atención, pero proporcionan información más profunda sobre el estado de seguridad.

  • Análisis del registro de auditoría: Identificar tendencias y anomalías en el comportamiento del usuario
  • Revisión de la actualización de seguridad: Evaluar las actualizaciones disponibles y planificar la implementación
  • Pruebas de integridad de la copia de seguridad: Realice una prueba de recuperación aleatoria

Revisiones estratégicas mensuales: Estas tareas a menudo requieren la colaboración entre equipos y pueden dar lugar a cambios importantes.

  • Pruebas de penetración: Pruebas de seguridad externas o internas
  • Revisiones de reglas de firewall: Identificar reglas obsoletas o demasiado permisivas
  • Supervisión del certificado: Renovar los certificados caducados a tiempo
  • Opiniones de acceso de los usuarios: Verificación de permisos de usuario

Análisis trimestrales de profundidad: Estas revisiones exhaustivas aseguran que la estrategia de seguridad siga el ritmo de las amenazas cambiantes y las necesidades comerciales.

  • Pruebas de recuperación en caso de catástrofe: Juega a través de escenarios completos de DR
  • Actualizaciones de respuesta a incidentes: Integrar las lecciones aprendidas de los incidentes
  • Formación en sensibilización en materia de seguridad: Informar a los empleados sobre las nuevas amenazas
  • Revisiones de control de acceso basadas en roles: Adaptar las definiciones de roles a los cambios organizacionales

Gestión del Cambio y Documentación

Cualquier cambio de seguridad debe ser documentado y comprensible. Los cambios indocumentados constituyen un riesgo importante: pueden revertirse accidentalmente o dar lugar a confusión cuando se producen cambios de personal.

Documentación de las mejores prácticas:

  • Justificación: ¿Por qué se hizo el cambio?
  • Evaluación de impacto: ¿Qué sistemas se ven afectados?
  • Plan de reversión: ¿Cómo se puede revertir el cambio?
  • Resultados de la prueba: ¿Cómo se validó el cambio?

Principio de los Cuatro Ojos: Los cambios críticos para la seguridad siempre deben ser validados por un segundo administrador. Esto reduce los errores y también le proporciona seguridad adicional, por ejemplo, contra amenazas internas.

Resumen: Entornos Proxmox seguros en la práctica

Las medidas de seguridad presentadas aquí forman un sistema integral de defensa en profundidad. Ninguna acción es perfecta, pero cuando se combinan, proporcionan una protección robusta contra la mayoría de las amenazas.

Estrategia de aplicación: Implemente estas medidas gradualmente, comenzando con las más básicas (actualizaciones, firewall, endurecimiento SSH) y luego trabaje hasta sistemas más complejos (monitoreo, cumplimiento). No olvides: Pruebe cada cambio a fondo primero en un entorno de puesta en escena / laboratorio.

Equilibrio entre seguridad y usabilidad: Las medidas de seguridad excesivas pueden hacer que los sistemas sean inutilizables y hacer que los usuarios eludan los controles de seguridad. Encuentre el equilibrio adecuado para su entorno y el panorama de amenazas correspondiente.

Mejora continua: El panorama de amenazas está en constante evolución. Lo que es seguro hoy puede ser vulnerable mañana. Manténgase informado sobre las nuevas amenazas y tecnologías de seguridad y ajuste su estrategia en consecuencia.

Nota importante sobre la aplicación: Todas las configuraciones presentadas aquí deben adaptarse a su entorno específico. Asegúrese de probar a fondo cada cambio antes de usarlo en producción. Siempre mantenga copias de seguridad actualizadas de su configuración y documente cuidadosamente cualquier cambio.

Y sí, probablemente me estoy repitiendo por decimotercera vez: La seguridad de la infraestructura Proxmox también es un maratón, no un sprint. Con las prácticas presentadas aquí y un enfoque disciplinado, puede construir y operar una plataforma de virtualización robusta y segura.

Las partes restantes de esta serie de artículos que también he vinculado aquí de nuevo para usted: Parte 1: red | Parte 2: almacenamiento | Parte 3: respaldo | Parte 4: seguridad | Parte 5: rendimiento

Stephan
|
| | | | | |
a la cima | página de inicio | para buscar