Checklist de seguridad para tu primer VPS: acceso, respaldo y verificación

Para proteger tu primer VPS, empieza por poder recuperarlo. Después limita quién entra, qué servicios quedan expuestos y cómo comprobarás que las actualizaciones y los respaldos funcionan. El resultado no es una lista de paquetes instalados: es un servidor con accesos probados, responsables identificados y una recuperación ensayada.

Esta guía sirve para un VPS Linux administrado por ti; los ejemplos de comprobación corresponden a Ubuntu Server con OpenSSH y UFW. En otras distribuciones, paneles o contenedores cambian los servicios y reglas. No apliques estas instrucciones a Windows ni a un VPS gestionado por otra persona sin coordinarte. Tampoco hay un plazo universal de 10 o 60 minutos: depende de la aplicación, sus datos y el acceso de rescate.

Cinco puertas: no pases a la siguiente sin evidencia

1. Recuperar: confirma acceso al panel y consola fuera de SSH, credenciales de emergencia protegidas y una restauración posible.
2. Inventariar: identifica usuarios, puertos, aplicaciones, versiones y dependencias antes de cerrar nada.
3. Restringir: realiza un cambio pequeño con procedimiento de retorno escrito, no un bloque de comandos desconocidos.
4. Verificar: abre una conexión nueva y prueba la tarea de negocio; que la sesión antigua siga viva no prueba el acceso futuro.
5. Mantener: asigna responsable, revisión y alerta. Una medida sin seguimiento se vuelve una suposición.

1. Asegura la cuenta y SSH, sin perder la entrada

Protege primero el panel del proveedor con MFA cuando esté disponible, cuentas individuales y métodos de recuperación bajo control. Un SSH bien configurado no impide que una cuenta de panel comprometida cambie el servidor. Evita compartir una sola identidad entre empleados y retira accesos cuando cambia su responsabilidad.

Para SSH, crea y prueba una cuenta administrativa individual con elevación de privilegios cuando corresponda; utiliza claves protegidas en el equipo cliente. Nunca copies una clave privada al VPS ni a un formulario de soporte. El servidor recibe la clave pública. Guarda cómo recuperar el acceso antes de restringir el inicio directo de root o deshabilitar un método de autenticación.

El procedimiento de aceptación es deliberadamente más estricto que “guardé el archivo”:

1. Conserva la sesión actual y abre una segunda con la cuenta y clave que usarás. Confirma que puede realizar la administración necesaria.
2. Respalda la configuración que cambiarás. Revisa archivos incluidos y reglas condicionales: no asumas que la última línea escrita prevalece.
3. Valida la sintaxis con sudo sshd -t. Un resultado sin errores no garantiza que las credenciales o reglas sean las deseadas.
4. Aplica el cambio durante la ventana acordada según el servicio y versión instalados. Abre una tercera conexión nueva sin reutilizar conexiones multiplexadas; comprueba que ocurra una nueva autenticación y valida el acceso previsto y el rechazo del que retiraste.
5. Si falla, conserva las sesiones disponibles y vuelve a la configuración respaldada mediante la vía de recuperación preparada. No cierres todo para “probar de nuevo”.

Ubuntu documenta la validación previa de OpenSSH; el manual de sshd_config explica la precedencia y las opciones. Consulta además el manual de tu versión instalada. Cambiar el puerto puede reducir ruido, pero no reemplaza autenticación, restricciones ni actualizaciones. Si utilizas MFA en SSH, revisa sus dependencias antes de deshabilitar autenticación interactiva.

2. Abre lo necesario, no todo lo que sugiera una plantilla

Escribe una ficha por servicio: proceso, puerto, protocolo, dirección de escucha, origen autorizado y responsable. Distingue el firewall del proveedor, el del sistema operativo y las reglas de contenedores o paneles. Una capa abierta puede contradecir la intención de otra.

Antes de activar una política restrictiva, permite explícitamente el acceso de gestión correcto y las dependencias necesarias. En UFW, sudo ufw status verbose permite revisar estado y reglas, y --dry-run previsualiza determinadas operaciones sin aplicarlas. Verifica también IPv6 cuando esté habilitado. La documentación de Ubuntu sobre firewall explica la sintaxis; aquí no se prescribe activar reglas a ciegas.

Un WAF trabaja sobre tráfico de aplicaciones web; no sustituye el control de SSH, permisos del sistema ni copias de seguridad. La mitigación DDoS depende del servicio contratado y sus límites. Pide qué protege, qué no, cómo se detecta un incidente y quién responde. No consideres un logo de “seguridad” como evidencia de cobertura.

3. Actualiza sin confundir “instalado” con “aplicado”

Comprueba que la distribución y la aplicación sigan recibiendo mantenimiento. Documenta repositorios, versiones críticas y procedimiento de reversión. Elige una política de actualizaciones compatible con la carga: automatizar parches no elimina la necesidad de revisar fallos, servicios reiniciados o cambios de comportamiento.

Algunas actualizaciones necesitan reiniciar servicios o el sistema. En Ubuntu, unattended-upgrades y los mecanismos de reinicio tienen opciones distintas; no presupongas su estado. Consulta actualizaciones automáticas de Ubuntu y acuerda cuándo validar acceso, aplicación y trabajos programados después del mantenimiento. No desactives AppArmor u otras protecciones como solución genérica a un error.

4. Un respaldo cuenta cuando puedes restaurarlo

Define con el negocio dos límites: cuántos datos recientes puede perder y cuánto tiempo puede estar detenido. Esos objetivos orientan frecuencia, retención y recursos; no son garantías de recuperación. Una copia en el mismo VPS no cubre la pérdida del servidor o de su almacenamiento.

Guarda copias separadas del entorno original y controla quién puede leerlas o borrarlas. Cifra los datos sensibles y conserva las claves de recuperación por una vía distinta, accesible a los responsables autorizados. Para bases de datos, verifica consistencia con el procedimiento soportado por el motor: copiar archivos abiertos no garantiza una base utilizable.

Ensayo mínimo: selecciona una copia identificada por fecha, restaura en un destino aislado que no sobrescriba producción, valida archivos y permisos, abre la aplicación y comprueba una operación representativa con datos de prueba. Evita correos, cobros o integraciones reales desde ese entorno. Registra duración, errores y qué no se recuperó. Si usas restic, su documentación de restauración permite escoger copia y destino; el éxito del comando no sustituye la comprobación de la aplicación.

5. Vigila síntomas que alguien pueda atender

Un monitoreo útil necesita destinatario, horario, escalamiento y una acción concreta. Además de CPU o RAM, observa espacio e inodos, antigüedad del último respaldo correcto, errores de aplicación y caducidad de certificados. Una alerta enviada a un buzón que nadie lee no crea cobertura 24/7.

Prueba una notificación inocua y comprueba que llega a quien debe responder. Para HTTPS, verifica dominio, cadena y renovación automática, no solo el candado del día. Let's Encrypt explica la validación del dominio y emisión mediante ACME. Un certificado no demuestra que la aplicación carezca de vulnerabilidades. No habilites HSTS indiscriminadamente sin comprobar todos los nombres y servicios afectados.

Ficha reutilizable: “hecho” significa evidencia guardada

Copia esta ficha a tu registro privado. No publiques IP de gestión, nombres de usuario ni rutas sensibles. Para cada control apunta responsable, fecha, resultado y ubicación de la evidencia; deja “pendiente” cuando no se haya probado.

• Consola de recuperación: acceso probado y método alternativo disponible.
• Cuenta administrativa: nueva conexión y privilegios necesarios comprobados.
• SSH: validación de configuración, nueva autenticación sin reutilizar conexiones multiplexadas, acceso permitido y rechazo previsto registrados.
• Red: inventario de servicios, reglas por capa y prueba desde orígenes propios autorizados.
• Actualizaciones: política, ventana, responsable y revisión posterior definidos.
• Respaldo: copia identificada, ubicación separada y restauración aislada probada.
• Aplicación: operación representativa correcta tras el cambio, sin efectos reales de prueba.
• Alertas: destinatario y recepción comprobados; escalamiento documentado.
• Retorno: pasos, condiciones para activarlo y responsable acordados.
• Próxima revisión: fecha concreta y revisión adicional ante cambios de aplicación, usuarios o red.

Ejemplo hipotético: un equipo consigue entrar con la nueva clave, pero el respaldo no restaura la base de datos. Su estado no es “VPS protegido”: el acceso está verificado y la recuperación está pendiente. No debe compensar ese fallo instalando más herramientas ni cerrando la ventana de mantenimiento sin comunicar el riesgo.

IA: ayuda para explicar, no para aprobar cambios

Un asistente puede ayudarte a organizar una checklist o interpretar documentación pública. Trátalo como apoyo, no como auditor: puede proponer opciones incompatibles con tu versión o pasar por alto un archivo incluido. No le entregues claves privadas, tokens, respaldos ni registros con datos personales. Usa ejemplos saneados y comprueba cada propuesta con documentación y un entorno de ensayo.

No concedas ejecución privilegiada para “arreglar todo”. La persona responsable sigue decidiendo el alcance, comprobando el retorno y validando el resultado. La IA no cambia los requisitos de acceso, recuperación ni responsabilidad.

¿Cuándo conviene un VPS administrado?

Si puedes mantener los controles anteriores y atender incidencias, administrar tu VPS es una alternativa válida. Si no tienes responsable de guardia, ventanas de mantenimiento o experiencia de restauración, un socio puede aportar operación documentada y reducir trabajo interno. Pagar más no garantiza seguridad: compara tareas y evidencias, no adjetivos.

Solicita por escrito quién mantiene sistema, panel y aplicación; quién prueba restauraciones; horarios y tiempos de respuesta; exclusiones, accesos y forma de recuperar tus datos al terminar el servicio. Lee también cómo repartir la operación de un VPS administrado y no administrado.

Si quieres contrastar tu situación con Cobalt Blue Web, solicita una revisión de alcance para tu VPS. Lleva sistema y versión, aplicaciones, número de responsables y estado de los respaldos, sin enviar secretos. Pide una propuesta con responsabilidades y condiciones verificables; puedes aplicar la misma ficha para evaluar otro proveedor o decidir continuar por tu cuenta.