How do YOU secure your RDP/Terminal Services?

[Prophecy]

Securing RDP/Terminal Services.

• Change the listening port on the server
  
• Enable Encryption
  
• Enable tunneling
  
• Enable policies for excess logins
  
• Enable MAC Filter/IP/Filtering/Time of Day filter
  

But what I want to know is how do YOU do it? What article did YOU follow? What methods do you feel are the most secure? I am just asking because I am writing a new security policy that I will deploy to numerous locations and I am looking for the most up to date source of information. Or perhaps the best written FAQ,Article for creating a well secure Terminal Services session.

Thanks

-proph

[sc302 Veteran]

I don't like exposing 3389 to the internet. vpn in then rdp.

Think of it like this everyone and their mother has a windows xp and above computer. rdp comes with it. there are plenty of brute forcers that will try to crack the administrator account (which by default has remote desktop enabled, sure you can lock it down but what is going to stop the brute forcer from trying one of your other accounts esp if it is a shady or ex employee. vpn, disable their account if they leave, end of story esp if you use a RADIUS server for auth.

[Guest]

Hamachi -> RDP

[Prophecy]

Yah SC302. I know that method. I was just looking for a more detailed policy suggestion. I am in the process of changing ports and utilizing VPN Tunnels to connect. I am just looking for an article so I can reference or check list my work ya know? I am working on my permissions and log out policies and so forth.

Thanks

[Raa]

I keep a secure password. That's it.

[+BudMan MVC]

Secure RDP to what and from where? Are you going to open it up to the public - or do only people on the local network have access?

As to changing the port, that is NOT a valid security method -- "security through obscurity is not security"!!

You/We need to understand what your wanting to secure it against, before we can suggest appropriate measures to take.

[Prophecy]

Secure RDP to what and from where? Are you going to open it up to the public - or do only people on the local network have access?

As to changing the port, that is NOT a valid security method -- "security through obscurity is not security"!!

You/We need to understand what your wanting to secure it against, before we can suggest appropriate measures to take.

Bud, I will be securing it mainly through the following methods. Enabling encryption, changing the port, enabling a VPN tunnel. Yes it will be opened to the outside world. This is a Terminal server. I am more interested in how you guys do it. How you are locking it down and what methods or articles you use.

[+BudMan MVC]

Why do you feel you need to change the port, if your forcing vpn connecting to access.. VPN pretty much is a given that the tunnel is encrypted, so why do you feel you need to encrypt the actual rdp traffic again -- its already inside an encrypted tunnel. And does not matter what port its listening on since they won't be able to get to it unless they are using the vpn.. So changing the port just makes it harder for you - extra config on the server, and then extra work for the users having to remember to use a different port.

Are you worried about someone sniffing the traffic after your vpn endpoint? Are you worried about local users accessing that should not?

So again I ask -- Who/What are you wanting to secure it against.. If you worried about external access, then the VPN is all you really need.. If you worried about hiding it from local users, then ok could change the port -- this does not prevent it from being found.. Just prevents idiots that don't know any better from popping up their rdp client and putting in the name or ip of the server.

Encrypting it will prevent what exactly on your local network? Do you have people of enough skill to be sniffing your switched traffic -- might want to look into securing that ;)

If you want to know how its commonly done.. Only authed users would have the correct username and password to rdp any server, if outside the network you would need to vpn in -- thats pretty much it. Changing the ports and forcing encryption don't really buy you much, and just make the setup more complex. For starters with forced encryption is possible the users client, might not be able to access it and if over a vpn your double encrypting if you ask me.

What type of environment are you in that username and password is not enough to secure it? Blocking local IPs, forcing encryption, changing ports is just added overhead for your administration if you ask me.. Which is fine if you have the man power to handle it ;) Most companies run their IT very understaffed so stuff like this is just adding to their workload with not much added security, now if you have a specific threat your worried about that you need to mitigate then sure it could be cost justified.. But in the real world, when you have 1 guy maintaining 50 servers and 400 users - these extras are hard to cost justify if you ask me.

Now in a perfect world you would have acls between clients and your servers only allowing traffic to specific ports from specific users -- and Im sure everyone in IT would love to be able to maintain such high standards, but this rarely the case in the real world.. You secure your resources and assets with the most cost effective means that require the least effort to meet your security goals and mitigate the most likely threats.. You don't go over the top unless their is some specific requirement - I feel you creating a policy that may call for unwarranted requirements that will just make your life harder in the long run and not really give you much bang for you buck other than overhead.

[Packet1009]

Pretty much everything the man said above.

If you're looking for something to put in a document as a blanket/cover-all statement:

1. Encryption (TLS)

2. VPN

3. Two-factor Auth

EDIT: nearly forgot

4. Leverage current technology (windows 2008) for a TS gateway setup where you only expose 443 to the world

[sc302 Veteran]

How am I locking it down. For one not exposing 3389 or changing the port to whatever and enabling that port through the firewall. You want to hit my terminal server, come in through an encrypted vpn client that I have have given you access through, then you can get to my terminal server. At that point there really is no need to encrypt anything else as everything on the network is trusted. Give the vpn'd users their own network so they don't have access to anything else other than the ts and themselves. Not really a whole lot else to secure after that, nor is there really a point. You could encorporate a changing password token like secure+ if you want even more security and the lack of a chance for someone to simply bruteforce in.

This is how a user would connect:

VPN, which encrypts the traffic over the internet to your endpoint, rdp to the terminal server, which has no open outside ports. Encrypted and secured. The end user has to auth to the vpn, then they have to auth on the ts.

Really it is that simple, and this is how we secure our Police users that have access to sensitive criminal databases. This coensides with the policies handed to them to be secure.

[Vice]

As to changing the port, that is NOT a valid security method -- "security through obscurity is not security"!!

Whist I agree that obscurity is not security I do believe that obscurity should be used as a first step in a much larger security response. For example I used to run an FTP server on port 21 and a VNC server on ports 5800 and 5900. I also had SSH on port 22. This is a very normal setup.

Every day the FTP would get 20-30+ attempted connections from bots trying many different passwords and username combos. That's fine because the FTP server only allowed 3 attempts from an IP for a 48 hour period. The VNC server had a similar situation but to a much lower degree and SSH access was similar to the FTP in attempts.

Now as an experiment I decided to move all the services to port number ranges around 3000-3500. And you know what happened? No attempts. For over 12 months now not a single attempt on any of these services have been made.

What should I take away from this? Well I'd say that many automated bots that are randomly trying every IP Address for services are not scanning each host before they attempt to connect. They aren't going up and down all the possible ports on a system to work out where you've hidden your services. They are only trying the default ports. 21, 22 and so on. The attackers have obviously come to the conclusion that they can spend less computer time trying the default ports and moving on to a new IP than they can scanning all 1 to 65535 port numbers on every system that registers the default ports as closed or non-responsive.

Now again I am no way no how advocating 'Change your port numbers that's good enough' that is exactly what I am NOT saying. All I'm saying is, change em and stop the automated bots. People that know 100% you have services running and have a vested interest in getting inside will always find those open ports they will always find them. But the bots aren't even looking.

Imagine a scenario where the FTP server you use has a flaw that can be exploited remotely and within 24 hours hundreds of thousands of FTP servers operating on port 21 are taken over. But your one wasn't just because you moved it up 3 port numbers. If you have the choice to make a simple change like this and even if it makes one attacker (automated or otherwise) give up it was successful and worth the change in my opinion. And again I am only advocating this as part of an overall package not as a single thing to do and forget about security.

[+BudMan MVC]

As you clearly pointed out -- you did not actually make your ftp server more secure by changing its port now did you. So my point still stands "security through obscurity is not security"

And while you might stop some lame bot attempts, you might have given yourself some other headaches.. Many companies only allow outbound on standard ports from their networks as a security measure. So you have billy wanting to access your ftp on port 24.. Well he can not access it, since HIS company does not allow that - so he has to get with his IT justify the firewall change to allow access to your ftp server. Do they allow it?

Same goes for any of the services you wanting to make available from the public side.. What if your at a location that allows 22, but not the port your ssh is listening on?? Now how do you ssh to your network?

FTP has enough problems with NAT, so if your behind a nat and you change the ftp ports, its possible your nat routers helpers will not function correctly or the person trying to connecting you from behind a nat as well can have issues.

A correct method to prevent bots access to your ftp server depending on the client base, would be to only allow specific source IPs to talk to it in the first place. You have not tried to hide anything, but all you connections are "limited" to trusted sources.

Another secure method is to only allow access to your services through a VPN, ftp bots are mute if you have to vpn or ssh to your network to access your ftp again "limited" access

Now I agree with your logic -- but its still not a valid security method because you did not restrict anything, your just trying to hide. Your not actually limiting any access, and if your ftp server is open to a exploit, that exploit is still open to the public net -- you just are hiding it, but what if box X+1 now just does a quick port scan for ftp server?

Hiding is not a valid security methodology, can it be used to limit exposure - ok I will give you that.. But its not actually securing anything. And can have its own issues, and can and does quite often give the owner a false sense of being secure -- oh I don't have to worry about strength of my passwords, nor if on latest patches -- bots are not finding my server since I have hidden in the bushes, I don't have to worry about blocking failed attempts from IP X, since nobody is finding me..

[Vice]

I clearly said: Whist I agree that obscurity is not security I do believe that obscurity should be used as a first step in a much larger security response. I never attempted to push your point down. Of course it still stands I agree with it. The rest is tl;dr

[Prophecy]

Its not an internal issue. Its an External issue I am more worried about. I agree with you guys, regarding security through obsecurity is not always the best approach. I have a tendancy to go overboard as it helps me to eliminate possibly entry ports in the event there is a compromise.

The VPN will be the most ideal situation.

[MS Bob 11]

Require Network Level Authentication on RDP servers and enable CredSSP on Windows XP clients (requires XPSP3 to be installed and CredSSP to be enabled in the registry).

[cluberti]

Using TS Gateway + smartcard login + login at the ultimate endpoint via smartcard or user / pass auth. It's easier to have TS Gateway + encryption + smartcard auth + user auth requirements and have one open endpoint (port 443) to watch in the DMZ between two firewalls than to publish servers directly.

[Dashel]

Well said Budman.

I use VPN and a secure password. 'More' secure is simply a more complex password.

[Raa]

Agreed. Just have a complex password.

I've got my server on the net, default port, no vpn etc. It's worked fine for years, and will continue to do so.