Teníamos un puerto abierto recibiendo 158,000 ataques al día. Decidimos no cerrarlo todavía

Una empresa manufacturera tenía el escritorio remoto de su servidor publicado directamente a internet. Ese servicio recibía, medido, alrededor de 158,000 intentos de acceso fallidos por día.

La recomendación de manual es de una línea: ciérralo hoy.

No lo cerramos. Y sostengo que fue la decisión correcta.

Qué había del otro lado del puerto#

Antes de cerrar nada, contamos quién lo usa. query session en el servidor, durante varios días, a distintas horas:

SESIÓN        USUARIO           ESTADO
rdp-tcp#2     cuenta-a          Activo
rdp-tcp#4     cuenta-b          Activo
rdp-tcp#5     cuenta-c          Activo
rdp-tcp#7     cuenta-d          Activo
rdp-tcp#9     cuenta-e          Activo

Cinco personas trabajan por ahí todos los días. Contabilidad, planta, administración. Ese puerto no era un descuido olvidado de una migración vieja: era la puerta principal de media empresa.

Cerrarlo ese martes tenía un resultado perfectamente predecible. El miércoles, cinco personas sin poder trabajar. El jueves, alguien con autoridad y con prisa exige que se restablezca. El viernes el puerto está abierto otra vez —abierto de emergencia, sin las mitigaciones, sin registro de quién lo abrió ni por qué— y encima nadie vuelve a confiar en la siguiente recomendación que hagamos.

La seguridad que interrumpe la operación no dura 48 horas. Y no se revierte por ignorancia: se revierte porque la empresa tiene que facturar.

El reflejo que hay que discutir#

Existe una idea muy extendida de que la medida más agresiva es la más profesional. Que quien cierra rápido es riguroso y quien espera es blando.

Es al revés. Cerrar un puerto es trivial —una regla de firewall, treinta segundos—. Lo difícil es construir la vía nueva, probarla en cada equipo, y solo entonces cerrar la vieja. Eso toma días y no luce.

Un cierre que se revierte en tres días no bajó el riesgo: lo subió. Terminas con el mismo puerto abierto, sin la mitigación temporal que tenías, y con un equipo directivo convencido de que la seguridad es un estorbo.

La complicación que casi nadie ve venir#

Había un agravante en este caso, y vale la pena porque se repite en muchos.

La empresa ya tenía una red privada instalada. La opción obvia era usar esa red para todo y cerrar el puerto de inmediato.

Solo que esa red privada era también la vía por la que nosotros administrábamos el servidor. Su administración estaba atada a una cuenta de correo que el proveedor de identidad había inhabilitado, así que nadie podía tocarla, agregar equipos ni renovar nada. La red seguía funcionando; simplemente ya no se podía administrar.

Eso deja una situación incómoda: la vía de rescate y lo que hay que migrar son la misma cosa. Si algo sale mal durante la migración, la herramienta con la que arreglarías el problema es justamente la que dejó de existir.

El puerto abierto —el problema— era al mismo tiempo la única red de seguridad. Cerrarlo antes de tener la vía nueva probada no era arriesgado: era quedarse sin manos.

El orden que seguimos#

Escribirlo como secuencia numerada no es burocracia. El orden ES la medida de seguridad, y saltarse un paso invalida los anteriores.

1. Levantar la vía nueva sin tocar la vieja. El túnel nuevo se instaló como un servicio aparte, con su propia carpeta y su propia configuración, junto al que ya corría. Durante toda la maniobra se estuvo midiendo el tiempo de respuesta del sistema productivo: entre 742 y 760 milisegundos, sin una sola interrupción. Un servicio nuevo no debe poder tumbar a uno viejo.

2. Probarla con una persona real. No con un ping. No con un puerto que responde. Con alguien abriendo su sesión y trabajando. Un puerto que contesta y una sesión que funciona son dos afirmaciones distintas, y solo la segunda importa.

3. Migrar equipo por equipo, verificando cada uno. Cinco personas, cinco confirmaciones. No "ya quedó configurado": entró y trabajó.

4. Cerrar el puerto. Hasta aquí, y no antes.

5. Retirar la vía anterior. Al final, cuando ya no sea la red de seguridad de nadie.

Hoy vamos en el paso tres. El puerto sigue abierto, con las mitigaciones puestas y con una fecha comprometida de cierre.

La diferencia entre esperar y postergar#

Un puerto abierto "temporalmente" tiene una tendencia bien documentada a seguir abierto tres años. Por eso esperar solo es defendible bajo tres condiciones, y conviene exigirlas:

Que el riesgo esté medido, no supuesto. Aquí sabemos el número exacto de intentos diarios, de dónde vienen y contra qué cuenta van. Sabemos que ninguno ha entrado, y cómo lo verificamos.

Que haya mitigación mientras tanto. El puerto no está desnudo: la cuenta objetivo de los atacantes no existe con ese nombre, el servicio no está en su puerto habitual, y el conteo de intentos corre solo y avisa si el patrón cambia.

Que exista fecha, y que la fecha sea de alguien. No "cuando se pueda". Un compromiso con nombre y día.

Sin esas tres, esperar no es criterio. Es postergar con vocabulario técnico.

Lo que queda como regla#

Antes de cerrar cualquier acceso, cuenta quién lo está usando. Casi siempre son más de los que la lista dice, y suelen ser gente que factura.

La vía nueva se prueba con una persona trabajando, en cada equipo, antes de tocar la vieja.

Y si la vía de rescate es la misma que vas a migrar, ese es el primer problema a resolver — no un detalle del plan, sino el plan entero.

Caso real de una empresa manufacturera. Se omitieron nombres de cuentas, direcciones internas y todo dato que permita identificar a la empresa.