Solved

Changing Terminal Server/Remote Desktop listening port on Server 2008

Posted on 2014-01-02
10
1,488 Views
Last Modified: 2014-01-02
Two questions:
1. What is the best way to change the Terminal Server/Remote Desktop listening port on Windows Server 2008 and Windows Server 2012 from Port 3389 to something else?


2. Any recommendations on what port number to change it to or does it matter?

Thanks.
0
Comment
Question by:b1dupree
  • 3
  • 3
  • 3
  • +1
10 Comments
 
LVL 10

Accepted Solution

by:
convergint earned 167 total points
Comment Utility
Start Registry Editor.
Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\PortNumber
On the Edit menu, click Modify, and then click Decimal.
Type the new port number, and then click OK.
Quit Registry Editor.
Restart the computer.

http://support.microsoft.com/kb/306759

The better way to do it is to keep the existing port and then do NAT translation from WAN to LAN on your router (assuming it supports it) and use a high numbered random port.  If you are changing you can use any number up to 65535.
0
 
LVL 25

Assisted Solution

by:Tony Giangreco
Tony Giangreco earned 167 total points
Comment Utility
Yes, you can change the port to 3390 or possibly a much higher port, but hackers will still try scanning for open ports and try logging in.

If that is your problem, I suggest installing a Firewall like a Sonicwall TZ210 or 215. After that, setup port translation from a port like 15000 to 3389 or 3390 so hackers can't determine what port to use.  This is what I did for our 2008 R2 terminal/RDP Server and it worked very well.

If you just want to change the port, here is how to do it

http://www.techrepublic.com/blog/the-enterprise-cloud/changing-the-rdp-listening-port-on-windows-server/
0
 

Author Comment

by:b1dupree
Comment Utility
Thanks.  Can you confirm that SBS 2008 uses port 443 for Terminal Server traffic so if I do port translation on the SonicWall I forward the traffic from the new port (15000) that I created on the SonicWall to port 443 (secure web)?
0
 
LVL 56

Assisted Solution

by:Cliff Galiher
Cliff Galiher earned 166 total points
Comment Utility
SBS uses 3389 for RDP traffic just like any other OS when left to defaults.

SBS *does* include the RDGateway role (which is available as a standalone role with other server editions as well). The RDGateway role acts, as the name implies, as a gateway and allows a compatible and properly configured RDP client to request a machine behind the gateway. The actual RDP traffic is tunneled over 443 to the gateway, but then the gateway establishes the RDP connection via 3389 (including to SBS itself) as normal.

The RDGateway port *cannot* be changed, and attempting to do so will break other services that also rely on and use 443, such as RWA. As pointed out, port scanning is trivial so changing the listening port adds little to no security. Strong passwords and intrusion monitoring are a far better and more reliable defense.
0
 

Author Comment

by:b1dupree
Comment Utility
Okay.  So, on an SBS server, if I use Port Translation with the SonicWall am I forwarding traffic from the new port that I created on the SonicWall to port 443 or port 3389?
0
Top 6 Sources for Identifying Threat Actor TTPs

Understanding your enemy is essential. These six sources will help you identify the most popular threat actor tactics, techniques, and procedures (TTPs).

 
LVL 56

Expert Comment

by:Cliff Galiher
Comment Utility
That depends on what you are trying to accomplish.

If you *really* want to have your SBS server's RDP service exposed directly to the web, then you want to forward port 3389. This, however, is terribly insecure and not something I'd *ever* do. You'd be far better off using RWA to access the server, which uses the RDGateway service (so 3389 is never *directly* exposed) and has been hardened.

If you are trying to change the port that RWA (or more specifically RDGateway) uses, then the simple answer is that you can't. The RDGateway service and clients that understand RDGateway were both engineered to use 443 for a variety of reasons and therefore the port can't be changed. While you could configure the port forwarding rule and it wouldn't hurt anything, no client could ever use that rule so it be completely ineffective...except as another point of exposure for port scanners.

In short, I don't consider either option to be particularly useful or secure. You *should* forward port 443 externally to 443 internally (no custom port) and use RWA to access your server. That is both more secure and conforms to the standards that the services and clients expect. Additionally, basic monitoring (which you should have in place anyways, even if you were not forwarding any traffic) to alert you when an excessive number of authentication failures have occurred will help you handle any brute-force attacks.

 Regarding that last bit and security; brute force attacks *will* happen. If not against RDGateway or RWA, will still happen against OWA or the SMTP service if you expose it. You put a service on the internet, brute force attacks will occur. Unless you want to have no internet access whatsoever. The best you can do is mitigate the risk and the above suggestions go a long ways towards that. As always, the security landscape is one that is every changing as new attacks and new methods to block those attacks get developed (such as cryptolocker.) The above advice is, I believe, valid and accurate as of the time of this writing though and would be better than the alternatives you are considering.
0
 

Author Comment

by:b1dupree
Comment Utility
Yes, I understand that.

If I setup port forwarding with the SonicWall then port 3389 is no longer exposed.  I would shut down port 3389 on the SonicWall (thereby no longer exposing 3389) and I would create an alternate port on the SonicWall which would forward internally to 3389 or 443.  I just am not sure whether to forward internally from the alternate port (say 15000) to 3389 or 443 once it is inside the SonicWall.
0
 
LVL 56

Expert Comment

by:Cliff Galiher
Comment Utility
"I would shut down port 3389 on the SonicWall (thereby no longer exposing 3389)"

Why would you expose it in the first place. Sonicwalls, like most UTMs, are configured in a default-closed state. So if you don't *open* 3389 (and it isn't by default) then you have nothing to close. 3389 would not be exposed in a default configuration.

So now we are back to what you are trying to accomplish. Forwarding a custom port *opens* up a security hole. It doesn't close an existing one.
0
 
LVL 25

Expert Comment

by:Tony Giangreco
Comment Utility
You could close 3389 and open 15000. Then have all RDP users come into port 15000 useing this on the rdp cloent:

mydomain:15000

That works for us.
0
 
LVL 25

Expert Comment

by:Tony Giangreco
Comment Utility
correction:
My-IP-Addrerss:15000
my-domain\username
0

Featured Post

Too many email signature updates to deal with?

Do you feel like you are taking up all of your time constantly visiting users’ desks to make changes to email signatures? Wish you could manage all signatures from one central location, easily design them and deploy them quickly to users? Well, there is an easy way!

Join & Write a Comment

You might have come across a situation when you have Exchange 2013 server in two different sites (Production and DR). After adding the Database copy in ECP console it displays Database copy status unknown for the DR exchange server. Issue is strange…
A procedure for exporting installed hotfix details of remote computers using powershell
This tutorial will walk an individual through the steps necessary to join and promote the first Windows Server 2012 domain controller into an Active Directory environment running on Windows Server 2008. Determine the location of the FSMO roles by lo…
This tutorial will walk an individual through setting the global and backup job media overwrite and protection periods in Backup Exec 2012. Log onto the Backup Exec Central Administration Server. Examine the services. If all or most of them are stop…

763 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

11 Experts available now in Live!

Get 1:1 Help Now