Servidores sin actualizar: el riesgo que nadie ve
Un servidor sin parches no falla: sigue andando igual hasta el día que alguien entra. Qué revisar, en qué orden y por qué el riesgo real no es técnico.
Por José Luis Vieyra
Un servidor sin actualizar no se queja. No se pone lento, no tira errores, no manda avisos. Sigue andando exactamente igual que el día que se instaló, y esa es justamente la razón por la que pasan años sin que nadie lo toque.
El problema aparece de golpe, y casi nunca por donde se esperaba. Este es un caso que atendimos en Ciudad de Panamá, y después de contarlo va el detalle de qué revisar y en qué orden.
Un caso
Quince años sin tocar el servidor por el que salía todo el correo
Un Sendmail configurado en 2009 y nunca vuelto a abrir
Una empresa conocida de autopartes en Ciudad de Panamá, con su propio site. Adentro, un servidor de correo sobre Linux SUSE sin entorno gráfico, con un Sendmail configurado más de quince años atrás. Por ahí salía todo el correo de la compañía: las facturas a clientes, las cotizaciones, la comunicación con proveedores. Todo. Sin respaldo, sin actualizaciones y sin mantenimiento, porque durante quince años no hizo falta: funcionaba.
Un día dejó de enviar, y con él se detuvo la facturación
No hubo aviso previo ni señal de que algo estuviera envejeciendo: pasó de funcionar a no funcionar de un momento a otro. Dejaron de salir las facturas, las cotizaciones quedaron sin enviar y la comunicación con proveedores se cortó. Para una empresa que vende y cobra por correo, eso no es un problema de sistemas, es la operación parada. Lo primero que se vio al entrar fue esto: una lista de actualizaciones pendientes que el servidor tenía esperando desde hacía años.
El culpable era un certificado caducado, y el parche existía desde hacía años
Al entrar y revisar, el problema resultó ser un certificado raíz del sistema que había llegado a su fecha de caducidad. Esas fechas se conocen con años de anticipación y la renovación llega dentro de las actualizaciones de seguridad: el parche que lo arreglaba existía desde hacía tiempo, pero en ese servidor nunca se había aplicado ninguno. Se actualizó el sistema y el correo volvió a salir el mismo día.
Hoy tienen respaldo y una revisión al mes
Arreglar el síntoma habría dejado el problema intacto, así que se montó el respaldo periódico que no existía y quedó una revisión mensual: alguien entra, aplica los parches, mira los registros y comprueba que los respaldos sirvan. Quince años de no tocar nada salieron más caros que ese rato al mes.
El servidor que funciona es el que nadie abre
En una pyme, el servidor suele ser lo que menos ruido hace. Está en un rincón o en una nube que alguien contrató hace tiempo, corre el sistema contable o el sitio web, y funciona. Mientras funcione, no hay motivo para abrirlo.
Eso crea una situación curiosa: la parte más crítica de la operación es la única que nadie revisa. Un vendedor nota si su computadora anda lenta. Un contador nota si el sistema no abre. Nadie nota que el servidor lleva tres años sin un parche, porque un parche que falta no se siente.
Y mientras tanto el mundo afuera sí cambia. Cada mes se publican fallas nuevas en los mismos programas que ese servidor corre. La diferencia es que ahora esas fallas son públicas, con su descripción y, muchas veces, con el código para aprovecharlas ya publicado.
Nadie eligió tu empresa: un programa probó tu puerto
La imagen del atacante eligiendo a una empresa panameña y estudiándola durante semanas es, en la práctica, poco frecuente. Lo que ocurre casi siempre es más aburrido y más eficaz: programas que recorren internet entera probando la misma falla conocida contra cada dirección que encuentran.
No eligen a nadie. Prueban a todos. Un servidor sin parches es simplemente el que contesta que sí.
Por eso el argumento de “nosotros somos muy chicos, a quién le vamos a interesar” no protege. Nadie se fijó en la empresa. Se fijó en el puerto abierto.
Estar en Panamá tampoco ayuda, y conviene decirlo porque se repite mucho en las conversaciones. Un programa que recorre direcciones no distingue países: una pyme en Vía España responde igual de rápido que una en cualquier otro lado, y un servidor alojado en un proveedor local está en internet exactamente igual que uno alojado afuera.
Los cinco frentes, en el orden en que conviene atacarlos
1. Los parches, y el problema aparte de un sistema sin soporte
Lo básico, y donde está el grueso del riesgo. Aplicar las actualizaciones de seguridad del sistema operativo con una frecuencia definida, no cuando alguien se acuerda.
En servidores Linux eso suele ser rutina. Una sola
orden lista lo que está pendiente, y la lista casi siempre sorprende por lo
vieja que es. El ca-certificates de la captura de arriba es el paquete que
mantiene al día las raíces de certificación del sistema: es exactamente el que
faltaba en el caso de la autopartera, esperando sin aplicarse mientras el correo
seguía saliendo con normalidad.
En Windows Server el riesgo mayor es otro: encontrar versiones que ya perdieron el soporte del fabricante, donde los parches sencillamente ya no existen. Ahí la conversación deja de ser sobre actualizar y pasa a ser sobre migrar.
2. Los puertos que alguien abrió hace años y nadie cerró
Casi todo servidor con años encima tiene puertos abiertos que nadie recuerda haber abierto. Una base de datos accesible desde internet porque hace cinco años un proveedor lo pidió. Un panel de administración sin restricción de origen. Un servicio de escritorio remoto expuesto, que es la puerta de entrada más común de los secuestros de datos en empresas pequeñas.
La regla es simple: lo que no tiene que ser público, no se expone. Y lo que sí, se expone detrás de una VPN o con el acceso limitado a direcciones conocidas.
3. Las cuentas de gente que ya no trabaja ahí
Esta es la parte incómoda, porque las respuestas suelen sorprender. Cuentas de gente que ya no trabaja ahí. Usuarios compartidos donde varias personas entran con la misma contraseña, así que no se puede saber quién hizo qué. Accesos de proveedores de un proyecto que terminó en 2023.
Acceso por llave en lugar de contraseña, una cuenta por persona, y revisar la lista cada tanto. No es sofisticado; es que casi nunca se hace.
4. Los respaldos, que deciden si son horas o dos semanas
Aquí está la diferencia entre un mal día y una empresa parada dos semanas.
Un respaldo que nunca se restauró no es un respaldo. Lo habitual, cuando se revisa, es encontrar copias que llevan meses ejecutándose correctamente sobre una carpeta que ya no contiene lo importante, o archivos que no se pueden abrir, o una copia que vive en el mismo servidor que se quiere proteger.
Los dos números que hay que poder responder son cuánto se tarda en recuperar y hasta qué momento se puede volver. Si no se han medido restaurando de verdad, no se saben.
5. Enterarse el mismo día y no tres semanas después
Monitoreo con aviso al canal donde alguien lo va a ver. Lo que pasa sin que nadie se entere es lo que hace grande el problema: un servidor comprometido puede estar semanas así, y cuanto más tiempo pasa, menos se sabe qué se llevaron y hasta qué copia se puede confiar.
Lo que cuesta dinero no es el servidor, es la operación detenida
La pérdida que cuesta dinero casi nunca es el equipo. Es la operación detenida.
Sin sistema no se factura, no se despacha, no se cobra. Y la salida rápida de ese estado no depende de lo bueno que sea el técnico ese día, sino de algo que se decidió meses antes: si hay un respaldo probado y si alguien sabe qué había en ese servidor.
Ahí es donde la documentación deja de ser burocracia. Una empresa que sabe qué tiene, dónde está y cómo se recupera vuelve a operar en horas. Una que no lo sabe, descubre a mitad del incidente que el dominio estaba a nombre del técnico que se lo montó hace años, o de un proveedor que ya no contesta. En Panamá eso pasa seguido, porque el que arma el primer servidor de una pyme suele ser alguien de confianza y no una empresa, y las cuentas quedan a su nombre sin que nadie lo piense.
Cuatro preguntas que puedes responder esta semana
No hace falta un proyecto para empezar. Cuatro preguntas, y las respuestas dicen casi todo:
- ¿Qué versión corre cada servidor, y todavía tiene soporte?
- ¿Cuándo se aplicó el último parche de seguridad?
- ¿Qué puertos están abiertos hacia internet?
- ¿Cuándo se restauró un respaldo por última vez? No cuándo se hizo: cuándo se restauró.
Y una quinta que no es técnica pero decide igual de rápido: ¿a nombre de quién están el dominio y el hosting? Si la respuesta es una persona y no la empresa, ese es el primer papel que hay que mover.
Si alguna no se puede responder, ese vacío es el primer trabajo, y suele ser más barato de cerrar de lo que parece.
Y si la respuesta honesta es que nadie va a acordarse de hacerlo cada mes, ahí es donde tiene sentido una revisión periódica: alguien externo que entra, aplica los parches, mira los registros y comprueba los respaldos. Un rato al mes, contra días de operación detenida.
Si quieres ver qué incluye esto cuando lo hacemos nosotros, está en servidores e infraestructura, con las cinco preguntas que hacemos al entrar a una infraestructura que no conocemos. Y si el problema de fondo es que los datos viven repartidos en sitios que nadie controla, ese caso está contado en migrar datos dispersos a una fuente única.
Lo que conviene recordar
- Un servidor sin parches funciona igual, y esa es la razón por la que el problema dura años.
- Los ataques a pymes no son dirigidos: son programas probando fallas conocidas contra todo el mundo. Ser chico no protege.
- El orden importa: parches, puertos expuestos, accesos, respaldos probados, monitoreo.
- No hace falta un ataque para quedarse parado. Un certificado que caducó y un parche que nunca se aplicó bastan para dejar a una empresa sin correo.
- Lo que decide cuánto cuesta un incidente no es la falla, es si alguien sabía qué había en ese servidor y si había por dónde volver.
Preguntas frecuentes
Si tu caso no encaja en ninguna, escríbenos y lo vemos.
¿Actualizar un servidor puede romper lo que tengo corriendo?
Puede, y por eso no se actualiza a ciegas. Los parches de seguridad del sistema operativo casi nunca rompen nada, porque están hechos para no cambiar comportamiento. Los que sí tienen riesgo son los saltos de versión mayor. Se prueban antes en una copia y se hace una instantánea para poder volver en minutos.
¿Cada cuánto hay que aplicar parches?
Los de seguridad, dentro de los 30 días de publicados, y en días si es una falla crítica que ya se está explotando. El resto puede esperar a una ventana mensual. Lo que no funciona es no tener ninguna frecuencia y aplicarlos cuando alguien se acuerda.
Mi servidor no está expuesto a internet. ¿Igual importa?
Sí. La mayoría de los ataques a pymes no entran por el servidor: entran por un correo, una contraseña reutilizada o un equipo de la oficina, y desde ahí se mueven hacia adentro. Un servidor interno sin parches es justo lo que hace fácil ese segundo paso.
¿Qué pasa si el sistema ya no tiene soporte?
Ya no salen parches, así que cada falla nueva queda abierta para siempre. No hay forma de asegurarlo por dentro: la salida es actualizar el sistema o mover la aplicación a uno con soporte. Mientras tanto se lo aísla todo lo posible, pero eso es contener, no resolver.
¿Cómo sé en qué estado estoy hoy?
Con cuatro datos: qué versión corre cada servidor y si todavía tiene soporte, cuándo se aplicó el último parche, qué puertos están abiertos hacia internet, y cuándo se probó por última vez restaurar un respaldo. Si alguno no se puede responder, ese es el primer trabajo.
¿Esto te está pasando?
Cuéntanos tu caso y te decimos si tiene solución y cuánto trabajo implica, sin costo.
Hablar por WhatsApp