Hay una conversación que se repite cada vez que revisamos la infraestructura de respaldo de una empresa. Preguntamos a dónde puede salir el servidor donde viven las copias, y la respuesta casi siempre es la misma: a internet, normal. Necesita bajar actualizaciones, validar la licencia, empujar la copia externa a la nube. Nadie lo dejó así por descuido: lo dejó así porque hacía falta que funcionara.
El detalle es que «a internet, normal» y «a los cuatro lugares que de verdad necesita» son dos configuraciones que se ven idénticas mientras todo va bien, y radicalmente distintas el día del incidente.
Lo que un ransomware necesita después de entrar
El cifrado es el final de la película, no el principio. Un ataque moderno es una operación conducida por personas: alguien entra por una credencial robada o un servicio expuesto, mira alrededor, escala privilegios y se toma su tiempo. Y hay una tarea que ejecuta antes que cualquier otra, porque de ella depende que la extorsión sirva de algo.
Busca los respaldos y los inutiliza primero.
La lógica es fría: una empresa que puede restaurar no paga. Por eso el repositorio de respaldo no es un daño colateral del ataque, es el objetivo prioritario. Y para llegar a él, el operador necesita algo que damos por sentado: un canal por donde mandar comandos y recibir respuesta.
Ahí es donde la salida a internet del repositorio deja de ser un detalle de plomería.
El patrón: lista blanca de salida y, debajo, el deny
La idea cabe en dos reglas de firewall y no requiere producto nuevo, licencia adicional ni un proyecto de seis meses:
- Una regla que permite al repositorio —y solo a él— alcanzar los destinos concretos que necesita para operar.
- Inmediatamente debajo, una regla que niega todo lo demás para ese mismo origen.
El efecto no es que el atacante no pueda comprometer el servidor. Es que, si lo compromete, se queda sordo y mudo: sin telemetría de vuelta y sin forma de recibir instrucciones. Un equipo tomado que no puede hablar con quien lo tomó sirve de muy poco.
Qué va realmente en esa lista
Suele ser mucho más corta de lo que la gente supone. En la práctica son cuatro familias de destino:
- El proveedor de respaldo. Actualizaciones de producto y validación de licencia.
- El almacenamiento objeto donde vive la copia externa. El destino de la copia fuera de sitio, sea nube pública o un repositorio remoto propio.
- La consola del EDR. Si el servidor está protegido, tiene que poder reportar. Cortarle esa salida es apagar el sensor justo en el equipo más sensible.
- Resolución de nombres y validación de certificados. El destino que casi siempre se olvida, y del que hablamos abajo.
Conviene expresarlos como objetos de servicio o FQDN, no como «internet con inspección». La inspección le dice qué pasa por el túnel; la lista blanca le dice a dónde puede haber túnel.
El orden no es un detalle de estilo
Las políticas de firewall se evalúan de arriba hacia abajo y gana la primera coincidencia. Eso tiene dos consecuencias prácticas.
La primera: el deny tiene que ir inmediatamente debajo de la lista blanca y acotado al mismo origen. Un deny genérico al final de la política no sirve, porque cualquier regla permisiva intermedia lo va a ensombrecer.
La segunda, menos obvia: si más arriba en la política existe una regla amplia de «salida de servidores», el repositorio va a coincidir ahí y sus dos reglas nunca se van a evaluar. Habrá un control que existe en el documento y no existe en el tráfico. Vale la pena verificar el orden real, no el que se supone.
Lo que se rompe, y hay que decirlo
Este patrón tiene costo operativo. Fingir que no lo tiene es cómo se llega a que alguien lo desactive a las 2 de la mañana durante una restauración.
- Los destinos se mueven. Los rangos de los proveedores de nube cambian y los objetos FQDN dependen de resolución que caduca. Un respaldo que llevaba meses corriendo empieza a fallar sin que nadie haya tocado nada.
- La validación de certificados se olvida siempre. Si el servidor no puede consultar el estado de revocación, los handshakes TLS no fallan limpio: se cuelgan. Y eso no se reporta como «bloqueo de firewall», se reporta como «el respaldo está lentísimo». Es el ticket más caro de diagnosticar de toda esta lista.
- Cada integración nueva es una solicitud de cambio. Esto es simultáneamente el beneficio y el precio. El día que agreguen una herramienta que hable con la nube, alguien va a tener que autorizar el destino. Ese roce es el control funcionando, no un defecto.
Cómo saber que está funcionando
Hay una señal simple y contraintuitiva: la regla de deny debe tener tráfico. Poco, constante y aburrido.
Si el contador está en cero desde que se creó, la explicación habitual no es que el servidor se porte de maravilla, sino que algo más arriba está coincidiendo primero y el control no se está aplicando. Un cero permanente merece revisión, no felicitación.
Con una advertencia que evita un diagnóstico en falso: el contador de bytes también se puede haber reseteado a mano. Antes de salir a cazar una regla que ensombrezca, conviene mirar la marca de «último uso» de la política, que no se reinicia junto con el contador. Un cero recién reseteado y un cero de una regla que nunca coincidió se ven idénticos en la columna de tráfico, y significan cosas opuestas.
Y al revés: un salto repentino en ese contador es de las alertas más limpias que se pueden tener. El repositorio intentando alcanzar un destino que nunca había intentado significa que cambió el software… o que algo está corriendo ahí que no debería.
Esto no sustituye la inmutabilidad
Es una capa, no la capa. El control de salida limita el alcance del atacante; la inmutabilidad hace que la copia no se pueda alterar aunque el atacante llegue con credenciales válidas. Son problemas distintos y se resuelven en lugares distintos.
La versión completa de este razonamiento es 3-2-1-1-0. Lo que aporta la lista blanca de salida es cerrar el camino por el que un atacante llegaría a ejercer esas credenciales en primer lugar.
Por qué esto se decide arriba y no en la sala de servidores
Casi toda empresa mediana puede decir «tenemos respaldos». Muchas menos pueden decir «tenemos respaldos que sobreviven a alguien que ya está dentro de la red». La distancia entre esas dos frases se descubre el peor día posible, y no se cierra comprando más almacenamiento.
El costo de este control es cercano a cero: dos reglas y la disciplina de mantener una lista corta. El costo de no tenerlo se mide en días de operación detenida y en una decisión de pago que nadie quiere estar tomando.
Es el tipo de detalle que separa una infraestructura que existe de una que está operada. Así diseñamos la seguridad perimetral con Fortinet alrededor de las plataformas de respaldo que administramos, y una de las integraciones que más rinde es precisamente ésta, con Veeam del lado del dato y la política de salida del lado de la red.
Rubén Espinoza es fundador y Director Técnico de IT Experts de México. Trabaja en la industria de TI desde 1998: diseña y opera soluciones de infraestructura, ciberseguridad, continuidad, automatización y tecnología OT para entornos empresariales e industriales. Escribe desde proyectos reales y sistemas en producción.
Ver perfil y todos sus artículos →