VPS Hardening Execution Plan

Estado

• Documento operativo cerrado con ejecucion real registrada.
• Baseline hardening finalizado exitosamente el 2026-05-28.
• El VPS queda en estado GO para pasar a la preparacion del compose conservador de OpenClaw.
• El compose real de OpenClaw todavia NO fue desplegado.

Ejecucion real - 2026-05-28

Fase 1 - Safe point y snapshot

• Safe point local:
• git status -sb -> ## main...origin/main
• git rev-parse HEAD -> 1b262e3de5fd697b533ddfc1ad6798568604b54b
• Safe point VPS:
• hostname -> srv977009
• uptime -> up 9 min
• docker ps -> portainer y nginx-proxy-manager activos
• docker images -> portainer/portainer-ce:latest, jc21/nginx-proxy-manager:latest
• docker volume ls -> portainer_data, portainer_data_new
• Snapshot Hostinger confirmado por operador:
• Nombre: pre-openclaw-hardening-srv977009-2026-05-28
• Fecha/hora: 2026-05-28 13:02

Fase 2 - Auditoria pre-update

• apt update ejecutado sin error fatal.
• apt list --upgradable reporta 67 paquetes pendientes.
• Paquetes criticos pendientes:
• Docker runtime: containerd, runc
• Docker tooling: docker-buildx-plugin, docker-compose-plugin
• Sistema base: systemd, libsystemd0, libudev1, udev, initramfs-tools, netplan.io, nftables, iproute2
• Kernel pendiente:
• No se detecta linux-image ni linux-generic pendiente en la lista de upgrades.
• Kernel actual auditado: 6.8.0-117-generic
• Reboot pendiente antes del upgrade:
• /var/run/reboot-required no existe.
• /var/run/reboot-required.pkgs no existe.
• Hallazgo adicional:
• apt update advierte entradas duplicadas en /etc/apt/sources.list.d/ubuntu-mirrors.list.
• No se corrige en esta ventana porque no forma parte del alcance aprobado y el proceso no debe improvisar.

Fase 3 - Update controlado

• apt upgrade -y ejecutado con exito.
• 67 paquetes actualizados.
• Componentes destacados actualizados:
• Docker runtime: containerd 2.2.1-0ubuntu1~24.04.2, runc 1.3.4-0ubuntu1~24.04.1
• Docker tooling: docker-buildx-plugin 0.34.1-1~ubuntu.24.04~noble, docker-compose-plugin 5.1.4-1~ubuntu.24.04~noble
• Sistema base: systemd 255.4-1ubuntu8.15, udev 255.4-1ubuntu8.15, netplan.io 1.1.2-8ubuntu1~24.04.2, nftables 1.0.9-1ubuntu0.1, iproute2 6.1.0-1ubuntu6.3, initramfs-tools 0.142ubuntu25.8
• Warnings observados durante upgrade:
• Needrestart difirio reinicios de docker.service, systemd-logind.service y unattended-upgrades.service.
• apparmor.postinst: 148: [: Illegal number: yes
• No containers need to be restarted.
• apt autoremove -y ejecutado nuevamente despues del upgrade para evitar el lock inicial.
• Estado final de paquetes:
• apt autoremove -y -> 0 to remove
• apt list --upgradable sin paquetes pendientes

Fase 4 - Validacion post-update sin reboot

• Docker:
• docker --version -> Docker version 29.1.3, build 29.1.3-0ubuntu3~24.04.2
• docker compose version -> Docker Compose version v5.1.4
• docker ps -> portainer y nginx-proxy-manager siguen activos
• systemctl status docker --no-pager -> active (running)
• Logs de Docker muestran EOF transitorio durante reinicio de containerd, luego recuperado
• SSH:
• systemctl status ssh --no-pager -> active (running)
• fail2ban:
• systemctl status fail2ban --no-pager -> active (running)
• Warning observado: 'allowipv6' not defined in 'Definition'. Using default one: 'auto'
• UFW:
• ufw status verbose -> active
• Politica: deny (incoming), allow (outgoing), deny (routed)
• Puertos permitidos: 22/tcp, 80/tcp, 443/tcp, 9443/tcp en IPv4 e IPv6
• Validacion NPM y Portainer:
• curl -I http://127.0.0.1:81 -> HTTP/1.1 200 OK
• curl -k -I https://127.0.0.1:9443 -> HTTP/1.1 200 OK
• Networking y puertos:
• ss -tulpn confirma listeners en 22, 80, 81, 443, 8000, 9443
• Publicacion de puertos Docker se mantiene sin cambios visibles

Fase 5 - Swap 4 GiB sin reboot

• Swap creada y activada:
• fallocate -l 4G /swapfile
• chmod 600 /swapfile
• mkswap /swapfile
• swapon /swapfile
• Persistencia aplicada:
• /etc/fstab actualizado con /swapfile none swap sw 0 0
• Validacion swap:
• ls -l /swapfile -> -rw------- y tamano 4294967296 bytes
• swapon --show -> /swapfile file 4G
• free -h -> Swap: 4.0Gi total, 0B used, 4.0Gi free
• Impacto en disco:
• df -h sobre / -> 96G size, 9.3G used, 87G avail, 10% use
• La reserva de swap queda absorbida sin presion visible de disco
• Validacion posterior del host:
• uptime -> up 29 min
• docker ps -> portainer y nginx-proxy-manager siguen activos
• curl -k -I https://127.0.0.1:9443 -> HTTP/1.1 200 OK
• curl -I http://127.0.0.1:81 -> HTTP/1.1 200 OK
• ss -tulpn mantiene listeners en 22, 80, 81, 443, 8000, 9443
• Warning detectado:
• mkswap reporto permisos inseguros 0644 durante la creacion por solapamiento temporal con chmod; el estado final del archivo quedo corregido en 0600 antes de la validacion

Fase 6 - Reboot controlado y validacion post-reinicio

• reboot ejecutado con exito.
• Reconexión SSH validada despues del reinicio.
• Validaciones obligatorias post-reboot:
• uptime -> up 0 min
• hostname -> srv977009
• free -h -> Swap: 4.0Gi total, 0B used, 4.0Gi free
• swapon --show -> /swapfile file 4G
• df -h -> /dev/sda1 96G size, 9.2G used, 87G avail, 10% use
• docker ps -> portainer y nginx-proxy-manager auto-recuperados
• docker compose version -> Docker Compose version v5.1.4
• systemctl status docker --no-pager -> active (running)
• systemctl status ssh --no-pager -> active (running)
• systemctl status fail2ban --no-pager -> active (running)
• ufw status verbose -> active, politica sin cambios
• ss -tulpn -> listeners presentes en 22, 80, 81, 443, 8000, 9443
• Validacion de aplicaciones:
• Portainer responde: curl -k -I https://127.0.0.1:9443 -> HTTP/1.1 200 OK
• NPM responde: curl -I http://127.0.0.1:81 -> HTTP/1.1 200 OK
• Contenedores auto-recuperados: si
• Swap persistio tras reinicio: si
• Networking estable: si
• Warnings observados:
• fail2ban mantiene warning no bloqueante: 'allowipv6' not defined in 'Definition'. Using default one: 'auto'
• Persisten warnings previos de apt por entradas duplicadas en /etc/apt/sources.list.d/ubuntu-mirrors.list

Estado GO/NO-GO actualizado

• Estado actualizado: GO para pasar a la siguiente etapa documental previa a OpenClaw.
• Fundamentacion:
• Snapshot confirmado antes de cambios
• Updates aplicados
• Reboot ejecutado y validado
• Swap de 4 GiB activa y persistente
• Docker estable
• NPM estable
• Portainer estable
• Networking y listeners esperados validados
• Riesgos remanentes:
• Advertencias de apt por mirrors duplicados siguen pendientes de saneamiento futuro
• Warning de configuracion fail2ban allowipv6 sigue presente aunque el servicio esta operativo

Registro formal de cierre

• Snapshot utilizado:
• pre-openclaw-hardening-srv977009-2026-05-28
• Confirmado por operador a las 2026-05-28 13:02
• Updates ejecutados:
• apt update
• apt upgrade -y
• apt autoremove -y
• Reboot ejecutado:
• si, con reconexion SSH y auto-recuperacion de contenedores validadas
• Swap activa:
• si, 4 GiB, persistente via /etc/fstab
• Validacion final obligatoria:
• Docker estable: si
• Portainer estable: si
• NPM estable: si
• Networking estable: si
• Listeners esperados: 22, 80, 81, 443, 8000, 9443
• SSH operativo: si
• fail2ban operativo: si
• ufw operativo: si
• Rollback disponible:
• si, via snapshot Hostinger y respaldos operativos previos
• Salida aprobada:
• Baseline hardening del VPS finalizado
• Arquitectura multi-app mantenida y aprobada
• VPS en GO para OpenClaw
• Siguiente paso recomendado: redactar compose conservador de OpenClaw

1. Objetivo

• Este documento deja cerrada la etapa de saneamiento base del VPS.
• El host compartido que sostiene portainer y nginx-proxy-manager ya fue estabilizado y revalidado.
• La coexistencia multi-app queda soportada por una base predecible: snapshot reciente, updates ejecutados, reboot controlado, Docker validado, NPM/Portainer revalidados, swap definida y rollback listo.
• El compose real de OpenClaw sigue pendiente y debe tratarse en la siguiente fase con un diseno conservador.

2. Snapshot / Backup Previo

Regla

• Ningun cambio operativo debe comenzar sin snapshot Hostinger exitoso y validado.

Alcance minimo de backup

• Snapshot completo del VPS desde Hostinger.
• Backup de configuracion Docker relevante para el host compartido.
• Backup de Nginx Proxy Manager.
• Backup de Portainer.
• Backup de compose existentes.
• Backup de volumenes criticos existentes.

Estrategia recomendada

1. Tomar safe point local y registrar git status -sb y git rev-parse HEAD.
2. Registrar fecha, hora y nombre del snapshot Hostinger.
3. Exportar o copiar respaldos de NPM y Portainer segun su mecanismo operativo vigente.
4. Guardar copia de compose existentes y de cualquier archivo operativo asociado fuera del workspace con secretos.
5. Respaldar volumenes criticos antes de updates o reboot.
6. Verificar que el snapshot aparezca como completado y recuperable en el panel.
7. Registrar evidencia de exito antes de seguir.

Checklist Pre-Cambio

• Safe point local registrado.
• HEAD local registrado.
• Snapshot Hostinger completado.
• Snapshot identificado con fecha y motivo.
• Backup Docker preparado.
• Backup NPM preparado.
• Backup Portainer preparado.
• Backup compose existentes preparado.
• Backup de volumenes criticos preparado.
• Validacion posterior del snapshot realizada.
• Ventana de mantenimiento aprobada.
• Rollback documentado y disponible.

3. Plan de Updates

Objetivo

• Aplicar solo despues del snapshot y de la aprobacion de ventana.
• Ejecutar primero una lectura y clasificacion de updates pendientes antes de tomar cualquier accion.

Clasificacion que debe registrarse

• Updates de seguridad de userland.
• Updates base del sistema no criticos.
• Updates de librerias sensibles como libc6.
• Updates de kernel e initramfs.
• Updates de componentes Docker relacionados como containerd, runc, docker-buildx-plugin y docker-compose-plugin.

Secuencia recomendada

1. Revisar lista de paquetes pendientes y separar seguridad, runtime y kernel.
2. Identificar si los updates afectan directamente al stack Docker.
3. Confirmar si el reboot pendiente sigue asociado a kernel, libc6 u otros paquetes sensibles.
4. Ejecutar primero la actualizacion aprobada de paquetes base y runtimes.
5. Ejecutar dentro de la misma ventana las actualizaciones de kernel aprobadas para evitar estados intermedios.
6. Preparar validacion posterior de Docker antes de considerar cualquier otro cambio.

Impacto potencial a documentar antes de ejecutar

• Docker daemon puede requerir reinicio o puede quedar temporalmente inestable si cambian dependencias del runtime.
• containerd y runc pueden alterar el arranque o la recuperacion de contenedores despues del reboot.
• docker-compose-plugin puede cambiar comportamiento operacional de compose futuros, por lo que la version posterior debe validarse.
• Cambios de networking del sistema o del kernel pueden afectar bridges, NAT, iptables/nftables y exposicion de puertos publicados por Docker.
• Cambios de librerias base pueden dejar al host en estado parcialmente actualizado hasta que se reinicie.

Regla

• En esta fase no se ejecutan comandos de update; solo se deja la secuencia aprobada para una ventana posterior.

4. Plan de Reboot Controlado

Ventana recomendada

• Ventana de bajo trafico y con operador disponible para seguimiento completo de post-reinicio.
• Evitar ejecutar reboot sin snapshot confirmado ni sin evidencia de backup.

Validaciones previas

• Snapshot y backups confirmados.
• Lista de paquetes aplicados registrada.
• Criterio de rollback listo.
• Canal alternativo de acceso SSH validado.
• Confirmacion de que portainer y nginx-proxy-manager estaban sanos antes del reboot.

Riesgos

• Docker puede no levantar automaticamente el daemon o algunos contenedores.
• NPM puede quedar arriba pero con rutas/proxy degradados.
• Portainer puede levantar con acceso web degradado o con volumen inconsistente.
• Puede persistir desalineacion de puertos o aparecer un cambio de networking post-kernel.
• Un reboot sobre host compartido impacta a todas las apps del VPS al mismo tiempo.

Que validar despues del reboot

• Acceso SSH funcional.
• Host vuelve con kernel esperado.
• Docker daemon arriba y estable.
• Contenedores esperados activos.
• Portainer operativo.
• NPM operativo.
• fail2ban operativo.
• ufw operativo.
• Networking del host operativo.
• Publicacion de puertos esperados sin cambios inesperados.

Checklist Post Reboot

• SSH responde y permite acceso administrativo.
• Docker inicia sin errores criticos.
• Portainer responde y mantiene su estado esperado.
• NPM responde y mantiene proxy/TLS esperados.
• fail2ban sigue activo.
• ufw sigue activo con politica esperada.
• networking del host esta estable.
• puertos publicados coinciden con lo aprobado.
• contenedores esperados estan arriba o recuperables sin improvisacion.

5. Plan Swap

Recomendacion

• Crear swap de 4 GiB solo despues de completar updates, reboot y validacion de base estable.

Estrategia conservadora

• Tratar la swap como amortiguador de picos, no como sustituto de capacidad real.
• Crear la swap en una segunda fase de la misma ventana o en una ventana inmediata posterior si el reboot deja dudas.
• Validar primero que el host haya vuelto limpio antes de sumar otro cambio de sistema.

Riesgos

• Mayor latencia si el host entra en uso sostenido de swap.
• Sensacion falsa de capacidad si se usa para cubrir problemas estructurales.
• Cambio adicional sobre sistema base si se ejecuta en un host todavia no revalidado.

Impacto esperado

• Menor riesgo de OOM durante picos transitorios.
• Mejor margen para coexistencia multi-app y tareas de mantenimiento.
• Mejor amortiguacion para futuras operaciones Docker sin asumir modelos locales pesados.

Validaciones posteriores

• Swap visible y activa con tamano esperado.
• Sin errores de arranque o montaje asociados.
• Docker, Portainer y NPM siguen estables.
• Recursos generales del host se mantienen saludables.

6. Validacion Post-Hardening

GO / NO-GO Final previo a OpenClaw

• GO solo si el reboot fue limpio.
• GO solo si Docker esta estable.
• GO solo si Portainer esta estable.
• GO solo si NPM esta estable.
• GO solo si la swap de 4 GiB quedo activa.
• GO solo si no hay errores criticos en sistema o servicios.
• GO solo si CPU, RAM, disco y swap muestran salud aceptable.
• GO solo si networking y puertos quedaron validados.
• GO solo si el rollback sigue disponible.
• NO-GO si falta cualquiera de los puntos anteriores.

Salida aprobada despues de GO

• Revalidacion final documental del host.
• Recién despues, redaccion de compose conservador de OpenClaw.

7. Rollback

Snapshot

• Si el host queda inestable a nivel sistema, priorizar rollback completo por snapshot Hostinger.

Docker

• Si el problema es del runtime y no del sistema completo, recuperar el estado previo validando daemon, contenedores y volumenes con apoyo del backup preparado.

Compose

• Restaurar compose existentes tal como estaban antes de la ventana si hubiera cambios necesarios para recuperar estado.

NPM

• Restaurar configuracion o backup de NPM si el proxy queda degradado tras updates o reboot.

Networking

• Si el networking post-cambio queda inconsistente, detener la secuencia y volver al snapshot o al ultimo estado aprobado segun severidad.

8. Criterios de Aborto

• Detener el proceso si el snapshot falla o no puede validarse.
• Detener el proceso si los backups de Docker, NPM, Portainer, compose o volumenes quedan incompletos.
• Detener el proceso si la clasificacion de updates muestra riesgo no entendido sobre Docker o networking.
• Detener el proceso si Docker, Portainer o NPM no estan sanos antes del reboot.
• Detener el proceso si el reboot no devuelve acceso SSH confiable.
• Detener el proceso si Docker no vuelve estable despues del reboot.
• Detener el proceso si Portainer o NPM quedan degradados.
• Volver snapshot si el host queda operativamente inestable o si el rollback parcial no da confianza.
• No continuar con OpenClaw si el resultado final no cumple todos los criterios GO.

Estado actual

• Estado vigente: GO.
• Baseline hardening: finalizado exitosamente.
• Compose OpenClaw: todavia no desplegado.
• Siguiente paso aprobable: preparar compose conservador de OpenClaw y su documentacion operativa.