Solved

Changing Terminal Server/Remote Desktop listening port on Server 2008

Posted on 2014-01-02
10
1,610 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
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
  • 3
  • 3
  • +1
10 Comments
 
LVL 10

Accepted Solution

by:
convergint earned 167 total points
ID: 39751923
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
ID: 39751938
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
ID: 39751953
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
Forrester Webinar: xMatters Delivers 261% ROI

Guest speaker Dean Davison, Forrester Principal Consultant, explains how a Fortune 500 communication company using xMatters found these results: Achieved a 261% ROI, Experienced $753,280 in net present value benefits over 3 years and Reduced MTTR by 91% for tier 1 incidents.

 
LVL 58

Assisted Solution

by:Cliff Galiher
Cliff Galiher earned 166 total points
ID: 39751968
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
ID: 39751987
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
 
LVL 58

Expert Comment

by:Cliff Galiher
ID: 39752033
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
ID: 39752050
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 58

Expert Comment

by:Cliff Galiher
ID: 39752086
"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
ID: 39752110
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
ID: 39752112
correction:
My-IP-Addrerss:15000
my-domain\username
0

Featured Post

How our DevOps Teams Maximize Uptime

Our Dev teams are like yours. They’re continually cranking out code for new features/bugs fixes, testing, deploying, responding to production monitoring events and more. It’s complex. So, we thought you’d like to see what’s working for us. Read the use case whitepaper.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

I was supporting a handful of Windows 2008 (non-R2) 2 node clusters with shared quorum disks. Some had SQL 2008 installed and some were just a vendor application that we supported. For the purposes of this article it doesn’t really matter which so w…
OfficeMate Freezes on login or does not load after login credentials are input.
This tutorial will walk an individual through configuring a drive on a Windows Server 2008 to perform shadow copies in order to quickly recover deleted files and folders. Click on Start and then select Computer to view the available drives on the se…
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles to another domain controller. Log onto the new domain controller with a user account t…

738 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