Buenas prácticas mínimas para un VPS Linux: checklist real para no dejarlo expuesto

Introducción

Montar un VPS Linux hoy es más fácil que nunca. En pocos minutos puedes tener una máquina pública con IP propia, acceso remoto, espacio para desplegar aplicaciones y libertad casi total para montar lo que quieras.

Y eso es justo lo bonito… y también lo peligroso.

Porque mucha gente lanza un VPS, instala lo básico para que la web funcione y lo deja así. Sin endurecer accesos, sin revisar puertos, sin firewall, sin logs, sin copias, sin actualizar, sin pensar en seguridad mínima. El resultado puede ser un servidor “operativo”, sí, pero demasiado expuesto.

No hace falta irse a un nivel paranoico ni montar una fortaleza imposible de mantener. Pero sí conviene aplicar una base mínima de buenas prácticas para que el servidor no quede regalado al primer bot que lo encuentre.

Esta guía está pensada como una checklist realista para un VPS Linux, especialmente útil si trabajas con:

• Ubuntu Server
• Debian
• VPS pequeños o medianos
• proyectos personales
• blogs
• paneles internos
• APIs
• apps PHP, Node, Python o similares

La idea aquí no es obsesionarse con seguridad avanzada, sino cubrir lo mínimo razonable para que tu VPS no esté innecesariamente expuesto.

Primera idea clave: un VPS es una máquina pública

Aunque el proyecto que alojes sea pequeño, si el VPS tiene IP pública y servicios abiertos, está en internet igual que cualquier otro servidor.

Eso significa que puede recibir:

• escaneos de puertos
• bots de login
• tráfico sospechoso
• peticiones extrañas
• intentos automáticos contra servicios conocidos

No importa si tu web todavía no tiene visitas. Internet no espera a que te hagas famoso para escanear tu servidor.

Por eso conviene tratar cualquier VPS expuesto como un sistema real que merece una base de protección y mantenimiento.

1. Mantén el sistema actualizado

Esta es una de las medidas más básicas y más importantes.

Actualizar el sistema ayuda a corregir:

• vulnerabilidades conocidas
• bugs de seguridad
• fallos del kernel
• errores en paquetes instalados
• componentes desactualizados

En sistemas basados en Debian o Ubuntu, lo típico sería trabajar con algo como:

sudo apt update
sudo apt upgrade

Y en algunos casos también revisar si hay reinicios pendientes o paquetes retenidos.

Esto no sustituye una buena configuración, pero sí evita dejar al servidor con vulnerabilidades conocidas simplemente por abandono.

2. Usa un usuario normal con sudo y evita trabajar siempre como root

Otro básico muy importante: no conviertas el acceso diario como root en tu forma habitual de administrar.

Lo más recomendable suele ser:

• crear o usar un usuario normal
• darle permisos administrativos mediante sudo
• conectarte con ese usuario
• elevar privilegios solo cuando haga falta

Ventajas:

• mejor trazabilidad
• menos riesgo de errores graves
• menos exposición directa del usuario root
• práctica más sana de administración

Root existe para tareas concretas, pero no debería ser tu identidad cotidiana para todo.

3. Asegura SSH desde el principio

Si tu VPS se administra de forma remota, SSH es la puerta principal. Y esa puerta debe estar bien cuidada.

Medidas mínimas muy recomendables:

• usar claves SSH
• evitar acceso por contraseña si ya tienes claves funcionando
• no permitir login directo de root
• revisar logs de acceso
• considerar firewall y fail2ban

Esto solo ya mejora muchísimo el perfil de seguridad del servidor.

4. Configura un firewall

No deberías dejar abierto todo lo que el sistema o tus pruebas van exponiendo.

Un firewall como UFW te permite:

• permitir solo lo necesario
• bloquear lo demás
• limitar exposición
• reducir superficie de ataque

Una política base razonable para muchos VPS sería:

• denegar entradas por defecto
• permitir salidas por defecto
• abrir solo SSH, HTTP y HTTPS si toca
• abrir puertos extra solo cuando de verdad los necesites

Un VPS sin firewall es una invitación innecesaria a demasiadas cosas.

5. No expongas servicios internos sin necesidad

Esto es muy común en servidores montados deprisa.

Ejemplos de cosas que muchas veces no deberían quedar expuestas públicamente:

• MySQL o MariaDB
• Redis
• paneles de desarrollo
• herramientas internas
• puertos de pruebas
• aplicaciones auxiliares
• dashboards sin protección

Antes de abrir un puerto, pregúntate:

• ¿de verdad tiene que estar accesible desde internet?
• ¿podría restringirse por IP?
• ¿podría quedarse solo en red interna?
• ¿podría ir detrás de autenticación o proxy?

Muchísimos problemas se evitan simplemente no exponiendo servicios que no necesitan estar públicos.

6. Instala Fail2ban si el servidor está expuesto

Si tu VPS tiene SSH o servicios sensibles accesibles desde internet, Fail2ban es una capa extra muy útil.

Ayuda a:

• detectar intentos repetidos de acceso fallido
• bloquear IPs problemáticas
• reducir ruido automatizado
• frenar bots básicos de fuerza bruta

No sustituye una mala configuración por una buena, pero sí refuerza bastante un entorno ya bien montado.

7. Revisa qué puertos están realmente escuchando

No todo lo que está abierto en el servidor es necesariamente evidente a simple vista.

Conviene revisar qué servicios están en escucha con herramientas como:

ss -tulpn

Esto te permite ver:

• qué puertos están abiertos
• qué procesos los usan
• qué cosas están escuchando
• si hay algo que no esperabas

Es una práctica muy útil después de instalar cosas, hacer pruebas o desplegar aplicaciones nuevas.

8. Revisa logs de forma periódica

No hace falta obsesionarse, pero sí conviene mirar logs con cierta regularidad.

Especialmente:

• logs de SSH
• logs del servidor web
• logs de servicios críticos
• journal del sistema
• errores de aplicaciones

Esto ayuda a detectar:

• accesos fallidos
• errores silenciosos
• reinicios inesperados
• problemas de configuración
• actividad sospechosa

Un VPS sano no es solo uno que “arranca”, sino uno del que entiendes lo que está pasando.

9. Haz copias de seguridad

Este punto no es opcional si el proyecto importa de verdad.

Un VPS puede fallar por:

• errores tuyos
• corrupción
• borrados accidentales
• fallos del proveedor
• malas actualizaciones
• ataques
• scripts defectuosos

Tener backups te da margen real de recuperación.

Como mínimo, piensa en respaldar:

• bases de datos
• archivos importantes de la web
• configuraciones
• certificados
• scripts
• contenido subido por usuarios si aplica

Y mejor aún si:

• se automatizan
• se guardan fuera del propio VPS
• se prueban de vez en cuando

Porque un backup que nunca has probado tampoco es garantía absoluta.

10. Documenta cambios importantes

Esto parece menor, pero ayuda muchísimo.

Documenta al menos:

• puertos abiertos y por qué
• servicios instalados
• rutas importantes
• usuarios de administración
• tareas cron
• ubicaciones de logs
• backups configurados
• cambios en SSH
• ajustes del firewall

Esto te salva tiempo y errores cuando vuelves semanas después o cuando algo falla y no recuerdas qué hiciste.

11. No instales paquetes por inercia

En servidores es muy fácil caer en:

• “instalo esto por si acaso”
• “lo dejo ahí por si luego me sirve”
• “probaré esta herramienta después”

Cuantos más paquetes y servicios tengas sin necesidad, más superficie de ataque y más complejidad innecesaria.

Mejor:

• instalar lo que realmente uses
• quitar lo que ya no necesites
• revisar qué servicios arrancan
• mantener el sistema lo más limpio posible

12. Usa HTTPS si expones una web

Si tu VPS aloja un sitio web o panel accesible desde navegador, HTTPS ya no debería verse como opcional.

Aporta:

• cifrado de tráfico
• más confianza
• mejor práctica de despliegue
• menos exposición de credenciales o sesiones

Además hoy es bastante accesible de configurar en muchísimos escenarios.

13. Vigila permisos y propietarios de archivos

Muchas incidencias de seguridad o funcionamiento vienen de permisos mal puestos.

Conviene revisar:

• propietarios correctos
• archivos sensibles no expuestos
• directorios con permisos razonables
• claves privadas protegidas
• archivos de configuración no demasiado abiertos

No hace falta convertirse en gurú de permisos el primer día, pero sí evitar barbaridades como dejar archivos críticos con acceso excesivo.

14. Automatiza tareas repetitivas con criterio

Si el servidor requiere tareas frecuentes, conviene automatizarlas bien en vez de depender siempre de memoria manual.

Por ejemplo:

• backups
• limpieza de temporales
• renovaciones o comprobaciones
• scripts de mantenimiento
• chequeos ligeros

Cron puede ayudar mucho aquí, siempre que:

• uses rutas absolutas
• registres salida
• pruebes bien las tareas

Automatizar bien reduce errores humanos.

15. Revisa el consumo de recursos

Especialmente en VPS pequeños, es importante observar:

• RAM
• CPU
• disco
• uso de swap
• crecimiento de logs
• consumo de aplicaciones

A veces un sistema “funciona” hasta que se queda sin espacio o hasta que una app empieza a comerse la memoria.

Herramientas como top, htop, free, df o du pueden ayudarte mucho aquí.

16. Piensa en el principio de mínimo acceso

Esta idea es muy útil y se puede aplicar a muchas capas del VPS:

• abrir solo puertos necesarios
• usar solo usuarios necesarios
• dar solo permisos necesarios
• exponer solo servicios necesarios
• automatizar solo lo necesario
• instalar solo lo necesario

Es una mentalidad simple pero muy poderosa.

17. Ten cuidado con pruebas en producción

En VPS personales mucha gente mezcla:

• experimentos
• apps reales
• scripts en pruebas
• configuraciones temporales
• paneles a medio montar

Y eso puede terminar mal.

Si puedes, separa:

• lo estable
• lo experimental
• lo público
• lo interno

Y si no puedes separar del todo, al menos documenta y limita bien qué está expuesto.

18. Comprueba que el arranque del servidor tenga sentido

No solo importa que algo funcione ahora. También importa qué pasa si el VPS reinicia.

Conviene revisar:

• qué servicios arrancan automáticamente
• si SSH está disponible
• si la web vuelve correctamente
• si el firewall sigue como debe
• si tus tareas automáticas dependen de algo más

Esto te ahorra sorpresas después de reinicios o mantenimientos del proveedor.

Ejemplo de checklist mínima razonable

Si me preguntas por un mínimo razonable para un VPS Linux público, pensaría en algo así:

• sistema actualizado
• usuario con sudo
• SSH con clave
• sin login root directo
• firewall UFW configurado
• solo puertos necesarios abiertos
• Fail2ban instalado si hay exposición pública
• backups básicos funcionando
• logs revisados
• servicios innecesarios cerrados
• HTTPS si hay web
• documentación mínima hecha

Eso ya cambia mucho el nivel del servidor.

Errores comunes con VPS Linux

1. Pensar “como es un proyecto pequeño no pasa nada”

Sí pasa. Los bots no distinguen por tamaño del proyecto.

2. Abrir demasiados puertos

Muchos terminan abiertos por pruebas o pereza.

3. No hacer backups

Hasta que un día los echas de menos.

4. Usar root para todo

Mala costumbre y más riesgo.

5. No revisar logs nunca

Pierdes visibilidad total.

6. Instalar servicios sin endurecerlos

El clásico “ya luego lo arreglo”.

7. No revisar qué arranca automáticamente

A veces el sistema reinicia y algo importante no vuelve bien.

Conclusión:

Un VPS Linux no necesita una configuración exageradamente compleja para estar mucho mejor protegido que el promedio. Con una base razonable de buenas prácticas ya puedes evitar muchísimos errores comunes y dejar de tener un servidor “funcionando a medias y expuesto de más”.

Actualizar, asegurar SSH, configurar firewall, limitar exposición, revisar logs, hacer backups y entender qué está abierto son medidas sencillas en comparación con el valor que aportan.

La clave no está en hacer todo perfecto desde el minuto uno, sino en no dejar lo esencial para “algún día”.