This Post lists the best practices for securing Terminal Server or Windows XP (for use with VDI)

How can I protect my terminal servers from Spyware, Malware, Trojans, Worms, Viruses and un-authorized software?


  1. Start with a secure installation of the Operating System.  Windows Server 2003 installs by default with the users being able to create files and folders in the root of the system drive and Windows 2000 Server installs by default with the Everyone group having Full Control NTFS Permissions to the entire System Drive.  To lock down the System Drive on Windows 2000 Server, start with the following settings:

    1. Root of System Drive – Authenticated Users = "Read and Execute"

    2. Root of System Drive – Administrators = "Full Control"

    3. Root of System Drive – System = "Full Control"

    4. Program Files Directory – Authenticated Users = "Read and Execute"

    5. Program Files Directory – Administrators = "Full Control"

    6. Program Files Directory – System = "Full Control"

  2. NEVER allow anyone to logon as an administrator or power user, unless they are a member of the IT Staff / IT Consulting Firm that is responsible for the server, and they are logging on to perform administrative functions, i.e. installing software, performing a backup…

  3. Force "Empty Temporary Internet Files when browser closed" via Group Policy.  This will delete most bad files from the Temp IE location of the user’s profile, and leave only the cookie files.

  4. Implement Roaming Terminal Server Profiles, Mandatory Terminal Server Profiles or Flex Terminal Server Profiles.

  5. Enable DeleteRoamingCache in the registry, or via "Delete Cached Copies of Roaming Profiles " in Group Policy.  Since the Roaming Profile does not propagate the user’s Temp Directory, enabling this policy will usually delete that anything the user downloaded unintentionally.  This policy deletes the user’s local profile at logoff once it’s been successfully unloaded and copied to the roaming location.

  6. Install the User Profile Hive Cleanup Service , which helps to ensure user sessions are completely terminated when a user logs off.  Without this service, user profiles are often not unloaded successfully which causes the copy to the roaming profile location and DeleteRoamingCache setting to fail.

  7. Install a Terminal Server compatible anti-virus scanner on each terminal server, a VSAPI anti-virus scanner on each SMTP Server, and an anti-virus scanner at the Internet Gateway.

  8. Set the Terminal Services Configuration Permission Compatibility to "Full Security" (Windows Server 2003) , or to "Windows 2000 Users" (Windows 2000 Server) . If you use the "Permissions compatible with Terminal Server 4.0 Users" (Windows 2000 Server) or "Relaxed Security" (Windows Server 2003), each user logging on is added to the TSUser Security Group, which has permissions and rights of the Power Users Group.

  9. Enable Software Restriction Policies in Group Policy, to define which files can be executed by users.

  10. If users need only one application, specify this program to start when they logon.  This can be done for everyone via Group Policy or Terminal Services Configuration , or for specific users via Active Directory or Local User Account.

  11. Consider locking down the user environment with a FREE program like BrsSuite , designed by Terminal Server Security Expert "Fabrice Cornet", of FC Consult, Belgium .

  12. Restrict access to applications normal users shouldn’t ever use, or that do not follow the policy restrictions in place, i.e. winfile and command.com

How can provide the most secure access to terminal servers from the Public Internet?  The RDP Protocol is secure and uses RSA Security’s RC4 cipher, at either 56 or 128 bits, however the following should be considered when providing access to terminal servers over the Public Internet:


  1. Set the RDP-Tcp Encryption Level to "High" (Windows 2000 Server or Windows Server 2003)

  2. Define and enforce a strong password policy .

  3. If you require password authentication to access a Remote Desktop Web Connection (RDWC, aka TSAC or TSWeb), do so over an SSL Connection.  Since you have to logon to the Terminal Server, there really is no advantage to requiring authentication to access a RDWC.

  4. Do NOT use traditional client-to-server VPN to provide secure access to Terminal Servers.  This may sound strange, but traditional client-to-server VPNs require connectivity over non-standard ports client software on the remote computer. These often prevent remote users from being able to connect.  In addition to the connectivity problems traditional VPN can cause, traditional client-to-server VPNs can open the corporate network to viruses, trojans or worms, because they extend the corporate network to the remote client.

  5. Do consider providing secure access to terminal servers via SSL VPN or a Terminal Server Secure Gateway , as these can provide access over standard ports like 443 or 80, which makes connectivity easy for remote users.  These devices or software applications also provide access to a specific computer, or set of computers, instead of opening a secure tunnel to the entire corporate network.

VMware “announce” the new Vi3 features

Main thing to say that is this is a just an announcement. There’s nothing new dowload and install yet. In fact some of these products (as far as I am aware yet) aren’t even on a private beta yet, never mind a public beta. Some of this was announced at VMworld in th keynotes. I’ll focus on what’s new:

  • 128GB of RAM for ESX 3.5
  • 64GB of RAM for Virtual Machines
  • Suport for Transparent Paravirtualization support for paravirtualizated enabled Linux 2.6.21 kernels
  • Support for MMU – Memory Management Unit – support for memory page tables handled by the new CPUs
  • Support for NPIV – N-Port ID Virtualization – presenting a WWN to a VM
  • Support for TCP Segment Offload and jumbo frames
  • Suport for local SATA Drives
  • Support for 10GigE
  • Storage VMotion – Moving VMs files around whilst the VM is running
  • Protect against operating system failures with virtual machine failure monitoring (experimental) in VMware HA. (Continuious HA???)
  • One-step restore of VMs using VMware Convertor/VirtualCenter
  • Distributed Power Management (Power down ESX hosts when you don’t need them – scarey or what!)
  • VMware Update Manager – “Windows Update” for ESX Hosts & the Vi Client and integrated with DRS
  • Consolidation Management – Mini-Capcity Planner and VMware Convertor integrated with VirtualCenter
  • Site Recovery Manager
  • ESX3i

Links:

Offical Press Release:

http://www.vmware.com/company/news/releases/esx_35.html
http://www.vmware.com/products/vi/features.html
http://www.vmware.com/products/vi/whatsnew.html