El servidor que llevas 12 años sin tocar es ahora el objetivo: cómo ponerlo al día sin romperlo

El servidor que dabas por intocable

Todos tenemos uno. Un VPS con un Debian o un Ubuntu que instalaste hace diez o doce años, que sirve algo que «no se puede tocar» —una web, una API interna, un panel— y que lleva tanto tiempo funcionando sin dar guerra que ya casi te has olvidado de que existe. No le has hecho un apt upgrade desde hace eras. Y, sin embargo, ahí sigue, impasible. Lo considerabas blindado precisamente por eso: porque en una década nadie le ha encontrado nada.

Pues siéntate, porque esa lógica se acaba de invertir. Ya lo avisamos cuando Mythos empezó a destapar fallos de 27 años en kernels que llevaban décadas en producción: hoy existen máquinas capaces de auditar un código entero y coser fallos invisibles en exploits funcionales, a una escala que ningún humano alcanza. Y ese servidor tuyo, con software de hace doce años, es el bocado más fácil del menú.

Lo que te mantenía a salvo no era la fortaleza de la máquina: era que mirarla con lupa salía caro y lento. Eso se ha terminado. La buena noticia: ponerla al día es perfectamente posible sin romper lo que hay encima. Vamos con el plan, paso a paso y sin dramatismos.

Antes de tocar NADA: una foto de la que puedas volver

Regla de oro número uno, la que separa una tarde de mantenimiento de un fin de semana de pánico: no toques un solo paquete sin tener antes una vía de regreso.

• Snapshot de la máquina entera. Si tu proveedor (Hetzner, DigitalOcean, OVH, etc.) ofrece snapshots, hazlo ahora. Es lo único que te deja deshacerlo todo de golpe si algo sale mal.
• Copia de lo que de verdad importa: bases de datos (mysqldump/pg_dump), configuración (/etc), datos de las aplicaciones y, si hay web, su raíz.
• Apunta el estado de partida. Guarda en un fichero la salida de estos comandos; te servirá de mapa:

uname -a                 # kernel actual
lsb_release -a           # versión de la distro (o cat /etc/os-release)
dpkg -l > paquetes.txt   # inventario de paquetes instalados
ss -tulpn                # qué está escuchando y en qué puerto
systemctl list-units --type=service --state=running

Si solo te llevas una frase de todo el artículo, que sea esta: el snapshot previo no es opcional.

Paso 1 — Saber qué tienes delante (y si la distro sigue viva)

Antes de actualizar, comprueba lo más importante: si tu versión de la distribución sigue recibiendo soporte de seguridad o ya está muerta (EOL, End Of Life).

• Mira el resultado de lsb_release -a. Un Ubuntu 16.04 o un Debian 9, por ejemplo, llevan años sin parches.
• Una distro en EOL es justo el problema: aunque hagas apt upgrade, no hay parches que aplicar porque los repositorios ya no publican. Estás actualizando a la nada.

Esto define tu camino. Si la distro aún tiene soporte, te basta con el Paso 2. Si está EOL, necesitarás además el Paso 3 (salto de versión) o, en casos extremos, migrar a una máquina nueva.

Paso 2 — Poner al día los paquetes y el kernel

Para una distro todavía soportada, el grueso del trabajo es esto:

apt update                       # refresca el índice de paquetes
apt upgrade                      # actualiza sin quitar nada
apt full-upgrade                 # permite cambios mayores (kernel, dependencias)
apt autoremove --purge           # limpia lo que ya no hace falta

Un par de avisos de los que ahorran sustos:

• El kernel solo se aplica tras reiniciar. Puedes actualizar el paquete del kernel, pero hasta que no hagas reboot sigues corriendo el viejo. Comprueba con uname -r antes y después.
• Si durante la actualización te aparece un menú preguntando qué hacer con un fichero de configuración modificado (*.dpkg-dist / *.dpkg-new), no le des a ciegas: «mantener la versión actual» suele ser lo seguro si tú tocaste esa config a mano.
• ¿Te da pereza vigilar esto cada mes? Activa las actualizaciones de seguridad automáticas:

apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

Paso 3 — El salto de versión (si tu distro está muerta)

Aquí es donde la gente suda, y con razón: saltar de versión mayor es el punto más delicado. Pero tiene método.

• Hazlo de una versión a la siguiente, nunca a saltos. De Ubuntu 18.04 se va a 20.04, luego a 22.04… no directamente a la última. Cada salto, su reinicio y su comprobación.

En Ubuntu:

apt update && apt full-upgrade   # primero al día en la versión actual
do-release-upgrade               # asistente oficial de salto de versión

En Debian, el salto es manual: se editan los repositorios en /etc/apt/sources.list (cambiando el nombre en clave: buster → bullseye → bookworm…) y luego:

apt update && apt full-upgrade

• Entre salto y salto, reinicia y verifica que la web y los servicios siguen vivos. Si algo se rompe, lo arreglas con un solo salto de contexto, no con cinco versiones de diferencia encima.
• ¿La máquina es muy vieja y arrastra demasiada personalización frágil? A veces sale más limpio levantar un VPS nuevo con la versión actual y migrar —lo contamos en detalle en cómo migrar un VPS sin downtime— que arrastrar doce años de parches sobre parches.

Paso 4 — Lo que se rompe (y cómo no asustarte)

Actualizar de verdad significa que algunas cosas van a cambiar de versión, y eso puede afectar a lo que corre encima. Los sospechosos habituales:

• PHP: pasar de PHP 7.x a 8.x rompe código antiguo. Revisa que tu aplicación tolera la nueva versión antes de dar el salto, o instala la versión concreta que necesitas y apúntala como deuda a resolver.
• MySQL/MariaDB: cambios de versión mayor pueden tocar el formato de datos. Por eso el mysqldump del principio no era opcional.
• Servicios y configuraciones: revisa que Nginx/Apache, tus cron, tus certificados y tus sockets siguen en pie tras cada reinicio.

La estrategia que nunca falla: cambia poco, reinicia, comprueba. No te lances a actualizar la distro, PHP y la base de datos a la vez; encadena los cambios y verifica entre uno y otro.

Paso 5 — Ya que estás, cierra la puerta

Si vas a tocar el servidor, aprovecha para dejarlo decente. Cuatro gestos baratos que suben mucho el listón:

• SSH con clave, no con contraseña, y PermitRootLogin no.
• Cortafuegos mínimo (ufw o nftables): abre solo lo que de verdad usas (ss -tulpn te dice qué hay escuchando de más).
• fail2ban para frenar el martilleo de fuerza bruta.
• Actualizaciones de seguridad automáticas (el unattended-upgrades del Paso 2) para que esto no se vuelva a quedar parado doce años.

La recomendación, sin rodeos

El servidor que «lleva años funcionando sin tocarlo» no es un mérito, es un riesgo dormido. Lo que cambió con herramientas como Mythos no es que tu máquina sea de pronto más débil: es que ahora mirarla con lupa industrial es barato, y lo que esté mal acabará encontrándose. La única defensa que envejece bien no es la suerte, es la disciplina de actualización.

Si tienes por ahí una de esas máquinas y se te revuelve el estómago solo de pensar en tocarla —porque «si funciona, no lo toques»—, ese es exactamente el servidor del que deberíamos hablar. Lo ponemos al día con snapshot, plan y vuelta atrás garantizada, sin que tus servicios se enteren. Antes de que lo mire alguien que no debería.