{"id":10312,"date":"2026-11-09T13:17:37","date_gmt":"2026-11-09T12:17:37","guid":{"rendered":"https:\/\/www.hostingtg.com\/blog\/?p=10312"},"modified":"2026-11-09T13:20:13","modified_gmt":"2026-11-09T12:20:13","slug":"como-asegurar-un-vps-ubuntu","status":"publish","type":"post","link":"https:\/\/www.hostingtg.com\/blog\/como-asegurar-un-vps-ubuntu\/","title":{"rendered":"C\u00f3mo asegurar un VPS Ubuntu en 10 minutos: SSH, firewall y fail2ban"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">Acabas de instalar Ubuntu en tu VPS, tienes <a href=\"https:\/\/www.hostingtg.com\/blog\/ssh-que-es\/\">acceso por SSH<\/a> y todo parece funcionar correctamente. \u00bfSignifica eso que tu servidor est\u00e1 protegido? Ni mucho menos.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Despu\u00e9s de tantos a\u00f1os <a href=\"https:\/\/www.hostingtg.com\/blog\/administrar-un-servidor-vps\/\">administrando servidores Linux<\/a>, he aprendido que muchos problemas de seguridad no empiezan con ataques sofisticados. A veces basta una contrase\u00f1a d\u00e9bil, un puerto abierto innecesariamente o un servicio que nadie se ha molestado en revisar.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Y lo peor es que estos descuidos pueden pasar completamente desapercibidos hasta que aparece un problema.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En <strong>HostingTG llevamos a\u00f1os trabajando con servidores Linux<\/strong> y ofreciendo soluciones de alojamiento para proyectos muy diferentes. Durante este tiempo he comprobado que no hace falta instalar una colecci\u00f3n interminable de herramientas para mejorar considerablemente la seguridad inicial de un servidor.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Lo importante es empezar por lo esencial y hacerlo en el orden correcto.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por eso, cuando alguien contrata uno de nuestros <a href=\"https:\/\/www.hostingtg.com\/servidores-vps\/\">VPS de HostingTG<\/a>, considero importante recordar que disponer de buenos recursos de hardware, almacenamiento NVMe y una infraestructura fiable es solamente una parte de la ecuaci\u00f3n. La configuraci\u00f3n del sistema operativo tambi\u00e9n desempe\u00f1a un papel fundamental.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En esta gu\u00eda voy a explicar <strong>c\u00f3mo asegurar un VPS Ubuntu en unos 10 minutos<\/strong>, centr\u00e1ndome en tres elementos fundamentales:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>SSH:<\/strong> proteger el acceso remoto utilizando claves criptogr\u00e1ficas y restringiendo los inicios de sesi\u00f3n inseguros.<\/li>\n\n\n\n<li><strong>Firewall UFW:<\/strong> permitir \u00fanicamente las conexiones que necesita nuestro servidor.<\/li>\n\n\n\n<li><strong>Fail2ban:<\/strong> detectar intentos repetidos de autenticaci\u00f3n fallidos y bloquear temporalmente las direcciones IP implicadas.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Tambi\u00e9n veremos c\u00f3mo comprobar que las medidas funcionan, qu\u00e9 errores conviene evitar y qu\u00e9 deber\u00edamos hacer despu\u00e9s para seguir reforzando Ubuntu.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Eso s\u00ed, 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.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Antes de empezar: prepara tu VPS Ubuntu<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">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\u00fan error.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Para este tutorial utilizar\u00e9 <a href=\"https:\/\/www.hostingtg.com\/blog\/ubuntu-server-vs-debian-para-tu-vps\/\">Ubuntu Server<\/a> 22.04 y 24.04 LTS como referencia, aunque buena parte de las instrucciones tambi\u00e9n pueden servir para otras versiones de Ubuntu y distribuciones basadas en Debian.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Partiremos de un <a href=\"https:\/\/www.hostingtg.com\/blog\/primeros-pasos-con-vps-guia-completa\/\">VPS reci\u00e9n instalado<\/a>, con conexi\u00f3n a Internet y acceso administrativo mediante SSH.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Tambi\u00e9n conviene saber cu\u00e1l es la direcci\u00f3n IP p\u00fablica del servidor, qu\u00e9 puerto utiliza SSH y si nuestro proveedor dispone de una consola de recuperaci\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por comodidad, utilizar\u00e9 <code>adminvps<\/code> como nombre de usuario y <code>203.0.113.10<\/code> como IP de ejemplo. Tendr\u00e1s que sustituirlos por los datos reales de tu servidor.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Actualiza Ubuntu y comprueba que tienes acceso sudo<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">La primera recomendaci\u00f3n que suelo hacer despu\u00e9s de instalar Ubuntu es <a href=\"https:\/\/www.hostingtg.com\/blog\/apt-get-update-vs-upgrade\/\">actualizar los paquetes<\/a>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Aunque la imagen del sistema operativo sea reciente, puede haber actualizaciones de seguridad pendientes.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Con\u00e9ctate por SSH y ejecuta:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo apt update\nsudo apt upgrade<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">El primer comando actualiza la informaci\u00f3n sobre los paquetes disponibles. El segundo instala las actualizaciones correspondientes.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Prefiero ejecutar ambos de forma separada y revisar los cambios antes de confirmarlos, especialmente cuando estoy trabajando en un servidor de producci\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Si has iniciado sesi\u00f3n directamente como root, puedes ejecutar estos comandos sin <code>sudo<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Tambi\u00e9n es recomendable comprobar la versi\u00f3n de Ubuntu:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>lsb_release -a<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Y verificar que tu usuario tiene permisos administrativos:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo whoami<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Si el comando devuelve <code>root<\/code>, significa que puedes ejecutar operaciones con privilegios elevados.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ten presente que algunas actualizaciones pueden requerir un reinicio. En ese caso, deber\u00edamos programarlo y comprobar despu\u00e9s que los servicios vuelven a funcionar correctamente.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Evita quedarte fuera del servidor: consola y sesi\u00f3n SSH de respaldo<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Este es uno de los consejos en los que m\u00e1s insisto.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Antes de modificar SSH o activar el firewall, mant\u00e9n abierta la conexi\u00f3n actual con tu VPS.<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Durante el tutorial vamos a aplicar cambios que pueden impedir nuevas conexiones si nos equivocamos.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por ejemplo, desactivar la autenticaci\u00f3n por contrase\u00f1a antes de comprobar las claves SSH podr\u00eda dejarnos sin una forma v\u00e1lida de iniciar sesi\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Lo mismo sucede si activamos UFW sin permitir previamente el puerto utilizado por SSH.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por eso recomiendo tres precauciones:<\/p>\n\n\n\n<ol start=\"1\" class=\"wp-block-list\">\n<li>Mantener abierta la sesi\u00f3n SSH con la que estamos administrando el servidor.<\/li>\n\n\n\n<li>Utilizar otra terminal para comprobar las nuevas conexiones.<\/li>\n\n\n\n<li>Verificar previamente que disponemos de alg\u00fan m\u00e9todo de recuperaci\u00f3n, como una consola de acceso fuera de banda ofrecida por el proveedor.<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">Tambi\u00e9n conviene comprobar si existe un firewall adicional en el panel del proveedor, ya que sus reglas pueden afectar a las conexiones independientemente de UFW.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Una configuraci\u00f3n de seguridad demasiado restrictiva, aplicada sin comprobarla, puede terminar convirti\u00e9ndose en un problema para nosotros mismos.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Y cr\u00e9eme: es mucho mejor invertir un minuto en estas verificaciones que tener que recuperar el acceso a un servidor bloqueado.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Paso 1. Asegurar SSH en Ubuntu con claves Ed25519<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">SSH es una de las herramientas que m\u00e1s utilizamos para administrar servidores Linux.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Nos permite ejecutar comandos, modificar configuraciones, instalar aplicaciones y controlar pr\u00e1cticamente cualquier aspecto del VPS sin necesidad de acceder f\u00edsicamente a la m\u00e1quina.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Precisamente por eso es uno de los primeros servicios que deber\u00edamos proteger.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Cuando un servidor dispone de una IP p\u00fablica, puede recibir intentos automatizados de conexi\u00f3n dirigidos al servicio SSH. Muchos de ellos buscan contrase\u00f1as d\u00e9biles o configuraciones descuidadas.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Mi recomendaci\u00f3n es bastante clara: <strong>utilizar <a href=\"https:\/\/www.hostingtg.com\/blog\/ssh-keygen\/\">claves SSH<\/a>, administrar el sistema con un usuario propio y evitar el inicio de sesi\u00f3n remoto directo como root<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Crear un usuario con permisos sudo<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Si hemos recibido nuestro VPS con acceso directo como root, lo primero ser\u00e1 <a href=\"https:\/\/www.hostingtg.com\/blog\/como-anadir-y-crear-usuarios-en-linux\/\">crear un usuario administrativo<\/a>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ejecutamos:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo adduser adminvps<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Ubuntu nos pedir\u00e1 una contrase\u00f1a para el nuevo usuario y algunos datos adicionales opcionales.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Es importante escoger una <a href=\"https:\/\/www.hostingtg.com\/blog\/gestor-de-contrasenas\/\">contrase\u00f1a robusta<\/a>, porque seguir\u00e1 siendo necesaria para determinadas operaciones administrativas con <code>sudo<\/code>, aunque posteriormente desactivemos el acceso SSH mediante contrase\u00f1a.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Despu\u00e9s a\u00f1adimos el usuario al grupo <code>sudo<\/code>:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo usermod -aG sudo adminvps<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Este comando permite que <code>adminvps<\/code> ejecute tareas administrativas utilizando <code>sudo<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Podemos comprobar que pertenece al grupo correspondiente:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>groups adminvps<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Entre los grupos mostrados deber\u00eda aparecer <code>sudo<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ahora bien, crear un usuario diferente de root no elimina por s\u00ed solo todos los riesgos. Un usuario con permisos sudo tambi\u00e9n puede realizar cambios importantes en el sistema.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La ventaja es que evitamos utilizar continuamente la cuenta root y podemos controlar mejor c\u00f3mo accedemos y administramos el servidor.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Generar e instalar una clave SSH Ed25519<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Personalmente, prefiero utilizar claves Ed25519 para el acceso SSH.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Son una opci\u00f3n moderna, ofrecen una seguridad criptogr\u00e1fica s\u00f3lida y permiten trabajar con claves relativamente compactas.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Lo primero es generar el par de claves <strong>en nuestro ordenador, no en el VPS<\/strong>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Desde Linux, macOS o Windows con OpenSSH disponible, ejecutamos:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ssh-keygen -t ed25519 -C \"mi-equipo\"<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">El sistema nos preguntar\u00e1 d\u00f3nde queremos guardar las claves y nos ofrecer\u00e1 la posibilidad de establecer una frase de contrase\u00f1a.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Recomiendo proteger la clave privada con una frase de contrase\u00f1a robusta.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Normalmente se generar\u00e1n dos archivos:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>id_ed25519<\/code>: nuestra clave privada, que nunca debemos compartir.<\/li>\n\n\n\n<li><code>id_ed25519.pub<\/code>: la clave p\u00fablica, que podemos instalar en el servidor.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Si ya utilizamos una clave SSH, no necesitamos generar otra obligatoriamente. Podemos reutilizar una adecuada, siempre que est\u00e9 protegida y tengamos control sobre ella.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Lo importante es no sobrescribir accidentalmente una clave existente.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">El siguiente paso consiste en instalar la clave p\u00fablica en el usuario administrativo del VPS.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Desde nuestro ordenador, en un entorno donde tengamos disponible <code>ssh-copy-id<\/code>, ejecutamos:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ssh-copy-id adminvps@203.0.113.10<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Este comando copia la clave p\u00fablica al archivo <code>authorized_keys<\/code> del usuario remoto y prepara los permisos necesarios.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Si utilizamos un puerto SSH diferente del habitual, tendremos que indicarlo mediante la opci\u00f3n correspondiente.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Una vez instalada, abrimos otra terminal y comprobamos el acceso:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ssh adminvps@203.0.113.10<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Para asegurarnos de que la conexi\u00f3n utiliza realmente la clave p\u00fablica, tambi\u00e9n podemos ejecutar desde nuestro ordenador:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ssh -o PreferredAuthentications=publickey \\\n    -o PasswordAuthentication=no \\\n    adminvps@203.0.113.10<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Si conseguimos iniciar sesi\u00f3n, vamos por buen camino.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Dentro del servidor comprobamos los permisos administrativos:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo whoami<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Deber\u00eda aparecer:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>root<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>No debemos continuar con el bloqueo de la autenticaci\u00f3n por contrase\u00f1a hasta haber comprobado que el nuevo usuario puede acceder mediante clave SSH y utilizar sudo.<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Esta verificaci\u00f3n es mucho m\u00e1s importante que cambiar el puerto 22 por otro diferente.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Cambiar el puerto puede reducir parte de los intentos automatizados m\u00e1s simples, pero no sustituye una autenticaci\u00f3n correctamente configurada.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Desactivar el acceso root y la autenticaci\u00f3n por contrase\u00f1a<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Ahora que tenemos un usuario administrativo y hemos comprobado que las claves funcionan, podemos endurecer la configuraci\u00f3n del servicio SSH.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En Ubuntu, el archivo principal suele ser:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>\/etc\/ssh\/sshd_config<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Sin embargo, las versiones modernas tambi\u00e9n pueden cargar configuraciones adicionales desde:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>\/etc\/ssh\/sshd_config.d\/<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Estas configuraciones pueden incluir ajustes proporcionados por la imagen del VPS o por herramientas como cloud-init.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por eso conviene revisar los archivos existentes y no asumir que basta con modificar una l\u00ednea cualquiera.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Primero podemos guardar una copia de la configuraci\u00f3n principal:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo cp \/etc\/ssh\/sshd_config \\\n    \/etc\/ssh\/sshd_config.bak<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Tambi\u00e9n conviene revisar las directivas de inclusi\u00f3n y los archivos adicionales:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>grep -n '^Include' \/etc\/ssh\/sshd_config\nls -l \/etc\/ssh\/sshd_config.d\/<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">En una instalaci\u00f3n est\u00e1ndar que incluya al principio los archivos <code>.conf<\/code> de ese directorio, podemos crear un archivo espec\u00edfico:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo nano \/etc\/ssh\/sshd_config.d\/00-hardening.conf<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">A\u00f1adimos:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>PermitRootLogin no\nPasswordAuthentication no\nKbdInteractiveAuthentication no\nPubkeyAuthentication yes<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Con estas directivas buscamos:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Impedir el inicio de sesi\u00f3n SSH directo como root.<\/li>\n\n\n\n<li>Desactivar la autenticaci\u00f3n mediante contrase\u00f1a.<\/li>\n\n\n\n<li>Deshabilitar la autenticaci\u00f3n interactiva por teclado, evitando mantener abierta otra v\u00eda de autenticaci\u00f3n basada en contrase\u00f1as.<\/li>\n\n\n\n<li>Mantener disponible la autenticaci\u00f3n mediante clave p\u00fablica.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Es importante comprobar c\u00f3mo se combinan estos ajustes con los archivos existentes. OpenSSH utiliza reglas de precedencia y puede aplicar configuraciones espec\u00edficas mediante bloques <code>Match<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Adem\u00e1s, antes de cambiar el acceso root debemos confirmar que ninguna tarea automatizada depende de esa conexi\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En algunos entornos empresariales tambi\u00e9n pueden utilizarse otros m\u00e9todos de autenticaci\u00f3n, como certificados o mecanismos centralizados. En esos casos, la configuraci\u00f3n debe adaptarse a la infraestructura.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Validar los cambios y comprobar la conexi\u00f3n SSH<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Antes de recargar SSH, ejecutamos:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo sshd -t<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Si no muestra errores, la sintaxis b\u00e1sica de la configuraci\u00f3n es v\u00e1lida.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Pero todav\u00eda debemos comprobar los valores efectivos:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo sshd -T | grep -E \\\n'^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication) '<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">En la configuraci\u00f3n planteada deber\u00edamos observar:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>permitrootlogin no\npubkeyauthentication yes\npasswordauthentication no\nkbdinteractiveauthentication no<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">La salida de <code>sshd -T<\/code> puede variar seg\u00fan el contexto de conexi\u00f3n, especialmente cuando existen reglas <code>Match<\/code>. Si las utilizamos, tambi\u00e9n habr\u00e1 que revisar el resultado para el usuario y la conexi\u00f3n concretos.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Una vez comprobada la configuraci\u00f3n, recargamos el servicio:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo systemctl reload ssh<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Ahora abrimos una nueva terminal y probamos otra vez:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ssh adminvps@203.0.113.10<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Si podemos conectarnos mediante nuestra clave y utilizar <code>sudo<\/code>, habremos completado una de las medidas m\u00e1s importantes de protecci\u00f3n del VPS.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">No cierres todav\u00eda la sesi\u00f3n administrativa original. La mantendremos abierta hasta terminar de comprobar el firewall.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Paso 2. Configurar el firewall UFW en Ubuntu<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Una vez protegido el acceso SSH, el siguiente elemento que recomiendo revisar es el firewall.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Hay una costumbre que considero especialmente peligrosa: instalar aplicaciones en un servidor sin comprobar despu\u00e9s <a href=\"https:\/\/www.hostingtg.com\/blog\/comprobar-puertos-abiertos\/\">qu\u00e9 puertos han quedado accesibles<\/a> desde Internet.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A veces instalamos una base de datos, una herramienta de administraci\u00f3n o un servicio de pruebas y dejamos abierta una conexi\u00f3n que realmente no necesitamos.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Mi criterio es bastante sencillo: <strong>si un servicio no necesita estar accesible p\u00fablicamente, no deber\u00eda estarlo<\/strong>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Para una configuraci\u00f3n inicial de Ubuntu, UFW es una opci\u00f3n muy pr\u00e1ctica.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">UFW significa <em>Uncomplicated Firewall<\/em> y facilita la administraci\u00f3n de reglas de filtrado de tr\u00e1fico sin necesidad de escribir directamente reglas complejas de bajo nivel.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Permitir SSH antes de activar el firewall<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Lo primero es comprobar si UFW est\u00e1 instalado:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ufw status<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Si el sistema indica que no encuentra el comando, podemos instalarlo:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo apt install ufw<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Antes de activarlo, necesitamos permitir las conexiones SSH.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Si utilizamos el puerto habitual, 22\/TCP, podemos ejecutar:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ufw allow 22\/tcp<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Tambi\u00e9n podemos utilizar:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ufw allow OpenSSH<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Este segundo comando emplea el perfil de aplicaci\u00f3n de UFW. Debemos comprobar que el perfil corresponde al puerto que realmente utiliza nuestro servicio SSH.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por ejemplo, si hemos configurado SSH para escuchar en el puerto 2222, la regla correspondiente ser\u00eda:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ufw allow 2222\/tcp<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">En ese caso, tendr\u00edamos que adaptar todas las comprobaciones posteriores al nuevo puerto.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Lo importante es entender que <strong>no debemos habilitar el firewall hasta asegurarnos de que existe una regla que permite nuestro acceso administrativo<\/strong>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Incluso podemos restringir SSH para que solo acepte conexiones desde una IP de administraci\u00f3n concreta, si disponemos de una direcci\u00f3n fija y conocemos las implicaciones de esa limitaci\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Para una configuraci\u00f3n inicial general, utilizaremos una regla de acceso al puerto SSH correspondiente.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Abrir los puertos HTTP y HTTPS cuando sean necesarios<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Si vamos a utilizar nuestro VPS Ubuntu para alojar una p\u00e1gina web, normalmente necesitaremos permitir conexiones HTTP y HTTPS.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Los puertos habituales son:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><th>Servicio<\/th><th>Puerto<\/th><th>Protocolo<\/th><\/tr><tr><td>SSH<\/td><td>22<\/td><td>TCP<\/td><\/tr><tr><td>HTTP<\/td><td>80<\/td><td>TCP<\/td><\/tr><tr><td>HTTPS<\/td><td>443<\/td><td>TCP<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Podemos permitir el tr\u00e1fico web mediante:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ufw allow 80\/tcp\nsudo ufw allow 443\/tcp<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Esto tiene sentido si nuestro servidor va a publicar una web mediante <a href=\"https:\/\/www.hostingtg.com\/blog\/instalar-nginx-en-ubuntu\/\">Nginx<\/a>, Apache u otra aplicaci\u00f3n que escuche en esos puertos.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Sin embargo, no todos los VPS necesitan ofrecer servicios web.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por ejemplo, un servidor utilizado exclusivamente para procesos internos podr\u00eda necesitar \u00fanicamente SSH y conexiones privadas.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Del mismo modo, servicios como <a href=\"https:\/\/www.hostingtg.com\/blog\/como-instalar-mysql-en-ubuntu\/\">MySQL<\/a>, Redis o determinados paneles de administraci\u00f3n no deber\u00edan quedar expuestos directamente a Internet salvo que exista una necesidad justificada y medidas de protecci\u00f3n adecuadas.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En HostingTG trabajamos con VPS destinados a proyectos muy diferentes. No necesita exactamente las mismas reglas un <a href=\"https:\/\/www.hostingtg.com\/hosting-wordpress\/\">servidor WordPress<\/a> que otro destinado a Docker, <a href=\"https:\/\/www.hostingtg.com\/hosting-n8n\/\">n8n<\/a> o aplicaciones que publican distintas API.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por eso prefiero definir las reglas del firewall en funci\u00f3n de los servicios reales, en lugar de abrir puertos simplemente por comodidad.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Activar UFW y comprobar las reglas de seguridad<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Una vez permitidas las conexiones necesarias, estableceremos una pol\u00edtica inicial sencilla:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ufw default deny incoming\nsudo ufw default allow outgoing<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Con estas reglas, UFW bloquear\u00e1 por defecto las conexiones entrantes que no est\u00e9n expresamente permitidas y autorizar\u00e1 las conexiones salientes.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Es una configuraci\u00f3n inicial razonable para muchos servidores web, aunque los entornos m\u00e1s restrictivos tambi\u00e9n pueden necesitar controlar el tr\u00e1fico saliente.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ahora activamos el firewall:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ufw enable<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">UFW puede mostrar una advertencia indicando que la operaci\u00f3n podr\u00eda afectar a las conexiones SSH.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Como previamente hemos permitido el puerto correcto, podemos continuar, siempre que hayamos verificado las reglas y mantengamos nuestra sesi\u00f3n administrativa abierta.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Despu\u00e9s comprobamos su estado:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ufw status verbose<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Deber\u00edamos encontrar una salida similar a esta:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Status: active\nDefault: deny (incoming), allow (outgoing)\n\n22\/tcp    ALLOW IN    Anywhere\n80\/tcp    ALLOW IN    Anywhere\n443\/tcp   ALLOW IN    Anywhere<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Los resultados exactos depender\u00e1n de los puertos que hayamos habilitado y de la configuraci\u00f3n IPv6.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Tambi\u00e9n podemos revisar las reglas numeradas:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ufw status numbered<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Esto resulta \u00fatil cuando necesitamos identificar una regla concreta para modificarla o eliminarla.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por \u00faltimo, abrimos una nueva terminal y comprobamos de nuevo que podemos conectarnos por SSH.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Si todo funciona, habremos a\u00f1adido otra capa de protecci\u00f3n al VPS.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Una advertencia importante: UFW no controla necesariamente todos los escenarios de exposici\u00f3n de puertos cuando utilizamos <a href=\"https:\/\/www.hostingtg.com\/blog\/introduccion-docker\/\">Docker<\/a>, contenedores o reglas de red a\u00f1adidas por otras aplicaciones. En esos entornos es necesario revisar tambi\u00e9n las publicaciones de puertos y las cadenas de filtrado correspondientes.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Tampoco debemos olvidar IPv6. Si nuestro VPS dispone de conectividad IPv6 p\u00fablica, las reglas y los servicios expuestos deben revisarse para ambos protocolos.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Paso 3. Instalar y configurar Fail2ban para SSH<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Con SSH reforzado y el firewall activo, vamos a instalar <a href=\"https:\/\/www.hostingtg.com\/blog\/fail2ban\/\">Fail2ban<\/a>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Es una herramienta que lleva muchos a\u00f1os formando parte de las configuraciones habituales de seguridad en servidores Linux y que personalmente sigo considerando \u00fatil para determinadas situaciones.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Su funcionamiento es relativamente sencillo.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Fail2ban examina registros de servicios y, cuando detecta determinados patrones de fallos repetidos, puede aplicar bloqueos temporales a las direcciones IP implicadas.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En el caso de SSH, esto puede ayudarnos a reducir intentos automatizados de autenticaci\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Eso s\u00ed, no conviene confundir sus funciones.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Fail2ban no sustituye las claves SSH ni el firewall.<\/strong> Tampoco garantiza protecci\u00f3n frente a cualquier ataque, especialmente si las solicitudes se distribuyen entre muchas direcciones IP o el ataque utiliza m\u00e9todos que no generan los eventos supervisados.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Su utilidad est\u00e1 precisamente en complementar otras medidas.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Instalar Fail2ban y configurar la protecci\u00f3n SSH<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Para instalarlo en Ubuntu, ejecutamos:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo apt install fail2ban<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Una vez instalado, necesitamos definir la protecci\u00f3n del servicio SSH.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En lugar de modificar directamente el archivo <code>jail.conf<\/code>, prefiero crear una configuraci\u00f3n local independiente.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Esto facilita el mantenimiento y evita depender de cambios que puedan producirse en el archivo de ejemplo durante las actualizaciones del paquete.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Primero nos aseguramos de que existe el directorio correspondiente:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo mkdir -p \/etc\/fail2ban\/jail.d<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Despu\u00e9s creamos el archivo:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo nano \/etc\/fail2ban\/jail.d\/sshd.local<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Introducimos la siguiente configuraci\u00f3n:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&#91;sshd]\nenabled = true\nport = ssh\nbackend = systemd\nmaxretry = 5\nfindtime = 10m\nbantime = 1h<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Vamos a ver qu\u00e9 significa cada par\u00e1metro.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><th>Par\u00e1metro<\/th><th>Funci\u00f3n<\/th><\/tr><tr><td><code>enabled = true<\/code><\/td><td>Activa la protecci\u00f3n SSH<\/td><\/tr><tr><td><code>port = ssh<\/code><\/td><td>Indica el puerto SSH est\u00e1ndar<\/td><\/tr><tr><td><code>backend = systemd<\/code><\/td><td>Consulta eventos mediante el journal de systemd<\/td><\/tr><tr><td><code>maxretry = 5<\/code><\/td><td>Establece el n\u00famero de fallos antes de aplicar la prohibici\u00f3n<\/td><\/tr><tr><td><code>findtime = 10m<\/code><\/td><td>Define una ventana de diez minutos<\/td><\/tr><tr><td><code>bantime = 1h<\/code><\/td><td>Establece una duraci\u00f3n de bloqueo de una hora<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Estos valores son una propuesta inicial, no una configuraci\u00f3n universal.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Si hemos cambiado el puerto SSH, debemos sustituir <code>ssh<\/code> por el puerto real. Tambi\u00e9n hay que comprobar que la acci\u00f3n de bloqueo utilizada por Fail2ban es compatible con el firewall del sistema.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En Ubuntu 22.04 y 24.04, utilizar el backend <code>systemd<\/code> puede resultar adecuado para leer los registros de autenticaci\u00f3n SSH desde el journal, siempre que el paquete y sus dependencias est\u00e9n correctamente instalados.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Precisamente por eso recomiendo no limitarse a copiar una configuraci\u00f3n: debemos comprobar que Fail2ban puede leer los eventos que necesita.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Tambi\u00e9n conviene tener cuidado si compartimos una misma IP p\u00fablica con otros administradores, ya que m\u00faltiples intentos fallidos podr\u00edan provocar el bloqueo temporal de esa direcci\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Para esos casos podemos valorar excepciones controladas mediante <code>ignoreip<\/code>, evitando listas de exclusi\u00f3n demasiado amplias.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Comprobar el servicio, los registros y las IP bloqueadas<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Una vez guardado el archivo, podemos comprobar que Fail2ban interpreta la configuraci\u00f3n:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo fail2ban-client -t<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Si la validaci\u00f3n termina correctamente, activamos y arrancamos el servicio:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo systemctl enable --now fail2ban<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Despu\u00e9s aplicamos la configuraci\u00f3n:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo fail2ban-client reload<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Comprobamos el estado general:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo fail2ban-client status<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Entre las protecciones activas deber\u00eda aparecer <code>sshd<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Para consultar espec\u00edficamente esa protecci\u00f3n:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo fail2ban-client status sshd<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">La salida suele incluir informaci\u00f3n sobre los intentos detectados y las direcciones IP bloqueadas.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Si no aparecen IP bloqueadas, eso no significa necesariamente que Fail2ban est\u00e9 funcionando mal. Puede ser simplemente que no haya detectado suficientes fallos para aplicar una prohibici\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Tambi\u00e9n debemos comprobar que el servicio est\u00e1 activo:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo systemctl status fail2ban<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Y consultar sus registros si observamos errores:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo journalctl -u fail2ban --no-pager -n 50<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Para revisar eventos relacionados con el servidor SSH, podemos utilizar:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo journalctl -u ssh --no-pager -n 50<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Dependiendo de c\u00f3mo est\u00e9 configurado el registro del sistema, puede ser necesario revisar otras unidades o fuentes de eventos.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">No recomiendo provocar m\u00faltiples fallos de autenticaci\u00f3n desde nuestra propia conexi\u00f3n de administraci\u00f3n \u00fanicamente para comprobar si el bloqueo funciona. Podr\u00edamos terminar bloqueando nuestra IP.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Una vez verificado que la protecci\u00f3n SSH est\u00e1 activa y que el backend puede consultar los registros correspondientes, habremos completado la tercera medida principal.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">C\u00f3mo comprobar que tu VPS Ubuntu est\u00e1 protegido<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Llegados a este punto, ya hemos realizado las tres configuraciones fundamentales: proteger SSH, limitar conexiones entrantes mediante UFW y activar Fail2ban.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Pero hay una diferencia importante entre ejecutar comandos y comprobar que han tenido el efecto esperado.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Despu\u00e9s de tantos a\u00f1os trabajando con servidores, he aprendido que merece la pena dedicar un poco de tiempo a las verificaciones. Una configuraci\u00f3n que parece correcta en un archivo puede no ser la que realmente est\u00e1 utilizando el servicio.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por ejemplo, podr\u00edamos modificar una directiva SSH que queda anulada por otra configuraci\u00f3n, abrir un puerto incorrecto en UFW o instalar Fail2ban sin tener activa la protecci\u00f3n que esper\u00e1bamos.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Vamos a comprobar los puntos esenciales.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Revisar SSH, puertos abiertos, UFW y Fail2ban<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Para revisar las opciones efectivas del servicio SSH:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo sshd -T | grep -E \\\n'^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication) '<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Debemos comprobar que el acceso root est\u00e1 desactivado, que la autenticaci\u00f3n por contrase\u00f1a y por teclado est\u00e1n deshabilitadas y que se permite la autenticaci\u00f3n por clave p\u00fablica.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">No olvides verificar tambi\u00e9n las reglas espec\u00edficas de usuario o direcci\u00f3n IP si utilizas bloques <code>Match<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Para consultar el firewall:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ufw status verbose<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Esperamos encontrar UFW activo y \u00fanicamente los puertos que necesitan los servicios publicados.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Podemos comprobar qu\u00e9 aplicaciones est\u00e1n escuchando en el servidor:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ss -tulpn<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Este comando permite identificar puertos TCP y UDP asociados a procesos.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Es importante interpretar correctamente los resultados. Un servicio puede escuchar \u00fanicamente en <code>127.0.0.1<\/code>, estar vinculado a una direcci\u00f3n privada o aceptar conexiones en todas las interfaces.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por tanto, que un puerto aparezca en esta lista no significa autom\u00e1ticamente que est\u00e9 accesible desde Internet.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Para determinar su exposici\u00f3n real, tambi\u00e9n tenemos que considerar las reglas del firewall, la configuraci\u00f3n del proveedor, IPv6 y cualquier capa adicional de red.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Finalmente, comprobamos Fail2ban:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo fail2ban-client status sshd<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Si la protecci\u00f3n est\u00e1 activa, podemos consultar los eventos detectados y los bloqueos aplicados.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Para una comprobaci\u00f3n completa, recomiendo realizar tambi\u00e9n una conexi\u00f3n SSH nueva desde un terminal independiente.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Esa prueba confirma algo fundamental: seguimos teniendo acceso administrativo despu\u00e9s de los cambios.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Checklist final de seguridad en 10 minutos<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Esta es la lista que utilizar\u00eda para revisar una configuraci\u00f3n inicial.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Ubuntu tiene instaladas las actualizaciones necesarias.<\/li>\n\n\n\n<li>Existe un usuario administrativo con permisos sudo.<\/li>\n\n\n\n<li>El usuario puede iniciar sesi\u00f3n mediante una clave SSH Ed25519.<\/li>\n\n\n\n<li>El acceso SSH directo como root est\u00e1 desactivado.<\/li>\n\n\n\n<li>La autenticaci\u00f3n SSH mediante contrase\u00f1a est\u00e1 desactivada.<\/li>\n\n\n\n<li>La configuraci\u00f3n SSH se ha validado y se ha probado una nueva conexi\u00f3n.<\/li>\n\n\n\n<li>UFW est\u00e1 activo y permite el puerto SSH correcto.<\/li>\n\n\n\n<li>Solo est\u00e1n abiertos los puertos p\u00fablicos necesarios.<\/li>\n\n\n\n<li>Fail2ban est\u00e1 instalado y la protecci\u00f3n <code>sshd<\/code> funciona.<\/li>\n\n\n\n<li>Se ha comprobado c\u00f3mo recuperar el acceso si falla SSH.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Si hemos completado todos estos puntos, tendremos una base de seguridad mucho m\u00e1s razonable que la de un VPS sin configurar.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">\u00bfSignifica que hemos eliminado cualquier posibilidad de ataque? No.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Pero s\u00ed habremos reducido riesgos habituales relacionados con el acceso remoto y la exposici\u00f3n innecesaria de servicios.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En cuanto al tiempo, debemos ser realistas. Si ya tenemos nuestras claves SSH preparadas y estamos familiarizados con Ubuntu, esta configuraci\u00f3n puede realizarse aproximadamente en diez minutos.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Si necesitamos generar claves por primera vez, descargar muchas actualizaciones, revisar configuraciones particulares o resolver errores, necesitaremos m\u00e1s tiempo.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La prioridad debe ser siempre aplicar y verificar correctamente cada cambio, no completar la gu\u00eda contra el reloj.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Errores habituales al asegurar un VPS Ubuntu<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Cuando hablamos de seguridad, solemos centrarnos en las herramientas que debemos instalar. Sin embargo, tambi\u00e9n conviene conocer los errores que pueden aparecer durante su configuraci\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Muchos no se deben a una vulnerabilidad especialmente compleja, sino a decisiones que parec\u00edan correctas en el momento de aplicarlas.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Uno de los ejemplos m\u00e1s comunes es bloquear el acceso al propio servidor.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Otro consiste en instalar servicios que quedan accesibles p\u00fablicamente sin que el administrador sea consciente de ello.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por eso me parece importante dedicar un apartado espec\u00edfico a estas situaciones.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Bloquear SSH por una regla incorrecta<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Imagina que tenemos un VPS configurado para utilizar SSH en el puerto 2222.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Decidimos activar UFW y, por costumbre, permitimos \u00fanicamente el puerto 22.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Despu\u00e9s cerramos nuestra sesi\u00f3n y descubrimos que ya no podemos conectarnos.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">El problema es que hemos permitido un puerto diferente del que realmente utiliza SSH.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Para evitarlo, debemos comprobar primero el puerto efectivo del servicio, a\u00f1adir la regla correcta y probar una conexi\u00f3n nueva antes de cerrar la actual.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Algo parecido ocurre al desactivar la autenticaci\u00f3n por contrase\u00f1a.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Si todav\u00eda no hemos instalado correctamente nuestra clave p\u00fablica en el servidor, podr\u00edamos quedarnos sin un m\u00e9todo v\u00e1lido para acceder.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En este caso, lo m\u00e1s importante es mantener abierta la sesi\u00f3n administrativa y disponer de un sistema de recuperaci\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Si perdemos el acceso remoto, necesitaremos utilizar la consola de recuperaci\u00f3n del proveedor, siempre que est\u00e9 disponible, para corregir las reglas de UFW o la configuraci\u00f3n de SSH.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Tambi\u00e9n recomiendo guardar copias de los archivos de configuraci\u00f3n antes de introducir modificaciones importantes.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La seguridad no consiste \u00fanicamente en aplicar restricciones. Tambi\u00e9n implica saber c\u00f3mo revertir un cambio si algo sale mal.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Exponer MySQL, Redis o servicios Docker innecesariamente<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Otro error frecuente es pensar que basta con activar un firewall para que cualquier servicio quede correctamente protegido.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por ejemplo, podemos instalar MySQL o Redis para una aplicaci\u00f3n y dejar su servicio escuchando en una interfaz p\u00fablica.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Si esa aplicaci\u00f3n se ejecuta en el mismo servidor, quiz\u00e1 no necesitemos permitir conexiones externas a la base de datos.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En muchos casos ser\u00e1 suficiente con utilizar una interfaz local, una red privada o una conexi\u00f3n protegida.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Con Docker debemos prestar todav\u00eda m\u00e1s atenci\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Al publicar puertos de contenedores, Docker puede a\u00f1adir reglas de red que no se comportan exactamente como las reglas entrantes habituales de UFW.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por eso no debemos asumir que <code>ufw status<\/code> refleja necesariamente toda la exposici\u00f3n de los servicios publicados mediante contenedores.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Conviene revisar tanto los puertos de los contenedores como las interfaces a las que est\u00e1n vinculados y las reglas de filtrado efectivas.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Algo parecido sucede con herramientas como n8n o paneles de administraci\u00f3n web.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Que una aplicaci\u00f3n tenga una interfaz accesible desde el navegador no significa que debamos publicarla directamente sin autenticaci\u00f3n, HTTPS y las restricciones necesarias.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Mi recomendaci\u00f3n es revisar cada servicio nuevo que instalamos y hacernos una pregunta:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>\u00bfEste puerto necesita estar accesible desde Internet o podr\u00eda funcionar de forma local o privada?<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Si no existe una necesidad real de exposici\u00f3n p\u00fablica, prefiero mantenerlo cerrado.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Qu\u00e9 hacer despu\u00e9s de los primeros 10 minutos<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Con SSH, UFW y Fail2ban correctamente configurados, nuestro VPS Ubuntu tendr\u00e1 una primera capa de protecci\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Pero la seguridad de un servidor no termina despu\u00e9s de su instalaci\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A medida que incorporamos aplicaciones, usuarios, bases de datos y servicios, tambi\u00e9n aparecen nuevas necesidades de configuraci\u00f3n y mantenimiento.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por eso considero importante diferenciar entre asegurar inicialmente Ubuntu y mantenerlo protegido durante toda su vida \u00fatil.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Actualizaciones autom\u00e1ticas y supervisi\u00f3n<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Mantener Ubuntu actualizado es una de las tareas b\u00e1sicas de administraci\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Una opci\u00f3n que podemos valorar es utilizar <code>unattended-upgrades<\/code> para instalar determinadas actualizaciones autom\u00e1ticamente.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Para instalarlo:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo apt install unattended-upgrades<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Despu\u00e9s podemos revisar su configuraci\u00f3n:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo dpkg-reconfigure --priority=low unattended-upgrades<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Tambi\u00e9n podemos consultar los ajustes peri\u00f3dicos:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>cat \/etc\/apt\/apt.conf.d\/20auto-upgrades<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">En una configuraci\u00f3n habilitada suelen aparecer estos valores:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>APT::Periodic::Update-Package-Lists \"1\";\nAPT::Periodic::Unattended-Upgrade \"1\";<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Si nuestro sistema no dispone de esos ajustes, tendremos que revisar la configuraci\u00f3n antes de asumir que las actualizaciones autom\u00e1ticas est\u00e1n funcionando.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En servidores de producci\u00f3n debemos controlar estos procesos para evitar interrupciones inesperadas.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Adem\u00e1s de las actualizaciones, recomiendo supervisar peri\u00f3dicamente los registros de SSH, los eventos de Fail2ban, los servicios activos y los puertos que han quedado abiertos.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Tambi\u00e9n conviene revisar los usuarios autorizados, las claves SSH instaladas y los permisos de los archivos sensibles.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">No se trata de revisar manualmente cada detalle todos los d\u00edas, sino de mantener una rutina razonable y utilizar herramientas de monitorizaci\u00f3n cuando el proyecto lo requiera.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Backups y seguridad seg\u00fan tu proyecto<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Hay otro elemento que considero fundamental y que no deber\u00edamos dejar para el final: las copias de seguridad.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Podemos tener SSH perfectamente configurado, UFW activo y Fail2ban bloqueando intentos fallidos, pero eso no evita todos los problemas posibles.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Una actualizaci\u00f3n defectuosa, un error administrativo, un fallo de almacenamiento o una vulnerabilidad en una aplicaci\u00f3n pueden provocar p\u00e9rdidas de datos.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por eso recomiendo disponer de <a href=\"https:\/\/www.hostingtg.com\/blog\/kopia\/\">copias de seguridad peri\u00f3dicas<\/a>, comprobar que se completan correctamente y realizar pruebas de restauraci\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Tambi\u00e9n es importante evitar que todas las copias est\u00e9n almacenadas \u00fanicamente en el mismo servidor.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Un snapshot puede ser \u00fatil para recuperar r\u00e1pidamente el estado de una m\u00e1quina, pero no siempre sustituye una estrategia de backups independientes.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En HostingTG trabajamos con servidores VPS que pueden destinarse a p\u00e1ginas web, aplicaciones, bases de datos y proyectos con necesidades muy diferentes.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por ejemplo, un VPS preparado para alojar WordPress o <a href=\"https:\/\/www.hostingtg.com\/hosting-woocommerce\/\">WooCommerce<\/a> debe prestar especial atenci\u00f3n a las actualizaciones del CMS, plugins, temas, base de datos y aplicaciones web.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En cambio, si utilizamos Docker, n8n o una aplicaci\u00f3n propia, tendremos que revisar los contenedores, las im\u00e1genes utilizadas, la publicaci\u00f3n de puertos, la autenticaci\u00f3n y el tratamiento de informaci\u00f3n sensible.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Lo mismo sucede con los paneles de administraci\u00f3n, las API y los sistemas empresariales.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">No existe una \u00fanica configuraci\u00f3n v\u00e1lida para absolutamente todos los proyectos.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En mi opini\u00f3n, contar con recursos adecuados, almacenamiento r\u00e1pido y una infraestructura fiable facilita el funcionamiento de las aplicaciones, pero no elimina nuestra responsabilidad de mantenerlas protegidas.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La seguridad debe acompa\u00f1ar al proyecto a medida que evoluciona.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Dudas de la comunidad<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">\u00bfEs suficiente con diez minutos para asegurar un VPS Ubuntu?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Diez minutos pueden bastar para aplicar una primera capa de protecci\u00f3n si tenemos experiencia y el servidor est\u00e1 preparado, pero no para garantizar una seguridad completa.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Configurar claves SSH, limitar puertos mediante UFW y activar Fail2ban ayuda a reducir riesgos habituales. Despu\u00e9s tendremos que seguir manteniendo Ubuntu, las aplicaciones y las copias de seguridad.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">\u00bfEs recomendable desactivar el acceso SSH mediante contrase\u00f1a?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">S\u00ed, siempre que previamente hayamos comprobado que podemos acceder utilizando nuestra clave SSH y disponemos de una forma de recuperaci\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Personalmente, prefiero utilizar Ed25519 y desactivar la autenticaci\u00f3n por contrase\u00f1a una vez verificado el acceso.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La clave privada debe permanecer protegida y no compartirse con otras personas.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">\u00bfQu\u00e9 puertos deber\u00eda abrir en el firewall UFW?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Depende del uso del servidor.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En un VPS destinado a alojar una p\u00e1gina web, habitualmente necesitaremos SSH y, cuando corresponda, HTTP y HTTPS.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Sin embargo, no deber\u00edamos abrir otros puertos \u00fanicamente porque una aplicaci\u00f3n los utilice internamente.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Las bases de datos, los sistemas de administraci\u00f3n y los servicios privados deben mantenerse fuera del acceso p\u00fablico siempre que sea posible.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">\u00bfFail2ban sigue siendo \u00fatil si utilizo claves SSH?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Puede seguir siendo \u00fatil como medida complementaria para detectar y responder a determinados intentos de autenticaci\u00f3n fallidos.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Su utilidad concreta depender\u00e1 de los m\u00e9todos de acceso habilitados, de los eventos registrados y de la configuraci\u00f3n aplicada.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">No debemos considerarlo un sustituto de las claves SSH, del firewall o de una pol\u00edtica adecuada de mantenimiento.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">\u00bfCambiar el puerto 22 de SSH mejora la seguridad?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Cambiar el puerto SSH puede reducir algunos intentos automatizados que se dirigen exclusivamente al puerto habitual.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Sin embargo, no impide que alguien descubra el nuevo puerto mediante un escaneo.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por eso no lo considero una medida suficiente por s\u00ed sola.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Es m\u00e1s importante configurar correctamente la autenticaci\u00f3n, restringir el acceso root y controlar las conexiones permitidas.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">\u00bfQu\u00e9 hago si pierdo el acceso SSH despu\u00e9s de configurar UFW?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Si el firewall bloquea el puerto SSH o hemos aplicado una configuraci\u00f3n incorrecta, necesitaremos utilizar otro m\u00e9todo de acceso administrativo.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La soluci\u00f3n puede pasar por la consola de recuperaci\u00f3n del proveedor, si est\u00e1 disponible, desde la que podremos corregir las reglas del firewall o los ajustes del servicio SSH.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Precisamente por eso recomiendo comprobar los m\u00e9todos de recuperaci\u00f3n antes de introducir cambios importantes.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Los primeros 10 minutos marcan la diferencia<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Asegurar un VPS Ubuntu no tiene por qu\u00e9 ser un proceso especialmente complicado, al menos cuando hablamos de establecer una primera capa de protecci\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Despu\u00e9s de a\u00f1os administrando servidores Linux, sigo considerando que hay tres medidas por las que merece la pena empezar: <strong>proteger SSH, configurar correctamente el firewall y utilizar Fail2ban cuando aporte una protecci\u00f3n adicional \u00fatil<\/strong>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Las claves SSH Ed25519 permiten mejorar la autenticaci\u00f3n remota. UFW nos ayuda a mantener cerrados los puertos innecesarios. Y Fail2ban puede reducir determinados intentos repetitivos de acceso.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Lo importante es aplicarlas en el orden adecuado y comprobar que todo funciona despu\u00e9s de cada cambio.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Tambi\u00e9n debemos recordar que cada VPS tiene unas necesidades diferentes. Un servidor destinado a alojar una web corporativa no requiere necesariamente la misma configuraci\u00f3n que otro utilizado para bases de datos, automatizaciones o aplicaciones empresariales.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por eso, cuando trabajamos con nuestros servidores en HostingTG, considero esencial adaptar la configuraci\u00f3n al uso real del proyecto y no limitarse a aplicar una lista de comandos sin entender qu\u00e9 hace cada uno.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Si est\u00e1s preparando un nuevo servidor, puedes consultar las opciones de <a href=\"https:\/\/www.hostingtg.com\/servidores-vps\/\">VPS de HostingTG<\/a> para desplegar Ubuntu y configurar tu entorno seg\u00fan las necesidades de tu aplicaci\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Pero recuerda: <strong>un buen VPS necesita tanto una infraestructura fiable como una administraci\u00f3n responsable<\/strong>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Opini\u00f3n Personal<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Despu\u00e9s de tantos a\u00f1os administrando servidores Linux, hay algo que tengo bastante claro: <strong>la seguridad de un VPS no deber\u00eda ser una tarea que dejamos para cuando tenemos tiempo, sino una de las primeras cosas que hacemos despu\u00e9s de instalarlo<\/strong>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En HostingTG llevamos a\u00f1os trabajando con servidores y proyectos de todo tipo, y mi experiencia me ha ense\u00f1ado que muchas veces no son las amenazas m\u00e1s sofisticadas las que deber\u00edan preocuparnos, sino esos peque\u00f1os descuidos que parecen inofensivos: una contrase\u00f1a poco segura, un puerto abierto sin necesidad o un servicio que lleva meses funcionando sin actualizarse.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Personalmente, siempre recomiendo empezar por lo b\u00e1sico. Configurar correctamente SSH, activar el firewall UFW y utilizar Fail2ban son tres medidas relativamente sencillas que pueden ayudarnos a evitar muchos problemas. Eso s\u00ed, hay algo que considero incluso m\u00e1s importante que ejecutar los comandos: <strong>entender qu\u00e9 estamos haciendo y comprobar que cada cambio funciona correctamente<\/strong>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">De poco sirve reforzar SSH si terminamos bloqueando nuestro propio acceso al servidor, o activar un firewall sin revisar qu\u00e9 servicios necesitamos mantener disponibles.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Tambi\u00e9n creo que debemos dejar de pensar que un servidor est\u00e1 completamente protegido porque hemos instalado unas cuantas herramientas de seguridad. Un VPS que hoy est\u00e1 bien configurado puede presentar riesgos ma\u00f1ana si dejamos de actualizarlo, instalamos aplicaciones vulnerables o nos olvidamos de las copias de seguridad.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por eso, mi filosof\u00eda es sencilla: empezar con una configuraci\u00f3n segura, mantener expuestos \u00fanicamente los servicios necesarios y revisar peri\u00f3dicamente el estado del sistema.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>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.<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>\u00bfY t\u00fa, c\u00f3mo proteges tus servidores?<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Me gustar\u00eda conocer tu experiencia. <strong>\u00bfQu\u00e9 medidas de seguridad aplicas nada m\u00e1s instalar un VPS Ubuntu? \u00bfUtilizas SSH con claves, UFW y Fail2ban, o prefieres otras herramientas?<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">\u00bfAlguna vez te has quedado sin acceso a un servidor despu\u00e9s de modificar SSH o configurar el firewall?<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Te leo en los comentarios.<\/strong> Comparte tus consejos, experiencias o dudas, porque estoy convencido de que todos podemos aprender algo de c\u00f3mo otros administradores protegen sus servidores Linux.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Acabas de instalar Ubuntu en tu VPS, tienes acceso por SSH y todo parece funcionar correctamente. \u00bfSignifica eso que tu servidor est\u00e1 protegido? Ni mucho menos. Despu\u00e9s de tantos a\u00f1os administrando servidores Linux, he aprendido que muchos problemas de seguridad no empiezan con ataques sofisticados. A veces basta una contrase\u00f1a d\u00e9bil, un puerto abierto innecesariamente [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":10313,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"set","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[952],"tags":[1255,1194,236,848,177,269],"class_list":["post-10312","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-guias","tag-fail2ban","tag-firewall","tag-seguridad","tag-ssh","tag-vps","tag-vulnerabilidades"],"_links":{"self":[{"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/posts\/10312","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/comments?post=10312"}],"version-history":[{"count":2,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/posts\/10312\/revisions"}],"predecessor-version":[{"id":10315,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/posts\/10312\/revisions\/10315"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/media\/10313"}],"wp:attachment":[{"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/media?parent=10312"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/categories?post=10312"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/tags?post=10312"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}