El estándar de seguridad en el despliegue moderno

Comprar un VPS y dejarlo con la configuración de fábrica es una irresponsabilidad. A los pocos minutos de tener una IP pública, vas a tener miles de intentos de acceso automatizados. Si no quieres que tu servidor termine siendo parte de una botnet, tienes que cerrar las puertas antes de mover una sola línea de código.

Hacer las cosas bien desde el principio no es por paranoia, es por higiene técnica. Este es el proceso exacto para dejar un servidor Linux listo para producción sin complicaciones.

Acceso por SSH

Entrar con usuario y contraseña es invitar a que alguien entre por fuerza bruta. El estándar hoy es usar llaves criptográficas y punto.

• Llaves con PuTTY: Genera una llave Ed25519 usando PuTTYgen. Es más eficiente y segura que las RSA viejas. La llave privada se queda en tu máquina y la pública se sube al servidor.
• Configuración del demonio: Una vez dentro, hay que editar /etc/ssh/sshd_config. Las reglas son claras: PermitRootLogin no para que nadie entre como root, y PasswordAuthentication no para que si no tienes la llave física, ni siquiera te pida contraseña.
• Resultado: El servidor ignora cualquier intento de conexión que no venga firmado por tu llave. Es la forma más barata y efectiva de dormir tranquilo.

Actualización con APT

Muchos servidores vienen con imágenes de sistema desactualizadas. Instalar software sobre un kernel con vulnerabilidades conocidas es buscarse problemas. Antes de instalar nada, hay que limpiar y parchear.

El comando es el de siempre, pero es obligatorio:

sudo apt update && sudo apt full-upgrade -y && sudo apt autoremove -y

Esto no es por tener versiones nuevas porque sí, sino por los parches de seguridad. Además, el autoremove quita basura y dependencias que no sirven para nada. Menos software instalado significa menos cosas que pueden romperse o ser explotadas.

Firewall

No dejes que el sistema operativo tenga puertos abiertos por descuido. La regla es: si no lo usas para que el mundo te vea, ciérralo.

Usamos UFW para limitar el tráfico a lo mínimo:

• Puerto 22: Solo para tu gestión por SSH.
• Puertos 80 y 443: Para que tus aplicaciones web puedan servir tráfico.

Cualquier otra cosa, como una base de datos Redis o Postgres, debe estar cerrada al exterior. Si necesitas acceder a ellas, hazlo por un túnel SSH o internamente, pero nunca las dejes expuestas a la red pública.

Instalación de Coolify

Con la base limpia y cerrada, toca montar la orquestación. Usamos Coolify porque nos da la comodidad de un PaaS (tipo Vercel) pero en nuestro propio hardware.

Lo que ganas con esto:

• Aislamiento: Cada aplicación vive en su propio contenedor Docker, separada del resto del sistema.
• Certificados SSL: Gestión automática de HTTPS sin tener que configurar certificados a mano cada vez.
• Control: Tienes despliegues automáticos pero los datos nunca salen de tu servidor.

Seguridad como hábito

Seguir este protocolo no te quita más de diez minutos una vez que tienes los comandos a mano, pero la diferencia en estabilidad es abismal. No hace falta ser un experto en ciberseguridad ni configurar sistemas complejos para dormir tranquilo; se trata simplemente de aplicar una higiene técnica básica que el 90% de la gente ignora por pereza.

Un servidor bien configurado es un servidor que no hace ruido. En este trabajo, cuanto menos ruido haga tu infraestructura, más tiempo tendrás para centrarte en lo que realmente importa: tu código y tus usuarios. Al final del día, la soberanía sobre tus datos y tu privacidad empieza por algo tan sencillo como saber quién tiene la llave de tu servidor. Si sigues estos pasos, esa llave solo la tienes tú, y eso es lo que separa un proyecto amateur de uno profesional.