Cómo asegurar un VPS Ubuntu en 10 minutos: SSH, firewall y fail2ban

Acabas de instalar Ubuntu en tu VPS, tienes acceso por SSH y todo parece funcionar correctamente. ¿Significa eso que tu servidor está protegido? Ni mucho menos.

Después de tantos años administrando servidores Linux, he aprendido que muchos problemas de seguridad no empiezan con ataques sofisticados. A veces basta una contraseña débil, un puerto abierto innecesariamente o un servicio que nadie se ha molestado en revisar.

Y lo peor es que estos descuidos pueden pasar completamente desapercibidos hasta que aparece un problema.

En HostingTG llevamos años trabajando con servidores Linux y ofreciendo soluciones de alojamiento para proyectos muy diferentes. Durante este tiempo he comprobado que no hace falta instalar una colección interminable de herramientas para mejorar considerablemente la seguridad inicial de un servidor.

Lo importante es empezar por lo esencial y hacerlo en el orden correcto.

Por eso, cuando alguien contrata uno de nuestros VPS de HostingTG, considero importante recordar que disponer de buenos recursos de hardware, almacenamiento NVMe y una infraestructura fiable es solamente una parte de la ecuación. La configuración del sistema operativo también desempeña un papel fundamental.

En esta guía voy a explicar cómo asegurar un VPS Ubuntu en unos 10 minutos, centrándome en tres elementos fundamentales:

• SSH: proteger el acceso remoto utilizando claves criptográficas y restringiendo los inicios de sesión inseguros.
• Firewall UFW: permitir únicamente las conexiones que necesita nuestro servidor.
• Fail2ban: detectar intentos repetidos de autenticación fallidos y bloquear temporalmente las direcciones IP implicadas.

También veremos cómo comprobar que las medidas funcionan, qué errores conviene evitar y qué deberíamos hacer después para seguir reforzando Ubuntu.

Eso sí, quiero dejar algo claro desde el principio: diez minutos pueden servir para establecer una primera capa de seguridad, pero no convierten un servidor en inexpugnable.

Antes de empezar: prepara tu VPS Ubuntu

Antes de modificar SSH, activar el firewall o instalar Fail2ban, necesitamos asegurarnos de que tenemos acceso al servidor y podemos recuperar el control si cometemos algún error.

Para este tutorial utilizaré Ubuntu Server 22.04 y 24.04 LTS como referencia, aunque buena parte de las instrucciones también pueden servir para otras versiones de Ubuntu y distribuciones basadas en Debian.

Partiremos de un VPS recién instalado, con conexión a Internet y acceso administrativo mediante SSH.

También conviene saber cuál es la dirección IP pública del servidor, qué puerto utiliza SSH y si nuestro proveedor dispone de una consola de recuperación.

Por comodidad, utilizaré adminvps como nombre de usuario y 203.0.113.10 como IP de ejemplo. Tendrás que sustituirlos por los datos reales de tu servidor.

Actualiza Ubuntu y comprueba que tienes acceso sudo

La primera recomendación que suelo hacer después de instalar Ubuntu es actualizar los paquetes.

Aunque la imagen del sistema operativo sea reciente, puede haber actualizaciones de seguridad pendientes.

Conéctate por SSH y ejecuta:

sudo apt update
sudo apt upgrade

El primer comando actualiza la información sobre los paquetes disponibles. El segundo instala las actualizaciones correspondientes.

Prefiero ejecutar ambos de forma separada y revisar los cambios antes de confirmarlos, especialmente cuando estoy trabajando en un servidor de producción.

Si has iniciado sesión directamente como root, puedes ejecutar estos comandos sin sudo.

También es recomendable comprobar la versión de Ubuntu:

lsb_release -a

Y verificar que tu usuario tiene permisos administrativos:

sudo whoami

Si el comando devuelve root, significa que puedes ejecutar operaciones con privilegios elevados.

Ten presente que algunas actualizaciones pueden requerir un reinicio. En ese caso, deberíamos programarlo y comprobar después que los servicios vuelven a funcionar correctamente.

Evita quedarte fuera del servidor: consola y sesión SSH de respaldo

Este es uno de los consejos en los que más insisto.

Antes de modificar SSH o activar el firewall, mantén abierta la conexión actual con tu VPS.

Durante el tutorial vamos a aplicar cambios que pueden impedir nuevas conexiones si nos equivocamos.

Por ejemplo, desactivar la autenticación por contraseña antes de comprobar las claves SSH podría dejarnos sin una forma válida de iniciar sesión.

Lo mismo sucede si activamos UFW sin permitir previamente el puerto utilizado por SSH.

Por eso recomiendo tres precauciones:

1. Mantener abierta la sesión SSH con la que estamos administrando el servidor.
2. Utilizar otra terminal para comprobar las nuevas conexiones.
3. Verificar previamente que disponemos de algún método de recuperación, como una consola de acceso fuera de banda ofrecida por el proveedor.

También conviene comprobar si existe un firewall adicional en el panel del proveedor, ya que sus reglas pueden afectar a las conexiones independientemente de UFW.

Una configuración de seguridad demasiado restrictiva, aplicada sin comprobarla, puede terminar convirtiéndose en un problema para nosotros mismos.

Y créeme: es mucho mejor invertir un minuto en estas verificaciones que tener que recuperar el acceso a un servidor bloqueado.

Paso 1. Asegurar SSH en Ubuntu con claves Ed25519

SSH es una de las herramientas que más utilizamos para administrar servidores Linux.

Nos permite ejecutar comandos, modificar configuraciones, instalar aplicaciones y controlar prácticamente cualquier aspecto del VPS sin necesidad de acceder físicamente a la máquina.

Precisamente por eso es uno de los primeros servicios que deberíamos proteger.

Cuando un servidor dispone de una IP pública, puede recibir intentos automatizados de conexión dirigidos al servicio SSH. Muchos de ellos buscan contraseñas débiles o configuraciones descuidadas.

Mi recomendación es bastante clara: utilizar claves SSH, administrar el sistema con un usuario propio y evitar el inicio de sesión remoto directo como root.

Crear un usuario con permisos sudo

Si hemos recibido nuestro VPS con acceso directo como root, lo primero será crear un usuario administrativo.

Ejecutamos:

sudo adduser adminvps

Ubuntu nos pedirá una contraseña para el nuevo usuario y algunos datos adicionales opcionales.

Es importante escoger una contraseña robusta, porque seguirá siendo necesaria para determinadas operaciones administrativas con sudo, aunque posteriormente desactivemos el acceso SSH mediante contraseña.

Después añadimos el usuario al grupo sudo:

sudo usermod -aG sudo adminvps

Este comando permite que adminvps ejecute tareas administrativas utilizando sudo.

Podemos comprobar que pertenece al grupo correspondiente:

groups adminvps

Entre los grupos mostrados debería aparecer sudo.

Ahora bien, crear un usuario diferente de root no elimina por sí solo todos los riesgos. Un usuario con permisos sudo también puede realizar cambios importantes en el sistema.

La ventaja es que evitamos utilizar continuamente la cuenta root y podemos controlar mejor cómo accedemos y administramos el servidor.

Generar e instalar una clave SSH Ed25519

Personalmente, prefiero utilizar claves Ed25519 para el acceso SSH.

Son una opción moderna, ofrecen una seguridad criptográfica sólida y permiten trabajar con claves relativamente compactas.

Lo primero es generar el par de claves en nuestro ordenador, no en el VPS.

Desde Linux, macOS o Windows con OpenSSH disponible, ejecutamos:

ssh-keygen -t ed25519 -C "mi-equipo"

El sistema nos preguntará dónde queremos guardar las claves y nos ofrecerá la posibilidad de establecer una frase de contraseña.

Recomiendo proteger la clave privada con una frase de contraseña robusta.

Normalmente se generarán dos archivos:

• id_ed25519: nuestra clave privada, que nunca debemos compartir.
• id_ed25519.pub: la clave pública, que podemos instalar en el servidor.

Si ya utilizamos una clave SSH, no necesitamos generar otra obligatoriamente. Podemos reutilizar una adecuada, siempre que esté protegida y tengamos control sobre ella.

Lo importante es no sobrescribir accidentalmente una clave existente.

El siguiente paso consiste en instalar la clave pública en el usuario administrativo del VPS.

Desde nuestro ordenador, en un entorno donde tengamos disponible ssh-copy-id, ejecutamos:

ssh-copy-id adminvps@203.0.113.10

Este comando copia la clave pública al archivo authorized_keys del usuario remoto y prepara los permisos necesarios.

Si utilizamos un puerto SSH diferente del habitual, tendremos que indicarlo mediante la opción correspondiente.

Una vez instalada, abrimos otra terminal y comprobamos el acceso:

ssh adminvps@203.0.113.10

Para asegurarnos de que la conexión utiliza realmente la clave pública, también podemos ejecutar desde nuestro ordenador:

ssh -o PreferredAuthentications=publickey \
    -o PasswordAuthentication=no \
    adminvps@203.0.113.10

Si conseguimos iniciar sesión, vamos por buen camino.

Dentro del servidor comprobamos los permisos administrativos:

sudo whoami

Debería aparecer:

root

No debemos continuar con el bloqueo de la autenticación por contraseña hasta haber comprobado que el nuevo usuario puede acceder mediante clave SSH y utilizar sudo.

Esta verificación es mucho más importante que cambiar el puerto 22 por otro diferente.

Cambiar el puerto puede reducir parte de los intentos automatizados más simples, pero no sustituye una autenticación correctamente configurada.

Desactivar el acceso root y la autenticación por contraseña

Ahora que tenemos un usuario administrativo y hemos comprobado que las claves funcionan, podemos endurecer la configuración del servicio SSH.

En Ubuntu, el archivo principal suele ser:

/etc/ssh/sshd_config

Sin embargo, las versiones modernas también pueden cargar configuraciones adicionales desde:

/etc/ssh/sshd_config.d/

Estas configuraciones pueden incluir ajustes proporcionados por la imagen del VPS o por herramientas como cloud-init.

Por eso conviene revisar los archivos existentes y no asumir que basta con modificar una línea cualquiera.

Primero podemos guardar una copia de la configuración principal:

sudo cp /etc/ssh/sshd_config \
    /etc/ssh/sshd_config.bak

También conviene revisar las directivas de inclusión y los archivos adicionales:

grep -n '^Include' /etc/ssh/sshd_config
ls -l /etc/ssh/sshd_config.d/

En una instalación estándar que incluya al principio los archivos .conf de ese directorio, podemos crear un archivo específico:

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

Añadimos:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

Con estas directivas buscamos:

• Impedir el inicio de sesión SSH directo como root.
• Desactivar la autenticación mediante contraseña.
• Deshabilitar la autenticación interactiva por teclado, evitando mantener abierta otra vía de autenticación basada en contraseñas.
• Mantener disponible la autenticación mediante clave pública.

Es importante comprobar cómo se combinan estos ajustes con los archivos existentes. OpenSSH utiliza reglas de precedencia y puede aplicar configuraciones específicas mediante bloques Match.

Además, antes de cambiar el acceso root debemos confirmar que ninguna tarea automatizada depende de esa conexión.

En algunos entornos empresariales también pueden utilizarse otros métodos de autenticación, como certificados o mecanismos centralizados. En esos casos, la configuración debe adaptarse a la infraestructura.

Validar los cambios y comprobar la conexión SSH

Antes de recargar SSH, ejecutamos:

sudo sshd -t

Si no muestra errores, la sintaxis básica de la configuración es válida.

Pero todavía debemos comprobar los valores efectivos:

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

En la configuración planteada deberíamos observar:

permitrootlogin no
pubkeyauthentication yes
passwordauthentication no
kbdinteractiveauthentication no

La salida de sshd -T puede variar según el contexto de conexión, especialmente cuando existen reglas Match. Si las utilizamos, también habrá que revisar el resultado para el usuario y la conexión concretos.

Una vez comprobada la configuración, recargamos el servicio:

sudo systemctl reload ssh

Ahora abrimos una nueva terminal y probamos otra vez:

ssh adminvps@203.0.113.10

Si podemos conectarnos mediante nuestra clave y utilizar sudo, habremos completado una de las medidas más importantes de protección del VPS.

No cierres todavía la sesión administrativa original. La mantendremos abierta hasta terminar de comprobar el firewall.

Paso 2. Configurar el firewall UFW en Ubuntu

Una vez protegido el acceso SSH, el siguiente elemento que recomiendo revisar es el firewall.

Hay una costumbre que considero especialmente peligrosa: instalar aplicaciones en un servidor sin comprobar después qué puertos han quedado accesibles desde Internet.

A veces instalamos una base de datos, una herramienta de administración o un servicio de pruebas y dejamos abierta una conexión que realmente no necesitamos.

Mi criterio es bastante sencillo: si un servicio no necesita estar accesible públicamente, no debería estarlo.

Para una configuración inicial de Ubuntu, UFW es una opción muy práctica.

UFW significa Uncomplicated Firewall y facilita la administración de reglas de filtrado de tráfico sin necesidad de escribir directamente reglas complejas de bajo nivel.

Permitir SSH antes de activar el firewall

Lo primero es comprobar si UFW está instalado:

sudo ufw status

Si el sistema indica que no encuentra el comando, podemos instalarlo:

sudo apt install ufw

Antes de activarlo, necesitamos permitir las conexiones SSH.

Si utilizamos el puerto habitual, 22/TCP, podemos ejecutar:

sudo ufw allow 22/tcp

También podemos utilizar:

sudo ufw allow OpenSSH

Este segundo comando emplea el perfil de aplicación de UFW. Debemos comprobar que el perfil corresponde al puerto que realmente utiliza nuestro servicio SSH.

Por ejemplo, si hemos configurado SSH para escuchar en el puerto 2222, la regla correspondiente sería:

sudo ufw allow 2222/tcp

En ese caso, tendríamos que adaptar todas las comprobaciones posteriores al nuevo puerto.

Lo importante es entender que no debemos habilitar el firewall hasta asegurarnos de que existe una regla que permite nuestro acceso administrativo.

Incluso podemos restringir SSH para que solo acepte conexiones desde una IP de administración concreta, si disponemos de una dirección fija y conocemos las implicaciones de esa limitación.

Para una configuración inicial general, utilizaremos una regla de acceso al puerto SSH correspondiente.

Abrir los puertos HTTP y HTTPS cuando sean necesarios

Si vamos a utilizar nuestro VPS Ubuntu para alojar una página web, normalmente necesitaremos permitir conexiones HTTP y HTTPS.

Los puertos habituales son:

Servicio	Puerto	Protocolo
SSH	22	TCP
HTTP	80	TCP
HTTPS	443	TCP

Podemos permitir el tráfico web mediante:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Esto tiene sentido si nuestro servidor va a publicar una web mediante Nginx, Apache u otra aplicación que escuche en esos puertos.

Sin embargo, no todos los VPS necesitan ofrecer servicios web.

Por ejemplo, un servidor utilizado exclusivamente para procesos internos podría necesitar únicamente SSH y conexiones privadas.

Del mismo modo, servicios como MySQL, Redis o determinados paneles de administración no deberían quedar expuestos directamente a Internet salvo que exista una necesidad justificada y medidas de protección adecuadas.

En HostingTG trabajamos con VPS destinados a proyectos muy diferentes. No necesita exactamente las mismas reglas un servidor WordPress que otro destinado a Docker, n8n o aplicaciones que publican distintas API.

Por eso prefiero definir las reglas del firewall en función de los servicios reales, en lugar de abrir puertos simplemente por comodidad.

Activar UFW y comprobar las reglas de seguridad

Una vez permitidas las conexiones necesarias, estableceremos una política inicial sencilla:

sudo ufw default deny incoming
sudo ufw default allow outgoing

Con estas reglas, UFW bloqueará por defecto las conexiones entrantes que no estén expresamente permitidas y autorizará las conexiones salientes.

Es una configuración inicial razonable para muchos servidores web, aunque los entornos más restrictivos también pueden necesitar controlar el tráfico saliente.

Ahora activamos el firewall:

sudo ufw enable

UFW puede mostrar una advertencia indicando que la operación podría afectar a las conexiones SSH.

Como previamente hemos permitido el puerto correcto, podemos continuar, siempre que hayamos verificado las reglas y mantengamos nuestra sesión administrativa abierta.

Después comprobamos su estado:

sudo ufw status verbose

Deberíamos encontrar una salida similar a esta:

Status: active
Default: deny (incoming), allow (outgoing)

22/tcp    ALLOW IN    Anywhere
80/tcp    ALLOW IN    Anywhere
443/tcp   ALLOW IN    Anywhere

Los resultados exactos dependerán de los puertos que hayamos habilitado y de la configuración IPv6.

También podemos revisar las reglas numeradas:

sudo ufw status numbered

Esto resulta útil cuando necesitamos identificar una regla concreta para modificarla o eliminarla.

Por último, abrimos una nueva terminal y comprobamos de nuevo que podemos conectarnos por SSH.

Si todo funciona, habremos añadido otra capa de protección al VPS.

Una advertencia importante: UFW no controla necesariamente todos los escenarios de exposición de puertos cuando utilizamos Docker, contenedores o reglas de red añadidas por otras aplicaciones. En esos entornos es necesario revisar también las publicaciones de puertos y las cadenas de filtrado correspondientes.

Tampoco debemos olvidar IPv6. Si nuestro VPS dispone de conectividad IPv6 pública, las reglas y los servicios expuestos deben revisarse para ambos protocolos.

Paso 3. Instalar y configurar Fail2ban para SSH

Con SSH reforzado y el firewall activo, vamos a instalar Fail2ban.

Es una herramienta que lleva muchos años formando parte de las configuraciones habituales de seguridad en servidores Linux y que personalmente sigo considerando útil para determinadas situaciones.

Su funcionamiento es relativamente sencillo.

Fail2ban examina registros de servicios y, cuando detecta determinados patrones de fallos repetidos, puede aplicar bloqueos temporales a las direcciones IP implicadas.

En el caso de SSH, esto puede ayudarnos a reducir intentos automatizados de autenticación.

Eso sí, no conviene confundir sus funciones.

Fail2ban no sustituye las claves SSH ni el firewall. Tampoco garantiza protección frente a cualquier ataque, especialmente si las solicitudes se distribuyen entre muchas direcciones IP o el ataque utiliza métodos que no generan los eventos supervisados.

Su utilidad está precisamente en complementar otras medidas.

Instalar Fail2ban y configurar la protección SSH

Para instalarlo en Ubuntu, ejecutamos:

sudo apt install fail2ban

Una vez instalado, necesitamos definir la protección del servicio SSH.

En lugar de modificar directamente el archivo jail.conf, prefiero crear una configuración local independiente.

Esto facilita el mantenimiento y evita depender de cambios que puedan producirse en el archivo de ejemplo durante las actualizaciones del paquete.

Primero nos aseguramos de que existe el directorio correspondiente:

sudo mkdir -p /etc/fail2ban/jail.d

Después creamos el archivo:

sudo nano /etc/fail2ban/jail.d/sshd.local

Introducimos la siguiente configuración:

[sshd]
enabled = true
port = ssh
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h

Vamos a ver qué significa cada parámetro.

Parámetro	Función
enabled = true	Activa la protección SSH
port = ssh	Indica el puerto SSH estándar
backend = systemd	Consulta eventos mediante el journal de systemd
maxretry = 5	Establece el número de fallos antes de aplicar la prohibición
findtime = 10m	Define una ventana de diez minutos
bantime = 1h	Establece una duración de bloqueo de una hora

Estos valores son una propuesta inicial, no una configuración universal.

Si hemos cambiado el puerto SSH, debemos sustituir ssh por el puerto real. También hay que comprobar que la acción de bloqueo utilizada por Fail2ban es compatible con el firewall del sistema.

En Ubuntu 22.04 y 24.04, utilizar el backend systemd puede resultar adecuado para leer los registros de autenticación SSH desde el journal, siempre que el paquete y sus dependencias estén correctamente instalados.

Precisamente por eso recomiendo no limitarse a copiar una configuración: debemos comprobar que Fail2ban puede leer los eventos que necesita.

También conviene tener cuidado si compartimos una misma IP pública con otros administradores, ya que múltiples intentos fallidos podrían provocar el bloqueo temporal de esa dirección.

Para esos casos podemos valorar excepciones controladas mediante ignoreip, evitando listas de exclusión demasiado amplias.

Comprobar el servicio, los registros y las IP bloqueadas

Una vez guardado el archivo, podemos comprobar que Fail2ban interpreta la configuración:

sudo fail2ban-client -t

Si la validación termina correctamente, activamos y arrancamos el servicio:

sudo systemctl enable --now fail2ban

Después aplicamos la configuración:

sudo fail2ban-client reload

Comprobamos el estado general:

sudo fail2ban-client status

Entre las protecciones activas debería aparecer sshd.

Para consultar específicamente esa protección:

sudo fail2ban-client status sshd

La salida suele incluir información sobre los intentos detectados y las direcciones IP bloqueadas.

Si no aparecen IP bloqueadas, eso no significa necesariamente que Fail2ban esté funcionando mal. Puede ser simplemente que no haya detectado suficientes fallos para aplicar una prohibición.

También debemos comprobar que el servicio está activo:

sudo systemctl status fail2ban

Y consultar sus registros si observamos errores:

sudo journalctl -u fail2ban --no-pager -n 50

Para revisar eventos relacionados con el servidor SSH, podemos utilizar:

sudo journalctl -u ssh --no-pager -n 50

Dependiendo de cómo esté configurado el registro del sistema, puede ser necesario revisar otras unidades o fuentes de eventos.

No recomiendo provocar múltiples fallos de autenticación desde nuestra propia conexión de administración únicamente para comprobar si el bloqueo funciona. Podríamos terminar bloqueando nuestra IP.

Una vez verificado que la protección SSH está activa y que el backend puede consultar los registros correspondientes, habremos completado la tercera medida principal.

Cómo comprobar que tu VPS Ubuntu está protegido

Llegados a este punto, ya hemos realizado las tres configuraciones fundamentales: proteger SSH, limitar conexiones entrantes mediante UFW y activar Fail2ban.

Pero hay una diferencia importante entre ejecutar comandos y comprobar que han tenido el efecto esperado.

Después de tantos años trabajando con servidores, he aprendido que merece la pena dedicar un poco de tiempo a las verificaciones. Una configuración que parece correcta en un archivo puede no ser la que realmente está utilizando el servicio.

Por ejemplo, podríamos modificar una directiva SSH que queda anulada por otra configuración, abrir un puerto incorrecto en UFW o instalar Fail2ban sin tener activa la protección que esperábamos.

Vamos a comprobar los puntos esenciales.

Revisar SSH, puertos abiertos, UFW y Fail2ban

Para revisar las opciones efectivas del servicio SSH:

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

Debemos comprobar que el acceso root está desactivado, que la autenticación por contraseña y por teclado están deshabilitadas y que se permite la autenticación por clave pública.

No olvides verificar también las reglas específicas de usuario o dirección IP si utilizas bloques Match.

Para consultar el firewall:

sudo ufw status verbose

Esperamos encontrar UFW activo y únicamente los puertos que necesitan los servicios publicados.

Podemos comprobar qué aplicaciones están escuchando en el servidor:

sudo ss -tulpn

Este comando permite identificar puertos TCP y UDP asociados a procesos.

Es importante interpretar correctamente los resultados. Un servicio puede escuchar únicamente en 127.0.0.1, estar vinculado a una dirección privada o aceptar conexiones en todas las interfaces.

Por tanto, que un puerto aparezca en esta lista no significa automáticamente que esté accesible desde Internet.

Para determinar su exposición real, también tenemos que considerar las reglas del firewall, la configuración del proveedor, IPv6 y cualquier capa adicional de red.

Finalmente, comprobamos Fail2ban:

sudo fail2ban-client status sshd

Si la protección está activa, podemos consultar los eventos detectados y los bloqueos aplicados.

Para una comprobación completa, recomiendo realizar también una conexión SSH nueva desde un terminal independiente.

Esa prueba confirma algo fundamental: seguimos teniendo acceso administrativo después de los cambios.

Checklist final de seguridad en 10 minutos

Esta es la lista que utilizaría para revisar una configuración inicial.

• Ubuntu tiene instaladas las actualizaciones necesarias.
• Existe un usuario administrativo con permisos sudo.
• El usuario puede iniciar sesión mediante una clave SSH Ed25519.
• El acceso SSH directo como root está desactivado.
• La autenticación SSH mediante contraseña está desactivada.
• La configuración SSH se ha validado y se ha probado una nueva conexión.
• UFW está activo y permite el puerto SSH correcto.
• Solo están abiertos los puertos públicos necesarios.
• Fail2ban está instalado y la protección sshd funciona.
• Se ha comprobado cómo recuperar el acceso si falla SSH.

Si hemos completado todos estos puntos, tendremos una base de seguridad mucho más razonable que la de un VPS sin configurar.

¿Significa que hemos eliminado cualquier posibilidad de ataque? No.

Pero sí habremos reducido riesgos habituales relacionados con el acceso remoto y la exposición innecesaria de servicios.

En cuanto al tiempo, debemos ser realistas. Si ya tenemos nuestras claves SSH preparadas y estamos familiarizados con Ubuntu, esta configuración puede realizarse aproximadamente en diez minutos.

Si necesitamos generar claves por primera vez, descargar muchas actualizaciones, revisar configuraciones particulares o resolver errores, necesitaremos más tiempo.

La prioridad debe ser siempre aplicar y verificar correctamente cada cambio, no completar la guía contra el reloj.

Errores habituales al asegurar un VPS Ubuntu

Cuando hablamos de seguridad, solemos centrarnos en las herramientas que debemos instalar. Sin embargo, también conviene conocer los errores que pueden aparecer durante su configuración.

Muchos no se deben a una vulnerabilidad especialmente compleja, sino a decisiones que parecían correctas en el momento de aplicarlas.

Uno de los ejemplos más comunes es bloquear el acceso al propio servidor.

Otro consiste en instalar servicios que quedan accesibles públicamente sin que el administrador sea consciente de ello.

Por eso me parece importante dedicar un apartado específico a estas situaciones.

Bloquear SSH por una regla incorrecta

Imagina que tenemos un VPS configurado para utilizar SSH en el puerto 2222.

Decidimos activar UFW y, por costumbre, permitimos únicamente el puerto 22.

Después cerramos nuestra sesión y descubrimos que ya no podemos conectarnos.

El problema es que hemos permitido un puerto diferente del que realmente utiliza SSH.

Para evitarlo, debemos comprobar primero el puerto efectivo del servicio, añadir la regla correcta y probar una conexión nueva antes de cerrar la actual.

Algo parecido ocurre al desactivar la autenticación por contraseña.

Si todavía no hemos instalado correctamente nuestra clave pública en el servidor, podríamos quedarnos sin un método válido para acceder.

En este caso, lo más importante es mantener abierta la sesión administrativa y disponer de un sistema de recuperación.

Si perdemos el acceso remoto, necesitaremos utilizar la consola de recuperación del proveedor, siempre que esté disponible, para corregir las reglas de UFW o la configuración de SSH.

También recomiendo guardar copias de los archivos de configuración antes de introducir modificaciones importantes.

La seguridad no consiste únicamente en aplicar restricciones. También implica saber cómo revertir un cambio si algo sale mal.

Exponer MySQL, Redis o servicios Docker innecesariamente

Otro error frecuente es pensar que basta con activar un firewall para que cualquier servicio quede correctamente protegido.

Por ejemplo, podemos instalar MySQL o Redis para una aplicación y dejar su servicio escuchando en una interfaz pública.

Si esa aplicación se ejecuta en el mismo servidor, quizá no necesitemos permitir conexiones externas a la base de datos.

En muchos casos será suficiente con utilizar una interfaz local, una red privada o una conexión protegida.

Con Docker debemos prestar todavía más atención.

Al publicar puertos de contenedores, Docker puede añadir reglas de red que no se comportan exactamente como las reglas entrantes habituales de UFW.

Por eso no debemos asumir que ufw status refleja necesariamente toda la exposición de los servicios publicados mediante contenedores.

Conviene revisar tanto los puertos de los contenedores como las interfaces a las que están vinculados y las reglas de filtrado efectivas.

Algo parecido sucede con herramientas como n8n o paneles de administración web.

Que una aplicación tenga una interfaz accesible desde el navegador no significa que debamos publicarla directamente sin autenticación, HTTPS y las restricciones necesarias.

Mi recomendación es revisar cada servicio nuevo que instalamos y hacernos una pregunta:

¿Este puerto necesita estar accesible desde Internet o podría funcionar de forma local o privada?

Si no existe una necesidad real de exposición pública, prefiero mantenerlo cerrado.

Qué hacer después de los primeros 10 minutos

Con SSH, UFW y Fail2ban correctamente configurados, nuestro VPS Ubuntu tendrá una primera capa de protección.

Pero la seguridad de un servidor no termina después de su instalación.

A medida que incorporamos aplicaciones, usuarios, bases de datos y servicios, también aparecen nuevas necesidades de configuración y mantenimiento.

Por eso considero importante diferenciar entre asegurar inicialmente Ubuntu y mantenerlo protegido durante toda su vida útil.

Actualizaciones automáticas y supervisión

Mantener Ubuntu actualizado es una de las tareas básicas de administración.

Una opción que podemos valorar es utilizar unattended-upgrades para instalar determinadas actualizaciones automáticamente.

Para instalarlo:

sudo apt install unattended-upgrades

Después podemos revisar su configuración:

sudo dpkg-reconfigure --priority=low unattended-upgrades

También podemos consultar los ajustes periódicos:

cat /etc/apt/apt.conf.d/20auto-upgrades

En una configuración habilitada suelen aparecer estos valores:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Si nuestro sistema no dispone de esos ajustes, tendremos que revisar la configuración antes de asumir que las actualizaciones automáticas están funcionando.

Es importante recordar que no todas las actualizaciones se aplican de la misma manera y que algunos cambios requieren reiniciar servicios o el sistema operativo.

En servidores de producción debemos controlar estos procesos para evitar interrupciones inesperadas.

Además de las actualizaciones, recomiendo supervisar periódicamente los registros de SSH, los eventos de Fail2ban, los servicios activos y los puertos que han quedado abiertos.

También conviene revisar los usuarios autorizados, las claves SSH instaladas y los permisos de los archivos sensibles.

No se trata de revisar manualmente cada detalle todos los días, sino de mantener una rutina razonable y utilizar herramientas de monitorización cuando el proyecto lo requiera.

Backups y seguridad según tu proyecto

Hay otro elemento que considero fundamental y que no deberíamos dejar para el final: las copias de seguridad.

Podemos tener SSH perfectamente configurado, UFW activo y Fail2ban bloqueando intentos fallidos, pero eso no evita todos los problemas posibles.

Una actualización defectuosa, un error administrativo, un fallo de almacenamiento o una vulnerabilidad en una aplicación pueden provocar pérdidas de datos.

Por eso recomiendo disponer de copias de seguridad periódicas, comprobar que se completan correctamente y realizar pruebas de restauración.

También es importante evitar que todas las copias estén almacenadas únicamente en el mismo servidor.

Un snapshot puede ser útil para recuperar rápidamente el estado de una máquina, pero no siempre sustituye una estrategia de backups independientes.

En HostingTG trabajamos con servidores VPS que pueden destinarse a páginas web, aplicaciones, bases de datos y proyectos con necesidades muy diferentes.

Por ejemplo, un VPS preparado para alojar WordPress o WooCommerce debe prestar especial atención a las actualizaciones del CMS, plugins, temas, base de datos y aplicaciones web.

En cambio, si utilizamos Docker, n8n o una aplicación propia, tendremos que revisar los contenedores, las imágenes utilizadas, la publicación de puertos, la autenticación y el tratamiento de información sensible.

Lo mismo sucede con los paneles de administración, las API y los sistemas empresariales.

No existe una única configuración válida para absolutamente todos los proyectos.

En mi opinión, contar con recursos adecuados, almacenamiento rápido y una infraestructura fiable facilita el funcionamiento de las aplicaciones, pero no elimina nuestra responsabilidad de mantenerlas protegidas.

La seguridad debe acompañar al proyecto a medida que evoluciona.

Dudas de la comunidad

¿Es suficiente con diez minutos para asegurar un VPS Ubuntu?

Diez minutos pueden bastar para aplicar una primera capa de protección si tenemos experiencia y el servidor está preparado, pero no para garantizar una seguridad completa.

Configurar claves SSH, limitar puertos mediante UFW y activar Fail2ban ayuda a reducir riesgos habituales. Después tendremos que seguir manteniendo Ubuntu, las aplicaciones y las copias de seguridad.

¿Es recomendable desactivar el acceso SSH mediante contraseña?

Sí, siempre que previamente hayamos comprobado que podemos acceder utilizando nuestra clave SSH y disponemos de una forma de recuperación.

Personalmente, prefiero utilizar Ed25519 y desactivar la autenticación por contraseña una vez verificado el acceso.

La clave privada debe permanecer protegida y no compartirse con otras personas.

¿Qué puertos debería abrir en el firewall UFW?

Depende del uso del servidor.

En un VPS destinado a alojar una página web, habitualmente necesitaremos SSH y, cuando corresponda, HTTP y HTTPS.

Sin embargo, no deberíamos abrir otros puertos únicamente porque una aplicación los utilice internamente.

Las bases de datos, los sistemas de administración y los servicios privados deben mantenerse fuera del acceso público siempre que sea posible.

¿Fail2ban sigue siendo útil si utilizo claves SSH?

Puede seguir siendo útil como medida complementaria para detectar y responder a determinados intentos de autenticación fallidos.

Su utilidad concreta dependerá de los métodos de acceso habilitados, de los eventos registrados y de la configuración aplicada.

No debemos considerarlo un sustituto de las claves SSH, del firewall o de una política adecuada de mantenimiento.

¿Cambiar el puerto 22 de SSH mejora la seguridad?

Cambiar el puerto SSH puede reducir algunos intentos automatizados que se dirigen exclusivamente al puerto habitual.

Sin embargo, no impide que alguien descubra el nuevo puerto mediante un escaneo.

Por eso no lo considero una medida suficiente por sí sola.

Es más importante configurar correctamente la autenticación, restringir el acceso root y controlar las conexiones permitidas.

¿Qué hago si pierdo el acceso SSH después de configurar UFW?

Si el firewall bloquea el puerto SSH o hemos aplicado una configuración incorrecta, necesitaremos utilizar otro método de acceso administrativo.

La solución puede pasar por la consola de recuperación del proveedor, si está disponible, desde la que podremos corregir las reglas del firewall o los ajustes del servicio SSH.

Precisamente por eso recomiendo comprobar los métodos de recuperación antes de introducir cambios importantes.

Los primeros 10 minutos marcan la diferencia

Asegurar un VPS Ubuntu no tiene por qué ser un proceso especialmente complicado, al menos cuando hablamos de establecer una primera capa de protección.

Después de años administrando servidores Linux, sigo considerando que hay tres medidas por las que merece la pena empezar: proteger SSH, configurar correctamente el firewall y utilizar Fail2ban cuando aporte una protección adicional útil.

Las claves SSH Ed25519 permiten mejorar la autenticación remota. UFW nos ayuda a mantener cerrados los puertos innecesarios. Y Fail2ban puede reducir determinados intentos repetitivos de acceso.

Lo importante es aplicarlas en el orden adecuado y comprobar que todo funciona después de cada cambio.

También debemos recordar que cada VPS tiene unas necesidades diferentes. Un servidor destinado a alojar una web corporativa no requiere necesariamente la misma configuración que otro utilizado para bases de datos, automatizaciones o aplicaciones empresariales.

Por eso, cuando trabajamos con nuestros servidores en HostingTG, considero esencial adaptar la configuración al uso real del proyecto y no limitarse a aplicar una lista de comandos sin entender qué hace cada uno.

Si estás preparando un nuevo servidor, puedes consultar las opciones de VPS de HostingTG para desplegar Ubuntu y configurar tu entorno según las necesidades de tu aplicación.

Pero recuerda: un buen VPS necesita tanto una infraestructura fiable como una administración responsable.

Dedicar los primeros diez minutos a proteger Ubuntu es un excelente comienzo. Mantener esa seguridad a lo largo del tiempo es lo que realmente marca la diferencia.

Opinión Personal

Después de tantos años administrando servidores Linux, hay algo que tengo bastante claro: la seguridad de un VPS no debería ser una tarea que dejamos para cuando tenemos tiempo, sino una de las primeras cosas que hacemos después de instalarlo.

En HostingTG llevamos años trabajando con servidores y proyectos de todo tipo, y mi experiencia me ha enseñado que muchas veces no son las amenazas más sofisticadas las que deberían preocuparnos, sino esos pequeños descuidos que parecen inofensivos: una contraseña poco segura, un puerto abierto sin necesidad o un servicio que lleva meses funcionando sin actualizarse.

Personalmente, siempre recomiendo empezar por lo básico. Configurar correctamente SSH, activar el firewall UFW y utilizar Fail2ban son tres medidas relativamente sencillas que pueden ayudarnos a evitar muchos problemas. Eso sí, hay algo que considero incluso más importante que ejecutar los comandos: entender qué estamos haciendo y comprobar que cada cambio funciona correctamente.

De poco sirve reforzar SSH si terminamos bloqueando nuestro propio acceso al servidor, o activar un firewall sin revisar qué servicios necesitamos mantener disponibles.

También creo que debemos dejar de pensar que un servidor está completamente protegido porque hemos instalado unas cuantas herramientas de seguridad. Un VPS que hoy está bien configurado puede presentar riesgos mañana si dejamos de actualizarlo, instalamos aplicaciones vulnerables o nos olvidamos de las copias de seguridad.

Por eso, mi filosofía es sencilla: empezar con una configuración segura, mantener expuestos únicamente los servicios necesarios y revisar periódicamente el estado del sistema.

Diez minutos no convierten un VPS Ubuntu en una fortaleza inexpugnable, pero pueden marcar una diferencia importante entre un servidor que acabamos de instalar y otro en el que ya hemos tomado medidas para reducir riesgos.

¿Y tú, cómo proteges tus servidores?

Me gustaría conocer tu experiencia. ¿Qué medidas de seguridad aplicas nada más instalar un VPS Ubuntu? ¿Utilizas SSH con claves, UFW y Fail2ban, o prefieres otras herramientas?

¿Alguna vez te has quedado sin acceso a un servidor después de modificar SSH o configurar el firewall?

Te leo en los comentarios. Comparte tus consejos, experiencias o dudas, porque estoy convencido de que todos podemos aprender algo de cómo otros administradores protegen sus servidores Linux.