Cerramos el puerto por el que entraban 145,000 ataques al día. No estaba donde creíamos, y el firewall no servía.

Una empresa nos autorizó cerrar la puerta por la que su servidor recibía 145,000 intentos de entrada al día. Parecía media hora de trabajo. Fueron cuatro, y la mitad se fue en descubrir que casi todo lo que suponíamos era falso.

Vale la pena contarlo con los tropiezos incluidos, porque el resultado limpio esconde justo lo que hace difícil este trabajo: lo que está escrito en la configuración no es lo que el sistema hace.

Antes de los comandos, una imagen que sirve para todo el artículo, porque la usamos nosotros mismos para no perdernos. Piense en la empresa como un edificio:

• El edificio tiene una sola dirección en la calle — la dirección con la que la empresa aparece en internet. Una, para decenas de computadoras adentro.
• En la entrada hay una recepción que reparte lo que llega y decide qué pasa. Ésa es la caja que da el proveedor de internet.
• El servidor es una oficina dentro del edificio, la 173.
• Y la oficina tiene su propia puerta con cerradura — que es el firewall del servidor, cosa distinta de la recepción.

Con eso en mente, los tres errores del día se cuentan solos.

La foto de la que partimos#

$d = (Get-Date).AddHours(-6)
(Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=$d}).Count
12489
(Get-WinEvent -FilterHashtable @{LogName='Security'; StartTime=$d}).Count
17159

Siete direcciones, siempre las mismas, probando un solo nombre de usuario. Llevaban meses. El plan era simple: cerrar el puerto por donde entran, medir que pararon, listo.

Primer error: no era el puerto que decía el manual#

El acceso remoto de Windows vive, por defecto, en el puerto 3389. Todo el mundo lo sabe, nosotros incluidos. Así que empezamos por ahí, cerrando con cuidado las reglas del 3389.

No cambió nada. Los ataques seguían, al mismo ritmo. Fuimos a preguntarle al sistema en vez de al manual:

(Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp').PortNumber
8088

Los 50,000 intentos diarios son la prueba de que mover el puerto no esconde nada: los escáneres prueban los 65,000 puertos, no sólo los famosos.

Segundo error: el firewall no bloqueaba nada#

Bien, el puerto es el 8088. Desactivamos sus reglas de "permitir". Y los atacantes seguían conectándose, con conexiones nuevas creadas segundos después de desactivarlas.

Ahí entendimos lo de fondo:

Get-NetFirewallProfile | Select-Object Name, DefaultInboundAction
Domain    NotConfigured
Private   NotConfigured
Public    NotConfigured

En la imagen del edificio: la puerta de la oficina 173 no tenía cerradura. No es que estuviera mal cerrada — es que aceptaba a cualquiera que girara la manija, y las "reglas de permitir" eran letreros de bienvenido pegados en una puerta que de todos modos abría sola.

Lo comprobamos midiendo, no suponiendo. Bloqueamos una sola de las siete direcciones y contamos:

New-NetFirewallRule -DisplayName prueba -Direction Inbound -Action Block -RemoteAddress 109.205.211.106 -Enabled True

$d = (Get-Date).AddMinutes(-3)
(Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=$d} | Where-Object { ([xml]$_.ToXml()).Event.EventData.Data.Where({$_.Name -eq 'IpAddress'}).'#text' -eq '109.205.211.106' }).Count
0

Con eso, la regla correcta, que en la imagen es sencilla: ponerle cerradura a la puerta de la oficina, con llave para quien trabaja adentro del edificio y para quien entra por el túnel de la empresa, y cerrada para todos los de la calle. En comandos: bloquear el 8088 para todo lo que no sea la red local ni el túnel.

$publico = @('1.0.0.0-9.255.255.255','11.0.0.0-99.255.255.255', ... )
New-NetFirewallRule -DisplayName bloquear-8088-internet -Direction Inbound -Action Block -Protocol TCP -LocalPort 8088 -RemoteAddress $publico -Enabled True

Tercer error: confundimos tres aparatos que eran uno#

Mientras tanto, discutíamos dónde cerrar de verdad: ¿en la puerta de la oficina, o abajo, en la recepción del edificio? Y ahí nos hicimos bolas con tres palabras que la gente usa como si fueran cosas distintas — pero que en la imagen del edificio son funciones de la misma recepción:

• Módem: traduce la señal del proveedor a red normal.
• Router: reparte esa red entre los equipos y decide qué entra de afuera.
• Firewall: inspecciona y bloquea.

En las casas y en la mayoría de las empresas, las tres son la misma caja — la recepción del edificio hace de módem, de router y de firewall al mismo tiempo. Nosotros discutíamos como si hubiera tres recepciones. Fuimos a identificar la caja real en vez de seguir adivinando:

openssl s_client -connect 192.168.1.254:443 </dev/null 2>/dev/null | openssl x509 -subject -noout
subject=CN=TELMEX, OU=..., O=ZTE, L=Nanjing, C=CN

Y de paso corrigió una suposición nuestra: por unas cabeceras de seguridad en su panel, habíamos dicho "esto parece un firewall de empresa". No lo era. Era el firmware reciente de un módem común. La empresa no tiene firewall — lo cual, dicho sea de paso, hace legítimo que alguien se lo quiera vender, con la advertencia de siempre: un firewall que nadie vigila es un gasto, no una defensa.

Lo que quedó, y lo que no#

Quedó: la puerta cerrada del lado que controlamos —el servidor—, con la prueba de que los ataques pasaron de 145,000 al día a cero, y sin que nadie perdiera acceso.

No quedó: cerrar también, allá abajo en la recepción, la instrucción que dice "lo que llegue marcado 8088, súbelo a la oficina 173". Ésa es la que sigue dejando pasar el tráfico hasta la puerta — sería el segundo candado. Llegamos a su panel por un túnel, desciframos su forma de login, y ahí paramos: la contraseña impresa en la etiqueta —la del WiFi— no abre la administración. Y no vamos a adivinar contraseñas contra el equipo de un cliente. Ese dato lo pide el dueño a su proveedor; no es nuestro para forzarlo.

Que falte ese segundo candado no es grave, y ésa es la parte tranquilizadora: la puerta de la oficina ya tiene cerradura, así que aunque la recepción siga subiendo cartas, se topan con una puerta que no abre. Pero lo dejamos anotado con nombre, no disimulado. Un pendiente que se declara es trabajo; uno que se calla es una sorpresa esperando fecha.

Lo que se llevó uno de este día#

Tres veces, en la misma tarde, chocamos con lo mismo: una cosa estaba configurada y no aplicaba. El puerto movido que los manuales no conocían. El firewall que "tenía reglas" y no bloqueaba. El límite de sesión —otro hallazgo del mismo día— puesto en la política de dominio de una máquina que no está en dominio, así que nunca corrió.

La lección no es técnica. Es que revisar que algo esté configurado no sirve de nada; hay que medir que esté haciendo su trabajo. Un firewall con reglas puede no filtrar. Un puerto "cerrado" puede estar abierto en otro número. Una contraseña impresa en una etiqueta puede no ser la que manda. La única forma de saberlo es la misma cada vez: pedirle al sistema que demuestre lo que hace, y contar el resultado.

Caso real, anonimizado. Las direcciones de los atacantes son reales —son infraestructura de ataque, no de nadie—; las cifras se midieron en el servidor. La marca del módem se nombra porque es una herramienta de consumo masivo, no un dato del cliente.