b1dupree
asked on
Changing Terminal Server/Remote Desktop listening port on Server 2008
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.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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?
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.
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.
ASKER
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.
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.
"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.
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.
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.
mydomain:15000
That works for us.
correction:
My-IP-Addrerss:15000
my-domain\username
My-IP-Addrerss:15000
my-domain\username
ASKER