Introducción

Vallumix es un motor modular de endurecimiento para sistemas Linux, escrito en Rust y alineado con los benchmarks del Center for Internet Security (CIS). Automatiza la aplicación de controles de seguridad en servidores, eliminando la inconsistencia del hardening manual y generando reportes de cumplimiento trazables para auditorías.

¿Qué hace Vallumix?

En esencia, Vallumix evalúa la postura de seguridad de un servidor Linux y, cuando se le indica, aplica remediaciones automáticas basadas en el CIS Benchmark. Cada control —desde deshabilitar filesystems innecesarios hasta endurecer la configuración de SSH— se implementa como una unidad independiente, testeable y reversible. El resultado es una herramienta que transforma el hardening de horas de trabajo manual en un proceso de minutos, reproducible y documentado.

Capacidades principales

• 70 controles CIS distribuidos en seis categorías: configuración inicial, servicios, red, logging y auditoría, acceso y autenticación, y mantenimiento del sistema.
• Tres perfiles preconfigurados que adaptan la selección de controles al rol del servidor: web, base de datos o bastión.
• Cinco formatos de reporte: HTML autocontenido, JSON parseable, JUnit XML para pipelines, texto plano con colores, y salida estructurada en JSON Lines para integración con SIEMs.
• Modo dry-run que previsualiza todos los cambios sin modificarlos, ideal para validación previa en producción.
• Rollback granular con respaldos versionados en /var/backups/vallumix, permitiendo revertir un control específico o una sesión completa.
• Binario único estático compilado con musl, sin dependencias de runtime: lo copias, lo ejecutas, funciona.

¿Para quién es?

Vallumix está diseñado para tres perfiles profesionales:

• Administradores de sistemas en PYMEs que necesitan endurecer servidores rápidamente y demostrar cumplimiento ante auditorías ISO 27001 o PCI-DSS sin invertir en herramientas comerciales.
• Ingenieros DevOps y DevSecOps que integran seguridad en pipelines de CI/CD con Terraform, Packer o Ansible, y requieren artefactos parseables y códigos de salida coherentes.
• Consultores de seguridad freelance que auditan clientes con una herramienta portable, de un solo binario, que genera reportes presentables y permite remediación controlada.

¿Es tu primera vez con Vallumix? Ve directamente a la [guía de instalación](installation/README.md) y luego ejecuta `vallumix audit --profile web --report html` para ver cómo funciona sin modificar nada. El modo audit es la forma más segura de familiarizarte con la herramienta.

Por qué Rust

La elección de Rust no es accidental. Una herramienta que se ejecuta como root y modifica archivos de sistema críticos debe ser intrínsecamente segura. Rust garantiza ausencia de errores de memoria en código safe, obliga al manejo explícito de errores mediante Result<T, E>, y permite compilar un binario estático que no depende de versiones de Python, intérpretes de Bash ni paquetes del sistema. Esto diferencia a Vallumix de soluciones basadas en scripts que fallan silenciosamente o rompen dependencias entre distribuciones.

Estado del proyecto

Vallumix es un proyecto de código abierto en evolución activa. La versión 1.0 soporta Debian 12, Ubuntu 22.04/24.04 LTS, RHEL 9 y derivadas (Rocky Linux, AlmaLinux). La documentación está disponible en español e inglés. Si encuentras un problema o tienes una sugerencia, consulta la guía de contribución en el repositorio.

Instalación

Vallumix se distribuye como un binario único sin dependencias de runtime. Puedes instalarlo mediante tres métodos, dependiendo de tu entorno y necesidades.

Métodos de instalación

Decisión rápida

¿Usas Debian o Ubuntu?     →  .deb  (ver página siguiente)
¿Usas RHEL, Rocky o Alma?  →  .rpm  (ver página siguiente)
¿Necesitas modificar el código o compilar para ARM64?  →  Desde fuente

Requisitos previos comunes

Independientemente del método:

• Acceso root o capacidad de ejecutar sudo.
• Sistema operativo soportado (consulta la sección de compatibilidad).
• Espacio libre en disco: al menos 50 MB para el binario y los respaldos iniciales.

Vallumix debe ejecutarse como root para aplicar controles de hardening. Sin embargo, la instalación del binario en sí puede hacerse como usuario normal si lo colocas en `~/.local/bin`. Solo las operaciones `apply`, `audit` y `rollback` requieren elevación de privilegios.

Verificación post-instalación

Tras instalar Vallumix, verifica que funciona correctamente:

vallumix --version
vallumix list --profile web

Si ambos comandos devuelven salida sin errores, la instalación es correcta y puedes continuar con la guía de primeros pasos.

Debian y Ubuntu

Este documento detalla la instalación de Vallumix en Debian 12 (Bookworm), Ubuntu 22.04 LTS (Jammy) y Ubuntu 24.04 LTS (Noble) mediante el paquete .deb oficial.

Requisitos previos

• Sistema operativo: Debian 12, Ubuntu 22.04 o 24.04.
• Arquitectura: amd64 o arm64.
• Acceso root o sudo.
• wget o curl instalado.

Instalación del paquete .deb

1. Descarga el paquete

Visita la página de releases del repositorio y descarga el archivo .deb correspondiente a tu arquitectura:

# Para amd64
wget https://github.com/jorgealonsodev/vallumix/releases/download/v1.0.0/vallumix_1.0.0_amd64.deb

# Para arm64
wget https://github.com/jorgealonsodev/vallumix/releases/download/v1.0.0/vallumix_1.0.0_arm64.deb

2. Instala con dpkg

sudo dpkg -i vallumix_1.0.0_*.deb

Si dpkg reporta dependencias no satisfechas, corrígelas con:

sudo apt-get install -f

Vallumix se compila como binario estático con musl. En la práctica, el paquete `.deb` no tiene dependencias de runtime. El comando `apt-get install -f` solo resolvería dependencias del paquete de metadatos si las hubiera.

3. Verifica la instalación

vallumix --version
which vallumix

El binario se instala en /usr/bin/vallumix.

Instalación desde repositorio APT (opcional)

Si prefieres gestionar Vallumix mediante apt en lugar de descargar .deb manualmente:

# Añade la clave GPG
curl -fsSL https://vallumix.dev/apt/gpg.key | sudo gpg --dearmor -o /usr/share/keyrings/vallumix.gpg

# Añade el repositorio
echo "deb [signed-by=/usr/share/keyrings/vallumix.gpg] https://vallumix.dev/apt stable main" | \
  sudo tee /etc/apt/sources.list.d/vallumix.list

# Instala
sudo apt update
sudo apt install vallumix

Desinstalación

sudo dpkg -r vallumix

Esto elimina el binario pero conserva los respaldos en /var/backups/vallumix. Si deseas eliminar también los respaldos:

sudo rm -rf /var/backups/vallumix

No elimines `/var/backups/vallumix` si podrías necesitar revertir cambios aplicados previamente. Los respaldos son tu única vía de rollback.

RHEL y Derivados

Esta guía cubre la instalación de Vallumix en Red Hat Enterprise Linux 9, Rocky Linux 9 y AlmaLinux 9 mediante el paquete .rpm oficial.

Requisitos previos

• Sistema operativo: RHEL 9, Rocky Linux 9 o AlmaLinux 9.
• Arquitectura: x86_64 o aarch64.
• Acceso root o sudo.
• wget o curl instalado.

Instalación del paquete .rpm

1. Descarga el paquete

# Para x86_64
wget https://github.com/jorgealonsodev/vallumix/releases/download/v1.0.0/vallumix-1.0.0-1.x86_64.rpm

# Para aarch64
wget https://github.com/jorgealonsodev/vallumix/releases/download/v1.0.0/vallumix-1.0.0-1.aarch64.rpm

2. Instala con dnf

sudo dnf install ./vallumix-1.0.0-1.*.rpm

dnf resuelve automáticamente cualquier dependencia del paquete. Como Vallumix es un binario estático compilado con musl, no requiere bibliotecas adicionales en runtime.

3. Verifica la instalación

vallumix --version
which vallumix

El binario se instala en /usr/bin/vallumix.

Instalación desde repositorio DNF (opcional)

Para gestionar actualizaciones automáticas mediante dnf:

# Añade el repositorio
sudo tee /etc/yum.repos.d/vallumix.repo <<EOF
[vallumix]
name=Vallumix Repository
baseurl=https://vallumix.dev/rpm/\$basearch
enabled=1
gpgcheck=1
gpgkey=https://vallumix.dev/rpm/gpg.key
EOF

# Instala
sudo dnf install vallumix

Desinstalación

sudo dnf remove vallumix

Al igual que con el paquete .deb, la desinstalación del .rpm conserva los respaldos en /var/backups/vallumix. Elimínalos manualmente solo si estás seguro de que no necesitarás rollback:

sudo rm -rf /var/backups/vallumix

Conserva los respaldos al menos hasta la próxima ventana de mantenimiento confirmada. Un rollback puede salvar horas de depuración si un control de hardening rompe un servicio crítico.

Desde Código Fuente

Compilar Vallumix desde el código fuente te da control total sobre las optimizaciones, parches y arquitecturas objetivo. Este método es el recomendado para desarrolladores, mantenedores de distribuciones o entornos con requisitos de compilación cruzada.

Requisitos previos

• Rust toolchain ≥ 1.75 (MSRV). Recomendado: latest stable via rustup.
• cargo y rustc funcionando.
• Para compilación cruzada: cross o docker.
• Sistema operativo Linux con acceso root (para ejecutar, no para compilar).

Vallumix no requiere dependencias de sistema en runtime, pero necesita un toolchain Rust completo para compilar. No intentes compilarlo con el rustc de los repositorios de la distribución si está desactualizado; usa rustup.

Compilación nativa

1. Clona el repositorio

git clone https://github.com/jorgealonsodev/vallumix.git
cd vallumix

2. Compila en modo release

cargo build --release

El binario resultante se encuentra en target/release/vallumix.

3. Instala en el sistema

sudo cp target/release/vallumix /usr/local/bin/
sudo chmod +x /usr/local/bin/vallumix

Compilación estática con musl

Para producir un binario completamente estático sin dependencias de glibc:

# Añade el target musl
rustup target add x86_64-unknown-linux-musl

# Compila
cargo build --release --target x86_64-unknown-linux-musl

El binario estático se genera en target/x86_64-unknown-linux-musl/release/vallumix.

El binario musl es el que se distribuye en los releases oficiales. Es ligeramente mayor que el binario glibc pero garantiza compatibilidad universal entre distribuciones sin preocuparse por versiones de libc.

Compilación cruzada

Para compilar desde tu máquina de desarrollo x86_64 hacia ARM64 (por ejemplo, para AWS Graviton o Raspberry Pi):

# Instala cross
cargo install cross --git https://github.com/cross-rs/cross

# Compila para ARM64
cross build --release --target aarch64-unknown-linux-musl

cross utiliza contenedores Docker con los toolchains necesarios, evitando que instales cadenas de compilación cruzada en tu sistema anfitrión.

Verificación

Tras compilar, ejecuta los tests y verifica el binario:

cargo test --workspace
cargo clippy --workspace -- -D warnings
./target/release/vallumix --version

Si cargo test pasa y clippy no reporta warnings, tu compilación es válida.

Conceptos Clave

Antes de ejecutar Vallumix, es importante comprender los conceptos que rigen su funcionamiento. Esta sección explica la arquitectura mental del sistema: perfiles, controles, idempotencia, rollback y el flujo de ejecución completo.

Flujo de ejecución

Cada vez que ejecutas Vallumix, el motor sigue un pipeline de 10 fases diseñado para ser predecible, seguro y auditable:

flowchart TB
    A["1. Parsing de argumentos<br/>clap"] --> B["2. Inicialización de tracing<br/>tracing-subscriber"]
    B --> C["3. Validación inicial<br/>root, distro, espacio en disco"]
    C --> D["4. Carga del perfil<br/>TOML -> serde"]
    D --> E["5. Construcción del contexto<br/>Context"]
    E --> F["6. Creación de respaldo versionado<br/>/var/backups/vallumix/<timestamp>"]
    F --> G["7. Iteración por controles<br/>pre_check → backup → apply → post_check"]
    G --> H["8. Generación de reportes<br/>trait Reporter"]
    H --> I["9. Resumen en consola<br/>tasa de cumplimiento"]
    I --> J["10. Código de salida<br/>0, 1, 2, 3"]

Este flujo garantiza que cada ejecución sea autónoma: valida el entorno, respalda antes de modificar, verifica después de aplicar y documenta todo en un reporte estructurado.

¿Qué significa cada fase?

1. Parsing de argumentos: clap valida flags, subcomandos y valores. Si hay un error sintáctico, el programa aborta antes de tocar el sistema.
2. Inicialización de tracing: configura el nivel de log y el formato (texto coloreado o JSON estructurado) según RUST_LOG y --log-level.
3. Validación inicial: comprueba que el usuario es root, que la distribución está soportada leyendo /etc/os-release, y que hay espacio suficiente en disco para respaldos.
4. Carga del perfil: deserializa el archivo TOML del perfil seleccionado (web.toml, database.toml o bastion.toml) y resuelve la lista de controles a ejecutar.
5. Construcción del contexto: reúne información del host (hostname, kernel, distribución) y la configura en una estructura Context que cada control recibirá.
6. Creación de respaldo: genera un directorio versionado con timestamp en /var/backups/vallumix/. Todos los archivos modificados se copian aquí antes de cualquier cambio.
7. Iteración por controles: para cada control del perfil, el motor ejecuta pre_check (¿ya cumple?), backup (copia de archivos), apply (aplica cambio), y post_check (¿funcionó?). En modo audit, solo ejecuta pre_check.
8. Generación de reportes: los traits Reporter producen los formatos solicitados (HTML, JSON, JUnit, texto).
9. Resumen en consola: muestra la tasa de cumplimiento, controles aprobados, fallidos y omitidos, junto con la ruta al reporte HTML.
10. Código de salida: 0 si cumple el umbral, 1 si no, 2 para errores de configuración, 3 para errores de privilegios.

Conceptos relacionados

• Perfiles: conjuntos preconfigurados de controles adaptados al rol del servidor.
• Controles: unidades atómicas de verificación y remediación, cada una implementando el trait Control.
• Idempotencia: propiedad que garantiza que ejecutar Vallumix varias veces produce el mismo estado final.
• Rollback: mecanismo para revertir cambios aplicados mediante respaldos versionados.

Entender este flujo te ayuda a interpretar los logs, a diagnosticar fallos y a explicarle a un auditor cómo funciona la herramienta. No es necesario memorizarlo, pero sí tenerlo como referencia cuando revises una ejecución problemática.

Perfiles

Los perfiles son el mecanismo mediante el cual Vallumix adapta la selección y severidad de los controles al rol operativo del servidor. En lugar de aplicar un hardening genérico que puede romper servicios legítimos, cada perfil prioriza los controles relevantes y omite o suaviza aquellos que no tienen sentido para el contexto.

Perfil Web

El perfil web está optimizado para servidores que alojan aplicaciones HTTP/HTTPS mediante Nginx, Apache u otros servidores web.

Qué incluye

• Controles de filtrado de red enfocados en puertos 80 y 443.
• Límites de recursos (ulimit, systemd limits) para procesos del servidor web.
• Endurecimiento de configuración TLS: versiones mínimas de protocolo, ciphersuites seguras, deshabilitación de certificados autofirmados.
• Permisos restrictivos en directorios de despliegue (/var/www, /usr/share/nginx/html).
• Políticas de logging estructurado para análisis forense de accesos y errores.
• Deshabilitación de servicios innecesarios que no afectan la funcionalidad web (avahi, cups, etc.).

Cuándo usarlo

• Servidores frontales que exponen aplicaciones web.
• Balanceadores de carga inversos (reverse proxies).
• Servidores de archivos estáticos.

El perfil web no deshabilita el servicio HTTP ni restringe el acceso a los puertos web. Su objetivo es endurecer el host subyacente sin romper la funcionalidad del servidor.

Perfil Database

El perfil database está diseñado para hosts que ejecutan motores de base de datos como PostgreSQL, MariaDB o MongoDB.

Qué incluye

• Restricción de acceso de red a interfaces internas o localhost.
• Controles estrictos sobre montajes de filesystem, especialmente /tmp y /var, con opciones noexec, nodev, nosuid.
• Endurecimiento del kernel para cargas de trabajo de E/S intensivas (vm.swappiness, dirty_ratio).
• Desactivación de binarios SUID/SGID no esenciales.
• Configuración de PAM y límites de recursos para el usuario del motor de base de datos.
• Logging de auditoría para conexiones y consultas administrativas.

Cuándo usarlo

• Servidores de base de datos dedicados.
• Nodos de réplica o clúster de bases de datos.
• Instancias donde el motor de BD es el servicio principal.

Perfil Bastión

El perfil bastion es el más agresivo de los tres. Está pensado para hosts saltadores (jump hosts) cuyo único propósito es servir como punto de entrada SSH autenticado hacia infraestructura interna.

Qué incluye

• Solo puerto 22 (SSH) expuesto; todo lo demás filtrado.
• Autenticación por clave pública obligatoria; deshabilitación de contraseñas.
• Soporte opcional para autenticación multifactor (MFA) con Google Authenticator.
• Registro exhaustivo de sesiones con auditd y script.
• Restricciones extensas de comandos y entorno mediante ForceCommand, ChrootDirectory y Match blocks.
• Endurecimiento máximo de PAM, sudo y cron.

Cuándo usarlo

• Bastiones de acceso remoto a infraestructura interna.
• Servidores de administración centralizada.
• Cualquier host cuya única función sea SSH.

El perfil bastión puede romper servicios que no sean SSH. No lo apliques en servidores web, bases de datos o cualquier host que necesite ejecutar otros servicios. Siempre ejecuta `--dry-run` antes de aplicar este perfil en un entorno nuevo.

Comparativa rápida

Selección de perfil

Usa la flag --profile en cualquier subcomando:

vallumix apply --profile web
vallumix audit --profile database --report html
vallumix list --profile bastion

Controles

Un control es la unidad atómica de trabajo en Vallumix. Representa una verificación de seguridad individual alineada con el CIS Benchmark, junto con la lógica necesaria para evaluar el estado actual del sistema y, si es necesario, aplicar una remediación.

¿Qué es un control CIS?

El Center for Internet Security (CIS) publica benchmarks que desglosan la configuración segura de sistemas operativos en cientos de recomendaciones numeradas. Cada recomendación se denomina "control" y tiene un identificador como 5.2.4 (deshabilitar login directo de root por SSH) o 1.1.1.1 (deshabilitar el soporte para cramfs).

Vallumix implementa una selección de estos controles —70 en la versión 1.0— distribuidos en seis categorías funcionales:

1. Configuración inicial: filesystems, actualizaciones automáticas, integridad de paquetes.
2. Servicios: identificación y desactivación de servicios innecesarios.
3. Red: parámetros del kernel para TCP/IP, IPv6, ICMP, firewall.
4. Logging y auditoría: rsyslog, journald, auditd.
5. Acceso, autenticación y autorización: PAM, contraseñas, SSH, sudo, cron.
6. Mantenimiento del sistema: permisos, integridad de /etc/passwd, umask.

El trait Control

En Vallumix, cada control se implementa como una estructura Rust que implementa el trait Control. Esta abstracción permite que el motor principal itere sobre Box<dyn Control> sin acoplarse a la lógica específica de cada verificación.

#![allow(unused)]
fn main() {
pub trait Control: Send + Sync {
    fn id(&self) -> &str;                          // p. ej. "5.2.4"
    fn description(&self) -> &str;
    fn severity(&self) -> Severity;
    fn applicable_distros(&self) -> &[Distro];

    fn check(&self, ctx: &Context) -> Result<CheckResult, ControlError>;
    fn apply(&self, ctx: &Context) -> Result<ApplyResult, ControlError>;
    fn rollback(&self, ctx: &Context, backup: &Backup) -> Result<(), ControlError>;
}
}

Cada método tiene una responsabilidad clara:

• id: devuelve el identificador CIS del control (por ejemplo, 5.2.4).
• description: descripción legible de lo que verifica y remedia.
• severity: nivel de criticidad del control.
• applicable_distros: lista de distribuciones donde el control tiene sentido.
• check: evalúa el estado actual sin modificar nada. Devuelve Compliant o NonCompliant.
• apply: aplica la remediación. Solo se invoca en modo apply, nunca en audit.
• rollback: revierte los cambios aplicados por este control usando el respaldo proporcionado.

Niveles de severidad

Cada control se clasifica según el impacto potencial de su incumplimiento:

Organización en el código

Los controles se organizan en vallumix-controls por dominio funcional:

vallumix-controls/src/
├── filesystem/
│   ├── mod.rs
│   └── disable_cramfs.rs      # CIS 1.1.1.1
├── ssh/
│   ├── mod.rs
│   └── disable_root_login.rs  # CIS 5.2.4
├── network/
│   └── ...
└── ...

Cada archivo implementa una única estructura de control y no debe exceder las 200 líneas de código efectivo. Si un control requiere lógica compleja, se descompone en funciones auxiliares privadas.

Puedes listar todos los controles disponibles con `vallumix list --profile web`. Esto muestra el ID CIS, la descripción, la severidad y el estado de cumplimiento actual sin aplicar cambios.

Idempotencia

La idempotencia es una de las propiedades fundamentales de Vallumix. Significa que ejecutar la herramienta una vez, dos veces o cien veces sobre el mismo servidor produce el mismo estado final, sin efectos secundarios acumulativos ni duplicación de cambios.

¿Por qué importa?

En entornos de producción, el hardening no es un evento único. Los servidores se reprovisionan, las configuraciones se ajustan, y las políticas de seguridad evolucionan. Si una herramienta de hardening no es idempotente, cada ejecución adicional puede:

• Acumular reglas duplicadas en archivos de configuración.
• Agregar múltiples entradas idénticas en cron o systemd.
• Sobreescribir respaldos anteriores con versiones posteriores, perdiendo la trazabilidad.
• Generar reportes inconsistentes entre ejecuciones.

Vallumix evita todos estos problemas diseñando cada control para que sea inherentemente idempotente.

Cómo garantiza la idempotencia Vallumix

Pre-check antes de aplicar

Antes de modificar cualquier archivo, cada control ejecuta una fase pre_check que evalúa si el sistema ya cumple con la recomendación. Si el control determina que el estado actual es compliant, salta directamente al siguiente sin tocar nada.

#![allow(unused)]
fn main() {
fn apply(&self, ctx: &Context) -> Result<ApplyResult, ControlError> {
    match self.check(ctx)? {
        CheckResult::Compliant => {
            return Ok(ApplyResult::SkippedAlreadyCompliant);
        }
        CheckResult::NonCompliant => {
            // Procede al backup y aplicación
        }
    }
}
}

Backup condicional

Los respaldos solo se crean cuando un control realmente va a modificar algo. Si todos los controles de una ejecución ya están compliant, no se genera ningún backup nuevo vacío.

Aplicaciones atómicas

Cuando un control modifica un archivo, lo hace de forma atómica: escribe el contenido nuevo en un archivo temporal y luego usa rename para reemplazar el original. Esto garantiza que el archivo nunca quede en un estado intermedio corrupto, incluso si el proceso se interrumpe.

Post-check de verificación

Después de aplicar un cambio, el control ejecuta post_check para confirmar que el estado del sistema coincide con lo esperado. Si no coincide, el resultado se marca como fallido y el reporte documenta la discrepancia.

Dry-run como validación de idempotencia

El modo --dry-run es la herramienta más efectiva para verificar la idempotencia sin riesgo:

sudo vallumix apply --profile web --dry-run --verbose

En este modo, Vallumix ejecuta pre_check para todos los controles e informa qué cambios se harían, pero no ejecuta backup ni apply. Si ejecutas --dry-run inmediatamente después de un apply exitoso, deberías ver que todos los controles aparecen como Compliant o SkippedAlreadyCompliant.

Incorpora `vallumix apply --profile web --dry-run` en tus playbooks de Ansible o scripts de aprovisionamiento como paso de validación antes de marcar un servidor como listo. Si el dry-run reporta cambios pendientes, significa que algo en tu proceso anterior no fue idempotente.

Idempotencia y reportes

Los reportes reflejan la idempotencia mediante los estados:

• Compliant: el control ya cumplía antes de la ejecución.
• Remediated: el control no cumplía y se aplicó con éxito.
• SkippedAlreadyCompliant: el control se saltó porque el pre_check indicó cumplimiento.
• Failed: el control no cumplía, se intentó remediar, pero el post_check falló.

Un reporte idempotente sobre un servidor ya endurecido debería mostrar predominantemente Compliant y SkippedAlreadyCompliant, con cero entradas Remediated.

Rollback

El sistema de rollback de Vallumix permite revertir cambios de hardening de forma granular, ya sea por control individual o por sesión completa. Esto transforma el hardening de una operación de riesgo en una operación reversible.

Arquitectura de respaldos

Cada vez que Vallumix aplica cambios, crea una sesión de respaldo versionada en /var/backups/vallumix/:

/var/backups/vallumix/
├── 2026-04-30T14-22-18/
│   ├── manifest.json          # Metadatos de la sesión
│   ├── 5.2.4/
│   │   └── sshd_config.bak    # Archivo respaldado por control 5.2.4
│   ├── 1.1.1.1/
│   │   └── modprobe.cramfs.bak
│   └── checksums.sha256       # Hashes SHA-256 de todos los archivos respaldados
└── 2026-04-30T15-07-03/
    └── ...

Cada sesión contiene:

• Directorio con timestamp ISO 8601: identifica cuándo se ejecutó.
• manifest.json: lista los controles aplicados, la distribución, el perfil usado y el usuario que ejecutó Vallumix.
• Subdirectorios por control ID: cada control que modificó archivos tiene su propio directorio con las copias de seguridad.
• checksums.sha256: hash criptográfico de cada archivo respaldado, permitiendo detectar corrupción o manipulación.

Rollback por control

Si identificas que un control específico causó un problema, reviértelo sin afectar los demás:

sudo vallumix rollback --control-id 5.2.4

Este comando:

1. Lee el manifest.json de la última sesión.
2. Localiza el respaldo del control 5.2.4.
3. Verifica la integridad del archivo mediante SHA-256.
4. Restaura el archivo original en su ubicación.
5. Ejecuta check para confirmar que el sistema volvió al estado previo.
6. Registra la acción en el log y genera un reporte de rollback.

El rollback por control es la opción preferida cuando sabes exactamente qué cambio rompió algo. Es rápido, preciso y minimiza el riesgo de revertir controles correctos que no tienen nada que ver con el incidente.

Rollback por sesión

Si no estás seguro de qué control causó el problema, o si varios controles interactuaron de forma inesperada, revierte toda una sesión:

# Última sesión automáticamente
sudo vallumix rollback --session last

# Sesión específica por timestamp
sudo vallumix rollback --session 2026-04-30T14-22-18

El rollback por sesión restaura todos los archivos respaldados en esa ejecución, en el orden inverso a como fueron aplicados, para manejar correctamente las dependencias entre archivos.

El rollback por sesión es una operación destructiva que revierte múltiples cambios. Aunque los respaldos están protegidos por checksums, una restauración masiva puede afectar la estabilidad del sistema si otros administradores han realizado cambios manuales en los mismos archivos entre la sesión de hardening y el rollback. Comunica siempre antes de ejecutar un rollback en producción.

Verificación de integridad

Antes de restaurar cualquier archivo, Vallumix recalcula el hash SHA-256 y lo compara con el registrado en checksums.sha256. Si no coinciden, el rollback aborta para ese archivo y lo marca como IntegrityCheckFailed en el reporte.

Limpieza de respaldos antiguos

Los respaldos no se eliminan automáticamente. Para evitar que /var/backups/vallumix crezca indefinidamente, configura una tarea cron que conserve solo las últimas N sesiones:

# Conservar solo las últimas 10 sesiones
0 2 * * * cd /var/backups/vallumix && ls -t | tail -n +11 | xargs rm -rf

Guías

Esta sección contiene guías prácticas orientadas a casos de uso reales. Cada guía parte de un escenario concreto, proporciona los comandos exactos y explica el resultado esperado.

Casos de uso cubiertos

Vallumix fue diseñado respondiendo a cinco escenarios recurrentes en la operación de servidores Linux:

¿Qué guía necesitas?

• Si eres administrador de sistemas y acabas de aprovisionar un servidor → CU-01.
• Si eres consultor de seguridad y necesitas un reporte para el cliente → CU-02.
• Si eres ingeniero de plataformas y no tocas producción sin validar antes → CU-03.
• Si eres SRE y recibiste una alerta tras un cambio de hardening → CU-04.
• Si eres DevOps y construyes imágenes base con Packer o Terraform → CU-05.

Todas las guías asumen que Vallumix está instalado y que tienes acceso root en el sistema objetivo. Si aún no has instalado Vallumix, comienza por la [sección de instalación](installation/README.md).

Convenciones usadas en las guías

• Los comandos precedidos por $ se ejecutan como usuario normal.
• Los comandos precedidos por # se ejecutan como root.
• La salida esperada se muestra en bloques de código sin prompt.
• Los bloques ```admonish señalan advertencias sobre operaciones destructivas o requisitos de privilegios.

Hardening de Servidor Web (CU-01)

Esta guía describe el endurecimiento completo de un servidor Ubuntu 24.04 LTS recién aprovisionado que alojará una aplicación web servida por Nginx. El objetivo es aplicar los controles del perfil web sin interrumpir el servicio HTTP.

Escenario

• Servidor: Ubuntu 24.04 LTS (Noble), 2 vCPU, 4 GB RAM.
• Servicio: Nginx 1.24 sirviendo una aplicación PHP-FPM en puerto 443.
• Estado inicial: Instalación mínima del servidor, sin hardening previo.
• Objetivo: Aplicar controles CIS del perfil web, generar reporte HTML para auditoría.

Paso 1: Verificar el entorno

# Verifica la distribución y versión
cat /etc/os-release | grep PRETTY_NAME
# Salida esperada: PRETTY_NAME="Ubuntu 24.04 LTS"

# Confirma que Nginx está activo
systemctl is-active nginx
# Salida esperada: active

# Verifica que el puerto 443 está escuchando
ss -tlnp | grep :443
# Salida esperada: LISTEN 0 4096 *:443

Paso 2: Instalar Vallumix

wget https://github.com/jorgealonsodev/vallumix/releases/download/v1.0.0/vallumix_1.0.0_amd64.deb
sudo dpkg -i vallumix_1.0.0_amd64.deb
vallumix --version
# Salida esperada: vallumix 1.0.0

Paso 3: Auditoría inicial (opcional pero recomendada)

Antes de modificar nada, evalúa la postura actual para tener una línea base:

sudo vallumix audit --profile web --report html,json --output /tmp/pre-audit

Esto genera /tmp/pre-audit.html y /tmp/pre-audit.json. En un servidor nuevo, la tasa de cumplimiento suele estar entre 30% y 50%.

Paso 4: Ejecutar hardening

sudo vallumix apply --profile web --report html --output /tmp/hardening-report

Salida esperada (resumen)

[  OK  ] 1.1.1.1  Disable cramfs support                 Compliant
[ FIX  ] 1.1.1.2  Disable freevxfs support               Remediated
[ FIX  ] 1.1.1.3  Disable jffs2 support                  Remediated
[  OK  ] 2.1.1    Ensure autofs is not installed         Compliant
[ FIX  ] 3.1.1    Ensure IP forwarding is disabled       Remediated
[  OK  ] 3.2.1    Ensure packet redirect sending is dis… Compliant
[ FIX  ] 3.4.1    Ensure firewalld is installed          Remediated
[ FIX  ] 5.2.4    Ensure SSH root login is disabled      Remediated
[  OK  ] 5.2.5    Ensure SSH strict mode is enabled      Compliant
[ FIX  ] 6.1.1    Ensure permissions on /etc/passwd      Remediated

─────────────────────────────────────────────
Execution complete
Profile:        web
Controls run:   70
Compliant:      28
Remediated:     38
Failed:         2
Skipped:        2
Compliance:     94.3%
Threshold:      90.0%
Status:         PASS
Report:         /tmp/hardening-report.html
─────────────────────────────────────────────

El perfil web no deshabilita Nginx ni cierra los puertos 80/443. Sin embargo, algunos controles de firewall (`3.4.x`) configuran reglas por defecto. Si tu aplicación requiere puertos adicionales (por ejemplo, 8080 para un API interna), revísalas después de la ejecución.

Paso 5: Verificar que Nginx sigue funcionando

curl -I https://localhost/
# Debe devolver HTTP/2 200 con los headers de tu aplicación

systemctl status nginx
# Debe mostrar active (running)

Paso 6: Re-ejecución idempotente

Para confirmar que Vallumix es idempotente, ejecútalo de nuevo:

sudo vallumix apply --profile web --report json --output /tmp/post-audit

En esta segunda ejecución, la mayoría de controles deberían aparecer como Compliant o SkippedAlreadyCompliant, con muy pocas o ninguna entrada Remediated.

Paso 7: Documentar para auditoría

Conserva estos tres artefactos:

1. /tmp/pre-audit.html — línea base inicial.
2. /tmp/hardening-report.html — evidencia de hardening aplicado.
3. /tmp/post-audit.json — confirmación de idempotencia.

Programa una re-ejecución mensual de `vallumix audit --profile web --report html` como tarea cron. Esto detecta desviaciones de configuración causadas por actualizaciones de paquetes o cambios manuales de otros administradores.

Auditoría de Cumplimiento (CU-02)

Esta guía describe cómo realizar una auditoría de seguridad sin modificar el sistema objetivo, generando reportes que sirven como evidencia para auditorías de cumplimiento ISO 27001, PCI-DSS o revisiones internas de seguridad.

Escenario

• Actor: Consultor de seguridad con acceso temporal a un servidor de cliente.
• Restricción: No puede modificar configuraciones del sistema.
• Objetivo: Evaluar la postura de seguridad y entregar un reporte ejecutivo.
• Distribución: Desconocida hasta la conexión (podría ser Debian, Ubuntu, RHEL o derivada).

Paso 1: Transferir Vallumix al servidor objetivo

Como Vallumix es un binario único estático, puedes copiarlo sin instalar dependencias:

# Desde tu máquina local
scp vallumix usuario@servidor-cliente:/tmp/
ssh usuario@servidor-cliente
sudo cp /tmp/vallumix /usr/local/bin/

Si no tienes acceso root en el servidor del cliente, solicita que un administrador local ejecute el binario por ti. El subcomando `audit` requiere root para leer archivos de configuración protegidos como `/etc/shadow` o `/etc/ssh/sshd_config`.

Paso 2: Detectar la distribución y seleccionar perfil

sudo vallumix list
# Muestra los perfiles disponibles y los controles asociados

Basado en el rol del servidor, selecciona el perfil adecuado:

• Servidor web (Nginx, Apache) → --profile web
• Servidor de base de datos (PostgreSQL, MariaDB) → --profile database
• Bastión SSH → --profile bastion

Si no estás seguro del rol, ejecuta los tres perfiles y compara los resultados.

Paso 3: Ejecutar la auditoría

sudo vallumix audit --profile database --report html,json --output /tmp/compliance-audit

El subcomando audit evalúa todos los controles del perfil pero nunca ejecuta apply. Solo realiza pre_check sobre cada control y genera el reporte.

Salida esperada

[  OK  ] 1.1.1.1  Disable cramfs support                 Compliant
[FAIL]  1.1.1.2  Disable freevxfs support               NonCompliant
[  OK  ] 2.1.1    Ensure autofs is not installed         Compliant
[FAIL]  3.1.1    Ensure IP forwarding is disabled       NonCompliant
[FAIL]  5.2.4    Ensure SSH root login is disabled      NonCompliant
[  OK  ] 5.2.5    Ensure SSH strict mode is enabled      Compliant
[FAIL]  6.1.1    Ensure permissions on /etc/passwd      NonCompliant

─────────────────────────────────────────────
Execution complete
Profile:        database
Controls run:   70
Compliant:      31
NonCompliant:   35
Skipped:        4
Compliance:     46.9%
Threshold:      not set
Status:         AUDIT ONLY (no changes applied)
Reports:        /tmp/compliance-audit.html
                /tmp/compliance-audit.json
─────────────────────────────────────────────

El estado `AUDIT ONLY` en la salida confirma que no se modificó ningún archivo del sistema. Esto es una garantía importante que debes destacar ante el auditor o cliente.

Paso 4: Generar el reporte HTML para el cliente

El reporte HTML es autocontenido: incluye CSS embebido, no requiere conexión a internet y se puede abrir directamente en cualquier navegador. Contiene:

• Portada: hostname, distribución, kernel, fecha y duración.
• Resumen ejecutivo: tasa de cumplimiento, comparación con ejecuciones previas.
• Detalle por control: ID CIS, descripción, severidad, estado, evidencia técnica.
• Recomendaciones de remediación manual para controles que no pueden automatizarse.
• Mapeo a estándares: referencias cruzadas a NIST 800-53, ISO 27001 Annex A y PCI-DSS.

Paso 5: Extraer métricas del JSON para dashboards

Si el cliente tiene un dashboard de cumplimiento (Grafana, Splunk, etc.), el JSON es la fuente de datos:

# Extrae la tasa de cumplimiento global
jq '.summary.compliance_rate' /tmp/compliance-audit.json
# Salida: 46.9

# Lista todos los controles no compliant
jq '.controls[] | select(.status == "NonCompliant") | {id: .id, severity: .severity, description: .description}' /tmp/compliance-audit.json

# Cuenta controles críticos fallidos
jq '[.controls[] | select(.status == "NonCompliant" and .severity == "Critical")] | length' /tmp/compliance-audit.json

Paso 6: Entregar resultados

El paquete de entrega para una auditoría típica incluye:

1. Reporte HTML: documento principal para revisión ejecutiva.
2. Reporte JSON: datos estructurados para integración con herramientas del cliente.
3. Log de ejecución: salida de vallumix audit con --verbose para trazabilidad técnica.
4. Declaración de no modificación: texto que certifica que la auditoría fue de solo lectura.

Ejecuta la auditoría con `--verbose` para capturar los comandos exactos que Vallumix usó para evaluar cada control. Esto proporciona trazabilidad técnica ante auditores que cuestionan la metodología de evaluación.

Validación en Dry-Run (CU-03)

El modo dry-run permite revisar exactamente qué cambios realizaría Vallumix antes de aplicarlos. Es una práctica obligatoria en entornos de producción donde cualquier modificación no planificada puede causar interrupciones de servicio.

Escenario

• Entorno: Pre-producción que replica fielmente el entorno productivo.
• Rol del servidor: Bastión SSH en Rocky Linux 9.
• Objetivo: Validar que el perfil bastion no rompe el acceso SSH administrativo antes de aplicarlo en producción.
• Preocupación: El perfil bastión deshabilita autenticación por contraseña y podría bloquear acceso si las claves no están correctamente distribuidas.

Paso 1: Verificar acceso por clave SSH

Antes de cualquier dry-run del perfil bastión, confirma que puedes acceder por clave pública:

# Desde tu estación de trabajo
ssh -o PasswordAuthentication=no admin@bastion-preprod
# Si falla, NO apliques el perfil bastión hasta resolverlo

El perfil bastión deshabilita explícitamente `PasswordAuthentication` en `sshd_config`. Si accedes por contraseña y aplicas este perfil, te bloquearás. Verifica el acceso por clave antes de continuar.

Paso 2: Ejecutar dry-run

sudo vallumix apply --profile bastion --dry-run --verbose --report json --output /tmp/dry-run-bastion

Qué hace exactamente el dry-run

• Ejecuta check en todos los controles del perfil, igual que audit.
• Para controles NonCompliant, genera una entrada en el reporte que describe qué cambio se haría, incluyendo:
  • Archivo que se modificaría.
  • Valor actual vs valor objetivo.
  • Justificación CIS.
• No ejecuta backup ni apply. El sistema permanece intacto.

Salida esperada (extracto)

[Dry-run] 5.2.4  Ensure SSH root login is disabled
  → Would set: PermitRootLogin no
  → In file:   /etc/ssh/sshd_config
  → Current:   PermitRootLogin yes
  → Justification: CIS 5.2.4 — Root login via SSH increases attack surface

[Dry-run] 5.2.8  Ensure SSH password authentication is disabled
  → Would set: PasswordAuthentication no
  → In file:   /etc/ssh/sshd_config
  → Current:   PasswordAuthentication yes
  → Justification: CIS 5.2.8 — Passwords are vulnerable to brute-force attacks

[Dry-run] 3.4.2  Ensure default deny firewall policy
  → Would execute: nftables rule set
  → Current:       no active firewall rules
  → Impact:        Port 22 will be explicitly allowed; all others dropped

Paso 3: Revisar controles de alto riesgo

En el reporte JSON, filtra los controles que podrían impactar operaciones críticas:

jq '.controls[] | select(.impact == "High")' /tmp/dry-run-bastion.json

Presta especial atención a:

• Controles de SSH que cambian métodos de autenticación.
• Controles de firewall que restringen puertos.
• Controles PAM que afectan políticas de contraseñas o bloqueo de cuentas.
• Controles de sudo que limitan privilegios administrativos.

Paso 4: Ajustar el entorno si es necesario

Si el dry-run revela que un control rompería algo esencial, tienes dos opciones antes de aplicar:

1. Modificar el entorno: por ejemplo, distribuir claves SSH a todos los administradores antes de deshabilitar contraseñas.
2. Omitir el control específico: edita el perfil TOML y comenta el control problemático. Esta opción está documentada en la referencia de perfiles.

Paso 5: Aplicar tras validación exitosa

Una vez que el dry-run no muestra sorpresas:

sudo vallumix apply --profile bastion --report html,json --output /tmp/bastion-applied

Automatiza el dry-run en tu pipeline de CI: ejecuta `vallumix apply --profile $PROFILE --dry-run --report json` en la etapa de validación. Si el reporte contiene controles con `impact: "High"` que no están en una lista de excepciones aprobada, falla el pipeline y requiere revisión manual.

Paso 6: Comparar dry-run vs ejecución real

Para auditoría interna, compara los reportes:

# Controles que el dry-run dijo que remediaría
jq '.controls[] | select(.dry_run_action == "WouldRemediate") | .id' /tmp/dry-run-bastion.json | sort > /tmp/expected.txt

# Controles que realmente se remediaron
jq '.controls[] | select(.status == "Remediated") | .id' /tmp/bastion-applied.json | sort > /tmp/actual.txt

# Deben ser idénticos
diff /tmp/expected.txt /tmp/actual.txt

Si hay diferencias, investiga: podría indicar que el estado del sistema cambió entre el dry-run y la ejecución real, o que un control falló silenciosamente.

Rollback tras Incidente (CU-04)

Esta guía describe cómo responder cuando un control de hardening aplica un cambio que rompe un servicio crítico. Cubre tanto el rollback de un control específico como el de una sesión completa.

Escenario

• Sistema: Servidor web Ubuntu 24.04 con Nginx y PHP-FPM.
• Acción: Se ejecutó vallumix apply --profile web durante una ventana de mantenimiento.
• Síntoma: Tras la ejecución, los usuarios reportan errores 502 Bad Gateway. PHP-FPM no puede escribir en /tmp para gestionar sesiones.
• Hipótesis: Un control de filesystem montó /tmp con noexec, lo cual es correcto desde la perspectiva CIS pero rompe la funcionalidad de PHP-FPM que usa archivos de sesión en /tmp.

Paso 1: Identificar el control responsable

El reporte de la ejecución es tu punto de partida. Localiza el archivo generado:

ls -lt /var/backups/vallumix/
# Identifica el timestamp de la sesión más reciente
# Ejemplo: 2026-05-01T09-15-33

Si aún tienes el reporte JSON de la ejecución:

jq '.controls[] | select(.status == "Remediated") | {id, description, severity}' /tmp/hardening-report.json

En este escenario, identificas que el control 1.1.2.2 (Ensure nodev option set on /tmp partition) y 1.1.2.3 (Ensure nosuid option set on /tmp partition) se aplicaron, y posiblemente 1.1.2.4 (Ensure noexec option set on /tmp partition) es el causante directo del problema.

Paso 2: Verificar los respaldos

ls /var/backups/vallumix/2026-05-01T09-15-33/
# Debe contener: manifest.json, checksums.sha256, y subdirectorios por control

# Verifica integridad de los respaldos
cd /var/backups/vallumix/2026-05-01T09-15-33
sha256sum -c checksums.sha256
# Todos deben reportar OK

Si `sha256sum -c` reporta FAIL para algún archivo de respaldo, NO ejecutes rollback de ese control. La copia de seguridad puede estar corrupta y restaurarla podría dejar el sistema en un estado inconsistente. Contacta al soporte o restaura manualmente desde otro medio.

Paso 3: Rollback del control específico

Si estás seguro de que solo 1.1.2.4 causó el problema, reviértelo individualmente:

sudo vallumix rollback --control-id 1.1.2.4

Salida esperada

[INFO] Restoring backup for control 1.1.2.4
[INFO] Source: /var/backups/vallumix/2026-05-01T09-15-33/1.1.2.4/fstab.bak
[INFO] Target: /etc/fstab
[INFO] Integrity check: SHA-256 OK
[INFO] Remounting /tmp with original options
[INFO] Post-check: /tmp is now compliant with pre-hardening state
[SUCCESS] Rollback of control 1.1.2.4 completed

Paso 4: Verificar la restauración del servicio

# Verifica que /tmp tiene las opciones originales
findmnt /tmp
# Debe mostrar: /tmp tmpfs tmpfs rw,nosuid,nodev (sin noexec)

# Reinicia PHP-FPM para que recree sus archivos de sesión
sudo systemctl restart php8.3-fpm

# Verifica que Nginx responde correctamente
curl -I https://localhost/
# Debe devolver HTTP 200

Paso 5: Alternativa — Rollback de sesión completa

Si no estás seguro de qué control causó el problema, o si varios controles de filesystem interactuaron mal, revierte toda la sesión:

# Rollback de la última sesión automáticamente
sudo vallumix rollback --session last

# O por timestamp específico
sudo vallumix rollback --session 2026-05-01T09-15-33

El rollback por sesión restaura todos los archivos en el orden inverso a como fueron modificados, minimizando dependencias circulares entre configuraciones.

El rollback de sesión completa revierte TODOS los controles aplicados, no solo el problemático. Esto puede dejar el servidor con una postura de seguridad más débil de la que tenía antes del hardening. Úsalo solo cuando el rollback individual no sea viable.

Paso 6: Documentar la excepción

Tras resolver el incidente, documenta el control problemático para futuras ejecuciones:

1. Edita el perfil TOML (/etc/vallumix/profiles/web.toml o el perfil local) y añade el control a la lista de exclusiones.
2. Ejecuta un nuevo dry-run para confirmar que el control se omite.
3. Reporta el conflicto al proyecto Vallumix si crees que el control debería ser más inteligente (por ejemplo, detectar si /tmp está siendo usado por procesos activos antes de aplicar noexec).

Incluye un paso de validación funcional post-hardening en tus runbooks: después de `vallumix apply`, ejecuta un smoke test de tus servicios críticos (health checks, endpoints principales, conexiones de base de datos). Detecta problemas en minutos, no en horas.

Integración CI/CD (CU-05)

Esta guía describe cómo integrar Vallumix en pipelines de aprovisionamiento automatizado usando Packer, Terraform y plataformas de CI como Jenkins, GitLab CI o GitHub Actions.

Escenario

• Pipeline: Construcción de imágenes base con Packer, despliegue con Terraform.
• Requisito: La imagen base debe cumplir al menos el 95% de controles CIS del perfil web.
• Objetivo: Fallar automáticamente la construcción si la tasa de cumplimiento está por debajo del umbral.
• Reporte: JUnit XML consumible por Jenkins para mostrar resultados en el dashboard de build.

Paso 1: Integración con Packer

En tu template Packer (por ejemplo, base-image.pkr.hcl), añade un provisioner shell que ejecute Vallumix después de la instalación base:

provisioner "shell" {
  inline = [
    "wget -q https://github.com/jorgealonsodev/vallumix/releases/download/v1.0.0/vallumix_1.0.0_amd64.deb",
    "dpkg -i vallumix_1.0.0_amd64.deb",
    "vallumix apply --profile web --threshold 95 --report junit --output /tmp/vallumix-results.xml",
  ]
  expect_disconnect = false
}

provisioner "file" {
  source      = "/tmp/vallumix-results.xml"
  destination = "vallumix-results.xml"
  direction   = "download"
}

Usa `--threshold 95` para que Vallumix devuelva código de salida `1` si la tasa de cumplimiento es inferior al 95%. Packer interpreta un código de salida distinto de cero como fallo de provisioner y aborta la construcción de la imagen.

Paso 2: Configurar threshold y códigos de salida

Vallumix devuelve códigos de salida explícitos que las herramientas de CI interpretan nativamente:

Paso 3: Integración con GitHub Actions

name: Hardening Base Image

on:
  push:
    branches: [main]

jobs:
  hardening:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build image with Packer
        run: packer build base-image.pkr.hcl

      - name: Upload JUnit report
        uses: actions/upload-artifact@v4
        with:
          name: vallumix-report
          path: vallumix-results.xml

      - name: Publish test results
        uses: dorny/test-reporter@v1
        with:
          name: Vallumix CIS Compliance
          path: vallumix-results.xml
          reporter: java-junit

El paso Publish test results muestra cada control CIS como un caso de test en la interfaz de GitHub Actions, con controles fallidos resaltados en rojo.

Paso 4: Integración con GitLab CI

stages:
  - build
  - compliance

build-image:
  stage: build
  script:
    - packer build base-image.pkr.hcl
  artifacts:
    paths:
      - vallumix-results.xml
    reports:
      junit: vallumix-results.xml
    expire_in: 30 days
  allow_failure: false

GitLab CI consume automáticamente el JUnit XML y muestra los resultados en la pestaña "Tests" del pipeline, con gráficos de tendencia entre ejecuciones.

Paso 5: Integración con Jenkins

En tu Jenkinsfile:

stage('Hardening') {
    steps {
        sh 'packer build base-image.pkr.hcl'
    }
    post {
        always {
            junit 'vallumix-results.xml'
        }
    }
}

Jenkins parsea el JUnit XML y muestra controles fallidos como tests fallidos en el dashboard de build. Puedes configurar políticas de "unstable build" si hay controles con severidad media o baja fallidos, y "failed build" si hay controles críticos fallidos.

Paso 6: Terraform post-deployment validation

Si usas Terraform para desplegar instancias, añade un local-exec provisioner o un null_resource que ejecute Vallumix tras el despliegue:

resource "null_resource" "hardening_validation" {
  triggers = {
    instance_id = aws_instance.web.id
  }

  provisioner "remote-exec" {
    connection {
      type        = "ssh"
      host        = aws_instance.web.public_ip
      user        = "ubuntu"
      private_key = file(var.private_key_path)
    }

    inline = [
      "sudo vallumix audit --profile web --threshold 95 --report junit --output /tmp/vallumix.xml",
      "cat /tmp/vallumix.xml",
    ]
  }
}

No ejecutes `vallumix apply` directamente desde Terraform `remote-exec` a menos que tengas un mecanismo de rollback automatizado y un proceso de aprobación de cambios. La aplicación de hardening en producción debe ser una operación deliberada, no un side effect del despliegue de infraestructura.

Referencia

Esta sección documenta exhaustivamente la interfaz de línea de comandos de Vallumix: subcomandos, flags globales, códigos de salida y comportamiento esperado de cada operación.

Subcomandos

Vallumix sigue el patrón de subcomandos popularizado por git y cargo:

Flags globales

Estas flags están disponibles en todos los subcomandos:

Códigos de salida

Vallumix devuelve códigos de salida explícitos que facilitan la integración con scripts y pipelines:

Diseña tus scripts de wrapper para que capturen el código `1` como "política de seguridad violada" y el código `2` como "revisar configuración". No trates ambos como genéricos "errores".

Convenciones de salida

• En modo interactivo con TTY, la salida usa colores, iconos (✓ ✗ ⚠ ℹ) y barras de progreso.
• En modo no-TTY (pipes, redirecciones, CI), la salida se simplifica a texto plano sin códigos de escape ANSI, respetando la variable NO_COLOR.
• El log estructurado se controla mediante RUST_LOG y la flag --log-level.

CLI Global

Esta página documenta las flags globales disponibles en todos los subcomandos de Vallumix, con ejemplos de uso y combinaciones comunes.

--profile <web|database|bastion>

Selecciona el perfil de controles a ejecutar. Es obligatorio en apply, audit y list.

vallumix apply --profile web
vallumix audit --profile database
vallumix list --profile bastion

--dry-run

Simula la ejecución completa sin modificar el sistema. Funciona con apply y rollback.

vallumix apply --profile web --dry-run --verbose

En modo dry-run:

• Se ejecutan check en todos los controles.
• Se informa qué cambios se harían.
• No se crean respaldos ni se modifican archivos.
• El código de salida es 0 si la validación de argumentos es correcta, independientemente del cumplimiento.

--verbose

Muestra información detallada de cada control: comandos ejecutados, salida cruda, archivos modificados.

vallumix apply --profile web --verbose

Útil para depuración y para capturar trazabilidad técnica en auditorías.

--quiet

Suprime toda la salida en consola excepto errores fatales. Los reportes se generan normalmente.

vallumix apply --profile web --quiet --report json --output /tmp/report

Ideal para pipelines donde solo interesa el código de salida y el artefacto de reporte.

--threshold <0-100>

Define el porcentaje mínimo de cumplimiento para que la ejecución devuelva código de salida 0.

vallumix apply --profile web --threshold 95
vallumix audit --profile database --threshold 85

Si la tasa de cumplimiento es inferior al umbral, Vallumix devuelve 1.

El umbral aplica al resultado final de la ejecución. Un control `Failed` reduce la tasa de cumplimiento igual que uno `NonCompliant`. Configura el umbral de forma realista según la madurez de seguridad de tu entorno.

--no-color

Deshabilita el coloreado de la salida terminal, respetando también la variable de entorno NO_COLOR.

vallumix apply --profile web --no-color
NO_COLOR=1 vallumix audit --profile web

--report <formatos>

Especifica uno o más formatos de reporte separados por comas.

vallumix apply --profile web --report html
vallumix audit --profile database --report html,json,junit
vallumix apply --profile bastion --report text

Formatos soportados:

--output <prefijo>

Prefijo de ruta para los archivos de reporte. Si no se especifica, Vallumix usa un nombre temporal en /tmp.

vallumix apply --profile web --report html,json --output /var/reports/web-$(date +%Y%m%d)
# Genera: /var/reports/web-20260501.html y /var/reports/web-20260501.json

Combinaciones comunes

# Auditoría silenciosa con reporte JSON para dashboard
vallumix audit --profile web --quiet --report json --output /var/lib/metrics/vallumix

# Aplicación con validación de umbral y reporte JUnit para CI
vallumix apply --profile database --threshold 95 --report junit --output /tmp/results

# Dry-run verbose para revisión manual antes de producción
vallumix apply --profile bastion --dry-run --verbose --report html --output /tmp/dryrun

# Listado completo sin colores para procesamiento con awk/grep
vallumix list --profile web --no-color

Comando apply

El subcomando apply es la operación principal de Vallumix. Evalúa cada control del perfil seleccionado y, si el sistema no cumple, aplica la remediación correspondiente tras crear un respaldo.

Sintaxis

vallumix apply [FLAGS] --profile <perfil>

Flags específicos de apply

Además de las flags globales, apply soporta:

Comportamiento

1. Validación: comprueba root, distro soportada, espacio en disco.
2. Carga de perfil: lee el TOML del perfil y resuelve la lista de controles.
3. Creación de sesión de respaldo: directorio versionado en /var/backups/vallumix/<timestamp>/.
4. Iteración por controles: para cada control:
   • check: ¿cumple? → Compliant, salta al siguiente.
   • backup: copia archivos a la sesión de respaldo.
   • apply: ejecuta la remediación.
   • post_check: verifica que el cambio surtió efecto.
5. Generación de reportes: según los formatos solicitados.
6. Resumen: tasa de cumplimiento, estados, ruta al reporte.
7. Código de salida: 0 si cumple umbral, 1 si no, 2 o 3 si hay errores.

Ejemplos

Aplicación básica

sudo vallumix apply --profile web

Aplica el perfil web con configuración por defecto. Genera un reporte HTML en /tmp.

Aplicación con umbral y reporte JSON

sudo vallumix apply --profile database --threshold 90 --report json --output /tmp/db-hardening

Si la tasa de cumplimiento es inferior al 90%, el comando devuelve 1.

Dry-run previo a aplicación

sudo vallumix apply --profile bastion --dry-run --verbose

Muestra todos los cambios que se harían sin ejecutarlos.

Aplicación silenciosa en pipeline

sudo vallumix apply --profile web --quiet --threshold 95 --report junit --output /tmp/results

Útil en scripts donde solo importa el código de salida y el artefacto JUnit.

Estados de control en apply

En el reporte de una ejecución apply, cada control aparece con uno de estos estados:

Un control en estado `Failed` indica que el sistema sigue en una configuración insegura para ese control. Revisa el reporte detallado para entender por qué la remediación no funcionó: puede deberse a un archivo de configuración inesperado, a un servicio que bloquea la modificación, o a un bug en la implementación del control.

Comando audit

El subcomando audit evalúa la postura de seguridad del sistema sin aplicar ningún cambio. Es la herramienta principal para auditorías de cumplimiento, evaluaciones de riesgo y líneas base de seguridad.

Sintaxis

vallumix audit [FLAGS] --profile <perfil>

Flags específicas de audit

Comportamiento

1. Validación: root, distro soportada.
2. Carga de perfil: lee el TOML y resuelve controles.
3. Iteración por controles: para cada control, ejecuta únicamente check.
   • No se crean respaldos.
   • No se ejecuta apply.
   • No se ejecuta post_check (no hay cambio que verificar).
4. Generación de reportes: con los estados Compliant o NonCompliant.
5. Resumen: tasa de cumplimiento.
6. Código de salida: 0 si cumple umbral, 1 si no.

Paralelismo con rayon

A diferencia de apply, el modo audit paraleliza la ejecución de check mediante rayon. Los controles que solo leen estado del sistema son independientes entre sí, por lo que pueden evaluarse concurrentemente de forma segura.

#![allow(unused)]
fn main() {
// Simplificación del motor de audit
use rayon::prelude::*;

let results: Vec<ControlResult> = controls
    .par_iter()   // Iterador paralelo de rayon
    .map(|control| control.check(&ctx))
    .collect();
}

Esto reduce significativamente el tiempo de auditoría en sistemas con muchos controles. El paralelismo es seguro porque check es de solo lectura y cada control implementa Send + Sync.

Ejemplos

Auditoría básica

sudo vallumix audit --profile web

Evalúa todos los controles del perfil web y muestra el resumen en consola.

Auditoría con reporte HTML y JSON

sudo vallumix audit --profile database --report html,json --output /tmp/compliance-audit

Genera /tmp/compliance-audit.html y /tmp/compliance-audit.json.

Auditoría con umbral para pipeline

sudo vallumix audit --profile web --threshold 85 --report junit --output /tmp/audit.xml

Devuelve 1 si la tasa de cumplimiento es menor al 85%. Útil para gates de calidad en CI/CD.

Auditoría verbose para diagnóstico

sudo vallumix audit --profile bastion --verbose

Muestra los comandos exactos que se ejecutaron para evaluar cada control, útil para entender falsos positivos o negativos.

Estados de control en audit

Ejecuta `audit` periódicamente (semanal o mensual) como tarea cron para detectar desviaciones de configuración causadas por actualizaciones de paquetes, cambios manuales de administradores o despliegues de aplicaciones. Un `audit` que baja de 95% a 70% en una semana es una señal de alerta clara.

Comando rollback

El subcomando rollback restaura configuraciones previas desde los respaldos versionados generados por apply. Permite revertir cambios de forma granular o masiva.

Sintaxis

vallumix rollback [FLAGS] [--control-id <id> | --session <sesión>]

Flags específicas de rollback

Debes especificar exactamente uno de `--control-id` o `--session`. Si no especificas ninguno, o si especificas ambos, Vallumix devuelve un error de configuración (código `2`).

Comportamiento

1. Validación: root, existencia del directorio de respaldos.
2. Resolución de sesión: si se usa --session last, selecciona el directorio con el timestamp más reciente.
3. Verificación de integridad: recalcula SHA-256 de cada archivo de respaldo y lo compara con checksums.sha256.
4. Restauración: copia los archivos de respaldo a sus ubicaciones originales.
5. Post-check: ejecuta check en los controles restaurados para confirmar que el sistema volvió al estado previo.
6. Reporte: documenta qué controles se restauraron, cuáles fallaron la verificación de integridad, y el estado final.

Ejemplos

Rollback del último control problemático

sudo vallumix rollback --control-id 5.2.4

Restaura únicamente el control 5.2.4 de la última sesión de respaldo.

Rollback de la última sesión completa

sudo vallumix rollback --session last

Restaura todos los controles aplicados en la sesión más reciente.

Rollback de una sesión específica

sudo vallumix rollback --session 2026-05-01T09-15-33

Restaura todos los controles de la sesión con timestamp exacto.

Dry-run de rollback

sudo vallumix rollback --session last --dry-run --verbose

Muestra qué archivos se restaurarían, desde qué respaldos, y el resultado esperado del post-check, sin modificar nada.

Estados de control en rollback

Si un control muestra `IntegrityCheckFailed`, no intentes restaurar manualmente el archivo de respaldo sin investigar primero por qué el hash cambió. Podría indicar corrupción de disco, manipulación del archivo, o un bug en el proceso de respaldo. Contacta al administrador del sistema o al equipo de seguridad.

Comando list

El subcomando list muestra el catálogo completo de controles disponibles en Vallumix, filtrados por perfil. Es útil para explorar qué controles se ejecutarían antes de lanzar un apply o audit.

Sintaxis

vallumix list [FLAGS]

Flags específicas de list

Formato de salida

La salida por defecto es una tabla en terminal con las siguientes columnas:

ID      | SEVERITY | PROFILE    | DESCRIPTION
--------|----------|------------|------------------------------------------
1.1.1.1 | Low      | web,db,ba  | Disable cramfs support
1.1.1.2 | Low      | web,db,ba  | Disable freevxfs support
5.2.4   | Critical | web,db,ba  | Ensure SSH root login is disabled
3.4.1   | Medium   | web,db     | Ensure firewalld is installed

Columnas

• ID: identificador CIS del control (por ejemplo, 5.2.4).
• SEVERITY: nivel de criticidad (Critical, High, Medium, Low).
• PROFILE: perfiles que incluyen este control (web, database, bastion, abreviados como w, db, ba).
• DESCRIPTION: descripción legible de la recomendación.

Ejemplos

Listar controles del perfil web

vallumix list --profile web

Listar controles del perfil bastión sin colores

vallumix list --profile bastion --no-color

Filtrar controles críticos con grep

vallumix list --profile web --no-color | grep Critical

Contar controles por perfil

vallumix list --profile web --no-color | wc -l
vallumix list --profile database --no-color | wc -l
vallumix list --profile bastion --no-color | wc -l

Usa `vallumix list` como paso de descubrimiento en scripts de aprovisionamiento. Antes de aplicar un perfil, lista sus controles y notifica al operador qué cambios esperar. Esto reduce la ansiedad en equipos que nunca han usado Vallumix.

Comando completion

El subcomando completion genera scripts de autocompletado para los shells más utilizados. Esto permite que al escribir vallumix <TAB> el shell sugiera subcomandos, flags y valores posibles.

Sintaxis

vallumix completion <shell>

Shells soportados

Bash

Genera y activa el autocompletado:

vallumix completion bash > /tmp/vallumix.bash
sudo cp /tmp/vallumix.bash /etc/bash_completion.d/vallumix

Para usuarios individuales sin privilegios de root:

mkdir -p ~/.local/share/bash-completion/completions
vallumix completion bash > ~/.local/share/bash-completion/completions/vallumix

Recarga la sesión o ejecuta source ~/.bashrc para activar.

Zsh

Con Oh-My-Zsh:

mkdir -p ~/.zsh/completions
vallumix completion zsh > ~/.zsh/completions/_vallumix

Asegúrate de que tu ~/.zshrc incluye el directorio de completions en fpath:

fpath+=(~/.zsh/completions)
autoload -U compinit && compinit

Recarga la sesión o ejecuta source ~/.zshrc.

Fish

mkdir -p ~/.config/fish/completions
vallumix completion fish > ~/.config/fish/completions/vallumix.fish

Fish recarga los completions automáticamente; no necesitas reiniciar la sesión.

PowerShell

vallumix completion powershell > vallumix.ps1

Añádelo en tu perfil de PowerShell:

. ./vallumix.ps1

Verificación

Tras instalar el autocompletado, pruébalo:

vallumix <TAB><TAB>
# Debe mostrar: apply, audit, rollback, list, completion, help

vallumix apply --<TAB><TAB>
# Debe mostrar: --profile, --dry-run, --verbose, --threshold, etc.

vallumix apply --profile <TAB><TAB>
# Debe mostrar: web, database, bastion

Incluye la generación de completions en tu script de instalación automatizada. Un administrador que puede autocompletar flags y perfiles comete menos errores de tipeo y descubre funcionalidades que de otro modo pasarían desapercibidas.

Catálogo de Controles

Vallumix implementa 70 controles del CIS Benchmark organizados en 7 dominios de seguridad. Cada control es una unidad atómica de verificación y remediación que comprueba una configuración específica y, si no cumple, aplica el cambio de hardening recomendado.

Los controles siguen el esquema de numeración del CIS Benchmark (por ejemplo, 1.1.1.1 para sistema de archivos, 5.2.4 para SSH). Cada control implementa el trait Control: verifica el estado actual, aplica la remediación si es necesario, y verifica de nuevo para confirmar la corrección.

Los 7 Dominios

No todos los controles se aplican a todos los roles de servidor. Utiliza un **perfil** (`web`, `database`, `bastion`) para seleccionar solo los controles relevantes para la función de tu servidor. Los perfiles se definen en archivos TOML bajo `profiles/`.

Tabla de Referencia de Controles

La siguiente tabla lista una muestra representativa de los 70 controles implementados por Vallumix. Los niveles de severidad se asignan en función de las recomendaciones del CIS y del impacto potencial del incumplimiento.

Cómo Usar Este Catálogo

• Navegar por dominio: la barra lateral agrupa los controles en los 7 dominios listados arriba.
• Buscar por CIS ID: cada página lista los controles en orden CIS con su ID exacto.
• Comprobar cobertura del perfil: la columna Perfiles indica qué roles de servidor incluyen el control.
• Verificar manualmente: cada página de control incluye el comando de verificación manual para que puedas confirmar el trabajo de Vallumix de forma independiente.

Vallumix es idempotente: ejecutar `apply` varias veces con el mismo perfil produce el mismo estado final. Los controles que ya cumplen se omiten automáticamente.

Para la lista completa de los 70 controles, inspecciona el código fuente en crates/vallumix-controls/src/lib.rs o las definiciones de perfil en profiles/web.toml, profiles/database.toml y profiles/bastion.toml.

Controles de Hardening del Sistema de Archivos

El dominio de sistema de archivos (sección CIS 1.1.x) contiene 9 controles que reducen la superficie de ataque deshabilitando módulos del kernel de sistemas de archivos no utilizados y endureciendo las opciones de montaje temporales. Los controladores de sistema de archivos no utilizados pueden ser explotados para cargar medios maliciosos o escapar de contenedores; deshabilitarlos elimina una clase de ataques a nivel de kernel.

1.1.1.1 — Deshabilitar cramfs

Qué hace apply: Vallumix comprueba si el módulo del kernel cramfs es cargable. Si está presente, crea o actualiza /etc/modprobe.d/cramfs.conf con install cramfs /bin/true y ejecuta rmmod cramfs si el módulo está actualmente cargado.

Verificación manual:

modprobe -n -v cramfs
lsmod | grep cramfs

Se espera: el primer comando debe mostrar /bin/true, y el segundo no debe devolver nada.

Justificación de seguridad: cramfs es un sistema de archivos de solo lectura comprimido raramente utilizado en servidores modernos. Mantener el módulo disponible permite a un atacante con acceso local montar imágenes manipuladas que podrían contener cargas maliciosas. Deshabilitarlo sigue el principio de mínima funcionalidad.

1.1.1.2 — Deshabilitar freevxfs

Qué hace apply: Crea /etc/modprobe.d/freevxfs.conf con install freevxfs /bin/true y descarga el módulo si está activo.

Verificación manual:

modprobe -n -v freevxfs
lsmod | grep freevxfs

Justificación de seguridad: freevxfs es el controlador de compatibilidad con VxFS de FreeBSD. No tiene uso legítimo en servidores Linux y representa un punto de entrada innecesario en el kernel.

1.1.1.3 — Deshabilitar jffs2

Qué hace apply: Instala una lista negra de modprobe para jffs2 (Journalling Flash File System v2) y lo elimina de la memoria.

Verificación manual:

modprobe -n -v jffs2
lsmod | grep jffs2

Justificación de seguridad: jffs2 está diseñado para dispositivos de memoria flash raw como sistemas embebidos. En un servidor con almacenamiento en bloque, este módulo no tiene propósito y podría ser abusado para interactuar con medios físicos.

1.1.1.4 — Deshabilitar hfs

Qué hace apply: Añade a la lista negra el módulo hfs (Apple Hierarchical File System) mediante modprobe y lo descarga.

Verificación manual:

modprobe -n -v hfs
lsmod | grep hfs

Justificación de seguridad: hfs permite montar volúmenes con formato legado de Apple. Los servidores no necesitan esta capacidad; eliminarlo evita que un atacante introduzca o extraiga datos mediante medios removibles con formato HFS.

1.1.1.5 — Deshabilitar hfsplus

Qué hace apply: Añade a la lista negra el módulo hfsplus y lo descarga si está activo.

Verificación manual:

modprobe -n -v hfsplus
lsmod | grep hfsplus

Justificación de seguridad: hfsplus es el controlador del sistema de archivos moderno de Apple. Se aplica el mismo razonamiento que para hfs: ninguna carga de trabajo de servidor requiere soporte nativo para sistemas de archivos de Apple.

1.1.1.6 — Deshabilitar squashfs

Qué hace apply: Añade a la lista negra el módulo squashfs. Nota: algunos runtimes de contenedores usan squashfs internamente; verifica tu carga de trabajo antes de aplicar este control.

Verificación manual:

modprobe -n -v squashfs
lsmod | grep squashfs

Justificación de seguridad: squashfs es un sistema de archivos comprimido de solo lectura usado en CDs en vivo y algunas capas de contenedores. Si tu servidor no depende de paquetes snap o tecnologías similares, deshabilitarlo elimina otro vector de montaje.

Algunas distribuciones usan squashfs para paquetes snap. Verifica que `snap list` esté vacío o no sea necesario antes de aplicar este control.

1.1.1.7 — Deshabilitar udf

Qué hace apply: Añade a la lista negra el módulo udf (Universal Disk Format, usado por DVD-ROMs).

Verificación manual:

modprobe -n -v udf
lsmod | grep udf

Justificación de seguridad: udf permite leer medios ópticos. Los servidores sin unidades ópticas no tienen uso para este módulo, y podría ser explotado para montar imágenes UDF maliciosas.

1.1.10 — Deshabilitar almacenamiento USB

Qué hace apply: Crea /etc/modprobe.d/usb-storage.conf con install usb-storage /bin/true y elimina el módulo de la memoria.

Verificación manual:

modprobe -n -v usb-storage
lsmod | grep usb-storage

Justificación de seguridad: Este es uno de los controles de sistema de archivos de mayor impacto. Deshabilitar usb-storage evita que el kernel reconozca dispositivos de almacenamiento USB masivo, bloqueando un vector de ataque físico común (por ejemplo, unidades USB maliciosas insertadas en una sala de servidores o un host virtualizado con passthrough USB).

1.1.2.1 — Endurecer opciones de montaje de tmpfs

Qué hace apply: Asegura que /tmp, /var/tmp y /dev/shm estén montados con las opciones noexec, nosuid y nodev. Si aún no están montados mediante fstab o unidades de montaje de systemd, Vallumix actualiza /etc/fstab o crea una unidad de montaje de anulación.

Verificación manual:

findmnt -n -o OPTIONS /tmp
findmnt -n -o OPTIONS /var/tmp
findmnt -n -o OPTIONS /dev/shm

Cada una debe contener noexec, nosuid y nodev.

Justificación de seguridad: Los directorios temporales son frecuentemente utilizados por atacantes para depositar y ejecutar cargas. El flag noexec previene la ejecución de binarios desde estas rutas, nosuid bloquea la escalada mediante setuid, y nodev previene el abuso de archivos de dispositivo. Juntos restringen significativamente la actividad post-explotación.

Controles de Deshabilitación de Servicios

El dominio de servicios (sección CIS 2.2.x) contiene 12 controles que detienen, deshabilitan y enmascaran servicios orientados a la red que no son necesarios para el rol del servidor. Cada demonio en ejecución es una potencial fuente de vulnerabilidades; eliminar servicios innecesarios es una de las formas más efectivas de reducir la superficie de ataque.

2.2.2 — Deshabilitar CUPS

Qué hace apply: Detiene el servicio cups, lo deshabilita del inicio en el arranque, y enmascara la unidad para que no pueda iniciarse manualmente o por otro servicio.

Verificación manual:

systemctl is-enabled cups
systemctl status cups

Se espera: masked o disabled, y el servicio debe estar inactivo.

Justificación de seguridad: CUPS (Common UNIX Printing System) expone puertos de red para descubrimiento de impresoras y envío de trabajos. Los servidores raramente necesitan capacidad de impresión, y CUPS tiene un historial de vulnerabilidades explotables remotamente.

2.2.3 — Deshabilitar Avahi

Qué hace apply: Detiene, deshabilita y enmascara el servicio avahi-daemon.

Verificación manual:

systemctl is-enabled avahi-daemon
systemctl status avahi-daemon

Justificación de seguridad: Avahi implementa mDNS/DNS-SD (Bonjour) para descubrimiento de servicios en la red local. Multidifunde información del host y de servicios, lo que filtra la superficie de ataque a cualquiera en el segmento de red local, y ha sido objetivo de ataques de amplificación.

2.2.4 — Deshabilitar servidor DHCP

Qué hace apply: Detiene, deshabilita y enmascara el servicio de servidor DHCP (por ejemplo, isc-dhcp-server, dhcpd).

Verificación manual:

systemctl is-enabled dhcpd 2>/dev/null || systemctl is-enabled isc-dhcp-server

Justificación de seguridad: Un servidor DHCP solo debe ejecutarse en infraestructura de red dedicada. Dejarlo habilitado accidentalmente en un servidor puede llevar a ataques de DHCP rogue, secuestro de red y incorporación no autorizada de dispositivos.

2.2.5 — Deshabilitar servidor LDAP

Qué hace apply: Detiene, deshabilita y enmascara el servicio de servidor LDAP (por ejemplo, slapd).

Verificación manual:

systemctl is-enabled slapd

Justificación de seguridad: A menos que el servidor sea explícitamente un proveedor de identidad, un servidor LDAP expone información de directorio y tráfico de autenticación que debería aislarse en servicios de directorio dedicados.

2.2.6 — Deshabilitar servidor NFS

Qué hace apply: Detiene, deshabilita y enmascara los servicios de servidor NFS (nfs-server, rpc-nfsd).

Verificación manual:

systemctl is-enabled nfs-server

Justificación de seguridad: Las exportaciones NFS pueden filtrar datos sensibles si están mal configuradas. El protocolo NFS históricamente ha sufrido problemas de suplantación de UID y autenticación débil. Solo los servidores de archivos dedicados deberían ejecutar NFS.

2.2.7 — Deshabilitar rpcbind

Qué hace apply: Detiene, deshabilita y enmascara rpcbind, el asignador de puertos RPC requerido por NFS y otros servicios RPC legados.

Verificación manual:

systemctl is-enabled rpcbind

Justificación de seguridad: rpcbind mapea números de programa RPC a puertos de red. Es esencial para NFSv3 pero innecesario en servidores modernos. Ha sido usado en ataques DDoS de amplificación y proporciona información sobre servicios RPC en ejecución a escáneres remotos.

2.2.8 — Deshabilitar servidor DNS (BIND)

Qué hace apply: Detiene, deshabilita y enmascara named (BIND) o el paquete de servidor DNS específico de la distribución.

Verificación manual:

systemctl is-enabled named

Justificación de seguridad: Ejecutar un servidor DNS recursivo o autoritativo en un servidor de propósito general aumenta la superficie de ataque y el riesgo de envenenamiento de caché DNS o abuso de amplificación. El DNS debería delegarse a resolvedores dedicados.

2.2.9 — Deshabilitar vsftpd

Qué hace apply: Detiene, deshabilita y enmascara el servidor FTP vsftpd.

Verificación manual:

systemctl is-enabled vsftpd

Justificación de seguridad: FTP transmite credenciales y datos en texto plano. Los flujos de trabajo modernos deberían usar SFTP (sobre SSH) o HTTPS. Un servidor FTP habilitado accidentalmente es una fuente frecuente de fugas de datos.

2.2.10 — Deshabilitar servidor HTTP

Qué hace apply: Detiene, deshabilita y enmascara el servicio httpd o apache2.

Verificación manual:

systemctl is-enabled httpd 2>/dev/null || systemctl is-enabled apache2

Justificación de seguridad: Este control se incluye en los perfiles database y bastion porque esos roles no deberían servir contenido web. Solo el perfil web omite este control, asumiendo que el administrador quiere explícitamente un servidor web.

2.2.11 — Deshabilitar Dovecot

Qué hace apply: Detiene, deshabilita y enmascara el servidor de correo IMAP/POP3 dovecot.

Verificación manual:

systemctl is-enabled dovecot

Justificación de seguridad: Los protocolos de acceso a correo deberían centralizarse en servidores de correo dedicados. Ejecutar Dovecot en un servidor web o de bases de datos expone innecesariamente credenciales de correo y almacenamiento.

2.2.14 — Deshabilitar demonio SNMP

Qué hace apply: Detiene, deshabilita y enmascara snmpd.

Verificación manual:

systemctl is-enabled snmpd

Justificación de seguridad: SNMP (especialmente v1 y v2c) usa cadenas de comunidad que a menudo se dejan en valores predeterminados como public. Incluso SNMPv3 requiere una gestión cuidadosa de claves. Si se necesita monitoreo, use métricas sin agente (Prometheus node_exporter, Telegraf) en su lugar.

2.2.15 — Deshabilitar demonio rsync

Qué hace apply: Detiene, deshabilita y enmascara el servicio rsyncd.

Verificación manual:

systemctl is-enabled rsync

Justificación de seguridad: El demonio rsync expone un puerto TCP (873) sin cifrado por defecto. Aunque rsync sobre SSH es seguro y ampliamente utilizado, el demonio independiente no debería ejecutarse a menos que se requiera explícitamente para un espejo público.

Controles de Red y Kernel

El dominio de red (sección CIS 3.1.x – 3.3.x) contiene 9 controles que endurecen la pila de red del kernel de Linux. Estos parámetros se aplican mediante sysctl y el subsistema de cortafuegos. Las configuraciones de red mal configuradas pueden convertir un servidor en un relé de tráfico, exponerlo a suplantación o hacerlo vulnerable a ataques de inundación de conexiones.

3.1.1 — Deshabilitar reenvío IP

Qué hace apply: Establece net.ipv4.ip_forward = 0 y net.ipv6.conf.all.forwarding = 0 en /etc/sysctl.conf (o un drop-in bajo /etc/sysctl.d/) y aplica el cambio con sysctl -p.

Verificación manual:

sysctl net.ipv4.ip_forward
sysctl net.ipv6.conf.all.forwarding

Ambos deberían devolver 0.

Justificación de seguridad: El reenvío IP permite al kernel enrutar tráfico entre interfaces. A menos que el servidor sea explícitamente un enrutador o puerta de enlace VPN, habilitar el reenvío puede convertirlo en un relé de tráfico no deseado para atacantes. Este es uno de los controles de red de mayor severidad.

3.1.2 — Deshabilitar redirecciones ICMP de envío

Qué hace apply: Establece net.ipv4.conf.all.send_redirects = 0 y net.ipv4.conf.default.send_redirects = 0.

Verificación manual:

sysctl net.ipv4.conf.all.send_redirects
sysctl net.ipv4.conf.default.send_redirects

Justificación de seguridad: Los mensajes de redirección ICMP son usados por enrutadores para informar a los hosts sobre mejores rutas. Un actor malicioso en la red local puede falsificar redirecciones para secuestrar tráfico (hombre en el medio). Deshabilitarlos previene este vector de ataque.

3.2.1 — Deshabilitar enrutamiento por origen

Qué hace apply: Establece net.ipv4.conf.all.accept_source_route = 0 y net.ipv4.conf.default.accept_source_route = 0.

Verificación manual:

sysctl net.ipv4.conf.all.accept_source_route
sysctl net.ipv4.conf.default.accept_source_route

Justificación de seguridad: El enrutamiento por origen permite al remitente especificar la ruta de red exacta que los paquetes deben seguir. Los atacantes pueden usar esto para eludir reglas de cortafuegos y políticas de enrutamiento dictando su propio camino a través de la red.

3.2.2 — Deshabilitar aceptación de redirecciones ICMP

Qué hace apply: Establece net.ipv4.conf.all.accept_redirects = 0 y net.ipv4.conf.default.accept_redirects = 0.

Verificación manual:

sysctl net.ipv4.conf.all.accept_redirects
sysctl net.ipv4.conf.default.accept_redirects

Justificación de seguridad: Aceptar redirecciones ICMP permite a un atacante en el mismo segmento de red redirigir el tráfico del host a través de una máquina comprometida. Este control complementa 3.1.2 al deshabilitar redirecciones en ambas direcciones.

3.2.3 — Deshabilitar envío de redirecciones ICMP

Qué hace apply: Asegura que net.ipv4.conf.all.send_redirects sea 0 (se solapa con 3.1.2 pero se valida independientemente).

Verificación manual:

sysctl net.ipv4.conf.all.send_redirects

Justificación de seguridad: Evita que el servidor mismo envíe redirecciones ICMP, que podrían ser falsificadas o mal utilizadas para influir en las tablas de enrutamiento de hosts pares.

3.2.6 — Habilitar filtrado de ruta inversa (rp_filter)

Qué hace apply: Establece net.ipv4.conf.all.rp_filter = 1 y net.ipv4.conf.default.rp_filter = 1.

Verificación manual:

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.default.rp_filter

Justificación de seguridad: El filtrado de ruta inversa descarta paquetes que llegan por una interfaz diferente a la que el kernel usaría para alcanzar la dirección de origen. Esta es una defensa principal contra ataques de suplantación de IP y falsificación de direcciones de origen.

3.2.7 — Habilitar cookies SYN TCP

Qué hace apply: Establece net.ipv4.tcp_syncookies = 1.

Verificación manual:

sysctl net.ipv4.tcp_syncookies

Justificación de seguridad: Las cookies SYN permiten al kernel mantener conexiones TCP durante un ataque de inundación SYN sin asignar recursos para conexiones semiabiertas. Cuando el backlog se llena, el kernel envía cookies criptográficas en lugar de mantener estado, permitiendo a clientes legítimos completar el handshake mientras descarta a los atacantes.

3.3.1 — Asegurar que firewalld esté configurado

Qué hace apply: Verifica que firewalld esté instalado, en ejecución, y tenga una política de denegación predeterminada. Si el servicio no está activo, Vallumix lo habilita e inicia. No define reglas específicas; el administrador debe configurar los puertos según las necesidades de la aplicación.

Verificación manual:

systemctl is-active firewalld
firewall-cmd --state
firewall-cmd --get-default-zone

Justificación de seguridad: Un cortafuegos a nivel de host es la última línea de defensa contra ataques de red. Incluso si el servidor está detrás de un cortafuegos perimetral, el filtrado local protege contra movimiento lateral y reglas ascendentes mal configuradas. El modelo basado en zonas de firewalld se integra bien con entornos cloud dinámicos.

Vallumix no abre ni cierra puertos específicos porque eso depende de la aplicación. Después de aplicar este control, configura los servicios requeridos con `firewall-cmd --permanent --add-service=...`.

Controles de Registro y Auditoría

El dominio de registro (sección CIS 4.1.x) contiene 11 controles que aseguran que los eventos del sistema sean capturados, retenidos y protegidos contra manipulación. Sin registros confiables, detectar intrusiones, reconstruir incidentes y satisfacer requisitos de cumplimiento es imposible. Este dominio cubre rsyslog, systemd-journald, auditd, rotación de logs y permisos de archivos de registro.

4.1.1.1 — Asegurar que rsyslog esté instalado

Qué hace apply: Verifica que el paquete rsyslog esté instalado. Si falta, no lo instala automáticamente (para evitar cambios inesperados en el gestor de paquetes) pero reporta el control como no cumplido.

Verificación manual:

rpm -q rsyslog 2>/dev/null || dpkg -l rsyslog

Justificación de seguridad: rsyslog es el demonio syslog estándar en la mayoría de las distribuciones Linux. Es la base para la recolección centralizada de logs, integración con SIEM y análisis forense. Una instalación faltante de rsyslog significa que muchos eventos del sistema nunca se persisten en disco.

4.1.1.2 — Asegurar que rsyslog esté configurado

Qué hace apply: Comprueba /etc/rsyslog.conf y /etc/rsyslog.d/*.conf en busca de reglas de registro estándar (auth, authpriv, cron, kern, mail, user). Si faltan reglas, Vallumix las añade a /etc/rsyslog.d/50-default.conf.

Verificación manual:

grep -r 'auth,authpriv' /etc/rsyslog.d/
grep -r 'cron\.' /etc/rsyslog.d/

Justificación de seguridad: Sin reglas rsyslog apropiadas, los fallos de autenticación, la salida de trabajos cron y los mensajes del kernel pueden descartarse silenciosamente. Este control asegura que el conjunto mínimo de reglas recomendadas por CIS esté presente.

4.1.1.3 — Asegurar permisos de archivos de rsyslog

Qué hace apply: Establece los permisos de los archivos de configuración de rsyslog en 640 y la propiedad en root:adm (o grupo apropiado para la distribución).

Verificación manual:

stat -c '%a %U:%G' /etc/rsyslog.conf
stat -c '%a %U:%G' /etc/rsyslog.d/

Justificación de seguridad: Los archivos de configuración de logs pueden redirigir, suprimir o desviar flujos de registro. Si son escribibles por usuarios no root, un atacante podría deshabilitar el registro de sus actividades o redirigir logs a /dev/null.

4.1.2.1 — Asegurar que journald esté configurado

Qué hace apply: Verifica que /etc/systemd/journald.conf contenga Storage=persistent y ForwardToSyslog=yes. Si faltan, los añade bajo la sección [Journal].

Verificación manual:

grep -E '^Storage=|^ForwardToSyslog=' /etc/systemd/journald.conf

Justificación de seguridad: Por defecto, journald almacena logs en memoria volátil (/run/log/journal). Una configuración de almacenamiento persistente asegura que los logs sobrevivan a los reinicios, lo cual es esencial para la investigación post-reinicio de incidentes.

4.1.2.2 — Asegurar que exista anulación de journald

Qué hace apply: Crea /etc/systemd/journald.conf.d/99-vallumix.conf con configuraciones endurecidas (Compress=yes, SystemMaxUse=500M, MaxFileSec=1week).

Verificación manual:

cat /etc/systemd/journald.conf.d/99-vallumix.conf

Justificación de seguridad: Un archivo de anulación evita que las actualizaciones de la distribución sobrescriban las configuraciones de hardening. Limitar el uso de disco (SystemMaxUse) protege contra ataques de denegación de servicio por llenado de logs.

4.1.3.1 — Asegurar que auditd esté instalado

Qué hace apply: Verifica que auditd y audispd-plugins estén instalados. Si faltan, reporta no cumplido.

Verificación manual:

rpm -q audit 2>/dev/null || dpkg -l auditd

Justificación de seguridad: auditd captura eventos relevantes para la seguridad a nivel de kernel: acceso a archivos, invocación de syscalls, inicios de sesión de usuarios y escaladas de privilegios. Es la columna vertebral de las trazas de auditoría de Linux y es requerido por la mayoría de los marcos de cumplimiento.

4.1.3.2 — Asegurar que auditd esté configurado

Qué hace apply: Comprueba que /etc/audit/auditd.conf contenga log_group = root (o adm) y max_log_file_action = ROTATE.

Verificación manual:

grep '^max_log_file_action' /etc/audit/auditd.conf
grep '^log_group' /etc/audit/auditd.conf

Justificación de seguridad: Una configuración apropiada de auditd asegura que los logs roten automáticamente y sean legibles solo por administradores autorizados. Sin rotación, la partición de auditoría puede llenarse y bloquear el demonio.

4.1.4.1 — Asegurar que existan reglas de auditoría de identidad

Qué hace apply: Añade reglas de auditoría para monitorear cambios en archivos de identidad: /etc/group, /etc/passwd, /etc/gshadow, /etc/shadow, /etc/security/opasswd.

Verificación manual:

auditctl -l | grep -E '(/etc/passwd|/etc/shadow|/etc/group|/etc/gshadow)'

Justificación de seguridad: Los cambios no autorizados en archivos de identidad son un indicador claro de creación de cuentas, escalada de privilegios o instalación de puertas traseras. Monitorear estos archivos permite la detección en tiempo real de manipulaciones.

4.1.4.2 — Asegurar auditoría de eventos de inicio de sesión

Qué hace apply: Añade reglas de auditoría para /var/log/lastlog, /var/run/faillock y binarios de inicio de sesión (/usr/bin/login, /usr/bin/su).

Verificación manual:

auditctl -l | grep -E '(lastlog|faillock|/usr/bin/login|/usr/bin/su)'

Justificación de seguridad: Los eventos de inicio de sesión son la fuente primaria de datos para detección de fuerza bruta y revisiones de acceso. Sin reglas de auditoría, los inicios de sesión fallidos y exitosos pueden existir solo en buffers de corta duración.

4.1.4.3 — Asegurar auditoría de eventos de sesión

Qué hace apply: Añade reglas de auditoría para inicio de sesión (/usr/bin/sudo, /usr/bin/sudoedit, /usr/bin/ssh) y terminación de sesión.

Verificación manual:

auditctl -l | grep -E '(/usr/bin/sudo|/usr/bin/ssh)'

Justificación de seguridad: La auditoría a nivel de sesión captura quién ejecutó comandos privilegiados y cuándo. Esto es crítico para la no repudio y para reconstruir la línea de tiempo de un incidente.

4.1.7 — Asegurar que logrotate esté configurado

Qué hace apply: Verifica que /etc/logrotate.conf exista y que /var/log esté cubierto por una regla de logrotate con período de rotación weekly o menor y retención de al menos 4 rotaciones.

Verificación manual:

grep -E '^weekly|^rotate' /etc/logrotate.conf
ls /etc/logrotate.d/

Justificación de seguridad: Sin rotación de logs, estos crecen indefinidamente y eventualmente agotan el espacio en disco. Los atacantes pueden explotar esto inundando logs para ocultar sus rastros o causar una denegación de servicio. La rotación también delimita la ventana de retención, lo que ayuda a cumplir con regulaciones de protección de datos.

Controles de Acceso, Autenticación y Autorización

El dominio de acceso y autenticación cubre el hardening de SSH (sección CIS 5.2.x) y la política de autenticación a nivel de sistema (PAM, umask, tiempo de espera del shell — secciones CIS 5.1.x, 5.3.x – 5.5.x). Con 21 controles en total entre SSH y autenticación, este es el dominio más crítico para prevenir accesos no autorizados. Un único parámetro SSH mal configurado puede exponer el servidor a fuerza bruta, relleno de credenciales o compromiso remoto completo.

Controles de SSH

5.2.1 — Asegurar que se usa el Protocolo 2 de SSH

Qué hace apply: Establece Protocol 2 en /etc/ssh/sshd_config. El Protocolo 1 es obsoleto y criptográficamente roto.

Verificación manual:

grep -E '^Protocol' /etc/ssh/sshd_config

Se espera: Protocol 2 o la línea ausente (OpenSSH moderno usa 2 por defecto).

Justificación de seguridad: El Protocolo 1 de SSH carece de comprobaciones de integridad, usa CRC-32 débil para validación de paquetes y es vulnerable a ataques de inserción. El Protocolo 2 introduce integridad criptográfica robusta e intercambio de claves seguro.

5.2.2 — Establecer LogLevel de SSH a INFO

Qué hace apply: Establece LogLevel INFO en sshd_config para asegurar que los intentos de inicio de sesión, intercambios de claves y fallos de autenticación se registren.

Verificación manual:

grep '^LogLevel' /etc/ssh/sshd_config

Justificación de seguridad: INFO captura suficiente detalle para detección de intrusiones e investigación forense sin la verbosidad de DEBUG. QUIET o FATAL ocultarían patrones de fuerza bruta.

5.2.3 — Deshabilitar contraseñas vacías

Qué hace apply: Establece PermitEmptyPasswords no en sshd_config.

Verificación manual:

grep '^PermitEmptyPasswords' /etc/ssh/sshd_config

Justificación de seguridad: Las contraseñas vacías permiten el inicio de sesión sin ninguna credencial. Incluso en redes internas, esto es inaceptable porque evade toda la capa de autenticación.

5.2.4 — Deshabilitar login de root

Qué hace apply: Establece PermitRootLogin no (o prohibit-password) en sshd_config y reinicia el servicio SSH.

Verificación manual:

grep '^PermitRootLogin' /etc/ssh/sshd_config

Justificación de seguridad: El login de root es el objetivo de mayor valor para ataques de fuerza bruta. Deshabilitarlo obliga a los atacantes a adivinar tanto un nombre de usuario como una contraseña, duplicando el espacio de búsqueda. También asegura que todas las acciones administrativas sean atribuibles a usuarios individuales mediante logs de sudo.

Este control puede bloquearte si no tienes acceso por clave como usuario no root. Verifica que `ssh -o PasswordAuthentication=no usuario@host` funcione antes de aplicar.

5.2.4b — Establecer MaxAuthTries en 4 o menos

Qué hace apply: Establece MaxAuthTries 4 en sshd_config.

Verificación manual:

grep '^MaxAuthTries' /etc/ssh/sshd_config

Justificación de seguridad: Limitar los intentos de autenticación por conexión ralentiza los ataques de fuerza bruta. Después de 4 fallos, la conexión se cierra, obligando al atacante a establecer una nueva sesión TCP.

5.2.6 — Establecer ClientAliveInterval

Qué hace apply: Establece ClientAliveInterval 300 y ClientAliveCountMax 0 para desconectar sesiones inactivas después de 5 minutos.

Verificación manual:

grep -E '^ClientAlive' /etc/ssh/sshd_config

Justificación de seguridad: Las sesiones inactivas dejadas abiertas en estaciones de trabajo compartidas o multiplexadores de terminal olvidados proporcionan una puerta abierta para cualquiera con acceso físico. La desconexión automática limita esta ventana.

5.2.8 — Limitar acceso SSH (AllowUsers / AllowGroups)

Qué hace apply: Si el administrador ha configurado AllowUsers o AllowGroups en los metadatos del perfil, Vallumix escribe esos valores en sshd_config. Por defecto, solo verifica que la directiva esté presente.

Verificación manual:

grep -E '^AllowUsers|^AllowGroups' /etc/ssh/sshd_config

Justificación de seguridad: Restringir SSH a usuarios o grupos específicos evita que cuentas deshabilitadas, terminadas o comprometidas accedan al servidor. Es especialmente importante en hosts bastión.

5.2.9 — Establecer banner de SSH

Qué hace apply: Establece Banner /etc/ssh/banner y crea el archivo de banner si no existe.

Verificación manual:

grep '^Banner' /etc/ssh/sshd_config

Justificación de seguridad: Un banner de inicio de sesión establece aviso legal y desalienta el acceso no autorizado. En algunas jurisdicciones, un banner es requerido para el enjuiciamiento exitoso bajo estatutos de delitos informáticos.

Controles de Autenticación (PAM)

5.3.1 — Asegurar que la calidad de contraseñas PAM está habilitada

Qué hace apply: Verifica que pam_pwquality.so esté referenciado en /etc/pam.d/system-auth o /etc/pam.d/common-password.

Verificación manual:

grep pam_pwquality /etc/pam.d/system-auth /etc/pam.d/common-password 2>/dev/null

Justificación de seguridad: pam_pwquality impone reglas mínimas de complejidad (longitud, clases de caracteres, comprobaciones de diccionario) en el momento de creación o cambio de contraseña. Sin él, los usuarios pueden establecer contraseñas triviales que caen ante ataques de diccionario en segundos.

5.3.2 — Asegurar longitud mínima de contraseña PAM

Qué hace apply: Establece minlen = 14 en /etc/security/pwquality.conf.

Verificación manual:

grep '^minlen' /etc/security/pwquality.conf

Justificación de seguridad: Las contraseñas más largas aumentan exponencialmente el espacio de búsqueda de fuerza bruta. Una frase de contraseña de 14 caracteres con clases de caracteres mixtas es actualmente considerada el mínimo para resistir el cracking offline de hashes.

5.3.4 — Asegurar que faillock de PAM está configurado

Qué hace apply: Añade líneas pam_faillock.so a la pila de autenticación con deny=5, unlock_time=900 y even_deny_root.

Verificación manual:

grep pam_faillock /etc/pam.d/system-auth /etc/pam.d/password-auth 2>/dev/null

Justificación de seguridad: faillock bloquea temporalmente cuentas tras repetidos fallos de autenticación. Esto detiene bots de fuerza bruta automatizados sin deshabilitar permanentemente la cuenta, dando tiempo a los administradores para reaccionar.

5.3.5 — Asegurar historial de contraseñas PAM

Qué hace apply: Establece remember = 5 en la configuración del módulo de contraseñas PAM para prevenir la reutilización de las últimas 5 contraseñas.

Verificación manual:

grep 'remember' /etc/pam.d/system-auth /etc/pam.d/common-password 2>/dev/null

Justificación de seguridad: Sin aplicación de historial, los usuarios ciclan entre un pequeño conjunto de contraseñas. Si una contraseña antigua se filtra en una brecha, el atacante a menudo puede iniciar sesión porque el usuario ha vuelto a ella.

5.5.1 — Asegurar que la umask predeterminada es restrictiva

Qué hace apply: Establece umask 027 en /etc/profile, /etc/bashrc y /etc/login.defs.

Verificación manual:

grep -E '^umask' /etc/profile /etc/bashrc /etc/login.defs 2>/dev/null

Justificación de seguridad: Una umask de 027 asegura que los archivos nuevos se creen con permisos 640 y los directorios con 750, evitando que otros usuarios lean datos recién creados por defecto.

5.5.2 — Asegurar que el tiempo de espera del shell está configurado

Qué hace apply: Añade TMOUT=900 y readonly TMOUT a /etc/profile y /etc/bashrc.

Verificación manual:

grep 'TMOUT' /etc/profile /etc/bashrc 2>/dev/null

Justificación de seguridad: Los tiempos de espera del shell cierran automáticamente sesiones locales e SSH inactivas después de 15 minutos. Esto complementa a ClientAliveInterval y protege contra acceso físico o ventanas de terminal abandonadas.

Controles de Mantenimiento del Sistema

El dominio de mantenimiento del sistema (sección CIS 6.1.x) contiene 8 controles enfocados en permisos de archivos, propiedad y auditoría periódica de ejecutables del sistema. Estos controles no cambian servicios en ejecución ni comportamiento de red; en su lugar, aseguran que los archivos críticos no sean legibles ni escribibles por usuarios no autorizados, y que no existan binarios SUID/SGID inesperados en el sistema.

6.1.1 — Asegurar permisos en /etc/passwd

Qué hace apply: Establece /etc/passwd en modo 644 y propiedad root:root.

Verificación manual:

stat -c '%a %U:%G' /etc/passwd

Se espera: 644 root:root.

Justificación de seguridad: /etc/passwd contiene nombres de usuario, UIDs, directorios home y shells predeterminados. Aunque no contiene hashes de contraseña (esos están en /etc/shadow), filtra datos de enumeración de usuarios e información de shell que ayuda a los atacantes a elaborar exploits dirigidos.

6.1.2 — Asegurar permisos en /etc/shadow

Qué hace apply: Establece /etc/shadow en modo 000 o 640 y propiedad root:shadow.

Verificación manual:

stat -c '%a %U:%G' /etc/shadow

Justificación de seguridad: /etc/shadow almacena hashes de contraseñas, envejecimiento de contraseñas y estado de bloqueo de cuentas. Si es legible por usuarios no root, un atacante puede extraer hashes para cracking offline con herramientas como Hashcat o John the Ripper.

6.1.3 — Asegurar permisos en /etc/group

Qué hace apply: Establece /etc/group en modo 644 y propiedad root:root.

Verificación manual:

stat -c '%a %U:%G' /etc/group

Justificación de seguridad: La membresía de grupo revela qué usuarios tienen acceso a recursos compartidos. Mantener este archivo legible para todos generalmente es aceptable, pero no debe ser escribible por nadie que no sea root.

6.1.4 — Asegurar permisos en /etc/gshadow

Qué hace apply: Establece /etc/gshadow en modo 000 o 640 y propiedad root:shadow.

Verificación manual:

stat -c '%a %U:%G' /etc/gshadow

Justificación de seguridad: /etc/gshadow almacena contraseñas de grupo y listas de administradores. Al igual que /etc/shadow, debe protegerse del acceso de lectura para prevenir ataques offline sobre credenciales de grupo.

6.1.5 — Auditar archivos escribibles por todos

Qué hace apply: Ejecuta find para localizar archivos con modo o+w que no tengan el sticky bit configurado en su directorio. El control reporta la lista pero no remedia automáticamente, porque los archivos escribibles por todos pueden ser intencionales (por ejemplo, directorios de spool compartidos).

Verificación manual:

find / -xdev -type f -perm -002 ! -perm -1000 -exec ls -l {} \; 2>/dev/null

Justificación de seguridad: Los archivos escribibles por todos permiten que cualquier usuario del sistema los modifique. Si dicho archivo es ejecutado por root u otro proceso privilegiado, un atacante puede inyectar contenido malicioso y escalar privilegios.

Revisa cuidadosamente la lista producida por este control. Elimina los permisos de escritura para todos donde no sean necesarios, y asegúrate de que el sticky bit esté configurado en directorios compartidos (por ejemplo, `/tmp`).

6.1.6 — Auditar ejecutables SUID y SGID

Qué hace apply: Ejecuta find para localizar todos los archivos con el bit setuid o setgid configurado. El control los reporta pero no elimina los bits automáticamente, porque muchos son necesarios para la funcionalidad básica del sistema (por ejemplo, /usr/bin/passwd, /usr/bin/sudo).

Verificación manual:

find / -xdev -type f \( -perm -4000 -o -perm -2000 \) -exec ls -l {} \; 2>/dev/null

Justificación de seguridad: Los binarios SUID/SGID se ejecutan con los privilegios de su propietario o grupo. Una vulnerabilidad en tal binario es una ruta directa de escalada de privilegios. Las auditorías regulares aseguran que ningún programa no autorizado (por ejemplo, herramientas de explotación compiladas) haya recibido permisos elevados.

6.1.7 — Auditar archivos sin propietario

Qué hace apply: Encuentra archivos cuyo UID o GID no se resuelva a un usuario o grupo válido en /etc/passwd y /etc/group.

Verificación manual:

find / -xdev -nouser -o -nogroup 2>/dev/null

Justificación de seguridad: Los archivos propiedad de usuarios eliminados suelen ser restos de cuentas comprometidas o herramientas de ataque huérfanas. También pueden indicar una instalación de paquete mal configurada. Limpiarlos reduce el desorden y elimina posibles puertas traseras.

6.1.8 — Auditar IDs duplicados

Qué hace apply: Comprueba /etc/passwd, /etc/group, /etc/shadow y /etc/gshadow en busca de UIDs, GIDs o nombres de usuario duplicados. Reporta duplicados pero no los corrige automáticamente.

Verificación manual:

awk -F: '{print $3}' /etc/passwd | sort | uniq -d
awk -F: '{print $3}' /etc/group | sort | uniq -d

Justificación de seguridad: Los UIDs duplicados pueden causar colisiones de permisos: dos usuarios diferentes pueden compartir involuntariamente la misma identidad en el sistema de archivos, permitiendo que uno acceda a los archivos del otro.

6.1.9 — Asegurar permisos de cron

Qué hace apply: Establece /etc/crontab, /etc/cron.d/, /etc/cron.daily/, /etc/cron.weekly/ y /etc/cron.monthly/ en modo 700 o 750 y propiedad root:root.

Verificación manual:

stat -c '%a %U:%G' /etc/crontab
stat -c '%a %U:%G' /etc/cron.d

Justificación de seguridad: Cron es un mecanismo de ejecución persistente. Si un atacante puede escribir en un directorio de cron del sistema, logra acceso root persistente en cada intervalo programado. Restringir estas rutas a root es esencial para la integridad.

Visión General del Sistema de Informes

Vallumix genera informes estructurados después de cada ejecución de audit o apply. Los informes resumen la información del host, las estadísticas de cumplimiento y el estado detallado de cada control evaluado. El sistema de informes se implementa en el crate vallumix-reporters y admite cuatro formatos de salida.

Formatos de Informe de un Vistazo

Generar un Informe

Usa la bandera --report para seleccionar el formato y --output para especificar la ruta de destino (sin extensión):

# Informe HTML para un auditor
vallumix audit --profile web --report html --output /var/reports/vallumix/audit-2024-06-01

# Informe JSON para un panel de control
vallumix audit --profile web --report json --output /var/reports/vallumix/audit-2024-06-01

# Informe JUnit para CI/CD
vallumix audit --profile web --report junit --output /var/reports/vallumix/ci-results

# Informe de texto para revisión en terminal
vallumix audit --profile web --report text --output /var/reports/vallumix/audit-2024-06-01

Si se omite --output, Vallumix escribe el informe en un archivo con marca temporal en /tmp.

Puedes generar múltiples informes de la misma ejecución ejecutando `audit` una vez y convirtiendo la salida JSON, o ejecutando `audit` con diferentes valores de `--report` en invocaciones separadas. Dado que Vallumix es idempotente, reejecutar `audit` no cambia el estado del sistema.

Modelo de Datos del Informe

Cada informe contiene los mismos datos subyacentes, independientemente del formato:

• host.hostname — el nombre del host del servidor.
• host.distro — la distribución detectada (por ejemplo, debian/12, rocky/9).
• summary.total — número total de controles evaluados.
• summary.pass — controles marcados como Compliant.
• summary.fail — controles marcados como NonCompliant.
• summary.skip — controles marcados como Skipped (por ejemplo, dry-run o no aplicable).
• summary.compliance_rate — porcentaje de controles cumplidos (pass / total * 100).
• controls[] — array de resultados individuales de controles, cada uno con id, description, severity, status, evidence y message opcional.

Aplicación de Umbrales

Vallumix admite un umbral de cumplimiento. Si la tasa de cumplimiento cae por debajo del umbral, la CLI sale con código 1, lo que señala fallo a los pipelines CI/CD y herramientas de orquestación:

vallumix audit --profile web --threshold 95

Esto es especialmente útil con el reporter JUnit: una etapa de pipeline puede bloquear el despliegue ante un resultado de cumplimiento del 100%.

Notas Específicas por Formato

• Los informes HTML son completamente autónomos; no requieren archivos CSS o JavaScript externos. Puedes enviar un único archivo .html a un auditor o abrirlo sin conexión.
• Los informes JSON usan nombres de campo en snake_case y formato legible para humanos. Se pueden canalizar directamente a jq para filtrar.
• Los informes JUnit mapean Compliant a pruebas aprobadas, NonCompliant a <failure>, y Skipped a <skipped>. El atributo classname es la descripción del control, y name es el ID del CIS.
• Los informes de texto detectan automáticamente NO_COLOR y eliminan los códigos de escape ANSI. En un pipeline, recaen en etiquetas de texto plano (OK, FAIL, SKIP).

Para ejemplos detallados de cada formato, consulta las páginas dedicadas en esta sección.

Informe HTML

El reporter HTML produce un informe autónomo en un único archivo, adecuado para auditores, oficiales de cumplimiento y presentaciones de gestión. Todo el CSS está incrustado en el documento; no se requieren solicitudes de red externas ni hojas de estilo.

Cuándo Usar HTML

• Auditorías de cumplimiento — envía un único archivo .html a un auditor externo.
• Paneles de gestión — ábrelo en un navegador para un resumen visual de la postura de seguridad del servidor.
• Revisión sin conexión — funciona sin acceso a Internet porque todos los estilos están en línea.
• Adjuntos de correo electrónico — un único archivo lo contiene todo.

Generar un Informe HTML

vallumix audit --profile web --report html --output /var/reports/vallumix/audit

El archivo resultante es /var/reports/vallumix/audit.html.

Estructura del Informe

El informe HTML incluye las siguientes secciones:

1. Encabezado — logo de Vallumix, marca temporal de generación, nombre del host y distribución.
2. Tarjeta de Resumen — gráfico circular o de barras que muestra los totales de aprobados, fallidos, omitidos y el porcentaje de tasa de cumplimiento.
3. Tabla de Controles — tabla ordenable con columnas para ID CIS, Descripción, Severidad, Estado, Evidencia y Mensaje. El estado está codificado por colores: verde para Compliant, rojo para NonCompliant, amarillo para Skipped.
4. Pie de Página — versión de Vallumix, nombre del perfil y una nota sobre verificación manual.

Descripción de la Captura de Pantalla

Al abrirlo en un navegador, el informe presenta un diseño limpio y profesional:

• La barra superior muestra el nombre del host (web01) y la distribución (debian/12) a la izquierda, y la marca temporal de generación a la derecha.
• Una gran cifra de tasa de cumplimiento (por ejemplo, 87.3%) se muestra prominentemente debajo de la barra.
• Tres cajas de resumen muestran Pass: 38, Fail: 5, Skip: 2 con fondos verde, rojo y ámbar respectivamente.
• La tabla de controles alterna colores de fila para legibilidad. Cada fila tiene una insignia de estado (Compliant, Non-Compliant, Skipped).
• Al pasar el cursor sobre una insignia de severidad (High, Medium, Low) se muestra una descripción emergente con la definición de severidad del CIS.
• Las filas con mensajes (por ejemplo, should be no) muestran una flecha de detalles expandible.

El reporter HTML usa el motor de plantillas Askama. La plantilla `report.html` se compila en el binario, por lo que la generación de informes no requiere archivos de plantilla en tiempo de ejecución.

Fragmento de Ejemplo de Salida

<!DOCTYPE html>
<html lang="es">
<head>
  <meta charset="UTF-8">
  <title>Informe de Cumplimiento Vallumix — web01</title>
  <style>
    body { font-family: system-ui, sans-serif; margin: 2rem; }
    .summary { display: flex; gap: 1rem; }
    .badge-pass { background: #22c55e; color: #fff; padding: .25rem .5rem; border-radius: .25rem; }
    .badge-fail { background: #ef4444; color: #fff; padding: .25rem .5rem; border-radius: .25rem; }
  </style>
</head>
<body>
  <h1>Informe de Cumplimiento Vallumix</h1>
  <p>Host: <strong>web01</strong> | Distro: <strong>debian/12</strong> | Generado: 2024-06-01 14:32:00 +0000</p>
  <div class="summary">
    <div>Total: 45</div>
    <div class="badge-pass">Pass: 38</div>
    <div class="badge-fail">Fail: 5</div>
    <div>Skip: 2</div>
  </div>
  <p>Tasa de Cumplimiento: <strong>84.4%</strong></p>
  <!-- Tabla de controles a continuación -->
</body>
</html>

Personalización

Dado que la plantilla se compila en el binario, personalizar la salida HTML requiere modificar crates/vallumix-reporters/templates/report.html y recompilar Vallumix. Las versiones futuras pueden admitir plantillas proporcionadas por el usuario a través del directorio --output.

Informe JSON

El reporter JSON produce un documento JSON legible para máquinas, con formato bonito, que contiene el resultado completo de la auditoría o aplicación. Es el formato preferido para la integración con paneles de control, plataformas SIEM y scripts de automatización personalizados.

Cuándo Usar JSON

• Grafana / paneles personalizados — ingiere el JSON en una base de datos de series temporales o muéstralo en un panel web.
• Integración con SIEM — reenvía el informe a Splunk, Elastic Security o Sentinel mediante un enviador de logs.
• Scripts de automatización — analiza el JSON con jq, Python o cualquier lenguaje con biblioteca JSON.
• Diferencias temporales — almacena informes JSON diarios en Git o almacenamiento de objetos y compara tendencias de cumplimiento.

Generar un Informe JSON

vallumix audit --profile web --report json --output /var/reports/vallumix/audit

Resultado: /var/reports/vallumix/audit.json.

Estructura JSON

{
  "host": {
    "hostname": "web01",
    "distro": "debian/12"
  },
  "summary": {
    "total": 45,
    "pass": 38,
    "fail": 5,
    "skip": 2,
    "compliance_rate": 84.4
  },
  "controls": [
    {
      "id": "1.1.1.1",
      "description": "Disable cramfs",
      "severity": "Low",
      "status": "Compliant",
      "evidence": "not present",
      "message": null
    },
    {
      "id": "5.2.4",
      "description": "Disable root login",
      "severity": "High",
      "status": "NonCompliant",
      "evidence": "PermitRootLogin yes",
      "message": "should be no"
    },
    {
      "id": "3.1.1",
      "description": "Disable IP forwarding",
      "severity": "Medium",
      "status": "Skipped",
      "evidence": "dry-run",
      "message": null
    }
  ]
}

Referencia de Campos

Procesamiento con jq

# Extraer solo controles de alta severidad fallidos
vallumix audit --profile web --report json | \
  jq '.controls[] | select(.status == "NonCompliant" and .severity == "High")'

# Calcular tasa de cumplimiento desde un informe guardado
jq '.summary.compliance_rate' /var/reports/vallumix/audit.json

# Contar controles por severidad
jq '[.controls[].severity] | group_by(.) | map({severity: .[0], count: length})' audit.json

Ejemplo de Ingestión en SIEM

Para Splunk o Fluent Bit, envuelve el informe JSON en un sobre de una sola línea y reenvíalo:

vallumix audit --profile web --report json --output /var/log/vallumix/last-audit
jq -c '.' /var/log/vallumix/last-audit.json >> /var/log/vallumix/audit-stream.log

Tu enviador de logs puede entonces analizar cada línea como un objeto JSON e indexar campos como host.hostname, summary.compliance_rate y controls[].id.

El reporter JSON usa `serde_json::to_string_pretty`, por lo que la salida es legible para humanos por defecto. Para pipelines de producción, canalízala a través de `jq -c` para minificar y reducir el tamaño de transferencia.

Informe JUnit XML

El reporter JUnit produce XML JUnit estándar que se integra de forma nativa con Jenkins, GitLab CI, GitHub Actions, Azure DevOps y cualquier otra plataforma CI/CD que entienda el formato de resultados de pruebas JUnit.

Cuándo Usar JUnit

• Bloqueo de CI/CD — falla una compilación o despliegue si el cumplimiento cae por debajo del 100%.
• Paneles de Jenkins — visualiza tendencias de cumplimiento junto con resultados de pruebas unitarias.
• Widgets de Merge Request de GitLab — muestra controles fallidos directamente en el MR.
• Anotaciones de GitHub Actions — muestra controles fallidos como anotaciones de ejecución de verificaciones.

Generar un Informe JUnit

vallumix audit --profile web --report junit --output /var/reports/vallumix/ci-results

Resultado: /var/reports/vallumix/ci-results.xml.

Estructura XML

<?xml version="1.0" encoding="UTF-8"?>
<testsuite name="vallumix" tests="4" failures="1" skipped="1" errors="0">
  <testcase name="1.1.1.1" classname="Disable cramfs">
    <!-- Compliant: sin elemento hijo -->
  </testcase>
  <testcase name="5.2.4" classname="Disable root login">
    <failure message="should be no">PermitRootLogin yes</failure>
  </testcase>
  <testcase name="3.1.1" classname="Disable IP forwarding">
    <skipped message="skipped"/>
  </testcase>
  <testcase name="4" classname="D &amp; E &lt;test&gt;">
    <!-- Compliant: caracteres especiales escapados -->
  </testcase>
</testsuite>

Mapeo de Campos

Ejemplos de Integración CI/CD

GitLab CI

compliance:
  stage: test
  script:
    - vallumix audit --profile web --report junit --output compliance
  artifacts:
    reports:
      junit: compliance.xml
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

GitLab mostrará los controles fallidos en el widget del MR y marcará el pipeline como fallido si algún control no cumple.

GitHub Actions

- name: Run compliance audit
  run: vallumix audit --profile web --report junit --output compliance

- name: Publish JUnit results
  uses: mikepenz/action-junit-report@v4
  if: always()
  with:
    report_paths: 'compliance.xml'

Jenkins

Usa el plugin JUnit para publicar el XML:

post {
    always {
        junit 'compliance.xml'
    }
}

Aplicación de Umbrales

Combina --threshold con el informe JUnit para hacer que la CLI salga con código distinto de cero cuando el cumplimiento es insuficiente. Las plataformas CI/CD tratan el código de salida 1 como un fallo de pipeline:

vallumix audit --profile web --report junit --output ci-results --threshold 100

Si deseas rastrear tendencias de cumplimiento a lo largo del tiempo, archiva los archivos XML JUnit en tu sistema CI. Tanto Jenkins como GitLab admiten gráficos históricos de resultados de pruebas que mostrarán tu tasa de cumplimiento a través de las compilaciones.

Informe de Texto para Terminal

El reporter de texto produce un informe amigable para terminal, diseñado para operadores que desean retroalimentación inmediata durante una ejecución de audit o apply. Usa iconos Unicode y códigos de color ANSI por defecto, con retroceso automático a texto plano cuando la salida se canaliza o cuando NO_COLOR está configurado.

Cuándo Usar Texto

• Triaje de operadores — detecta rápidamente controles fallidos después de ejecutar apply.
• Paneles de terminal — muestra el estado de cumplimiento en una consola o monitor de pared.
• Streaming de logs — transmite salida a un multiplexor de terminal (tmux, screen) durante la automatización.
• Filtrado por canalización — canaliza a grep o less para aislar controles específicos.

Generar un Informe de Texto

vallumix audit --profile web --report text --output /var/reports/vallumix/audit

Cuando se usa --report text sin --output, el informe se imprime en stdout.

Formato de Salida

Vallumix Compliance Report — srv01 (rocky/9)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Total:  45   Pass:  38   Fail:   5   Skip:   2
  Compliance Rate: 84.4%

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[LOW]  ✓ Compliant 1.1.1.1 — Disable cramfs
      → not present
[HIGH] ✗ Non-Compliant 5.2.4 — Disable root login
      → PermitRootLogin yes
[MED]  ⚠ Skipped 3.1.1 — Disable IP forwarding
      → dry-run
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Elementos Visuales

Soporte para NO_COLOR

Vallumix respeta el estándar NO_COLOR. Si la variable de entorno NO_COLOR está configurada con cualquier valor no vacío, el reporter de texto elimina todas las secuencias de escape ANSI:

NO_COLOR=1 vallumix audit --profile web --report text

Esto es útil cuando:

• Rediriges la salida a un archivo que será leído por humanos.
• Ejecutas dentro de sistemas CI que no renderizan códigos ANSI.
• Canalizas hacia herramientas que no procesan secuencias de escape.

Canalización y Filtrado

Dado que el formato de texto está orientado a líneas, funciona bien con herramientas Unix estándar:

# Mostrar solo controles fallidos
vallumix audit --profile web --report text | grep 'FAIL'

# Contar fallos de alta severidad
vallumix audit --profile web --report text | grep -c '\[HIGH\].*FAIL'

# Transmitir a un archivo de log con marcas temporales
vallumix audit --profile web --report text | ts '[%Y-%m-%d %H:%M:%S]' > /var/log/vallumix/audit.log

En un terminal con fondo oscuro, el esquema de colores predeterminado (aprobado en verde, fallido en rojo, omitido en amarillo) proporciona alto contraste. Si tu tema de terminal usa colores inusuales, el modo de texto plano (`NO_COLOR=1`) puede ser más legible.

Solución de Problemas

Esta página recoge los problemas más frecuentes reportados por usuarios de Vallumix, junto con sus causas probables y soluciones.

Permiso denegado (Permission denied)

Síntoma:

Error: privilege check failed — effective UID is 1000, root required

Causa: Vallumix requiere privilegios de root para leer archivos de configuración protegidos (/etc/shadow, /etc/ssh/sshd_config) y para modificar configuraciones del sistema.

Solución:

sudo vallumix apply --profile web

Si ejecutas Vallumix dentro de un contenedor o máquina virtual sin acceso root, eleva los privilegios antes de ejecutarlo. No uses chmod 777 como workaround en archivos de sistema.

Distribución no soportada

Síntoma:

Error: distribution "Fedora 40" is not supported
Supported: debian-12, ubuntu-22.04, ubuntu-24.04, rhel-9, rocky-9, almalinux-9

Causa: Vallumix detecta la distribución leyendo /etc/os-release. Si la distro no está en la lista de soportadas, aborta para evitar aplicar controles que podrían no ser compatibles.

Solución:

• Si es una derivada de Debian/RHEL que debería funcionar, fuerza la detección con la variable de entorno VALLUMIX_DISTRO_OVERRIDE (solo para pruebas, sin soporte garantizado).
• Si necesitas soporte oficial para una nueva distribución, abre un issue en el repositorio.
• Para contenedores o entornos no convencionales, evalúa si Vallumix es la herramienta adecuada (véase "Fuera de alcance" en el PRD).

Bloqueo de acceso SSH tras hardening

Síntoma: Tras aplicar el perfil bastion o controles de SSH agresivos, no puedes conectarte por SSH.

Causa: El perfil bastión deshabilita PasswordAuthentication y PermitRootLogin. Si te conectabas por contraseña o como root, perdiste el acceso.

Prevención:

# ANTES de aplicar bastión, verifica acceso por clave
ssh -o PasswordAuthentication=no admin@servidor

Recuperación:

• Accede a la consola física o al panel de administración de la nube (VNC, serial console, EC2 Instance Connect).
• Restaura manualmente /etc/ssh/sshd_config desde el respaldo en /var/backups/vallumix/<timestamp>/5.2.4/.
• Reinicia SSH: sudo systemctl restart sshd.

El bloqueo SSH es el incidente más grave que puede causar una herramienta de hardening remota. Siempre verifica el acceso por clave antes de aplicar controles de SSH. En servidores cloud, confirma que tienes acceso a la consola serial o VNC como vía de recuperación.

Espacio insuficiente en disco para respaldos

Síntoma:

Error: insufficient disk space for backups — 45 MB available, 100 MB required

Causa: Vallumix verifica el espacio libre en disco antes de crear la sesión de respaldo. Si no hay suficiente espacio, aborta para evitar quedarse a mitad de camino sin respaldos.

Solución:

# Libera espacio en /var
df -h /var
sudo apt autoremove   # Debian/Ubuntu
sudo dnf autoremove   # RHEL/Rocky/Alma
sudo journalctl --vacuum-time=7d

Si /var está en una partición separada y pequeña, considera montar /var/backups/vallumix en un volumen mayor o configurar una ruta alternativa mediante variable de entorno (si el proyecto la soporta).

Controles fallidos tras aplicación

Síntoma: Un control aparece como Failed en el reporte tras apply.

Causas comunes:

1. Servicio bloquea el archivo: un demonio mantiene abierto el archivo de configuración con bloqueo de escritura.
2. Configuración inesperada: el archivo tiene una sintaxis que el control no anticipa.
3. Dependencia de otro control: un control previo modificó algo que este control asumía constante.

Solución:

• Revisa el log con --verbose para ver el error exacto.
• Verifica si un servicio bloquea el archivo: lsof /etc/ssh/sshd_config.
• Aplica el control manualmente siguiendo la recomendación CIS, luego re-ejecuta Vallumix para confirmar.

Reporte no generado

Síntoma: La ejecución termina pero no encuentras el archivo de reporte.

Causa: --output no especificó un directorio existente o los permisos impiden escribir.

Solución:

# Asegúrate de que el directorio existe y es escribible
mkdir -p /var/reports/vallumix
sudo vallumix audit --profile web --report html --output /var/reports/vallumix/audit

Si no usas --output, Vallumix usa /tmp por defecto. Algunos sistemas limpian /tmp en cada reinicio.

Preguntas Frecuentes

1. ¿Vallumix sustituye a OpenSCAP o Lynis?

No. Vallumix se posiciona en un segmento diferente: es una herramienta moderna, autónoma y escrita en Rust que aplica cambios y permite rollback. OpenSCAP es más completo en cobertura de benchmarks pero requiere infraestructura de contenido SCAP. Lynis audita pero no aplica remediaciones automáticas. Usa la herramienta que mejor se adapte a tu flujo de trabajo.

2. ¿Es seguro ejecutar Vallumix en producción?

Sí, si sigues las precauciones recomendadas: ejecuta --dry-run primero, verifica el reporte, asegúrate de tener acceso a la consola física o VNC en caso de bloqueo SSH, y utiliza el perfil adecuado para el rol del servidor. El sistema de rollback te permite revertir cambios si algo falla.

3. ¿Puedo omitir controles específicos?

Sí. Edita el archivo de perfil TOML (/etc/vallumix/profiles/web.toml o una copia local) y comenta o elimina el control que deseas omitir. Luego usa tu perfil personalizado con --profile /ruta/a/mi-perfil.toml.

4. ¿Cuánto espacio en disco necesito?

Vallumix requiere al menos 100 MB libres en /var/backups/vallumix para la sesión de respaldo inicial. El binario ocupa menos de 8 MB. Los reportes HTML son típicamente de 50-200 KB.

5. ¿Puedo usar Vallumix en contenedores Docker?

No es el caso de uso previsto. Los controles CIS están diseñados para sistemas operativos completos, no para contenedores. El hardening de contenedores requiere el CIS Docker Benchmark, que es un enfoque distinto. Vallumix abortará en la mayoría de contenedores porque no detectará una distribución soportada completa.

6. ¿Cómo actualizo Vallumix?

Descarga la nueva versión del release e instálala sobre la anterior. Los respaldos en /var/backups/vallumix se conservan. Tras actualizar, ejecuta vallumix --version para confirmar.

wget https://github.com/jorgealonsodev/vallumix/releases/download/v1.1.0/vallumix_1.1.0_amd64.deb
sudo dpkg -i vallumix_1.1.0_amd64.deb

7. ¿Los respaldos caducan?

No. Vallumix no elimina respaldos automáticamente. Configura una tarea cron para limpiar sesiones antiguas si el espacio en disco es limitado.

8. ¿Puedo aplicar múltiples perfiles en el mismo servidor?

No está recomendado. Los perfiles pueden tener controles superpuestos con configuraciones conflictivas. Si necesitas características de varios perfiles, crea un perfil personalizado que combine los controles deseados sin duplicaciones.

9. ¿Qué pasa si un control falla?

Un control en estado Failed significa que la remediación no pudo aplicarse o el post-check no confirmó el cambio. El servidor sigue funcionando; Vallumix no aborta la ejecución por un control fallido. Revisa el reporte detallado para entender la causa y corrige manualmente si es necesario.

10. ¿Vallumix modifica contraseñas de usuario?

No. Vallumix no gestiona contraseñas de usuarios ni crea ni elimina cuentas. Los controles de autenticación se limitan a configuraciones del sistema como PAM, SSH y sudoers.

11. ¿Cómo reporto un bug o solicito una función?

Abre un issue en el repositorio de GitHub. Para bugs, incluye la distribución, la versión de Vallumix, el comando ejecutado y el mensaje de error completo. Para solicitudes de función, describe el caso de uso y por qué la funcionalidad actual no lo cubre.

12. ¿Vallumix garantiza la seguridad de mi servidor?

No. Vallumix automatiza controles CIS que reducen la superficie de ataque, pero la seguridad es un proceso continuo, no un producto. Sigue aplicando parches, monitorea logs, realiza auditorías periódicas y complementa con herramientas de detección de intrusiones. Vallumix es una pieza del rompecabezas, no el rompecabezas completo.

Si tu pregunta no está aquí, revisa la [sección de solución de problemas](troubleshooting.md) o busca en los issues abiertos del repositorio. Es probable que alguien ya haya encontrado el mismo problema.

Glosario

Este glosario define los términos técnicos utilizados a lo largo de la documentación de Vallumix, basados en el PRD y en la terminología estándar de la industria de ciberseguridad.

Términos

Hardening

Proceso de reducción de la superficie de ataque de un sistema mediante la desactivación de funcionalidades innecesarias y la configuración segura de las restantes. En Vallumix, el hardening se automatiza aplicando controles CIS.

CIS Benchmark

Guías de configuración segura mantenidas por el Center for Internet Security (CIS). Son referencias industriales ampliamente reconocidas que definen configuraciones seguras para sistemas operativos, aplicaciones y dispositivos de red.

Idempotencia

Propiedad por la cual ejecutar una operación una o múltiples veces produce el mismo resultado final. Vallumix garantiza idempotencia mediante pre-checks: si un control ya cumple, no se modifica nada.

Bastión (jump host)

Servidor expuesto a internet cuyo único propósito es servir como punto de entrada autenticado hacia infraestructura interna. El perfil bastion de Vallumix aplica el hardening más agresivo, orientado exclusivamente a SSH.

Dry-run

Modo de ejecución que simula los efectos de una operación sin realizarlos efectivamente. En Vallumix, --dry-run ejecuta todos los checks y reporta qué cambios se harían, pero no crea respaldos ni modifica archivos.

MSRV (Minimum Supported Rust Version)

Versión mínima del compilador de Rust que el proyecto se compromete a soportar. Para Vallumix, la MSRV es 1.75.

Crate

Unidad de compilación y distribución en Rust, equivalente conceptual a un paquete. Vallumix se organiza como un workspace de Cargo con múltiples crates: vallumix-core, vallumix-controls, vallumix-reporters, vallumix-backup y vallumix-cli.

Workspace

Agrupación de múltiples crates relacionados gestionados conjuntamente por Cargo. El workspace de Vallumix permite compilar y testear todos los crates desde la raíz del proyecto.

Trait

Mecanismo de Rust para definir comportamiento compartido, similar a las interfaces en otros lenguajes. El trait Control abstrae el ciclo de vida de cada verificación CIS en Vallumix.

SLSA (Supply-chain Levels for Software Artifacts)

Marco de Google para asegurar la cadena de suministro de software. Vallumix publica attestations SLSA Level 3 en sus releases para garantizar la proveniencia y integridad del binario.

Control

Unidad atómica de verificación y remediación en Vallumix. Cada control implementa el trait Control y representa una recomendación específica del CIS Benchmark (por ejemplo, "deshabilitar login de root por SSH").

Perfil

Conjunto preconfigurado de controles adaptado al rol de un servidor. Vallumix incluye tres perfiles: web, database y bastion.

Rollback

Operación de reversión que restaura configuraciones previas desde respaldos versionados. Vallumix permite rollback por control individual o por sesión completa.

Respaldos versionados

Copias de seguridad organizadas por sesión de ejecución, identificadas por timestamp. Cada sesión incluye el archivo modificado, un manifesto de metadatos y checksums SHA-256.

Threshold (umbral)

Porcentaje mínimo de cumplimiento configurable. Si la tasa de cumplimiento de una ejecución está por debajo del umbral, Vallumix devuelve código de salida 1.

Reporter

Trait que abstrae la generación de reportes en diferentes formatos. Vallumix implementa reporters para HTML, JSON, JUnit XML y texto plano.

Superficie de ataque

Conjunto de puntos de entrada que un atacante podría explotar en un sistema. El objetivo del hardening es reducir esta superficie al mínimo necesario para la funcionalidad operativa.

Si encuentras un término en la documentación que no está en este glosario, abre un issue para solicitar su inclusión. La documentación debe ser accesible tanto para administradores experimentados como para quienes se inician en hardening de sistemas.