Cómo Auditar un Linux VPS con vps-audit—y Leer los Resultados Correctamente

Una Auditoría Rápida de VPS Es un Punto de Partida, No un Veredicto

Tu sitio web se carga y SSH responde, pero eso no revela actualizaciones pendientes, configuraciones SSH permisivas o listeners inesperados. Una auditoría de primer paso plantea esas preguntas.

vps-audit es una lista de verificación Bash para Debian y Ubuntu que convierte señales de configuración local, mantenimiento, listener y recursos en un informe codificado por colores. Como un panel de control de vehículo, señala áreas que necesitan inspección sin diagnosticar cada causa.

Esta guía ejecuta de forma segura vps-audit v0.2.0 fijado, verifica resultados importantes con herramientas nativas y los convierte en prioridades. El ejemplo utiliza un VPS Ubuntu de AlexHost ejecutando Ubuntu 24.04 LTS. Las imágenes de otros proveedores pueden diferir, y el SO invitado no administrado sigue siendo responsabilidad del operador.

Qué verifica vps-audit—y qué no puede probar

vps-audit verifica indicadores locales sin examinar ningún área exhaustivamente. Esta tabla muestra qué puede—y qué no puede—decirte cada resultado.

SUID permite que un programa se ejecute con los privilegios efectivos del propietario del archivo. Los programas del sistema legítimos lo usan, así que investiga un archivo SUID inesperado en lugar de eliminarlo. Fail2ban y CrowdSec pueden bloquear tráfico hostil, pero la instalación o el estado activo solo no prueba que protejan el servicio previsto.

El script aplica umbrales genéricos al uso de recursos, servicios, inicios de sesión fallidos y oyentes. Estos no son puntajes de riesgo conscientes de la carga de trabajo; diferentes roles de VPS pueden alcanzar el mismo color por razones diferentes.

La herramienta no inspecciona malware, vulnerabilidades conocidas, aplicaciones, contenedores, firewalls del proveedor, cumplimiento o tendencias. Aunque su README menciona “Conexiones activas de Internet”, v0.2.0 solo obtiene la IP pública e inventaría oyentes locales. Porque necesita visibilidad privilegiada, primero controla qué archivo recibe acceso sudo.

Antes de Darle sudo a un Script Descargado

Este flujo de trabajo de Debian/Ubuntu requiere acceso SSH, sudo, y las herramientas estándar utilizadas a continuación. Trabaja en un directorio desechable. Si falta una herramienta, detente en lugar de cambiar la línea base instalándola.

El ejemplo utiliza vps-audit v0.2.0, publicado el 10 de agosto de 2026 y aún la versión más reciente cuando se verificó el 8 de septiembre de 2026.

Su etiqueta apunta al commit 57c323d46b48026740f0b35b9bad6cd6127c757b. Fijar la versión evita un cambio posterior desde main mutable.

Crea un directorio dedicado y descarga ese script etiquetado exacto sobre HTTPS:

mkdir -p "$HOME/vps-audit-test"
cd "$HOME/vps-audit-test"
curl -fL --proto '=https' --tlsv1.2 
  -o vps-audit.sh 
  https://raw.githubusercontent.com/nuver-labs/vps-audit/v0.2.0/vps-audit.sh

Esto guarda vps-audit.sh en el nuevo directorio. La opción -f falla en errores HTTP, mientras que -L sigue redirecciones.

A continuación, registra una huella digital SHA-256 local y muestra la configuración relevante para este tutorial:

sha256sum vps-audit.sh
grep -nE '^(VPS_AUDIT_VERSION|RESOURCE_(WARN|FAIL)|SERVICES_(WARN|FAIL)|LOGINS_(WARN|FAIL)|OPEN_PORTS_(WARN|FAIL)|PASSWORD_MINLEN|DEFAULT_REPORT_DIR|ENABLE_CHOWN)=|api.ipify.org' vps-audit.sh

La salida genera una huella digital del archivo y muestra su ruta de informe, umbrales y solicitud a api.ipify.org. El código fuente etiquetado completo también lee el estado local, simula apt-get -s upgrade, y busca recursivamente archivos SUID. No es de solo lectura: escribe un informe, puede crear su directorio y contacta un servicio externo. Revisa el código fuente antes de otorgar privilegios elevados si puedes leer código shell.

Los umbrales de recursos son 50% para WARN y 80% para FAIL. Los servicios en ejecución utilizan 20/40, inicios de sesión fallidos 10/50, oyentes nominalmente 10/20, y longitud de contraseña 12. La sección de limitaciones explica por qué el estado del oyente no sigue esas variables.

⚠️ Advertencia: Fijar la versión, hacer hash, inspección dirigida y verificación de sintaxis mejoran la reproducibilidad pero no establecen confianza. El commit no está firmado, y la versión no proporciona activos de suma de verificación o firma.

Mantén el hash con las notas de auditoría. Antes de una ejecución, compáralo con el archivo. Una coincidencia muestra que las copias contienen los mismos bytes. Una diferencia puede provenir de otra versión, una descarga modificada o una edición local. Registrar la etiqueta y el hash vincula cada informe al script que lo produjo.

Finalmente, analiza el archivo sin ejecutar sus comandos normales, luego agrega permiso de ejecución solo si el análisis tiene éxito:

bash -n vps-audit.sh 
  && chmod +x vps-audit.sh 
  && printf 'Syntax check: PASS; execute permission addedn'

Esto confirma solo que Bash puede analizar el archivo y que se agregó permiso de ejecución. El script fijado ahora está listo para una ejecución sin cambios.

Ejecutar vps-audit y Localizar el Informe

El script imprime detalles del sistema y estados de color, luego escribe un informe en texto plano. Su búsqueda recursiva de SUID hace que el tiempo de ejecución sea variable, así que mídelo.

Ejecuta el archivo fijado una vez y preserva el estado de salida del proceso shell:

printf 'Audit started: '
date -u '+%Y-%m-%d %H:%M:%S UTC'
TIMEFORMAT=$'Elapsed real: %3R secondsnUser CPU: %3U secondsnSystem CPU: %3S seconds'
time sudo ./vps-audit.sh
AUDIT_STATUS=$?
printf 'Audit exit status: %sn' "$AUDIT_STATUS"

En el VPS probado, la auditoría comenzó a las 13:12:10 UTC el 14 de septiembre de 2026 y terminó en 58.412 segundos. Devolvió 0 y guardó ./vps-audit-report-20260914_131210.txt.

Elapsed real es el tiempo de reloj de pared; los valores de usuario y sistema miden el tiempo de CPU. El estado de salida 0 significa que el proceso se completó, no que todas las comprobaciones pasaran. v0.2.0 devuelve 0 incluso con resultados FAIL.

Selecciona el nuevo informe, inspecciona sus metadatos y extrae conteos y ejemplos sin mostrar el archivo sensible en su totalidad.

REPORT=$(ls -1t ./vps-audit-report-*.txt 2>/dev/null | head -n 1)
if [ -z "$REPORT" ]; then
    printf 'No vps-audit report found in the current directory.n' >&2
    exit 1
fi
printf 'Report selected: %sn' "$REPORT"
sudo stat --format='Owner: %U:%G | Mode: %A (%a) | Size: %s bytes | Modified: %y' "$REPORT"

for status in PASS WARN FAIL; do
    count=$(sudo grep -c "^\[$status\]" "$REPORT" || true)
    printf '%s: %sn' "$status" "$count"
done

sudo grep -E '^[(PASS|WARN|FAIL)] (Running Services|Disk Usage|Password Policy)' "$REPORT"

La hora de modificación del informe a las 13:13:08 UTC coincidió con la ejecución. Contenía 17 resultados: seis PASS, tres WARN y ocho FAIL. Estas son clasificaciones, no una puntuación de seguridad.

Los totales de estado son útiles al comparar ejecuciones de la misma versión, pero siempre inspecciona las líneas detrás de un cambio. Un recuento FAIL más bajo puede provenir de diferentes entradas o comportamiento del analizador en lugar de una mejora. Un total sin cambios también puede ocultar un problema resuelto y uno nuevo.

El informe de 2.665 bytes pertenecía a root:root con modo 644 (-rw-r--r--), como se esperaba con sudo y ENABLE_CHOWN=false estándar. Los usuarios de grupo y otros pueden leer ese modo si los permisos del directorio les permiten alcanzar el archivo. La propiedad de root por sí sola no lo hace privado.

❗ Importante: El informe contiene el nombre de host, IP pública, detalles del sistema y hallazgos. Mantenlo privado y redacta identificadores, indicadores y información de servicio sensible antes de compartir.

Si una ejecución futura carece de un estado, registra esa ausencia en lugar de reconfigurar el VPS para fabricar un color.

Cómo leer PASS, WARN y FAIL sin reaccionar en exceso

Las etiquetas del dashboard informan cómo cada prueba coincidió con las reglas de v0.2.0:

Separa la observación de la recomendación. En “22 servicios en ejecución”, el conteo es la observación; “reducir la superficie de ataque” es un consejo basado en un umbral genérico. Confirma el conteo, identifica los servicios y luego decide si ese consejo se ajusta al servidor.

Haz tres preguntas sobre cada resultado: ¿Es el valor preciso? ¿Es intencional? ¿Cuál es el impacto realista? Los comandos nativos verifican el valor; el contexto de la carga de trabajo determina el resto.

El WARN del puerto SSH se basa en política: v0.2.0 marca el puerto 22. Mover SSH puede reducir el ruido automatizado pero no puede reemplazar la autenticación fuerte o los controles de acceso. Un servicio conocido en el puerto 22 puede importar menos que un oyente comodín desconocido.

Para un FAIL, inspecciona la regla antes de proponer una corrección. La prueba de inicio de sesión raíz acepta solo PermitRootLogin no, por lo que la configuración distinta prohibit-password aún falla. Verifica OpenSSH directamente antes de actuar.

Un PASS también necesita contexto. Para unattended-upgrades, el script confirma solo que el paquete existe—no su configuración o historial de ejecución.

Verificar hallazgos de alto impacto con comandos nativos

Utiliza comandos nativos de solo lectura para verificar acceso SSH, filtrado de hosts y oyentes locales. Primero, pregunta qué OpenSSH resuelve realmente después de combinar los valores predeterminados y la configuración incluida:

sudo sshd -T 
  | grep -E '^(port|listenaddress|permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication) '

Ubuntu carga /etc/ssh/sshd_config.d/*.conf cerca del inicio de su configuración principal. sshd -T resuelve la configuración combinada, lo que la convierte en evidencia más sólida que buscar en un archivo.

OpenSSH resolvió el puerto 22 en direcciones IPv4 e IPv6 comodín. También devolvió permitrootlogin yes, passwordauthentication yes, pubkeyauthentication yes, y kbdinteractiveauthentication no. La configuración resuelta confirma los hallazgos del script sobre inicio de sesión raíz y autenticación por contraseña, aunque el estado de la cuenta, PAM y las reglas Match aún pueden afectar un inicio de sesión específico.

Segundo, pregunta qué UFW informa sobre su estado y política administrada:

sudo ufw status verbose

Ubuntu documenta UFW como su interfaz de firewall predeterminada. Aquí estaba activo con registro de bajo nivel y políticas de denegación predeterminada para tráfico entrante y enrutado. Las reglas permitían puertos entrantes 22, 80, 443 y 37985 sobre IPv4 e IPv6. Esto confirma el estado de UFW, no si cada regla es apropiada.

Tercero, inventaría oyentes TCP y UDP locales, direcciones de enlace y procesos propietarios:

sudo ss -lntup

Las opciones seleccionan oyentes TCP y UDP numéricos y solicitan detalles del proceso. Los puertos 53, 62789, 8404 y 11111 eran solo bucle invertido; los puertos 22, 80, 2096, 5678 y 37985 utilizaban direcciones comodín. No aparecieron detalles del proceso, por lo que sus propietarios y propósitos siguen siendo desconocidos.

process listener
    → bind address / interface
    → host firewall
    → provider-edge firewall or NAT
    → external network path

Los puertos 22, 80 y 37985 tenían oyentes comodín y reglas de permiso UFW. UFW permitía 443 sin un oyente, mientras que 2096 y 5678 tenían oyentes sin reglas de permiso mostradas.

Una regla de firewall y un oyente responden preguntas diferentes. La regla permite tráfico si hay un servicio para aceptarlo; el oyente muestra un servicio esperando, pero no si el tráfico de red puede alcanzarlo. Leer ambos juntos reduce la investigación sin afirmar exposición externa.

📝 Nota: ss muestra el estado de enlace local, y UFW muestra un firewall de host. Ninguno prueba alcanzabilidad de Internet a través de firewalls de proveedor o NAT; eso requiere pruebas autorizadas desde otro sistema.

v0.2.0 sin embargo etiqueta la misma lista como “Total” y “Public” después de descartar direcciones de enlace, aunque cuatro de nueve puertos TCP eran solo bucle invertido. Su filtro LISTEN también pierde filas UDP marcadas como UNCONN. Lee este resultado como un recuento de puerto TCP local, no exposición pública.

Convertir Hallazgos Verificados en una Cola de Acciones Práctica

Establezca prioridad por confianza, exposición, impacto e intención. Priority 1 cubre debilidades confirmadas que requieren acción. Priority 2 cubre hallazgos importantes que aún necesitan investigación, mientras que Priority 3 cubre elementos de menor riesgo o impulsados por políticas. Si una configuración es intencional, documente por qué, cualquier control compensatorio y cuándo revisarlo.

La tabla aplica ese enfoque a esta ejecución; la evidencia incompleta mantiene una prioridad tentativa:

Priority 2 no significa inofensivo; la evidencia sigue siendo incompleta. Asigne a cada elemento sin resolver un propietario y una fecha límite. Promuévalo si la verificación confirma exposición o debilidad. Si es intencional y controlado, registre la decisión claramente.

La etiqueta del informe no establece el orden: la verificación y el contexto lo hacen.

⚠️ Advertencia: No cambie la autenticación SSH o las reglas de firewall remoto desde esta secuencia de comandos. Un error puede bloquearlo. Antes de la remediación, confirme el acceso de clave probado y valide la nueva configuración. Mantenga una segunda sesión abierta y asegúrese de que el acceso a consola o recuperación funcione.

Maneje cada remediación como un flujo de trabajo separado. Asigne dependencias antes de detener servicios, clasifique actualizaciones antes de programarlas y verifique propiedad y sumas de verificación antes de cambiar permisos SUID.

Dónde se detiene la vista de vps-audit

vps-audit v0.2.0 es una lista de verificación Bash de un momento específico. No puede establecer exposición externa, detectar vulnerabilidades o malware, inspeccionar cargas de trabajo, analizar registros almacenados ni proporcionar monitoreo continuo. No es una prueba de penetración ni una evaluación de CIS Benchmark.

El código añade advertencias importantes.

• El estado del puerto se convierte en PASS por debajo de tres puertos TCP analizados, WARN en tres o cuatro, y FAIL en cinco o más, a pesar de las variables nominales 10/20.
• Un PASS de unattended-upgrades solo verifica el paquete, no su configuración, temporizador o historial de ejecución.
• La prueba de actualización utiliza metadatos en caché para un apt-get -s upgrade general, luego llama a cada paquete listado una “actualización de seguridad”.

La prueba de registro de sudo solo lee /etc/sudoers, perdiendo /etc/sudoers.d/ y registros normales de journal o syslog. El Issue #33, abierto cuando se verificó el 8 de septiembre de 2026, documenta este FAIL falso en Ubuntu 20.04 y 24.04. El análisis también puede fallar con salida en idiomas no ingleses, como se registra en el issue #37 abierto. A pesar de la redacción de su README, esta versión no lista conexiones establecidas.

Amplíe la revisión cuando sea necesario. El comportamiento sospechoso requiere análisis de registros almacenados y cargas de trabajo. Para un VPS importante, confirme copias de seguridad probadas y considere pruebas externas autorizadas. Los sistemas críticos o regulados pueden justificar Lynis, el CIS Benchmark de Ubuntu 24.04 o revisión profesional.

Conclusión: Verificar, Priorizar y Revisar

Mantén el informe original privado y conserva una copia redactada. Registra el SHA-256 del script, la etiqueta y el commit junto con el tiempo de ejecución, los servicios previstos, los resultados de verificación y la cola de acciones.

1. Verifica los hallazgos de alto impacto con comandos nativos antes de cambiar el servidor.
2. Corrige los problemas confirmados de alto riesgo de forma segura, investiga las incógnitas y documenta las excepciones intencionales.
3. Vuelve a ejecutar la misma versión fijada después de los cambios o según un cronograma, luego compara los informes manualmente.

Al comparar informes, enfócate en cambios de autenticación, reglas de firewall, listeners y hallazgos resueltos. Las marcas de tiempo y las lecturas de recursos cambiarán. Anota los cambios deliberados para que el próximo revisor entienda por qué los resultados difieren.

vps-audit no tiene base de datos de referencia, programador, análisis de tendencias ni motor de comparación. Su valor proviene de un hábito repetible: ejecutar, verificar, priorizar y revisar.