by
Brian Madden
Two friends of mine, Christa Anderson and Kristin Griffin, are collaborating on a Windows 2008 Terminal Services book for Microsoft. Part of this project includes small "tips from the field" entries written by different people. They asked me to write a short bit on security, specifically, what's my one "hot tip" about locking down a terminal server?
For me this was easy, because I think there's one super simple thing that's better than any other advice I've ever received about locking down a Terminal Server. That tip? Remove the "execute" NTFS permission from everywhere except the folders where it's absolutely needed (which is probably only the Windows and Program Files folder). But folders like temp, temporary Internet files, the Outlook saved attachments folder, and the home drives--there is no reason that a user should ever have to execute anything from these folders. And honestly, if you just pull the execute permissions, you almost don't have to worry about anything else. How could users possibly install rogue software if they can't run anything from those locations? (Well, depending on your client drive mapping rules I guess.) How can users even infect a server if they can't execute anything from these locations?
Implementing this is pretty straightforward. The easiest way is to create a path rule with software restriction policies (part of Group Policy in Windows 2003 / 2008). You could also do this via good old-fashioned NTFS permissions, although you have to be careful that users don't have enough permissions in a folder to grant themselves execute permissions if you just remove it.
Besides this, what else do you do to lock down a Terminal Server? Microsoft actually has a great KB article detailing all of the Group Policy settings you can make to lock down Terminal Servers. They also published a fairly decent white paper on this topic a few years back. What other tips and tricks do you have?
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.