Checklist de seguridad para VPS: 12 pasos tras el primer inicio de sesión

Doce pasos de blindaje en orden — claves SSH, firewall, parches automáticos, fail2ban, restauraciones probadas — en un VPS Core sin KYC desde $4.80/mes.

La configuración por defecto es la vulnerabilidad

Pregunta qué es lo que realmente entra en los servidores VPS y la respuesta es vergonzosamente prosaica: no son zero-days contra el kernel, sino la autenticación por contraseña dejada activada y una contraseña de root que sobrevivió a un escaneo automatizado. El ruido de fuerza bruta contra una IPv4 pública recién estrenada empieza a los pocos minutos del primer arranque, y cada intento es un intento de adivinar la única credencial que la instalación por defecto acepta. El orden que verás abajo existe por esa asimetría: un valor por defecto aburrido frustra más ataques que cualquier herramienta exótica que puedas instalar después.

El mecanismo detrás del ruido es económico. Las botnets escanean todo el espacio IPv4 de forma continua porque adivinar contraseñas es barato; todo lo que encarece el intento filtra a la botnet, y todo lo que lo hace imposible lo filtra absolutamente. La autenticación solo con claves lo hace imposible en lugar de caro, un firewall de denegación por defecto vuelve invisible la mayor parte de la superficie, y los parches automáticos cierran los agujeros que quedan. Nada de esto tiene misterio: la disciplina está en el orden y en el seguimiento, no en las herramientas.

Dónde se equivoca la gente con el orden: instalar una pila de monitorización, endurecer nginx, afinar bases de datos — todo antes de tener las claves en su sitio. El servidor queda expuesto desde el momento en que se aprovisiona, unos 60 segundos después del pago, y el escaneo llega tanto si has terminado tu café como si no. Semanas de trabajo de aplicación cuidadoso no sobreviven a una primera hora débil, porque el atacante no espera a tu hoja de ruta.

Todo lo de esta lista cabe en los primeros treinta minutos, y los pasos están ordenados de modo que cada uno reduzca el riesgo del siguiente. Si solo hicieras los dos primeros — claves y firewall — ya habrías eliminado los modos de fallo que realmente acaban con la mayoría de los servidores. El resto es profundidad, y de profundidad va esta página; el resumen del final lo comprime todo en una secuencia ejecutable.

Primero las claves, luego cierra la puerta de las contraseñas

El paso uno es añadir tu clave pública SSH y desactivar la autenticación por contraseña para root — antes de que nada más toque la red. Genera un par moderno con ssh-keygen -t ed25519, instala la mitad pública con ssh-copy-id o añadiéndola a ~/.ssh/authorized_keys, después fija PasswordAuthentication no y PermitRootLogin prohibit-password en sshd_config(5) y recarga sshd. Desde ese momento, el tráfico que empezó a los pocos minutos del arranque se convierte en un ruido permanentemente inofensivo.

El mecanismo es la eliminación de la credencial, no su protección: un servidor solo con claves no tiene contraseña que adivinar, así que los intentos diarios de tus logs se vuelven ruido sin ninguna vía posible de éxito. RFC 4253 define el transporte por el que viajan las claves; el punto práctico es más simple: el secreto nunca cruza el cable, así que nada en la red puede capturarlo y nada en tus logs puede filtrarlo. Crea a la vez un usuario sudo con nombre para el trabajo diario, y reserva root para la consola y contextos de rescate.

Dónde duele este paso: dejarte fuera. Mantén abierta la consola del panel de hosting mientras recargas sshd, y prueba un segundo terminal antes de cerrar el primero. La consola del panel es la vía fuera de banda que convierte una errata en sshd en un arreglo de cinco minutos en lugar de una reinstalación, y es también la razón por la que el error es recuperable en absoluto — una propiedad de la capa de hosting, no de tu configuración.

La gestión de claves sobrevive a la puesta en marcha: una clave por persona, una por cuenta de automatización, cada una con un comentario que nombre a su dueño, y nada compartido entre portátiles. Añadir a un compañero es un añadido a authorized_keys, no una ceremonia; cuando alguien se va, borrar su línea es toda la revocación. Esa propiedad — claves con nombre, usuarios con nombre, eliminación de una sola línea — es lo que hace que los 10 minutos extra del primer día valgan cada auditoría posterior.

Llegar al servidor a través de un túnel en lugar de exponer directamente 22/tcp es la versión mejorada de este paso — la guía de WireGuard lo cubre de principio a fin. En cualquier caso, la identidad ya está resuelta; la siguiente superficie es todo aquello a lo que el servidor responde a desconocidos, y esa lista es más corta de lo que la mayoría cree antes de ejecutar realmente la auditoría.

Denegación por defecto es una lista, no un aparato

Un firewall no es un producto que se instala; es una política que se mantiene. Ponlo en denegación por defecto y permite exactamente 22/tcp (o tu puerto desplazado), 80/tcp y 443/tcp para la web, y un puerto por cada servicio en marcha que realmente necesite la red. La wiki de nftables ofrece el tour de sintaxis de diez minutos, y nft list ruleset muestra lo que realmente se aplica — que ocasionalmente no es lo que crees, y la brecha entre ambas cosas es donde viven los incidentes.

Audita antes de permitir: ss -tulpn (ss(8)) enumera cada socket a la escucha y el proceso que hay detrás. Todo lo que escuche en 0.0.0.0 y que no puedas nombrar es o un servicio que olvidaste o uno que nunca instalaste a propósito — ambas respuestas requieren actuar, y solo una de ellas es tranquilizadora. Las interfaces de administración y las bases de datos se atan a 127.0.0.1, o viven detrás del túnel de la sección anterior, y nada que responda públicamente debería existir sin una razón que puedas decir en voz alta.

Dónde falla la denegación por defecto: se olvida la regla de conexiones establecidas, y el servidor responde a los SYN pero nunca completa un handshake — cinco minutos confusos hasta que alguien lee la documentación línea por línea. Segundo clásico: el firewall del panel y el del guest no coinciden, y el más restrictivo gana en silencio. Cuando las dos capas discrepan, quieres saber cuál es la autoridad antes del incidente, no durante, así que elige una capa que mantener y documenta la otra como de solo lectura.

Un ruleset mínimo que puedas recitar de memoria supera a uno ingenioso que no puedas depurar a las 3 de la mañana, y eso es una restricción de diseño, no una confesión. Con la superficie de red acotada, el ruido restante es lo que aún llegue a lo que decidiste exponer — lo cual es un problema de logging más que de seguridad, y los problemas de logging tienen soluciones baratas.

Haz legible el ruido de fuerza bruta

Tras el firewall, el log de autenticación de cualquier servidor público se llena de intentos fallidos antes de una hora. fail2ban existe para hacerlo legible: vigila /var/log/auth.log, cuenta los fallos por origen y ordena al firewall que descarte a los reincidentes durante un tiempo. Instálalo y luego consulta fail2ban-client status sshd para ver crecer la lista de baneos — prueba de que el bucle funciona de extremo a extremo, y una pequeña satisfacción diaria en cuanto veas cuánta parte de internet es exactamente esto.

El mecanismo es poner precio a la molestia, no prevenir: la autenticación solo con claves ya hizo imposible adivinar, así que la contribución de fail2ban es la higiene de los logs y el ahorro de ancho de banda más que la seguridad en sentido estricto. Fija bantime y findtime en valores con dientes — una hora, no cinco minutos — y pon tus propias direcciones en la lista blanca para que equivocar la clave tres veces seguidas no te deje fuera de tu propio servidor a la peor hora posible.

Los filtros merecen una prueba de humo antes de fiarte de ellos: ejecuta fail2ban-regex contra una muestra de líneas reales del log y confirma que el patrón coincide con lo que tu distribución escribe de verdad, lo cual varía según la versión. Una jail que coincide con 0 líneas funciona en silencio para siempre, ofreciendo la comodidad de un escudo con la cobertura de un colador. Dos minutos con la herramienta de regex responden la pregunta que el panel nunca responderá.

Dónde se rompe: un bantime tan corto que el mismo host vuelve de inmediato, jails activadas para servicios que no existen en el servidor, y el clásico eterno — banear tu propia IP a través de un NAT perimetral que comparte todo lo que hay detrás. sshguard es la alternativa más ligera cuando un framework completo de jails es más de lo que el servidor merece; cualquiera de las dos herramientas supera a la tercera opción, que es leer por obligación miles de líneas de inicios de sesión fallidos a la semana.

Con identidad, superficie y ruido resueltos, el servidor ya es más difícil de entrar que la inmensa mayoría de los de internet. Los riesgos restantes corren sobre un reloj que controlas mal: el propio software, que envejece ataque o no. Ese es el problema del parcheado, y se resuelve quitando tu calendario del bucle por completo.

Parches sin calendario

Cada CVE que sale para tu distribución es un recordatorio que acabarás olvidando. Las actualizaciones desatendidas eliminan el olvido: en sistemas de la familia Debian, apt install unattended-upgrades activa una ejecución diaria que descarga los parches de seguridad automáticamente — la wiki de Debian documenta el comportamiento exacto — y el archivo /etc/apt/apt.conf.d/50unattended-upgrades decide qué cuenta como seguridad. Tras la primera activación, el servidor se parchea solo con una periodicidad que ya nunca tendrás que recordar.

El mecanismo tiene un hueco que la automatización no puede cruzar: el kernel. Un kernel parcheado espera en memoria hasta el reinicio, y /var/run/reboot-required es la señal que indica que hay uno pendiente — compruébala semanalmente, o reinicia en un horario fijo que tú elijas. El portal de seguridad de Debian es de donde salen los avisos; el servidor no necesita que los leas, solo que lo reinicies de vez en cuando, que es la mano de obra de seguridad más barata que comprarás nunca.

Verifica la automatización una vez en lugar de darla por buena: unattended-upgrade --dry-run --debug muestra qué descargaría la próxima ejecución, y el historial de lo que hizo de verdad se acumula en /var/log/unattended-upgrades/ para compararlo con los ajustes de 50unattended-upgrades. Una automatización que nunca has visto funcionar es una casilla marcada, no un control; una que has visto funcionar una vez, con logs que contrastar, es ambas cosas — y revisarla tras cada versión puntual de la distribución la mantiene honesta.

Dónde se rompe: mezclar repositorios hasta que apt se queda con paquetes rotos, desactivar el servicio desatendido "temporalmente" durante un cambio grande y no volver a activarlo nunca, y las versiones EOL — una distribución sin soporte deja de recibir justo el repositorio del que la automatización lee, así que la máquina aparenta estar mantenida mientras el parcheado se ha detenido en silencio. Fallo de segundo orden: reiniciar un servicio concurrido en pleno día cuando un reinicio en hora tranquila habría sido invisible para todos tus usuarios.

Los parches protegen el software que ejecutas; los dos pasos siguientes protegen los datos que hay debajo — una copia en otro sitio, y una copia ilegible sin clave. De los dos, el primero es el que la gente se salta, y es el que decide si un mal día se convierte en un inconveniente o en un final, así que va ahora.

Una copia de seguridad nunca restaurada es un rumor

Programa snapshots como rollback previo a cada cambio, añade una copia fuera del servidor en un almacenamiento distinto y después — el paso que separa una copia de seguridad de una esperanza — ejecuta una restauración a un directorio de pruebas y demuestra que la cadena funciona. rsync -a --delete a una segunda ubicación más un snapshot completo periódico cubre la mayoría de servidores pequeños, y crontab -e (crontab(5)) programa ambos sin instalar nada nuevo.

El mecanismo es el control del radio de explosión. Un servidor comprometido o corrupto con una restauración probada es un incidente de 15 minutos; el mismo servidor con una copia sin probar es potencialmente una pérdida total, porque las copias sin probar fallan por las razones más amables — el trabajo se detuvo en silencio en marzo, el destino se llenó en junio, la clave de cifrado vive en el mismo disco que debía proteger. Cada uno de esos fallos es invisible hasta el día en que necesitas la copia, y esa es precisamente la razón por la que el ensayo no es opcional.

La verificación cierra el círculo: tras cada ensayo, compara el árbol restaurado con lo esperado y anota cuánto duró todo el procedimiento, porque el número de tiempo de recuperación es el que tu yo del futuro necesitará de verdad a las 3 de la mañana. Una copia de seguridad con tiempo de restauración desconocido es un plan al que le falta su parámetro central. Escribe el número junto al calendario y actualízalo cada trimestre con la misma rutina, para que el plan y su aritmética envejezcan juntos en lugar de por separado.

Dónde fallan los planes de copia: todo viviendo en la misma máquina física (un snapshot no es una copia de seguridad), credenciales de la copia externa guardadas donde un atacante pueda leerlas, y restauraciones que nunca se ensayaron ni una vez. El trimestre es la cadencia honesta para el ensayo — ponlo en el calendario junto a la comprobación de reinicio, y trata un trimestre saltado como una comprobación fallida, no aplazada.

Las restauraciones también acotan el daño del modo de fallo que la automatización no puede evitar: el error del operador, que es como muere la mayoría de los datos de producción. La última capa defensiva cambia de nuevo las reglas: los datos ilegibles sin clave son datos que un disco robado no puede entregar, sin importar quién lo saque del edificio.

Cifra el disco, desbloquéalo tras el arranque

Mete los datos sensibles en reposo en un contenedor LUKS que se abre después del arranque, y una compromise físico o una imagen del disco apagado darán como resultado texto cifrado en lugar de tu base de datos. El proyecto cryptsetup mantiene las herramientas: cryptsetup luksFormat construye el contenedor, /etc/crypttab lo nombra en el arranque y cryptsetup luksOpen lo monta. El patrón es un párrafo de configuración y una frase de contraseña, y convierte "disco robado" de incidente en un no-acontecimiento.

El problema headless es la verdadera restricción de diseño: una frase que se teclea en el arranque necesita algo donde teclearla. En las gamas dedicadas, IPMI te da esa consola — KVM remoto, medios virtuales, todo — y por eso el metal dedicado cifrado es sencillo: alquila Forge por $49/mes de lista — $39.20/mes en el término anual — y el desbloqueo es solo una sesión de consola remota tras cada reinicio, con 2 x 1 TB de NVMe esperando ilegibles detrás cada vez que el servidor está apagado. En un VPS, la consola del proveedor cumple el mismo papel, solo que con menos ancho de banda.

Protege la cabecera con el mismo cuidado que los datos: cryptsetup luksHeaderBackup escribe el pequeño archivo que puede revivir un contenedor dañado, y perder tanto la cabecera como la frase de contraseña termina la conversación para siempre. Guarda esa copia fuera del servidor bajo las mismas reglas de custodia que la propia frase. Dos artefactos, 2 ubicaciones, y la capa de cifrado se vuelve aburrida exactamente del modo al que aspira el resto de este checklist.

Dónde se rompe: cifrar solo después de que los secretos ya tocaron el disco sin cifrar — rota los datos o reprovisiona para estar seguro —, dejar el swap fuera del contenedor, y la gestión de la frase de contraseña. Una frase que nadie puede recuperar convierte una función de seguridad en pérdida de datos en el siguiente ciclo de energía, así que la custodia de dos personas no es exagerada para nada que importe, y una frase escrita en el mismo disco no es custodia en absoluto.

Con el disco bloqueado, la superficie restante ya no está en el servidor: es el panel que puede reiniciarlo, editar su DNS y leer sus metadatos de tráfico. El sshd_config más fuerte del mundo no sobrevive a una cuenta de hosting débil, que es exactamente a donde va la siguiente sección.

El panel también es superficie de ataque

El panel de hosting reinicia servidores y edita DNS, lo que lo convierte en superficie de ataque por limpia que esté la VM. Actívale 2FA el mismo día en que crees la cuenta, y trata sus credenciales con la misma disciplina que root. El modelo de cuenta sin KYC de aquí — un token o un email más una contraseña de 12 caracteres — traslada todo el peso de la identidad a esa única credencial, lo que es un argumento a favor del token más un gestor de contraseñas, no un argumento contra el modelo.

El mecanismo es la concentración de privilegios. Cualquiera con acceso al panel puede reconstruir la VM (tu frase LUKS sobrevive, el estado en marcha no), redirigir su DNS y leer los metadatos de conexión conservados hasta 24h. Eso es más poder operativo del que lleva una clave SSH robada, y pesca mejor por phishing, porque el email llega pareciendo una factura y no un evento de seguridad — y eso es exactamente por qué el segundo factor tiene que vivir en la cuenta del panel y no solo en el servidor.

Las vías de recuperación merecen la misma auditoría que los inicios de sesión: qué buzones pueden restablecer la contraseña del panel, y ¿esos buzones llevan su propio segundo factor? Un token guardado solo en un gestor de contraseñas, con el gestor detrás de 2FA y una copia en papel en un cajón, sobrevive a escenarios que un enlace de restablecimiento por email no. Traza la cadena una vez; el eslabón débil es casi siempre el buzón del que nadie recordó que el panel podía llegar.

Dónde se rompe: inicios de sesión del panel compartidos en un equipo, sin 2FA porque "la VM está endurecida", y direcciones de recuperación en un buzón que a su vez no tiene segundo factor. Revisa el acceso al panel cada vez que cambie la plantilla de personas — las salidas son cuando esta capa falla de verdad, y la auditoría lleva cinco minutos si la haces antes de la salida y no después.

Panel, claves, firewall, parches, copias, disco: seis capas, todas tuyas, ninguna exótica. La séptima pregunta — ¿necesitas antivirus? — tiene una respuesta genuinamente contraintuitiva para servidores, porque el sistema base casi nunca es la vía de infección que importa, y saber dónde el escaneo paga de verdad cambia para qué lo despliegas.

Escanea lo que aceptas, no lo que sirves

Un antivirus en el sistema base de un servidor Linux es puro teatro: los repositorios de la distribución firman sus paquetes, y la vía de infección habitual de un servidor no es un binario por drive-by sino contenido que aceptaste de otras personas. Donde los escáneres se ganan el sueldo es en las subidas, los spools de correo y los archivos generados por usuarios — un escáner de clase ClamAV sobre el directorio de entrada, ejecutado en cada subida o por calendario, atrapa la capa de entrega de la mayoría de payloads comerciales antes de que lleguen a ejecutarse.

El mecanismo es el alcance. Escanear lo que cruza un límite de confianza — usuarios que envían archivos, correo que llega, archivos que se descomprimen — es defendible; escanear el sistema operativo cada hora encuentra binarios firmados y desperdicia la CPU que podría haber ido a la carga de trabajo. Si el servidor acepta subidas que los clientes de otras personas descargan después, el escaneo de entrada más servir desde un dominio separado son los dos movimientos que importan, y freshclam manteniendo las firmas al día en /var/lib/clamav es lo que hace que el primero valga algo.

La ubicación sigue la misma lógica del límite: mantén el directorio de entrada separado de todo lo que ejecuta — /srv/uploads/ montado con noexec y servido desde su propio hostname es el mínimo. Escanear encuentra payloads; la separación los deja inertes, así que una detección tardía sigue sin encontrar nada ejecutable. Juntos, el par cubre la mayoría de cadenas de entrega comerciales — la clase que llega a diario y se ejecuta 0 veces cuando los flags del mount son correctos.

Dónde se rompe: cuarentenas que nadie revisa — detección sin respuesta es decoración —, firmas del escáner que dejaron de actualizarse en marzo, y el escaneo tratado como sustituto de las capas aburridas. Ningún escáner compensa una autenticación por contraseña o un kernel sin parchear, y el orden de este checklist es el orden de esa frase. Decide quién lee la cuarentena antes de construirla, o no la construyas.

Esa es la pila completa, y se degrada: cambia la plantilla de personas, aparecen servicios, la lista del firewall crece un puerto cada vez. El blindaje no es un estado sino un calendario — y el calendario, como el orden de operaciones, es la parte que merece escribirse. La siguiente sección es esa escritura, y el resumen posterior es la versión ejecutable.

Un checklist se degrada según un calendario

Los pasos uno a nueve se configuran y se olvidan hasta que cambia la arquitectura; la degradación vive en las comprobaciones restantes. Vuelve a verificar la restauración de copias cada trimestre, relee el firewall tras cada servicio nuevo, y revisa el acceso al panel cada vez que cambie la plantilla. Pide Core a $6/mes de lista — $4.80/mes en el término anual — como servidor de ensayo desechable y reejecuta toda esta lista sobre él antes de tocar producción; un ensayo que cuesta $4.80/mes es un ensayo que de verdad ocurre, y ese es todo el truco.

Ya que estás, haz un snapshot de la propia configuración: nft list ruleset guardado en un archivo bajo control de versiones convierte cada cambio en un diff revisable, y un ruleset del que nadie puede hacer diff es un ruleset que nadie puede auditar. El mismo truco cubre la configuración de sshd y el crontab. La configuración que vive solo en memoria se degrada en el momento en que lo hace el servidor, y cada incidente se encoge a una comparación de 5 minutos cuando existen los ficheros del antes y el después.

El mecanismo de la degradación es la deriva sin testigo: un servicio añadido en mayo con un agujero en el firewall, una regla de sudo que nadie recuerda haber aprobado, un destino de copias que se llenó en silencio. Nada avisa, porque nada está roto — hasta el día en que cada una de esas cosas se convierte en el incidente, momento en el que las tres se descubren en el post-mortem y ninguna era descubrible antes. El ensayo trimestral es el testigo, y solo funciona si es lo bastante barato para sobrevivir a un trimestre ajetreado.

Dónde se rompe la reverificación: se convierte en un documento que nadie abre. Ata cada comprobación periódica a un disparador que se active por sí solo — el calendario para los ensayos de restauración, el checklist de despliegue para las releídas del firewall, el circuito de RR. HH. para el acceso al panel — y el calendario sobrevive a la persona que lo escribió, que es la única versión del calendario que importa a escala de años y no de semanas.

Ejecuta la secuencia completa en cualquier servidor nuevo y ya habrás superado los modos de fallo que acaban con la mayoría; ejecútala cada trimestre en el más viejo y te mantendrás ahí. La línea temporal de abajo comprime todo lo de esta página en el orden en que los comandos se ejecutan de verdad, que es la forma que querrás abierta en un segundo terminal.

El checklist de blindaje, en el orden de ejecución

Minuto uno: claves. ssh-keygen -t ed25519, la mitad pública en ~/.ssh/authorized_keys, PasswordAuthentication no en /etc/ssh/sshd_config, un usuario sudo con nombre para el trabajo diario, y un segundo terminal probado antes de cerrar el primero. La consola del panel sigue abierta en una pestaña hasta que la nueva sesión se demuestre, porque el acceso fuera de banda es lo que hace que cada error posterior de esta lista sea recuperable y no fatal — y el presupuesto de 30 minutos se mantiene tanto si el objetivo es producción como si es un servidor de ensayo.

Minuto cinco: firewall — denegación por defecto, luego 22/tcp, 80/tcp, 443/tcp y un puerto por cada servicio real, confirmado con ss -tulpn y nft list ruleset. Minuto diez: fail2ban instalado con un bantime en escala de horas y tus propias direcciones en la lista blanca, y actualizaciones desatendidas activadas desde /etc/apt/apt.conf.d/50unattended-upgrades. Ninguno de los dos pasos vuelve a requerir una decisión tuya, y ese es el punto de hacerlos pronto.

Minuto veinte: snapshots programados, una copia externa fluyendo y una restauración ensayada en un directorio de pruebas, para que la cadena esté demostrada y no supuesta. Los datos sensibles van a un contenedor LUKS que se abre tras el arranque, con la frase de contraseña bajo custodia en algún sitio que no sea el disco que protege. Tarde del primer día: 2FA en el panel de hosting, escaneo de entrada en todo lo que acepte subidas, y el ensayo trimestral en el calendario con un recordatorio real adjunto.

Continuo, en el mismo orden: /var/run/reboot-required semanalmente, releer el firewall tras cada servicio nuevo, acceso al panel revisado en cada cambio de plantilla. Nada es ingenioso, y ese es el punto — claves, una lista corta de permisos, parches automáticos, una restauración probada, un disco cifrado, un panel de dos factores. El orden importa porque cada paso reduce el riesgo del siguiente, el calendario importa porque cada paso deriva sin uno, y treinta minutos ahora más una hora trimestral es el precio entero de permanecer más allá de los modos de fallo que acaban con la mayoría de los servidores.