Cómo asegurar un VPS nuevo: checklist después de instalar Ubuntu

1. Actualiza el sistema

sudo apt update
sudo apt full-upgrade -y
sudo reboot

Después del reinicio vuelve a conectarte y confirma que los servicios arrancaron. Revisa actualizaciones regularmente y considera unattended-upgrades para parches de seguridad.

2. Crea un usuario administrativo

adduser adminweb
usermod -aG sudo adminweb

Elige un nombre propio, no copies necesariamente adminweb. Abre una segunda terminal y comprueba:

ssh adminweb@IP_DEL_VPS
sudo whoami

El resultado debe ser root.

3. Configura llaves SSH

Genera una llave Ed25519 en tu computador y cópiala al servidor:

ssh-keygen -t ed25519 -a 100
ssh-copy-id adminweb@IP_DEL_VPS

En Windows, si ssh-copy-id no está disponible, copia el contenido de la clave .pub dentro de ~/.ssh/authorized_keys en el servidor. La guía de llaves SSH cubre permisos y comprobaciones.

4. Endurece SSH sin quedarte fuera

Crea un archivo adicional en lugar de editar a ciegas la configuración principal:

sudo nano /etc/ssh/sshd_config.d/99-hardening.conf

Contenido recomendado después de verificar las llaves:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 4

Valida y recarga:

sudo sshd -t
sudo systemctl reload ssh

No cierres la sesión original hasta abrir una nueva correctamente.

5. Activa el firewall

Autoriza SSH antes de activar UFW:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status verbose

Cuando instales un servidor web añade Nginx Full o los puertos 80 y 443. No abras bases de datos al mundo. Consulta la guía de firewall en Linux.

6. Instala protección contra fuerza bruta

sudo apt install -y fail2ban
sudo systemctl enable --now fail2ban
sudo fail2ban-client status

Fail2Ban complementa las llaves y el firewall. Ajusta sus jails según los servicios reales y revisa cómo configurar Fail2Ban.

7. Revisa puertos y servicios

sudo ss -tulpn
systemctl --type=service --state=running

Deshabilita servicios innecesarios y escucha bases de datos en localhost o una red privada. Cada puerto público debe tener una razón documentada.

8. Configura hora y registros

timedatectl
sudo timedatectl set-timezone UTC
sudo journalctl -p warning -b

UTC simplifica la correlación de logs entre sistemas. Si tu operación exige otra zona, úsala de forma consistente.

9. Crea backups recuperables

Define qué datos copiar, frecuencia, retención, cifrado y destino externo. Incluye archivos de aplicación, bases de datos y configuraciones necesarias. Un backup que nunca se restauró es una suposición.

No guardes la única copia en el mismo VPS. Consulta la guía de backups en VPS.

10. Configura monitoreo

Vigila disponibilidad, CPU, RAM, disco, certificados y errores. Activa alertas antes de llegar al límite. Como comprobación inicial:

uptime
free -h
df -h
sudo journalctl -p err -b

11. Protege aplicaciones y secretos

Ejecuta servicios con usuarios sin privilegios, utiliza variables o gestores de secretos, limita permisos y evita credenciales en repositorios. Mantén runtime, dependencias y contenedores actualizados.

El acceso root no debe ser la cuenta cotidiana de una aplicación. Si un proceso web es comprometido, los permisos limitados reducen el daño.

12. Documenta la recuperación

Guarda fuera del VPS las instrucciones de acceso de emergencia, restauración, DNS, dependencias y responsables. Comprueba que la consola del proveedor funciona antes de necesitarla.

Los VPS KVM de Terranode incluyen consola y herramientas de gestión desde el panel. Esas funciones ayudan a recuperar acceso, pero no sustituyen tu propia configuración ni las copias externas.

Checklist final

• [ ] Sistema actualizado y reiniciado
• [ ] Usuario sudo probado
• [ ] Llave SSH probada en otra sesión
• [ ] Root remoto y contraseñas desactivados
• [ ] Firewall activo con puertos mínimos
• [ ] Fail2Ban operativo
• [ ] Servicios y puertos revisados
• [ ] Backups externos configurados y restaurados en prueba
• [ ] Monitoreo y alertas activos
• [ ] Procedimiento de emergencia documentado

El orden correcto para endurecer Ubuntu sin perder acceso

La seguridad inicial debe aplicarse en un orden que siempre conserve una vía de entrada comprobada. Empieza por actualizar, crea el usuario administrativo, instala su llave, prueba una segunda sesión y solo entonces restringe root y contraseñas.

• Mantén abierta la sesión original hasta terminar dos conexiones nuevas con el usuario sudo.
• Confirma desde la consola del proveedor que puedes reiniciar y abrir una terminal si SSH deja de responder.
• Anota la IP, el usuario, el puerto y la ubicación de la llave antes de cambiar el demonio SSH.

La comprobación práctica debe acompañar el cambio. La prueba válida es cerrar únicamente una sesión secundaria, volver a entrar y ejecutar sudo -v. También conviene intentar deliberadamente una contraseña después de desactivarla: debe fallar.

La precaución principal en este punto es clara: el error grave es recargar una configuración no validada o cerrar la única sesión funcional. sshd -t detecta sintaxis, pero no demuestra que elegiste el usuario o la llave correctos.

Actualizaciones que no convierten producción en un experimento

Instalar parches reduce vulnerabilidades conocidas, pero un full-upgrade también puede cambiar kernel, OpenSSH o bibliotecas usadas por la aplicación. En un servidor nuevo es el momento ideal para hacerlo porque todavía no hay carga de negocio.

• Revisa /var/run/reboot-required para saber si el kernel o una biblioteca crítica exige reinicio.
• Habilita actualizaciones automáticas solo para seguridad y define una ventana para reinicios controlados.
• Después de reiniciar comprueba red, SSH, hora, resolución DNS y los servicios que hayas instalado.

Para verificar esta parte sin depender de intuiciones, usa apt list --upgradable antes del cambio y journalctl -b -p warning después. Si una actualización afecta OpenSSH, conserva la terminal actual mientras validas otra conexión.

La precaución principal en este punto es clara: no confundas instalar paquetes automáticamente con reiniciar automáticamente. Un reinicio sorpresa durante una importación o una copia puede causar una interrupción evitable.

Permisos administrativos: sudo para personas, usuarios limitados para servicios

Una cuenta humana necesita elevar privilegios de forma auditable; una aplicación web no. Separar ambos usos evita que una vulnerabilidad en el servicio entregue de inmediato control completo del VPS.

• Crea una cuenta distinta para cada administrador en lugar de compartir root o una llave común.
• Ejecuta Node, PHP, bases de datos y workers con sus usuarios de servicio, sin shell cuando no la necesitan.
• Revisa periódicamente los grupos sudo y docker; pertenecer a docker equivale prácticamente a root.

La evidencia que conviene guardar es concreta. Comprueba identidades con id, miembros de grupos con getent group sudo y procesos con ps -eo user,pid,cmd. Cada proceso debe tener únicamente los permisos que requiere.

La precaución principal en este punto es clara: dar NOPASSWD: ALL por comodidad elimina una barrera importante. Si automatizas, concede comandos concretos en un archivo de /etc/sudoers.d/ y valida con visudo -c.

Firewall: publicar solo lo que realmente presta servicio

UFW debe reflejar la arquitectura, no una lista copiada. Un servidor web suele necesitar 22 —o el puerto SSH elegido—, 80 y 443; MySQL, PostgreSQL, Redis y paneles internos no deberían escuchar para todo internet.

• Añade la regla SSH antes de activar UFW y verifica el puerto efectivo con sshd -T.
• Prefiere reglas from IP para paneles administrativos, métricas y accesos temporales.
• Comprueba la exposición desde otra red: mirar ufw status desde dentro no revela reglas del proveedor o de Docker.

Antes de dar el paso por terminado, relaciona ss -tulpn con ufw status numbered: todo socket en 0.0.0.0 o :: debe tener propietario y motivo. Elimina reglas temporales por número cuando termines.

La precaución principal en este punto es clara: docker puede insertar reglas propias y publicar un puerto pese a UFW. Enlaza contenedores internos a 127.0.0.1 o controla la cadena DOCKER-USER, además del firewall perimetral.

Fail2Ban bien configurado: menos ruido, no inmunidad

Fail2Ban observa registros y bloquea temporalmente IP que repiten fallos. Es útil para reducir intentos automatizados, pero no corrige contraseñas débiles, software vulnerable ni puertos innecesarios.

• Confirma que el jail de SSH lee el backend de systemd o el archivo de log usado por tu Ubuntu.
• Define tiempos de prohibición razonables y una lista de confianza pequeña; no incluyas rangos completos sin necesidad.
• Prueba desde una IP controlada y conserva la consola para retirar un bloqueo accidental.

En producción, la validación útil es la que reproduce la ruta real. fail2ban-client status sshd debe mostrar el jail, filtros y bloqueos. Correlaciona un intento fallido con journalctl -u ssh para confirmar que el evento llega al filtro.

La precaución principal en este punto es clara: un filtro demasiado agresivo puede bloquear oficinas detrás de una IP compartida. Las llaves SSH y la desactivación de contraseñas reducen el problema en su origen.

Una revisión compacta para esta fase puede ejecutarse así:

sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication'
sudo ss -tulpn
sudo ufw status numbered
sudo fail2ban-client status sshd
sudo journalctl -u ssh --since '24 hours ago'

Lee la salida completa y conserva la hora de la prueba. Estos comandos no corrigen nada por sí solos: sirven para confirmar el estado antes de decidir el siguiente cambio.

Puertos, demonios y paquetes que sobran

La superficie de ataque real se compone de procesos escuchando y software instalado. Eliminar un servicio que no usas suele ser más seguro que intentar protegerlo con otra capa.

• Distingue sockets locales de públicos al leer ss -tulpn; 127.0.0.1 no equivale a 0.0.0.0.
• Deshabilita con systemctl disable --now solo después de identificar la dependencia y documentar cómo restaurarla.
• Revisa paquetes instalados manualmente y repositorios externos, porque cada origen amplía la cadena de confianza.

La comprobación práctica debe acompañar el cambio. Después de retirar un demonio, comprueba que desapareció el socket y que la aplicación principal sigue respondiendo. Guarda el nombre del paquete y su configuración antes de purgarlo.

La precaución principal en este punto es clara: cerrar el puerto en UFW oculta el servicio desde fuera, pero no resuelve una aplicación vulnerable alcanzable por otro proceso comprometido dentro del host.

Registros útiles y reloj coherente para investigar incidentes

Los logs solo ayudan si tienen hora correcta, retención suficiente y espacio disponible. UTC simplifica correlacionar Nginx, la aplicación, la base y servicios externos, aunque el equipo opere en otro huso horario.

• Verifica sincronización con timedatectl timesync-status y evita cambiar el reloj manualmente.
• Limita el crecimiento de journald y logrotate según el disco; un log descontrolado puede tumbar el servidor.
• Centraliza o copia fuera los registros importantes si necesitas investigar después de perder el VPS.

Para verificar esta parte sin depender de intuiciones, provoca un evento inocuo —una conexión SSH fallida desde tu IP— y localízalo por hora, usuario e IP. Así validas antes de un incidente que sabes consultar la evidencia.

La precaución principal en este punto es clara: no registres secretos, tokens ni cuerpos completos de solicitudes sensibles. Proteger un VPS también implica reducir lo que un atacante podría extraer de los propios logs.

Backups que sobreviven a la pérdida completa del servidor

La copia mínima debe incluir datos, cargas de usuarios, configuraciones no reproducibles y secretos necesarios para restaurar. Una imagen del proveedor acelera una reversión, pero no sustituye una copia independiente.

• Define RPO: cuántas horas de datos puedes perder; eso decide la frecuencia de bases y archivos.
• Define RTO: cuánto tardarás en reconstruir DNS, paquetes, certificados y servicios en una máquina vacía.
• Cifra la copia externa y guarda su clave fuera del VPS; perder la clave equivale a perder el backup.

La evidencia que conviene guardar es concreta. Restaura un archivo, una base y una configuración en una ruta temporal. Registra duración y errores; el mensaje de éxito del trabajo automático no prueba que el contenido sea utilizable.

La precaución principal en este punto es clara: no sincronices con --delete como única historia. Un borrado accidental o ransomware se replica al destino si no conservas versiones o snapshots inmutables.

Prueba de aceptación antes de instalar la aplicación

El endurecimiento termina cuando el acceso autorizado funciona y el no autorizado falla. Haz la prueba desde una red distinta, porque desde localhost puedes pasar por alto el firewall, NAT o reglas del proveedor.

• Conecta con la llave del administrador, ejecuta sudo y confirma que root remoto y contraseña ya no funcionan.
• Escanea únicamente tu IP para verificar que solo aparecen los puertos planeados y compara con sockets locales.
• Reinicia una vez mientras el servidor aún está vacío y comprueba SSH, firewall, Fail2Ban, hora y monitoreo.

Antes de dar el paso por terminado, guarda una captura textual de reglas, puertos, versiones y servicios. Esa línea base permite saber qué cambió cuando aparezca una incidencia semanas después.

La precaución principal en este punto es clara: no declares éxito porque cada servicio diga active. La prueba debe recorrer el camino real: red pública, autenticación, aplicación, datos y alerta.

Qué revisar cada mes en un VPS Ubuntu protegido

La seguridad no queda congelada el día de instalación. Una revisión breve y recurrente detecta cuentas olvidadas, puertos abiertos por despliegues, discos llenos y parches pendientes antes de que se conviertan en incidentes.

• Revisa usuarios, llaves autorizadas, sudoers, reglas de firewall y últimos inicios de sesión.
• Aplica parches pendientes en una ventana, reinicia cuando corresponda y valida servicios desde fuera.
• Restaura una muestra del backup y prueba al menos una alerta de disponibilidad o espacio.

En producción, la validación útil es la que reproduce la ruta real. Compara el inventario mensual con la línea base y explica cada diferencia. Un nuevo puerto de base de datos o una llave desconocida requiere acción inmediata, no solo documentación.

La precaución principal en este punto es clara: evita listas interminables sin responsable. Asigna fecha, evidencia y persona; un control que nadie comprueba acaba siendo decoración.

Caso práctico: preparar hoy un servidor que alojará una aplicación

Una forma útil de consolidar el procedimiento es recorrer un incidente de principio a fin. En este caso, el objetivo no es acumular comandos, sino dejar endurecimiento inicial en un estado que otra persona pueda entender, verificar y recuperar.

Primero registra el estado anterior y la hora. La seguridad inicial debe aplicarse en un orden que siempre conserve una vía de entrada comprobada. Empieza por actualizar, crea el usuario administrativo, instala su llave, prueba una segunda sesión y solo entonces restringe root y contraseñas. Por eso la primera decisión debe quedar escrita junto con el resultado esperado. Si el cambio afecta acceso o datos, abre una ruta de recuperación independiente antes de continuar.

Después aplica una sola modificación y observa su efecto. Instalar parches reduce vulnerabilidades conocidas, pero un full-upgrade también puede cambiar kernel, OpenSSH o bibliotecas usadas por la aplicación. En un servidor nuevo es el momento ideal para hacerlo porque todavía no hay carga de negocio. La evidencia mínima incluye la orden ejecutada, su salida relevante y una comprobación desde el lugar real del usuario. Ejecutar la prueba únicamente dentro del VPS puede ocultar reglas de red, DNS o proxy que forman parte del servicio.

En el tercer paso revisa privilegios y exposición. Una cuenta humana necesita elevar privilegios de forma auditable; una aplicación web no. Separar ambos usos evita que una vulnerabilidad en el servicio entregue de inmediato control completo del VPS. Pregunta qué identidad ejecuta el proceso, qué archivos puede leer y desde qué redes se alcanza. Si la respuesta es «cualquiera» o «todo», detente y reduce el alcance antes de añadir otra capa.

A continuación prueba la condición de fallo. UFW debe reflejar la arquitectura, no una lista copiada. Un servidor web suele necesitar 22 —o el puerto SSH elegido—, 80 y 443; MySQL, PostgreSQL, Redis y paneles internos no deberían escuchar para todo internet. Una buena validación incluye el camino positivo y el negativo: lo autorizado funciona y lo que decidiste bloquear deja de funcionar. Guarda la salida y no cierres el acceso de emergencia hasta completar ambos lados.

Luego simula recuperación. Fail2Ban observa registros y bloquea temporalmente IP que repiten fallos. Es útil para reducir intentos automatizados, pero no corrige contraseñas débiles, software vulnerable ni puertos innecesarios. Revertir en una ventana tranquila revela dependencias ausentes, permisos que solo existían en la sesión del administrador y pasos que nunca se documentaron. El rollback debe indicar qué se restaura, desde dónde y cómo sabes que terminó bien.

Finalmente observa el servidor durante una ventana comparable a la carga habitual. La superficie de ataque real se compone de procesos escuchando y software instalado. Eliminar un servicio que no usas suele ser más seguro que intentar protegerlo con otra capa. Si aparecen errores nuevos, crecimiento sostenido o reintentos, el cambio todavía no está terminado. Si la ruta funciona y las métricas permanecen dentro de lo previsto, registra versión, fecha y responsable. Ese registro convierte una solución individual en una operación repetible.

El resultado esperado no es «se ejecutaron los comandos», sino una evidencia breve: configuración válida, servicio accesible solo por la ruta prevista, prueba negativa correcta, datos persistentes cuando corresponda y un camino de recuperación ensayado. Con esa disciplina, endurecimiento inicial deja de depender de memoria o improvisación.

Cómo comprobar que el endurecimiento resiste desde fuera

La revisión final debe ejecutarse desde otra conexión a Internet, no solo desde el propio VPS. Una consulta a localhost atraviesa un camino distinto y no descubre una regla abierta en el firewall del proveedor, una interfaz pública inesperada o un servicio publicado por Docker. Desde un equipo autorizado, comprueba primero qué puertos TCP responden y contrasta el resultado con el inventario que definiste para el servidor:

nmap -Pn -sT -p 22,80,443,3306,5432,6379 IP_DEL_VPS

En un servidor web típico deberían responder únicamente SSH, HTTP y HTTPS. MySQL, PostgreSQL y Redis deben aparecer cerrados o filtrados salvo que exista una red privada diseñada para ellos. No escanees direcciones ajenas y no confundas un puerto filtrado con un servicio eliminado: vuelve al VPS y compara el resultado externo con sudo ss -ltnp.

Después prueba la política de identidad. Abre una sesión con la llave autorizada, confirma que sudo funciona y, sin cerrar esa sesión, intenta desde otra terminal una cuenta inexistente, el acceso directo de root y la autenticación por contraseña. Las negativas esperadas son parte de la prueba. Si alguna entra, revisa la configuración efectiva con sudo sshd -T; este comando incorpora archivos incluidos y evita confiar únicamente en una línea que quizá fue anulada más abajo.

Termina reiniciando el VPS mientras aún no aloja datos importantes. Comprueba que UFW, SSH, Fail2Ban, sincronización horaria y alertas vuelven automáticamente. Un servidor aparentemente seguro antes del reinicio, pero que pierde reglas o no levanta SSH después, todavía no está listo para producción.