Traditionally Microsoft ISA Server has been deployed on industry standard servers or purpose-built appliances. Today, deploying Forefront Threat Management Gateway (TMG) 2010 on virtual servers has become more popular with the rapid adoption of server virtualization technologies like VMware’s ESX and Microsoft’s Hyper-V. Although Forefront TMG is fully supported in a virtualized environment, the choice to deploy TMG on a virtual platform should be made with careful consideration toward both security and performance. The debate about whether or not to deploy TMG on a virtual server is largely philosophical (sometimes bordering on religious!), so my intent here is to provide you with valuable information to use to make the best decision based on your needs and requirements. Before considering the deployment of TMG on a virtual server, take a hard look at your requirements both in terms of security and performance and carefully weigh the rewards versus the risks of deploying TMG in a virtual infrastructure.
Benefits of Virtual Server Deployments
Deploying Forefront TMG on a virtual server offers several distinct advantages over traditional server installations. The speed with which a virtual server can be deployed is typically much faster than with physical servers, providing flexible scalability and allowing administrators to quickly and easily add capacity to a system to meet additional or unforeseen resource demands. In addition, virtualization provides the ability to create snapshots which can be beneficial for testing updates and for disaster recovery. However, virtualized deployments have some potential drawbacks and, as with almost anything, these benefits come with some tradeoffs in terms of security and performance.
There’s No Free Lunch
Virtualization imposes a performance penalty which, in some environments, can be substantial. It is important to understand that virtualization was not explicitly designed for performance. Rather, it was intended to improve resource utilization for servers by consolidating workloads that, by themselves, did not use all of the capacity available of a dedicated server. As such, the overhead incurred with any hypervisor will ultimately have a negative effect on the TMG firewall’s peak throughput and performance. Also, keep in mind that not all workloads lend themselves well to virtualization, and depending on your configuration and traffic profile it may not be the optimal platform to choose for your TMG deployment. Remember, just because you can virtualize something doesn’t necessarily mean it is a good idea. TMG is fundamentally a network security device, and as such can process a lot of network traffic. It is important to consider that in most virtual environments all the network I/O is processed on the host server’s processor. This is in addition to the load created by the virtual server’s own CPU, as well as the network I/O and CPU demand generated by any other virtual machines on the same virtual host. If you are hosting multiple TMG virtual servers on the same host, or co-locating TMG servers with other heavy workloads, the system can be quickly overloaded. This leads to increased network latency and overall degraded performance for all users.
Virtualization and Security
Installing Forefront TMG on a virtual server can also have serious security implications. The Law of Unintended Consequences often comes in to play, as virtualization introduces variables that affect services in unexpected ways. It also introduces a serious security dependency, where the security of the TMG firewall is entirely dependent on the security of the underlying host server and hypervisor. A successful attack on the hypervisor could lead to a full compromise of the TMG firewall running on that host. Operator error can be a factor as well, and this can be especially troublesome in medium and large sized organizations where the administrative responsibilities for the underlying virtual infrastructure are different from that of the security administrators tasked with managing the TMG firewall. Systems engineers and security professionals think very differently, and this can lead to consequences with potentially disastrous effects. A systems engineer, in an attempt to rectify a connectivity issue, might inadvertently connect a public network to an internal system, perhaps without even realizing it, and expose an internal system to an untrusted network. While this is more difficult to do in a physical environment (often requiring running cables and connecting to patch panels, etc.) in a virtual environment this can be accomplished with a simple mouse-click. It is also much more difficult to realize these mistakes after the fact.
Security and Performance Mitigations
To address some of these concerns it is essential to implement and adhere to specific processes and procedures for managing the virtual infrastructure that supports your TMG deployment. It is an excellent idea to implement security zones across your virtual infrastructure, segmenting systems and services according to sensitivity and risk. This is somewhat subjective, but the general idea is not to mix things like domain controllers and important infrastructure services like DNS or DHCP with general purpose file and data servers. Ideally your TMG firewalls would be hosted on a dedicated virtual host if possible (if they are public facing, this is a necessity in my opinion!). If you do intend to co-locate TMG with other services, be sure to use network adapters that are dedicated solely to TMG traffic. It is vital to the overall security of your virtualized edge infrastructure that traffic from public, untrusted networks be completely isolated from private internal network traffic. It is also highly recommended that if you deploy Forefront TMG in a virtual infrastructure that you place it behind another edge firewall running on dedicated hardware.
As a veteran information and network security engineer I tend to look at things differently than most IT professionals. And when it comes to edge security, for me, less is more. Complexity is the enemy of security, and deploying a Forefront TMG firewall in a virtual infrastructure adds more moving parts and greatly increases the overall attack surface of the solution. That’s not to say that deploying TMG on a virtual server can’t be done securely. With careful planning and consideration, and diligent monitoring and auditing, I believe it can. In terms of performance, dedicated hardware offers more consistent and predictable performance with better throughput, and troubleshooting is much simpler with physical deployments as well. Again, those shortcomings can be addressed by creating additional virtual machines or adding capacity to the host server. Whether the rewards of virtualizing your TMG firewalls outweigh the risks is up to you. I would encourage you to look closely at your needs and requirements, and evaluate your security policy thoroughly before jumping in to a TMG virtualization project.