Checklist de endurecimiento de KVM
22 controles establecidos para proteger un host KVM / QEMU / libvirt, con progreso por sección y exportación a Markdown.
Abrir la herramienta →La herramienta interactiva se abre en inglés.
Un checklist interactivo de 22 controles establecidos para proteger un host KVM/QEMU/libvirt, agrupados en 7 áreas: SO del host y confinamiento, QEMU y modelo de dispositivos, CPU y canales laterales, memoria, aislamiento de red, control de acceso, y parcheo y monitoreo. Todos los controles son reales y están ampliamente documentados: confinamiento sVirt/SELinux o AppArmor, QEMU sin root y por VM, el sandbox seccomp (-sandbox on), un modelo de dispositivos mínimo (sin disquetera → VENOM), máquinas q35/microvm, mitigaciones de canales laterales de la CPU, desactivar KSM en hosts multiinquilino, aislamiento de red por inquilino, libvirt y /dev/kvm con mínimo privilegio, y cadencia de parcheo y auditoría. La superficie de ataque real de invitado a host es el código de emulación de dispositivos de QEMU y el kernel compartido del host, no el pequeño módulo KVM, así que la mayoría de los controles reducen o aíslan esa superficie. Cada elemento explica por qué importa y da una pista concreta de comando o configuración. Todo se ejecuta en tu navegador, el progreso se guarda en local y puedes exportarlo en Markdown. Es una ayuda educativa, no una auditoría ni una certificación. Es una herramienta Pro.
- Recorre cada una de las 7 secciones y marca los controles que ya tienes implantados.
- Lee por qué importa cada control y la pista de comando o configuración (p. ej., seccomp_sandbox = 1, kvm-intel.nested=0, systemctl disable ksm).
- Sigue el progreso por sección y en total.
- Copia o exporta el checklist en Markdown y confirma los comandos con la documentación de tu distribución antes de aplicarlos en producción.
Preguntas frecuentes
¿Cuál es el control de endurecimiento de KVM más importante?
El confinamiento del proceso de la VM con control de acceso obligatorio, sVirt (SELinux) o AppArmor, es la capa de contención más importante. Etiqueta cada proceso QEMU y sus imágenes de disco para que incluso un QEMU totalmente comprometido solo pueda tocar sus propios recursos, no otras VM ni el host. libvirt lo habilita por defecto; mantén SELinux en modo enforcing y confirma security_driver en qemu.conf. Después, los controles de más valor son ejecutar QEMU sin root con un uid por VM, habilitar el sandbox seccomp y eliminar los dispositivos emulados que no se usan.
¿Por qué importa eliminar la disquetera virtual (y otros dispositivos)?
Cada dispositivo emulado es código C en QEMU que analiza entradas controladas por el invitado, y ahí es donde se han encontrado la mayoría de los escapes de invitado a host. El ejemplo canónico es VENOM (CVE-2015-3456): un desbordamiento de búfer en el controlador de disquetera virtual de QEMU que era alcanzable incluso cuando no había ninguna disquetera configurada para el invitado. Como ese código venía en todos los VMM que integraban QEMU, un solo fallo del modelo de dispositivos afectó a la vez a KVM, Xen y otros. Reducir la lista de hardware del invitado al mínimo que necesita la carga (sin disquetera, sin controladores heredados sin uso, prefiriendo virtio y un modelo de máquina q35 o microvm) elimina superficie de ataque directamente.
¿Qué mitigaciones de kernel del host y de CPU debería tener un host KVM?
Mantén activadas las mitigaciones microarquitectónicas del kernel (no arranques con mitigations=off), porque clases de canales laterales como L1TF/Foreshadow (CVE-2018-3646), MDS y la familia Spectre/Meltdown pueden filtrar datos entre VM en hardware compartido. En hosts con inquilinos que no confían entre sí, desactiva también SMT (hyper-threading) o usa core scheduling para que dos inquilinos nunca compartan un núcleo físico, desactiva la virtualización anidada si los invitados no la necesitan (kvm-intel.nested=0 / kvm-amd.nested=0) y mantén actualizado el microcódigo de la CPU. Revisa /sys/devices/system/cpu/vulnerabilities/* para ver el estado actual del host.
¿Debería desactivar KSM en un host KVM?
Desactiva Kernel Same-page Merging (KSM) cuando el host ejecute inquilinos que no confían entre sí. KSM deduplica páginas de memoria idénticas entre VM para ahorrar RAM, pero ese compartir crea un canal lateral de tiempos medible que puede revelar si otro inquilino tiene datos concretos. Desactívalo con systemctl disable --now ksm ksmtuned (o echo 0 > /sys/kernel/mm/ksm/run). Es razonable mantener KSM activado solo dentro de un único dominio de confianza en el que la filtración entre VM no preocupe.
¿Es gratis?
No, es una herramienta Pro. Con una cuenta gratuita tienes 3 usos de prueba; después necesitas Pro.