0

I've been doing my research on thin client setups and it seems like a very cool concept. Instead of purchasing and maintaining many PCs you can simply have thin clients that RDP into a Server 2008 server. All programs (Outlook, Browser, Adobe, specialty apps) are installed on the server 2008 box.

This has me thinking, is this setup inherently insecure? For example if a user downloads a PDF containing an exploit, goes to a page containing a malicious applet (assuming Java is still unpatched), or runs a malicious exe of some sort will this program be able to escalate privileges and take over the entire Server 2008 (along with all users that are RDPed in)? I assume that the programs are supposed to run as the user that is RDPed in and executed them.

In a thick client environment the worst that can happen is the malware can take over the user's PC. The malware will not affect other thick clients unless they run it.

How can I protect against this?

Dan
  • 15,280
  • 1
  • 35
  • 67
  • *"In a thick client environment the worst that can happen is the malware can take over the user's PC."* No it's not. A virus could infect every other machine on the netwowrk. And kill your dog. And set your house on fire. I'd say any of those are worse. – Ryan Ries Apr 11 '13 at 21:44
  • Very true. The infected PC can be used as an entryway into the network. Just as a single hacked webserver can be an entryway into the datacenter. I was considering privilege escalation on a host. However if there is an exploit that roots the box, I would rather a single client PC be rooted as opposed to the entire Server 2008 installation with all the users. – temp93453845 Apr 11 '13 at 21:52
  • A better solution for you might be VDI. Each virtual desktop is virtualized within a hypervisor, which isolates it from all the other VMs and the host, meaning that most conventional viruses won't be able to escape that one VM. – Ryan Ries Apr 11 '13 at 22:00

2 Answers2

1

Your concerns are essentially correct - in a traditional Windows Server Remote Desktop Services, you have a shared estate. This isn't just an issue because of viruses, but you should remember that any user can impact everyone else on the box in a myriad of ways - CPU, RAM, Disk I/O and usage etc etc.

There's no easy answer to all of these questions, though there are tools to mitigate. Back to your original question, though - the answer is to ensure you use A/V, take advantage of network based security and use tools such as group policy to lock down the user environment. I've worked with hundreds of terminal servers and, with the right precautions, viruses should be almost a non-issue.

It's worth bearing mind the advantages to thin clients though. If you scale your infrastructure properly the users should never notice a server being taken out of production. Combine that with good DR practises and monitoring and the whole end to end repair could be totally transparent.

Dan
  • 15,280
  • 1
  • 35
  • 67
0

Is a Terminal Services or RDP thin client solution insecure?

In many ways a Terminal server environment is exactly like a typical desktop from the perspective of security. But in some ways it is different.

  • Your users are not administrators/powers users
    • They cannot install software. So you have a well understood limited selection of software that you can keep patches applied. Subscribe to all the vendors mail lists and so on.
    • Making some higher-up an administrator/power user because they whine a lot simply is not an option. If you give any end-user admin access your terminal servers have an extremely high chance of getting quickly trashed for everyone. You quickly learn to never make exceptions on the terminal servers.
  • You have a smaller number of systems to maintain/monitor, and they are most likely similar/identical.
    • You don't have to deal with obscure hardware differences, you can automate your installation/update procedures. You should have enough servers in your pool so you can pull one out of the farm to update it, test, and bring back online as soon as patches to critical issues are released. You can get every member TS updated, and have a very high certainty you have everything updated with the latest patches.
    • You can, and should setup your monitoring system to collect CPU, Memory, I/O stats for your terminal servers so you can monitor performance. A typical infection probably would be quickly noticed as it consumes system resources.
  • Since you are running a well identified, and limited set of software software whitelist tools may be feasible. As in software restriction policies, or Faronics Anti-EXE or something similar.
    • A whitelist approach means that you explicitly approve every program that can run. The vast majority of malware simply won't be able to get past the whitelist
  • You will be using Roaming Profiles, and Redirected folders to keep your End-user data on a file server.
    • Since all your data is somewhere else, if a Terminal server gets trashed, you simply rebuild it. Again, having a spare server in your farm makes this easy.
  • Your terminal servers will almost certainly be 64 bit systems. This means you get to enable all the advanced DEP, memory randomization features, and so on. These are not foolproof, but they decrease the attack surface

While I can certainly agree that there is a potential risk of an end-user getting something that exploits a escalation bug and then trashes the entire system. I have never seen it actually happen in the ~10 years I have been maintaining TS environments for a couple schools. Occasionally something has gotten in and trashed a users profile, but malware trashing the entire system hasn't happened yet.

Systems that are properly maintained, with a very tight locked down access, with a decent anti-malware program install will protect your system most of the time. Maintaining the servers will be easier than maintaining a lot of desktops.

Zoredache
  • 128,755
  • 40
  • 271
  • 413