Windows optimize

Changing the RDP listening port on Windows Server

IT pro Rick Vanover shows how to change the default port that remote desktop listens on and make subsequent connections in order to make RDP more secure.

Remote desktop protocol (RDP) is the de facto administrative console access, and it may be necessary to make it even more secure by changing the TCP port used for the network access. RDP transports on TCP 3389 by default for all supported versions of Windows; if you want to change the port, it requires a quick change in the Windows registry.

(Note: Editing the registry is risky, so be sure you have a verified backup before saving any changes.)

The following hive has the specific TCP port used for RDP:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp]

In this hive, the PortNumber value contains the configured port that Windows will listen for RDP connections. The default port assignment is represented as D3D in hexadecimal or 3389 in binary. For this example, I will change the port to 53389. Figure A shows this change being made on a test server. Figure A

It may require a reboot to make the port assignment take effect (my Windows Server 2008 R2 test system did). Once the system is listening on the new port, connections need to specify the new port in the RDP client properties, as shown in Figure B. Figure B

The Windows Server system will now listen on the new port with the Svchost.exe process, visible in task manager by entering Netstat  -a -n -o to view the current processes and list the associated executable.

Have you had to change your RDP port to another port or possibly change it back? If so, share your thoughts about the experience in the discussion.

Stay on top of the latest Windows Server 2003 and Windows Server 2008 tips and tricks with our free Windows Server newsletter, delivered each Wednesday.

Automatically sign up today!

About

Rick Vanover is a software strategy specialist for Veeam Software, based in Columbus, Ohio. Rick has years of IT experience and focuses on virtualization, Windows-based server administration, and system hardware.

22 comments
pdiddyflex
pdiddyflex

Now I can enjoy unfiltered internet at work!

pkokkinis
pkokkinis

By enabling Remote Desktop, an exception is automatically added in Windows Firewall for port 3389. You'll want to disable or delete this rule and create a new exception for your new port.

Paul W
Paul W

Here is a VBS Script that does the same thing Set WshShell = CreateObject("Wscript.Shell") RDPPORT = wshshell.regread ("HKLM\system\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\PortNumber") strUserIn = inputBox("Enter Required port number","RDP listening Port Number",RDPPORT) if strUserIn "" then if IsNumeric(strUserIn) = "True" then If strUserIn > 0 and strUserIn < 65535 then WshShell.RegWrite "HKLM\system\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\PortNumber", strUserIn, "REG_DWORD" msgbox "Your RPD listening port is now " + cstr(strUserIn) + ". You will need to restart your machine for the change to take affect.",,"User Action Required" else msgbox "The port number you entered is out of range." end if else msgbox "That's not even a number." end if end if Set WshShell = Nothing

etafner
etafner

"... in order to make RDP more secure." There is NO SECURITY by OBSCURITY. There should be an article about using a protocol-level encryption by using certificates, NLA, host trust and other security factors, not this. Me and most people on the Windows community recommend that if you need to to something at Registry level, what means that you don't have an interface to do that, you should be doing it at all. I'm totally against this article, this is my opinion and my experience. Please don't get me wrong.

LocoLobo
LocoLobo

When I remote in from another desktop on the same network, does it have to be calling on that port?

b4real
b4real

Each time I did this, I forgot about the change. Not sure how to best 'remember' this type of change except a blanket standard or tier / security zone that needs a different port.

uberg33k50
uberg33k50

"...most people on the Windows community...". Most Windows Network Administrators I know edit the registry. Even Microsoft tech articles have many references to editing the regestry. Of course if you mean users -- yeah they should probably not edit the registry.

systems
systems

If you have a NAT'd network with multiple servers/workstations you need to access that is why you do this. And while "Security by Obscurity" is not very valid, most port scans do not scan EVERY port so if you did do a high port you might avoid some scans. And for those who believe you need a gui to do systems work, well I guess you only work with windows. Even MS disagrees with this as they promote Powershell.

kleclair
kleclair

I agree with etafner on this one. Give us protocol-level encryption or certs. It is simple really. If the user manipulates the registry for "security" purposes, an intruder can do the same to weaken security. Where is the advantage really? A simple TCP/IPview will reveal what port the host you are trying to Remote to is using. I just do not see any advantages to why you would do that.

clevernickname
clevernickname

In the interest of making certain I understand your logic... Changing native port values is pointless and unless there is a gui mechanism to make the change, don't do it?

jc2it
jc2it

I agree with etafner this article was a waste of time. If you want to learn about security then you need to learn how to break in to stuff. Good Luck. Six months from now you will be reinstalling the OS so you can "fix" your "broken" RDP server.

michael
michael

I agree that there is no security by obscurity. Having said that, I do think that changing the RDP listening port is a wise thing to do, as a *first step* to securing remote access. I get many port scans on port 3389, and they're looking for a server with RDP on the default port on which they can then try breaking into using popular, insecure passwords. By using a different port, it makes it just a bit harder for them. However, no system admin should think that it makes the server totally secure. A few other comments for admins who want to do this: first, search Google for a list of TCP ports, and make sure you choose one which is unused. Second, whatever port you choose, make sure to setup port forwarding on the router/firewall so it will work from outside the network (if that's what you want). Third, document it, so you'll remember what port you're using! -Michael

b4real
b4real

Basically, connect as HOSTNAME:NewPort where "NEWPORT" is the new TCP/IP Port you've designated on the server. But that is only for use in the client -> MSTSC. The registry settings on the client (where you are connecting from) do not need to be changed.

etafner
etafner

Sure, editing the Registry is a common practice, but usually to solve problems and not for configuration. On the beginning of each Microsoft article the would point out of editing the Registry, there is a big warning about doing it. There is a lot of complications if you do it wrongly and a lot of side effects. They are non-manageable changes, so these changes might revert to default values and so on. I did a lot of that on the past and from my experience I can tell, for sure, that software design counts: if there is no interface for that, you shouldn't be touching it. At some point, a very experienced Windows administrator would realize that if you need to change something on the Registry, there might be a way to do it manageably, via GPOs or a interface that might take care of that. If you are doing something at this very low level, there are three options: that setting is present somewhere on a User Right, Group Policy Object or you should be tinkering with it all. Or you're trying to fix a problem, which might be a bug. But we are missing the point. I have to say that I missed the point when I raised the discussion about changing things at Registry level and I'm sorry for that, that's another discussion. The question at hand is: if the software protocol is not secure enough, maybe it needs an update or configuration. Just changing the port to another one won't do any good, the port signature (how it would respond after opening a connection to it) would easily detect that it's the RDP service that is running on there. Maybe no mistake: changing the port address is not the way to make a service secure.

Beoweolf
Beoweolf

This is (was) not just a practice to obscure Port addresses, it was used to allow the transition from early versions of Exchange (5.0/5.5) which used used LDAP on NT ... to run on AD based windows2000 and later OS. Early exchange listen on port 389 - AD communicated on port 389; Conflict was resolved by moving exchange to another port, usually 3389. The problem of passing on environment changes was easily fixed by maintaining a list of exceptions (a run book) borrowed from Mainframe days. Any non-standard changes made to an Network were document, (date, time and initialed by reponsible part, which included reason for change). If possible you would also include an end date or condition for removeing the change. There is a case for doing things not built into the OS - it was called system administration.;) http://support.microsoft.com/kb/q224447/

etafner
etafner

Sorry, I mixed two things on a try to clarify my argument, which is still valid, anyway. I put a response to another commenter below, please take a look on that.

Joshua1
Joshua1

You lock your door even though thieves can still get past a lock. When you put an alarm on your house, an expert thief can still bypass it. We still do these things b/c it does mitigate/eliminate some would-be problems. When you get your home router and set up WPA2 with upper,lower,numbers,symbols in your key, and mac filters implemented, and supressed SSI - we do not leave the default settings in place. We further secure it by obscuring the network - changing the defaults. The default RDP port is no different. You can change it, not as an entire answer to security, but as 1 part of reducing risk for your company. Forgetting your new port number poses no more of a problem than forgetting a password, yet we don't set all our passwords to "password" so they're easy to remember. (Obviously, changes to servers and networks should be documented, backed up, and shared).

b4real
b4real

You could make the argument that it is LESS secure to obscure ports. Take the key terms of security for technology: Confidentiality, Integrity, Availability. Obscuring ports violates the 'integrity' of the service. When is it right to use? I'm not sure - so the next question is why did you write this then? The time it makes sense (FOR ME) is for NAT/port translation. A front end IP address with some RDP traffic going to this host over 3389 and other hosts receiving RDP traffic over another port. That, to me, is the only legit use case.

rfolden
rfolden

And don't forget to change the value in the 2003/2008 "remote web desktop" page, typically located at http:///tsweb, as I don't think it is changed automatically. The value by default in "default.htm" is MsRdpClient.AdvancedSettings2.RDPPort = 3389 Change it to your liking.

EdGallagherMVP
EdGallagherMVP

Changing the default port number has virtually no impact on security any more. It may have helped at one time, but port scanners have made this pretty useless. Yes, thieves can get through a lock, but this is no lock. It is more like just painting the door another color.

Joshua1
Joshua1

If RDP via the 'Net is required, I would definitely change that port number. (IPSEC VPN and then RDP would be better). A lot of attacks come from internal sources, so I see no reason not to change the internal port - it doesn't hurt anything. A junior tech can learn a new port number pretty easily.

eositis
eositis

Port changes such as this should only be done at the external firewall level, if at all. Inside the firewall, your system should be running a standard, but secure, configuration. When the system kicks the bucket, the junior tech must be able to quickly confirm the system works correctly internally. If it works correctly internally and not externally, you know where the problem lies. (duh, firewall!) If you are concerned about inside security, rather than obscuring ports, you should have your servers in a separate vlan/ip address space, behind a firewall, from the users you are worried about. Finally, in a high security configuration, you should not have the secure system's ports open to a public network at all. Access should only be via an intermediary (DMZ) machine, from which you open a second connection to the inside machine/network. The intermediary machine (inside the dmz) can have its rdp port obfuscated, but even better would be to only permit access to the intermediary with an encrypted vpn tunnel. These days, with virtualisation available at the drop of the hat, it is even possible to implement the entire infrastructure within a VM host.