Primeros pasos al recibir un VPS: la checklist de seguridad
Un VPS recién entregado empieza a recibir intentos de acceso a los pocos minutos de tener IP pública. Antes de instalar tu aplicación hay que hacer diez cosas: actualizar, crear un usuario sin privilegios, pasar a claves en lugar de contraseñas, cerrar el acceso directo del administrador, cambiar el puerto, levantar el firewall, instalar el bloqueo por intentos fallidos, sincronizar la hora, configurar los avisos y dejar los respaldos andando.
La lista, en orden
- Actualizá todo el sistema antes que nada. La imagen con la que se creó el servidor puede tener semanas.
- Creá un usuario propio con permisos de administración y dejá de usar la cuenta de root directamente.
- Generá un par de claves y configurá el acceso por clave. Después desactivá la autenticación por contraseña.
- Prohibí el acceso directo de root por SSH.
- Cambiá el puerto de SSH. No es seguridad de verdad, pero saca de encima el 95 por ciento del ruido automatizado.
- Levantá el firewall dejando abierto solo lo que usás: SSH, web y lo que tu aplicación necesite.
- Instalá un bloqueador de intentos fallidos que banee IPs tras varios errores.
- Sincronizá la hora con NTP. Sin hora correcta los registros no sirven y los certificados fallan.
- Configurá los avisos por correo del sistema a una casilla que leas.
- Dejá los respaldos automáticos corriendo y probá una restauración antes de poner nada en producción.
Por qué las claves y no las contraseñas
Una contraseña, por larga que sea, se puede adivinar por fuerza bruta a lo largo del tiempo. Una clave criptográfica de las que se usan hoy es, en la práctica, inadivinable.
Además, la clave no viaja: el servidor manda un desafío y tu equipo lo firma. Nunca se transmite el secreto, así que no hay nada que interceptar.
Lo que se olvida siempre
- Guardar la clave privada en un lugar seguro y con respaldo. Si se pierde, hay que entrar por consola de emergencia.
- Documentar el puerto nuevo de SSH. Es clásico cambiarlo, cerrar la sesión y no acordarse.
- Probar el firewall desde afuera, no desde el propio servidor.
- Verificar que los avisos por correo efectivamente llegan.
- Anotar qué se instaló y por qué. En seis meses nadie se acuerda.
Antes de cerrar la sesión, siempre
Cada vez que toques la configuración de SSH o del firewall, abrí una segunda sesión y comprobá que entrás antes de cerrar la primera. Es la única red de seguridad que existe contra dejarse afuera del propio servidor.
Si igual te quedaste afuera, la consola del panel del proveedor entra por fuera de la red y permite arreglarlo.
Preguntas frecuentes
¿Cambiar el puerto de SSH sirve de algo?
No frena a nadie decidido, pero elimina casi todo el ruido de los escaneos masivos. Con menos ruido, los intentos que quedan en el registro son los que vale la pena mirar.
¿Hace falta antivirus en Linux?
Para el sistema, rara vez. Sí conviene si el servidor recibe archivos de usuarios o maneja correo, para no reenviar a otros algo infectado.
¿Cada cuánto hay que actualizar?
Los parches de seguridad, apenas salen; muchas distribuciones los aplican solas si se habilita. Las actualizaciones mayores, planificadas y con respaldo previo.
Seguí leyendo
Snapshots y backups en un VPS: la diferencia que salva
Un snapshot no es un backup. Para qué sirve cada uno, cuándo usarlos y por qué tener solo uno de los dos deja un agujero.
Por qué te bloquean la IP y cómo desbloquearla
De un momento a otro no entrás a tu propio sitio ni al correo. Casi siempre es el mismo mecanismo, y se resuelve en minutos.
Si te hackearon el sitio: las primeras cuatro horas
El orden correcto para contener, limpiar y volver, sin borrar la evidencia que dice por dónde entraron.