¿A qué puerto debo mover RDP?

A cualquiera libre por encima de 10000 — 34519, 47820, el que esté disponible. Evita puertos que reclamen servicios conocidos, ya que los escáneres los sondean específicamente, y evita el 3390, que es lo primero que prueba cualquiera después del 3389. Confirma con Get-NetTCPConnection que nada está escuchando antes de comprometerte.

¿Cambiar el puerto RDP rompe los clientes de Escritorio remoto?

No, pero ahora cada cliente debe indicar el puerto: server:34519 en el campo de equipo, o mstsc /v:server:34519. Los archivos .rdp guardados y los gestores de conexiones conservan el puerto antiguo y fallarán hasta que se actualicen. Los firewalls corporativos que permiten el 3389 saliente pueden bloquear el nuevo puerto por completo, que es la queja más habitual tras el cambio.

¿Es seguro exponer RDP en un puerto no estándar?

Es exactamente igual de seguro que en el 3389, con menos ruido de fondo. El puerto no es un control de acceso: el servicio se identifica por su saludo inicial, y Shodan indexa RDP en puertos no estándar de forma continua. La seguridad viene de lo que gestiona los intentos, no de dónde llegan.

¿Cambio el puerto o simplemente bloqueo las IP atacantes?

El bloqueo es la defensa; el cambio de puerto es higiene que hace legible tu registro. Si solo vas a hacer una cosa, bloquea. Hacer ambas es mejor que cualquiera de las dos: llegan menos intentos, y los que llegan se detienen antes de que Windows gaste nada en ellos.

Cambiar el puerto RDP 3389: qué arregla y qué no

Sacar RDP de su puerto por defecto reduce muchísimo el volumen de ataques y no protege de casi nada. Conviene entender ambas mitades antes de hacerlo.

6 min de lecturaActualizado el 2026-08-26

El resumen honesto

Mover RDP fuera del 3389 recortará tu volumen de inicios de sesión fallidos en torno a un 90% de la noche a la mañana. También es cierto que no es un control de seguridad, y tratarlo como tal es la forma en que se comprometen servidores de administradores que creían haber terminado.

Ambas afirmaciones son ciertas porque responden a preguntas distintas. La caída de volumen es real, medible y útil. La protección es prácticamente nula frente a cualquiera que dedique treinta segundos a mirar.

¿Merece la pena? Normalmente sí — como reducción de ruido, además de una defensa, nunca en lugar de una.

Lo que sí detiene

La inmensa mayoría del tráfico de ataque RDP viene de escáneres no dirigidos que hacen una sola cosa: conectarse al puerto 3389 a lo largo de grandes rangos de IP y probar contraseñas en lo que responda. No escanean puertos. Escanear 65.535 puertos en cada dirección cuesta órdenes de magnitud más que comprobar uno, y hay suficientes máquinas en el 3389 como para que no compense.

Múdate al 34519 y sales por completo de esa población. La gráfica se desploma, el registro de seguridad deja de rotar cada pocas horas, y volver a encontrar un evento real en él pasa a ser posible.

Ese último punto está infravalorado. Un registro de eventos que se puede leer vale dinero durante un incidente, y con tres mil fallos al día no tienes uno.

Lo que no detiene

Cualquiera que escanee todo el rango de puertos te encuentra en minutos. RDP se identifica trivialmente por su saludo inicial independientemente del puerto, así que un escáner que recorra todos los puertos y tome huella de lo que responda etiquetará tu servicio correctamente a la primera.

Shodan y Censys hacen exactamente eso de forma continua, en todo internet, y publican los resultados como un índice consultable. Tu puerto RDP no estándar está ahí, localizable por cualquiera, a los pocos días de abrirlo.

Así que frente a un bot no dirigido, cambiar el puerto funciona. Frente a alguien que te ha elegido — un competidor, un exempleado, un operador de ransomware recorriendo la lista de empresas de un sector — le cuesta unos minutos. Y no hace absolutamente nada contra contraseñas débiles, SMB expuesto, un host sin parchear o credenciales filtradas en otro sitio.

También hay un inconveniente activo: los puertos raros rompen cosas. Los firewalls corporativos que permiten el 3389 saliente bloquearán el 34519 saliente, y te enterarás por un usuario que no puede trabajar.

Cómo cambiarlo sin dejarte fuera

El puerto vive en el registro, y hay que informar al Firewall de Windows antes de reiniciar el servicio — en ese orden, o te desconectarás de una máquina a la que solo llegas por RDP.

Elige un puerto por encima de 10000 que nada use, verifica que está libre, ábrelo y solo entonces cambia:

powershell

$NewPort = 34519

# 1. Confirmar que nada está escuchando ya ahí.
Get-NetTCPConnection -LocalPort $NewPort -ErrorAction SilentlyContinue

# 2. Abrirlo en el firewall PRIMERO, antes de que el servicio se mueva.
New-NetFirewallRule -DisplayName "RDP-$NewPort" -Direction Inbound `
  -Protocol TCP -LocalPort $NewPort -Action Allow

# 3. Apuntar Terminal Services al nuevo puerto.
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name PortNumber -Value $NewPort

# 4. Reiniciar el servicio (esto corta tu sesión actual).
Restart-Service TermService -Force

Después

Conéctate indicando el puerto explícitamente — mstsc /v:server:34519 — y actualiza todo lo que guardaba el antiguo: archivos RDP guardados, gestores de conexiones, comprobaciones de monitorización, configuraciones de jump-host, la documentación de tu equipo. Luego elimina o restringe la antigua regla de permiso del 3389, o no habrás ganado nada.

No borres la regla antigua antes de confirmar que el puerto nuevo funciona desde fuera de tu red. Dentro de la LAN todo funciona igualmente, que es exactamente como la gente se convence de que va bien.

Con qué combinarlo

Cambiar el puerto reduce el ruido. Algo tiene que seguir gestionando los intentos que llegan — y tras un cambio de puerto, los que llegan son de alguien que te buscaba específicamente, que son precisamente los que te importan.

Eso significa las mismas tres cosas de antes: vigilar los inicios de sesión fallidos, banear los orígenes que crucen un umbral, y no caer nunca en tu propio baneo. RDP Protector detecta el puerto RDP real desde el registro y los sockets en escucha en vez de asumir el 3389, así que un servidor que se ha movido queda cubierto sin configurar nada — y reconstruye sus reglas automáticamente si el puerto vuelve a cambiar.

Cambia el puerto para tener un registro legible. Mantén una defensa para el tráfico que te encuentra igualmente.

FAQ

¿A qué puerto debo mover RDP?: A cualquiera libre por encima de 10000 — 34519, 47820, el que esté disponible. Evita puertos que reclamen servicios conocidos, ya que los escáneres los sondean específicamente, y evita el 3390, que es lo primero que prueba cualquiera después del 3389. Confirma con Get-NetTCPConnection que nada está escuchando antes de comprometerte.
¿Cambiar el puerto RDP rompe los clientes de Escritorio remoto?: No, pero ahora cada cliente debe indicar el puerto: server:34519 en el campo de equipo, o mstsc /v:server:34519. Los archivos .rdp guardados y los gestores de conexiones conservan el puerto antiguo y fallarán hasta que se actualicen. Los firewalls corporativos que permiten el 3389 saliente pueden bloquear el nuevo puerto por completo, que es la queja más habitual tras el cambio.
¿Es seguro exponer RDP en un puerto no estándar?: Es exactamente igual de seguro que en el 3389, con menos ruido de fondo. El puerto no es un control de acceso: el servicio se identifica por su saludo inicial, y Shodan indexa RDP en puertos no estándar de forma continua. La seguridad viene de lo que gestiona los intentos, no de dónde llegan.
¿Cambio el puerto o simplemente bloqueo las IP atacantes?: El bloqueo es la defensa; el cambio de puerto es higiene que hace legible tu registro. Si solo vas a hacer una cosa, bloquea. Hacer ambas es mejor que cualquiera de las dos: llegan menos intentos, y los que llegan se detienen antes de que Windows gaste nada en ellos.