High Availability and Disaster Recovery for Virtual Environments

Virtualization is increasingly being used by IT departments for server consolidation and testing purposes. Virtual servers offer flexibility, but if a single physical server containing multiple virtual servers fails, then the impact of data loss is enormous.

Introduction

Virtual servers are used to reduce operational costs and to improve system efficiency. The growth in virtual servers has created challenges for IT departments regarding high availability and data protection. It is not enough to protect physical servers but also virtual servers as they contain business critical data and information. Virtual servers offer the flexibility, but at the same time if a single physical server containing multiple virtual servers fails, then the impact of data loss is enormous.

Virtualization Benefits

Companies are adopting virtualization at a rapid speed because of the tremendous benefit it offers and some of them include:

• Server Consolidation: Virtualization helps to consolidate multiple servers into one single physical server thus offering improved operational performance.
• Reduced Hardware Costs: As the number of physical servers goes down, the cost of servers and associated costs like IT infrastructure, space, etc. will also decrease.
• Improved Application Security: By having a separate application in each virtual machine, any vulnerability is segregated and it does not affect other applications.
• Reduced Maintenance: Since virtual servers can easily be relocated and migrated, maintenance of hardware and software can be done with minimal downtime.
• Enhanced Scalability – The ease with which virtual servers can be deployed will result in improved scalability of IT implementation.

File or Block Level Replication

Different kinds of replication techniques can be used to replicate data between two servers both locally and remotely. In block level, replication is performed by the storage controllers or by mirroring the software. In file-system level (replication of file system changes), the host software performs the replication. In both block and file level replication, it does not matter what type of applications are getting replicated. They are basically application agnostic, but some vendors do offer solutions with some kind of application specificity. But these solutions cannot provide the automation, granularity and other advantages that come with application-specific solution. Also, one needs to be concerned about the following:

• Replicated server is always in a passive mode - cannot be accessed for reporting/monitoring purposes.
• Possibility of virus/corruption getting propagated from production server to replicated server.

Application Specific Replication Approach

In this approach, the replication is done at a mailbox or database level and it is very application specific. One can pick and choose the mailboxes or databases that need to be replicated. In the case of Exchange Server, one can set up a granular plan for key executives, sales and IT people, in which the replication occurs more frequently to achieve the required Recovery Point Objective (RPO) and Recovery Time Objective (RTO). For everyone else in the company, another plan can be set up where the replication intervals are not that frequent.

Another advantage of this approach is that the replicated or failover server is in an Active mode. The failover server can be accessed for reporting and monitoring purposes. With other replication approaches, the failover server is in a Passive mode and cannot be used for maintenance, monitoring or reporting purposes.

Backup and Replication

Some solutions offer both backup and replication as part of a single solution. In this case, the backup is integrated with replication and the users get a two-in-one solution. Considered two-tier architecture, these solutions consists of an application and agent environment. The application server also hosts the network share that stores all the backup files. The files are stored on this network share and not on any particular target server so as to prevent loss of backup files. If the target server goes down, users would like to continue to access their backup files in order to rebuild the target server with as little downtime as possible.

The mailboxes and databases will be backed to the backup server and then replicated to the remote failover server. The full back and restore is done first and then only the changes will be applied through incremental. For restoring emails, mailboxes and databases, the local backup data can be used and for disaster recovery purposes, the remote failover server can be utilized.

Virtual Environments

Many high availability solutions protect data that reside on virtual servers. Customers can have multiple physical servers at the primary location and at the offsite disaster recovery location they can have one physical server with multiple virtual servers. Also, multiple virtual servers from the primary site can be easily backed up and replicated to the disaster recovery site.

With some disaster recovery solutions, both on physical and virtual servers, the appropriate agents are installed and these agents have very small footprint. Because of the limited footprint, the impact on these servers is minimal from a performance perspective. With other replication solutions, one has to install the entire application on the virtual servers and this will take a huge toll on performance.

Physical to Virtual Servers

In this scenario, the production environment has physical servers and the disaster recovery site is deployed in a virtual environment. Both the physical and virtual servers are controlled by the Application and it can be located either at the production site or at the remote site.

Figure 1

Virtual to Virtual Environments

In order to achieve significant cost savings, some companies not only virtualize their disaster recovery site but also use virtual servers in the production environment. One can have one or more physical servers housing many virtual servers both at production and remote sites.

Figure 2

Failover/Failback

When a disaster strikes the primary site, then all the users will be failed over to the remote site. Once the primary is rebuilt, one can go through the failback process to the original primary servers very easily. Also, only a particular virtual server containing Exchange or SQL server can be failed over without affecting other physical or virtual servers.

The only way to make sure that your disaster recovery solution works is to test it periodically. Unfortunately, to do that one has to failover the entire Exchange or SQL server. Administrators will be leery about doing this for fear of crashing the production Exchange or SQL server. Some solutions can create a test mailbox or database and use it for failover/failback testing periodically. Through this approach, customers can be fully assured that their disaster recovery solution will work when it is badly needed and have peace of mind.

Migration

Virtual servers in conjunction with certain disaster recovery solutions can be used as a migration tool. If a physical server goes bad, then one can failover to the remote failover virtual server. Once the primary site is rebuilt, then the failback can be easily achieved. With some applications, there is no need to have identical versions of Exchange on primary and failover servers. In fact, one can run Exchange 2003 on primary server and Exchange 2007 on failover server. This feature can be used as a migration tool. For example, you can failover to the failover server which runs Exchange 2007. Upgrade the original primary to Exchange 2007 and failback again. This scenario is applicable to SQL 2000, SQL 2005 and SQL 2008 servers also.

Conclusion

Companies are increasingly adopting virtual servers as virtualization offers many compelling benefits. This increase in virtualization poses tremendous disaster recovery and data protection challenges to IT Administrators. There is a greater need to implement the appropriate high availability and failover solutions to protect these servers.

Can Terminal Services be considered Virtualization?

Virtualization is a hot topic and at the moment very hyped up. Manufacturers would like to use that hype to boost their products by linking it to the virtualization market. In this craze Terminal Services was also labeled as a "Virtualization product". In this article let’s look at the facts and I’ll also give my opinion about this virtualization label.

Introduction

Although virtualization techniques were mentioned a long time ago (around 1960), within the ICT market the launch of VMWare caused the big success of the virtualization market. Their server virtualization product, which made it possible to run multiple servers on one physical system, started the virtualization space. After server virtualization other virtualization products and fields followed quickly like application virtualization, operating system virtualization and desktop virtualization. Products which were already available before the virtualization market want to hitch a ride on the virtualization craze. I was a bit surprised when both Microsoft and Citrix determined that Terminal Services and Citrix Presentation Server are virtualization products.

What is…?

Before we can start determining whether Terminal Services can be labeled as a virtualization product, we need to first find out what the definitions of virtualization and terminal services are.

Virtualization:

Virtualization is a broad term that refers to the abstraction of computer resources. Virtualization hides the physical characteristics of computing resources from their users, be they applications, or end users. This includes making a single physical resource (such as a server, an operating system, an application, or storage device) appear to function as multiple virtual resources; it can also include making multiple physical resources (such as storage devices or servers) appear as a single virtual resource.

Terminal Services:

Terminal Services is one of the components of Microsoft Windows (both server and client versions) that allows a user to access applications and data on a remote computer over any type of network, although normally best used when dealing with either a Wide Area Network (WAN) or Local Area Network (LAN), as ease and compatibility with other types of networks may differ. Terminal Services is Microsoft's implementation of thin-client terminal server computing, where Windows applications, or even the entire desktop of the computer running terminal services, are made accessible to a remote client machine.

Terminal Services Virtualization?

Both Microsoft and Citrix are using the virtualization space to position their Terminal Services/Citrix Presentation Server/XenApp product features. Microsoft calls it presentation virtualization, while Citrix used the term session virtualization. Microsoft also describes Terminal Service virtualization as follows:

Microsoft Terminal Services virtualizes the presentation of entire desktops or specific applications, enabling your customers to consolidate applications and data in the data center while providing broad access to local and remote users. It lets an ordinary Windows desktop application run on a shared server machine yet present its user interface on a remote system, such as a desktop computer or thin client.

If we go a bit deeper, Microsoft is describing their interpretation of presentation virtualization as follows: Presentation virtualization isolates processing from the graphics and I/O, making it possible to run an application in one location but have it controlled in another. It creates virtual sessions, in which the executing applications project their user interfaces remotely. Each session might run only a single application, or it might present its user with a complete desktop offering multiple applications. In either case, several virtual sessions can use the same installed copy of an application.

Ok, now we have the definitions of virtualization, terminal services and the way Microsoft explains why terminal services are a virtualization technique, it is time to determine if Microsoft is right with their assumption.

Terminal Services is virtualization!

Reading the explanation of virtualization, two important definitions are mentioned: abstraction and hiding the physical characteristics.

From the user perspective the application is not available on his workstation/thin client, but is running somewhere else. Using the definition of hiding physical characteristics, Terminal Services can be seen, from a user perspective, as virtualization. Because the application is not installed locally the user does not have any physical identification with the application.

With the IT perspective in mind Terminal Service can also be seen as virtualization based on the definition that (physical) resources can function as multiple virtual resources. Traditionally, installed applications on a local workstation can be started by one user at a time. By installing the application on a Terminal Server (in combination with a third party SBC add-on) applications can be used by more users at the same time. Although an application cannot be seen as a 100% physical resource, you can see Terminal Services as a way of offering a single resource that will be shown as multiple virtual resources.

In summary, Terminal Services can be seen as virtualization because the application is abstracted from the local workstation and the application appears to function as multiple virtual resources.

Terminal Services is not virtualization!

However, let’s take a closer look at the physical resources. Hardware virtualization, application virtualization and OS virtualization really do separate from the physical resource. With application virtualization the application is not physically available on the system, OS virtualization does not need a hard disk to operate, and with hardware virtualization the virtual machine does not communicate (directly) with real hardware. However Terminal Services, from an IT perspective, still needs physical resources. Terminal Services is not really virtualizing anything, only the location where the application/session is started and the methodology of displaying the application to the user are different. In other words, as Microsoft describes in their explanation, Terminal Services isolates processing from the graphics and I/O, but this is still done using another device without an additional layer in between.

Conclusion

Back to the main question: is Terminal Services virtualization? And the answer is …… it depends. It depends how you look at the concept of virtualization and your point of view on Terminal Services. Terminal Service can be seen as virtualization if you check it from the user perspective view (the application is not running physically on the workstation or thin client) or the view that a single application/session can be used at once by more than one user. If you look at how other virtualization techniques work, Terminal Services does not function the same way and physically nothing is running in a separate layer.

So there is no clear answer and the answer is subjective depending on how you look at virtualization and Terminal Services. My personal opinion is that Terminal Services cannot be labeled as virtualization, because it is not comparable with other virtualization techniques. Through my eyes Terminal Services is not adding an additional (virtualization) layer, but is only dividing the processes between two systems. I think both Microsoft and Citrix are using the "virtualization" term to gain advantages through the current boom of the virtualization market, but both know that if you look at the IT techniques it is not "real" virtualization.

What is the ISA 2006 Firewall?

I’ve had a number of encounters with customers and consultants lately that remind me of a situation that I’ve been aware of for years. Did you know that most people don’t actually know what the ISA firewall is and what it does? I think some of the confusion is related to the name of the product. First, there is the “Internet Security and Acceleration” which doesn’t really give you a good idea as to the product’s purpose and function, and second, appending the term “Server” at the end of the product name is confusing, because most people don’t associate firewalls as “firewall servers”.

Of course, people could go to the Microsoft Web site and try to figure out what the ISA firewall is and does. But like most of the home pages on the Microsoft.com Web site, it’s very hard to determine what the product is and does from the information on those pages. You see it promoted as a “security gateway”, which is the latest buzz term in the business. You also see it promoted as a “secure application publishing” solution. OK, what’s that in the big scheme of things? The problem that customers and consultants have is that they don’t understand the marketing speak and just need to know what the ISA firewall is and does.

ISA Server 2006 is Microsoft’s newest version of its Internet Security and Acceleration Server product line. Initially introduced in December 2000, ISA Server 2000 was the first version of the ISA Server product. A major revamp of ISA Server was released in May 2004 and christened ISA Server 2004. This major overhaul included significant improvements and put it on par with other major firewall and security gateway products, such as Check Point NG, Cisco PIX/ASA and Blue Coat. ISA Server 2006 was released to the general public in August of 2006.

ISA Server 2006 is a multi-featured and multi-purpose product that can be deployed in a variety of ways to meet the unique requirements of virtually any organization. As an integrated firewall, Web proxy and VPN server and gateway, ISA Server 2006 can be configured to act in each of these roles or be set up to provide only a subset. This flexibility enables you to introduce ISA Server into your network with minimal disruption to your current infrastructure and provide the security services you need.

In order to help you understand what ISA Server or an NS9200 series security gateway appliance can do for you in securing your core network applications and servers, we’ll discuss the following topics:

• What is ISA Server 2006?
• What’s new and improved in ISA Server 2006
• What’s the difference between ISA Server 2006 Standard Edition and Enterprise Edition?

What is ISA Server 2006?

ISA Server 2006 is many products in one. In a single software package you get:

• A network layer firewall
• An application layer inspection security gateway
• Forward and reverse Web proxy and caching server
• Remote access VPN server
• Site to site VPN gateway

A Network Layer Firewall

ISA Server 2006, like Check Point NG and the Cisco PIX/ASA firewall product lines, is a stateful packet inspection firewall. A stateful packet inspection firewall is able to look at the IP (Internet Protocol) information and make sure that attackers don’t take advantage of inherent security vulnerabilities at the network layer. ISA 2006 is able to check and prevent prevalent network layer attacks so that attackers on the Internet, or even in your own organization, are not able to disable or take over the ISA 2006 firewall.

Stateful packet inspection firewalls were state of the art in the 1990s. However, the threat landscape has changed significantly since that time. While malicious users at the end of the 20th century were interested in disabling the firewall and defacing Web sites for personal ego gratification, modern day hackers are more interested in obtaining or destroying corporate information for personal gain. Today’s network criminal is not interested in attacking the firewall or defacing a Web server; he’s more interested is “going under the radar” to steal, change, or destroy data.

Application Layer Inspection Security Gateway

Stateful packet inspection firewalls are unable to determine if there is an attack against a Web server, mail server, FTP server or any other kind of network application. All the stateful packet inspection-only firewall can do is protect you against simple network layer attacks. For this reason, an application layer inspection firewall or security gateway is required.

After ISA Server 2000 was released in December 2000, it quickly became the thought leader in application layer inspection space. Prior to the release of ISA Server 2000, the Gold Standard for firewalls was the Cisco PIX. The PIX was a simple stateful packet inspection firewall and could not protect networks against complex application layer attacks that modern hackers were using to steal, change and destroy corporate data.

ISA 2006 continues in the tradition of ISA Server as the leading edge application layer inspection firewall and security gateway. In fact, you’ll see ISA Server described as a “secure gateway” instead of a firewall, because the term firewall is losing it’s luster due to it’s heritage as a stateful packet inspection-only device. The ISA 2006 firewall takes both stateful packet inspection and application layer inspection and combines them into a powerful network security gateway solution.

Forward and Reverse Web Proxy and Caching Server

A Web proxy server is a machine that accepts Web connections from Web browsers and other Web enabled applications and forwards those connections to the destination Web server on the behalf of the user making the request. The Web proxy server can accept connections from users on your corporate network and forward them to an Internet Web server or it can accept incoming connections to Web servers and services on your corporate network and forward them to company servers.

When the ISA Server 2006 firewall acts as a Web proxy server, it has full knowledge of the communications being made through it. This enables the ISA firewall’s Web proxy services to provide a significant level of security for Web connections and protects your network from viruses, worms, hacking attempts and more, including identifying and authorizing users before allowing Web connections through the ISA firewall and Web proxy and caching server.

When the ISA firewall’s Web proxy service intercepts Web connections, it can perform many security checks to protect your network. Some of these include:

• Pre-authenticating the user at the ISA firewall and Web proxy and caching server for incoming connections to corporate Web and mail servers. When pre-authentication is enforced by the ISA firewall, it prevents anonymous users on the Internet from connecting to your corporate assets. Since attackers don’t have access to legitimate user credentials, they are unable to attack your Web servers
• Transparently authenticate users on the corporate network before their connections are allowed to the Internet. This allows the ISA Server to record the user names for all connections made through the ISA firewall and includes this information in logs and reports for forensics and regulatory purposes
• Perform deep application layer inspection on all the Web connections made through the ISA firewall using ISA’s HTTP Security Filter. This application layer inspection filter enables the ISA firewall to “scrub” Web sessions to make sure suspicious and potentially dangerous HTTP commands and data do not compromise your network
• Control what Web sites users are allowed to access, the time of day the users are able to connect, and even control the types of information users can download from the Web. For example, you can use the ISA firewall’s Web proxy features to block access to executable files, streaming media, and documents, such as Microsoft Word files
• Cache information requested by users to accelerate the Internet experience. When a user on the corporate network requests a Web page, ISA 2006 places that Web page in its Web cache. The ISA firewall stores that information and when another user makes a request for the same Web page, the Web page is returned to the user from the Web cache. This removes the requirement of having to connect to the Internet Web server to retrieve the same page again and reduces the amount of bandwidth needed on the Internet connection and provides users much faster access to the information.

This is just a short list of what the ISA 2006 Web proxy and caching component can do for your company. For comprehensive information on how the ISA firewall’s Web proxy component can secure and accelerate your organization.

Remote Access VPN Server

An increasing number of employees need access to information contained on the corporate network when they’re out of the office. Employees need to access Word documents, PowerPoint files, databases and more when on the road or when working from home. Even more important to business continuity is the ability to provide off-site workers access to corporate information in the event of an emergency, when workers might not be able to leave their homes. One of the most secure ways you can provide employees access to this information is by using a remote access VPN server.

A VPN (virtual private networking) server allows users outside the office to connect to the corporate network from a laptop or workstation from anywhere in the world. Once the user creates the secure VPN connection, that user’s computer is like a computer located at the office and can potentially access information from any server within the corporate network.

One of the drawbacks of traditional VPN solutions sold by major VPN server vendors is that once the user connects to the VPN server, that user has access to any resource on the corporate network. The problem with this is that the computers remote access users used to connect to the corporate network are typically not managed machines and therefore are at a higher liability for worm, virus and trojan infection.

The ISA Server 2006 plugs this security hole found in typical “hardware” VPN servers using three powerful methods:

• Strong user/group-based access control and least privilege access for remote access VPN connections
• Application layer inspection on all remote access VPN connections
• ISA 2006 VPN Quarantine Control

Strong User/Group based Access and Least Privilege for Remote Access VPN Connections

ISA 2006 allows you to control user access based on the user account or the users group membership. Access policy is enforced on the user so that, in contrast to traditional “hardware” VPN servers, users are allowed access only to applications the user is given permission to use and no more. VPN users aren’t allowed free access to the entirety of the corporate network – only to resources they require to get their work done

Application Layer Inspection on all Remote Access VPN Connections

Survivors of the Blaster worm might recall that they had a false sense of security when they configured their Internet firewalls to block the worm from gaining entry to their network from the Internet. These companies were still infected by Blaster, not from the Internet, but from VPN users. These companies used traditional “hardware” remote access VPN servers that could not perform application layer inspection on the VPN users.

In contrast to the traditional remote access VPN server, ISA 2006 performs both stateful packet and application layer inspection on all traffic moving over the VPN link. Worms like Blaster cannot infect the corporate network over ISA 2006 VPN connection because the ISA firewall’s smart RPC application layer inspection filter blocks the worm traffic. This ability to inspect application traffic enables the ISA firewall to protect you against compromised VPN client computers in the same way that it protects you from Internet based exploits.

ISA Server 2006 VPN Quarantine Control

For a comprehensive remote access VPN client defense in depth solution, the remote access VPN server should be able to pre-qualify the security status and general system health of the machine connecting through the remote access VPN link. This enables you to be more confident that even unmanaged machines meet minimal security configuration requirements before being allowed to connect to the corporate network.

ISA Server 2006 solves this problem by implementing Remote Access VPN Quarantine (VPN-Q). The VPN-Q feature allows you to configure a set of parameters that the VPN client systems must meet before being allowed to access resources on the corporate network. If the VPN client system is not able to pass these security and health checks, you can configure the VPN-Q feature to automatically update and configure the VPN clients so that they pass inspection and then allow them into the system. If the VPN clients are unable to be completely updated, then the connection is dropped. This protects your company from fatally flawed and compromised computers that could attack and destroy your company’s core information assets.

Site to Site VPN Gateway

We all hope that our companies grow large enough to require branch offices. But with the expansion into branch offices is the increased complexity and expense required to connect those branch offices to the main office network’s resources.

There are a number of options available to provide branch office connectivity to the main office, these include:

• Dedicated WAN links provided by telco providers
• Managed VPN networks provided by telco providers and ISPs
• Corporate managed VPN site to site VPN networks terminated at company VPN gateways
• Limited connectivity via “publishing” of corporate resources

Dedicated WAN links and managed VPNs are a good solution for companies who are immune from cost considerations. These options can be prohibitively expensive and organizations who are interested in cost-control prefer to use corporate managed site to site VPN connections between corporate managed VPN gateways.

A VPN gateway allows you to connect your main office to all of your branch offices over inexpensive Internet connections and do so in a secure fashion. Each ISA firewall and security gateway, at the branch offices and the main office, enforce strong stateful packet and application layer inspection over the information moving over the site to site VPN links. In addition, all connections made by branch office users is logged and recorded so that you have a comprehensive history of what users at the branch offices have been doing with main office resources.

The ISA 2006 site to site VPN feature set is an integral part of the ISA 2006 branch office gateway role. For a detailed discussion of the using ISA 2006 as a branch office security gateway.

What’s New and Improved in ISA Server 2006?

ISA Server’s roots were originally in Microsoft Proxy Server 2.0. ISA Server 2000 represented a major revamp of the Microsoft Proxy Server product and transformed it from a simple proxy server to a full featured network firewall and application layer security gateway. Another major reconstruction of the ISA firewall product line took place, with over 100 improvements and changes, with the introduction of the ISA 2004 firewall. In contrast to previous versions of ISA Server, the new ISA 2006 firewall and Web proxy and caching product represents an incremental change.

The major improvements included with ISA 2006 are focused on secure Web publishing, enhanced branch office performance and reliability and worm/flood protection. Table 1 provides some details of these improvements.

New and Improved in ISA 2006	Details
Secure Web Publishing	ISA 2006 includes a number of improvements in providing secure remote access to Web servers and services on the corporate network. Some of these include: New SharePoint Portal Server Publishing Wizard Improved Outlook Web Access (OWA), Outlook Mobile Access (OMA), Exchange ActiveSync (EAS) and Outlook 2003+ RPC/HTTP Web Publishing Wizard Increased options for two factor authentication, including SecureID and RADIUS One-time passwords New Kerberos constrained delegation enables remote users with laptops and Windows mobile-enable devices to use secure user certificates to authenticate to the ISA firewall New LDAP authentication allows ISA 2006 to be placed in a high security DMZ and leverage Active Directory users/groups Web farm load balancing. This new feature enables you to publish a collection of Web servers that perform the same function or contain the same content and have the ISA 2006 firewall automatically load balance the connections. ISA Server is about to do this without requiring NLB or an hardware load balancer, with great increases the simplicity of deployment and greatly reduces the cost by removing the hardware load balancer
Branch office security gateway	ISA 2006 includes a number of new and improved features that makes it the ideal selection for a branch office security gateway. These include: HTTP compression of the link connecting the branch office to the main office Diffserv Quality of Service (QoS) enables the ISA firewall to participate in Diffserv service groups and provide preferential treatment to connections to mission critical servers BITS caching reduces the cost and the load on links connecting the main office to the branch office by reducing the number of requests required for Microsoft updates The new site to site VPN wizard makes it easy for a non-technical user to provision a branch office ISA firewall with the help of an answer file created by the main office ISA firewall administrator
Worm and flood protection	ISA 2004 included a basic worm and flood protection feature that prevented the ISA firewall and ISA firewall protected networks from being compromised by worm flood attacks. The ISA 2006 firewall builds on this flood protection and increases the level of security against network flooding by adding many new configurable worm flood protection settings.

Table 1: New and Improved Features in ISA 2006

Standard Edition or Enterprise Edition?

There are two versions of ISA Server 2006. These are:

• ISA Server 2006 Standard Edition
• ISA Server 2006 Enterprise Edition

ISA 2006 Standard Edition is aimed at the small and medium sized business market of 75-500 users. ISA 2006 Standard Edition is comparable to a PIX or ASA firewall that is being used at a single site either in a lone firewall configuration or a lone firewall with a hot or cold standby. Management of ISA 2006 Standard Edition firewalls is done on a per machine basis.

In contrast, ISA 2006 Enterprise Edition is designed with medium to enterprise sized businesses in mind, where there are several ISA firewalls located at the main office and potentially thousands of ISA firewall located in branch offices all over the world servicing 500-100,000 users. The Enterprise Edition of the ISA 2006 firewall and Web proxy and caching server provides features required for medium and enterprises sized business alike, including centralized management and configuration, throughput in the multi-gigabyte range, and intelligent load balancing and caching leading to optimal uptime and performance for even the largest enterprise environments.

Summary

The goal of this article was to let you know about the ISA firewall and help you define its features and capabilities. The ISA firewall is a comprehensive network security solution that provides network edge and perimeter firewall, remote access VPN server, site to site VPN gateway, and Web proxy and caching in a single product.

All of these features can be deployed at the same time on a single device, or you can deploy the ISA firewall using only one or two of these roles. At it’s core, the ISA firewall is a network firewall on par with Cisco PIX/ASA or Check Point, but with the additional Web proxy and caching functionality that the Cisco and Check Point offerings do not have (unless you want to pay rapacious licensing fees).

The ISA firewall is also a high performance solution, easily supporting over 1.5Gbps stateful packet inspection and over 300Mbps Web proxy application layer inspection. ISA firewalls come in two versions: a Standard Edition for mid-sized businesses without branch offices or HA requirements, and Enterprise Edition, designed for mid-sized to enterprise businesses, who require centralized support for deployment, configuration and management of a globally distributed firewall and Web proxy/caching solution.

ISA Firewall Web Caching Capabilities

Introduction

ISA can act as a firewall, as a combined firewall and Web caching server (the best “bang for the buck”), or as a dedicated Web caching server. You can deploy ISA as a forward caching server or a reverse caching server. The Web proxy filter is the mechanism that ISA uses to implement caching functionality.

Note:
If you configure ISA as a caching-only server, it will lose most of its firewall features and you will need to deploy another firewall to protect the network.

ISA supports both forward caching (for outgoing requests) and reverse caching (for incoming requests). The same ISA firewall can perform both forward and reverse caching at the same time.

With forward caching the ISA firewall sits between the internal clients and the Web servers on the Internet. When an internal client sends a request for a Web object (a Web page, graphics or other Web file), it must go through the ISA firewall. Rather than forwarding the request out to the Internet Web server, the ISA firewall checks its cache to determine whether a copy of the requested object already resides there (because someone on the internal network has previously requested it from the Internet Web server).

If the object is in cache, the ISA firewall sends the object from cache, and there is no need to send traffic over the Internet. Retrieving the object from the ISA firewall’s cache on the local network is faster than downloading it from the Internet Web server, so internal users see an increase in performance.

If the object is not in the ISA firewall’s cache, the ISA firewall sends a request for it from the Internet Web server. When it is returned, the ISA firewall stores the object in cache so that the next time it is requested, that request can be fulfilled from the cache.

With reverse caching, the ISA firewall acts as an intermediary between external users and the company’s Web servers. When a request for an object on the company Web server comes in from a user over the Internet, the ISA firewall checks its cache for the object. If it’s there, the ISA firewall impersonates the internal Web server and fulfills the external user’s request without ever “bothering” the Web server. This reduces traffic on the internal network.

In either case, the cache is an area on the ISA firewall’s hard disk that is used to store the requested Web objects. You can control the amount of disk space to be allocated to the cache (and thus, the maximum size of the cache). You can also control the maximum size of objects that can be cached, to ensure that a few very large objects can’t “hog” the cache space.

Caching also uses system memory. Objects are cached to RAM as well as to disk. Objects can be retrieved from RAM more quickly than from the disk. ISA allows you to determine what percentage of random access memory can be used for caching (by default, ISA uses 10 percent of the RAM, and then caches the rest of the objects to disk only). You can set the percentage at anything from 1percent to 100 percent. The RAM allocation is set when the Firewall service starts. If you want to change the amount of RAM to be used, you have to stop and restart the Firewall service.

The ability to control the amount of RAM allocated for caching ensures that caching will not take over all of the ISA Server computer’s resources.

Note:
In keeping with the emphasis on security and firewall functionality, caching is not enabled by default when you install the ISA firewall. You must enable it before you can use the caching capabilities.

Using the Caching Feature

Configuring a cache drive enables both forward and reverse caching on your ISA firewall. There are a few requirements and recommendations for the drive that you use as the cache drive:

• The cache drive must be a local drive. You can not configure a network drive to hold the cache.
• The cache drive must be on an NTFS partition. You can not use FAT or FAT32 partitions for the cache drive.
• It is best (but not required) that you not use the same drive on which the operating system and/or ISA Server application are installed. Performance will be improved if the cache is on a separate drive. In fact, for best performance, not only should it be on a separate drive, but the drive should be on a separate I/O channel (that is, the cache drive should not be on a drive slaved with the drive that contains the page file, OS, or ISA program files). Furthermore, if performance of ISA firewall is a consideration, MSDE logging consumes more disk resources than text logging. Therefore, if MSDE logging is used, the cache drive should also be on a separate spindle from the MSDE databases.

Note:
You can use the convert.exe utility to convert a FAT or FAT32 partition to NTFS, if necessary, without losing your data.

The file in which the cache objects are stored is named dir1.cdat. It is located in the urlcache folder on the drive that you have configured for caching. This file is referred to as the cache content file. If the file reaches its maximum size, older objects will be removed from the cache to make room for new objects.

A cache content file cannot be larger than 64GB (you can set a smaller maximum size, of course). If you want to use more than 64GB for cache, you must configure multiple drives for caching and spread the cache over more than one file.

You should never try to edit or delete the cache content file.

ISA Firewall Cache Rules

ISA uses cache rules to allow you to customize what types of content will be stored in the cache and exactly how that content will be handled when a request is made for objects stored in cache.

You can create rules to control the length of time that a cache object is considered to be valid (ensuring that objects in the cache do not get hopelessly out of date), and you can specify how cached objects are to be handled after they expire.

ISA gives you the flexibility to apply cache rules to all sites or just to specific sites. A rule can further be configured to apply to all types of content or just to specified types.

Cache Rules to Specify Content Types That Can Be Cached

A cache rule lets you specify which of the following types of content are to be cached:

• Dynamic content This is content that changes frequently, and thus, is marked as not cacheable. If you select to cache dynamic content, retrieved objects will be cached even though they are marked as not cacheable.
• Content for offline browsing In order for users to be able to browse while offline (disconnected from the Internet, all content needs to be stored in the cache. Thus, when you select this option, ISA will store all content, including “non-cacheable” content, in the cache.
• Content requiring user authentication for retrieval Some sites require that users be authenticated before they can access the content. If you select this option, ISA will cache content that requires user authentication.

You can also specify a Maximum object size. By using this option, you can set limits on the size of Web objects that will be cached under a particular cache rule.

Using Cache Rules to Specify How Objects are Retrieved and Served from Cache

In addition to controlling content type and object size, a cache rule can control how ISA will handle the retrieval and service of objects from the cache. This refers to the validity of the object. An object’s validity is determined by whether its Time to Live (TTL) has expired. Expiration times are determined by the HTTP or FTP caching properties or the object’s properties. Your options include:

• Setting ISA to retrieve only valid objects from cache (those that have not expired). If the object has expired, the ISA will send the request on to the Web server where the object is stored and retrieve it from there.
• Setting ISA to retrieve requested objects from the cache even if they are not valid. In other words, if the object exists in the cache, ISA will retrieve and serve it from there even if it has expired. If there is no version of the object in the cache, the ISA will send the request to the Web server and retrieve it from there.
• Setting ISA to never route the request. In this case, the ISA relies only upon the cache to retrieve the object. Objects will be returned from cache whether or not they are valid. If there is no version of the object in the cache, the ISA will return an error. It will not send the request to the Web server.
• Setting ISA to never save the object to cache. If you configure the rule this way, the requested object will never be saved to the cache.

Note:
The default TTL for FTP objects is one day. TTL boundaries for cached HTTP objects (which are defined in the cache rule) consist of a percentage of the age of the content, based on when it was created or last changed.

You can also control whether HTTP and FTP content are to be cached for specific destinations, and you can set expiration policies for the HTTP and FTP objects. You can also control whether to enable caching of SSL content.

Because SSL content often consists of sensitive information (which is the reason it’s being protected by SSL), you might consider not enabling caching of this type of content for better security.

If you have multiple cache rules, they will be processed in order from first to last, with the default rule processed after all the custom rules. The default rule is automatically created when you install ISA. It is configured to retrieve only valid objects from cache, and to retrieve the object from the Internet if there is no valid object in the cache.

The Content Download Feature

The content download feature is used to schedule ISA to download new content from the Internet at pre-defined times so that when Web Proxy clients request those objects, updated versions will be in the cache. This enhances performance and ensures that clients will receive up-to-date content more quickly.

You can monitor Internet access and usage to determine which sites users access most frequently and predict which content will be requested in the future. Then you can schedule content download jobs accordingly. A content download job can be configured to periodically download one page (URL), multiple pages, or the entire site. You can also specify how many links should be followed in downloading the site. You can configure ISA to cache even those objects that are indicated as not cacheable in the cache control headers. However, a scheduled content download job would not complete if the Web server on which the object is stored requires client authentication.

To take advantage of this feature, you must enable the system policy configuration group for Scheduled Content Download Jobs, and then configure a content download job.

When you enable the Schedule Content Download Jobs system policy configuration group, this causes ISA to block unauthenticated HTTP traffic from the local host (the ISA server) – even if you have another policy rule configured that would allow such traffic. There is a workaround that will make it possible to allow this traffic and still use content download jobs. This involves creating a rule to allow HTTP access to All Networks and being sure that another rule higher in the order is configured to allow HTTP access from the local host.

Control Caching via HTTP Headers

There are two different factors that affect how HTTP (Web) content is cached. The configuration of the caching server is one, but Webmasters can also place information within the content and headers to indicate how their sites and objects should be cached.

Meta tags are commands within the HTML code of a document that specify HTTP expiration or non-cacheable status, but they are only processed by browser caches, not by proxy caches. However, HTTP headers are processed by both proxy caches and browser caches. They are not inserted into the HTML code; they are configured on the Web server and sent by the Web server before the HTML content is sent.

HTTP 1.1 supports a category of headers called cache control response headers. Using these headers, the Webmaster can control such things as:

• Maximum age (the maximum amount of time the object is considered valid, based on the time of the request)
• Cacheability
• Revalidation requirements

ETags and Last-Modified headers are generated by the Web server and used to validate whether an object is fresh.

In Microsoft Internet Information Services, cache control response headers are configured in the HTTP Headers tab of the property pages of the Web site or Web page.

ISA does not cache responses to requests that contain certain HTTP headers. These include:

• Cache-control: no-cache response header
• Cache-control: private response header
• Pragma: no-cache response header
• www-authenticate response header
• Set-cookie response header
• Cache-control: no-store request header
• Authorization request header (except if the Web server also sends a cache-control: public response header)

Summary

In this article we looked at a part of the ISA firewall that we do not talk about too much – the firewall’s Web caching feature. You can use the ISA firewall as a combined firewall and Web caching device, or even use the firewall as a Web caching device only. No matter how you choose to deploy the firewall, your ISA firewall can cache Web content to speed up your end users’ Internet experience.

Logging and Reporting in ISA Server 2006

Introduction

Microsoft ISA Server 2006 provides you with network perimeter protection that enables secure remote access to applications and data while protecting your IT infrastructure from Internet-based threats. With ISA Server 2006 you can securely publish content for remote access, establish secure connections with branch office sites, and defend against both internal and external Web-based threats.

Sitting on the front line of the network perimeter and acting as the authentication gatekeeper for authorized remote access, the ISA Server typically receives a significant amount of network traffic. When it comes to monitoring the performance of ISA Server, assessing network security, or conducting a forensic analysis of ISA Server traffic as a function of incident response, you will need to understand how to work with the logging and reporting features of ISA Server.

Working With ISA Server 2006 Built-In Reports

Thankfully, Microsoft thought of that and built relatively robust logging and reporting capabilities into ISA Server 2006. ISA Server 2006 reports let you view general traffic patterns, analyze which applications or protocols are used most frequently, which sites are being accessed, unauthorized or malicious attempts to access network resources, and more.

ISA Server 2006 Default Logging

ISA Server aggregates data from the Web proxy and firewall logs using Dailysum.exe. The Dailysum.exe program is part of ISA Server and runs by default at 12:30am each day to extract and summarize the log data from those sources. Even if no reports are configured to run, Dailysum.exe will run, unless it is disabled. At the beginning of each month Dailysum.exe also generates a summary of the previous month’s activity. By default, at least 35 daily summaries and 13 monthly summaries are saved. These summaries are stored as *.ILS database files in the ISASummaries folder which can be found within the ISA Server installation folder.

Built-in Report Types

ISA Server 2006 comes with a variety of predefined report types that enable you to quickly and easily review common traffic data and critical security information. The built-in report types are:

• Summary - The Summary report provides a general overview of network traffic sorted by application.
• Web Usage - Illustrates Web usage on the network by displaying data regarding frequent Web users, browsers being used, and sites being visited.
• Application Usage - Provides details on Internet application usage including top users, and most used applications.
• Traffic and Utilization - Displays overall Internet usage including average network traffic, peak connections, cache hit ratios, and more.
• Security - Lists unauthorized access attempts and other potential efforts to breach network security.

Filtering Results and Creating Custom Reports

With these reports as a base, ISA Server 2006 allows you to customize or filter the results using the following criteria:

• Top protocols - Displays the selected number of most used protocols used during the report timeframe
• Top Users - Displays the selected number of users who used the network the most, or generated the most traffic during the report timeframe
• Top Sites - Shows the selected number of top sites visited by users during the report timeframe
• Cache hit ratio - This criteria displays the ratio between the number of Web requests and the number that were served locally from the cache
• Object types - Shows only the specified number of most frequently requested object types
• Browsers - Report shows the specified number of most-used Web browsers
• Operating systems - Displays the specified number of most-used client operating systems
• Destinations - Filters the results to display a specified number of most frequently visited Internet destinations=
• Client applications – Limits the report to display the specified number of client applications generating the most network traffic
• Dropped packets - Displays the specified number of clients that have had the highest number of dropped packets during the report timeframe
• Authorization failures - Shows the specified number of clients causing the most failed authorization requests during the reporting period

You use the ISARepGen.exe application, installed by default with ISA Server, to generate one-time or recurring reports. You can create a one-time report using the New Report Wizard. By definition the report will run only one time once you complete the wizard. Follow these steps to generate a one-time report:

1. Click the Reports tab on the Monitoring node
2. Select the Tasks tab
3. Click Generate a New Report

You can also configure recurring reports to be generated on a predefined periodic basis such as daily, weekly, or monthly. To create a new recurring report you have to run the New Report Job Wizard and specify the criteria to define what content the report should cover and the frequency that the report should be generated. Follow these steps to create a recurring report:

1. Click the Reports tab on the Monitoring node
2. Select the Tasks tab
3. Click Create and Configure Report Jobs

Whether you are creating a one-time or recurring report, you will need to supply information to the wizard such as the name of the report, the content that should be included within the report, the reporting timeframe or frequency schedule (depending on whether it is a one-time or recurring report), the directory the report should be published to and any access credentials necessary for ISA Server to write to that directory, and whether or not an email notification should be generated when the report is created and any SMTP or email address information necessary to facilitate that notification.

Extracting Per-User Details from ISA Logs

Log data can be written to a text file, however, even in small and medium-sized business environments the text file can quickly grow to a cumbersome size. The better logging options are to use a SQL Server database, or SQL Server’s scaled down cousin- MSDE. There are some security and performance advantages to using an external SQL Server for maintaining log data, but SQL Server requires separate licensing. MSDE provides many of the same features as SQL Server, but in a less robust database that runs locally on the ISA Server.

Regardless of whether you store log data in MSDE or SQL Server, you can use SQL queries to extract information. SQL queries enable you to filter log data on a very granular level and export data to Excel spreadsheets where it can be easier to work with and manipulate it.

For example, assume that while reviewing a standard daily ISA Server 2006 Security report you notice an inordinate number of failed authorization attempts by one specific user account, MaryN. The user in question is out on maternity leave and the Failed Access events appear to indicate an attempt to compromise the user account and breach the network. What you would want to do is to review data which is specific to this user account over the past week and try to determine the scope of the problem and at what point the issue began.

When filtering the log data, you need to specify the criteria that you want to filter, the conditional argument to apply, and the value. In our example you might filter on the following:

• Filter by: ‘Client Username’
• Condition: ‘equal to’
• Value: ‘MaryN’

In order to investigate the anomalous failed authorizations, you want to examine log data for the past week for MaryN. So, you would also want to narrow the results using:

• Filter by: ‘GMT Log Time’
• Condition: ‘On or After’
• Value: enter a calendar date a week prior to display information after that point

Protecting the Network With ISA Server 2006

Third party tools such as GFI WebMonitor for ISA Server provide even more detailed and valuable reports to help you administer access to your network and protect your users and network from malicious activity. In addition to the expanded reporting capabilities, GFI WebMonitor for ISA Server also extends the security and traffic-filtering functionality of ISA Server 2006. GFI WebMonitor for ISA Server enables you to enforce Internet acceptable use policies with ISA Server 2006, filter web content based on categories, prevent data leakage by filtering outbound files, and protect against malware compromise by scanning inbound traffic.

ISA Server 2006 is a powerful and effective tool for your network perimeter. It enables remote users to connect to internal resources securely while protecting the internal network from unauthorized access. To be effective though, you need to have procedures in place for when and how to review log and report data, and how to respond when malicious or anomalous activity is detected. Third-party tools can extend the functionality of ISA Server 2006 itself, as well as helping to automate and simplify management of network security, providing more robust and effective reporting.

A Proxy By Any Other Name

In almost every corporate computer network today there are proxies to be found. This is pretty much a standard computer security practice. The confusion starts when people start talking about all the various proxy types. Within the confines of this article all of the various proxy types will be discussed.

Most corporate computer networks today are designed with a purpose in mind. That purpose is usually a balance of security and usability. The end state of almost every corporate computer network today is to facilitate the work of the employee. Making their life easier through a simplified computing experience makes good business sense. One must also take into account network security concerns as well. This is where the proxy enters the picture. Just what is a proxy though? Well a proxy server is a computer operating as a server vice workstation. This proxy server in turn offers other computers an indirect means of accessing other computer services. Services such as a Web server for example located somewhere on the Internet. Simply put, the workstation opens its homepage of say EonConnects.net and that request is in turn relayed to the proxy server. The server will check to see if it has a cached version of this page and if not it will then go get it and relay it back to the workstation in question.

The nuts and bolts of it

If the above noted scenario still doesn’t make a whole lot of sense to you then think of it this way. Having such a proxy server will, for one, speed up the browsing experience for a corporate user. It is much faster to serve up a cached page then it is to retrieve it every time. When the proxy server or, in this case, the caching proxy receives a page request it will, as mentioned, check to see if it already has it. It will also see if the cached page has expired or not. Should the validity of the resource requested have expired then it will go and get a new copy of that resource. That alone makes it worth having a proxy server on a network. There are many other advantages to having one though. Those advantages very much impact the security posture of a corporate network as well, hence the prevalent usage of them. One of the most obvious advantages is being able to centralize all web page requests in one location. This will establish a chokepoint that can be exploited for security purposes.

The transparent proxy

Just as I mentioned above, having the ability to have all client requests go through a single computer gives one the ability to monitor client usage. By client I mean a corporate workstation. This centralization is done by configuring the client browser to use the transparent proxy server’s address. Though this definition of a transparent proxy is a popular one it is also incorrect. In reality a transparent proxy is a combination of proxy server and NAT technology. In essence client connections are NAT’d (network address translation) so that they can be routed to the transparent proxy. Having this type of setup is also a major pain, I am told, to implement and maintain.

The reverse proxy

What the devil is a reverse proxy you ask!? Good question indeed. Typically a reverse proxy is installed in close proximity to one, or several web servers. What in actuality happens is that the reverse proxy itself is the point of first contact for all traffic being directed at the web servers. Why go through the bother of this though? Well for several reasons actually. One of the primary ones is for security purposes as this reverse proxy is a first layer and acts as a buffer for the web servers themselves. Another reason is for SSL connections. Encryption is a computer intensive task and having it performed on the reverse proxy vice, the actual web server makes sense in terms of performance. Were the web servers themselves handling both the encryption part as well as the actual web server part then that machine would quickly become rather slow. For that reason the reverse proxy is equipped to handle the SSL connections and normally has some type of acceleration hardware installed on it for this very purpose.

Another key reason that the reverse proxy is employed is for load balancing. Think of a popular website that has a lot of visitors at any given time. It makes sense that there would be multiple web servers there to handle all incoming page requests. With a reverse proxy in front of these back end web servers no one box gets crushed but rather the load is balanced across all web servers. This certainly helps for overall performance. Another feature of the reverse proxy is the ability to cache certain content in an effort to further take a load off of the web servers. Lastly, the reverse proxy can also handle any compression duties that are required. All in all there is a tremendous amount of work being done by the reverse proxy.

Split proxies

Just when you think you’re done there is always something else! In this case that would be the split proxy. Well much as its name infers, the split proxy is simply a couple of proxies that are installed over a couple of computers. It’s that simple really. Although this type of proxy configuration is one that I have never come across, I have heard of them being used. One of its main selling points is the ability to compress data and that is a boon when slow networks are involved.

Wrap up

Over the course of this article we have seen the various types of proxies in use today in many corporate network environments. As we have seen many of them are used for specific reasons. There is not really one proxy type that can do it all, hence the variety of them. One of the greatest abilities of the proxy is to help enforce an acceptable usage policy on a corporate network. All too often we hear about someone who was fired for inappropriate use of company computer assets. What that neat use of the English language means is that someone was likely surfing for pornography from work and on company time no less in all likelihood. Even though someone doing this is acting foolishly and deserves to be terminated there are other reasons as well to control and monitor employee Internet usage. You can imagine for example how well it would go over for a high profile, publicly traded company to have an employee caught downloading kiddie porn. If that type of news hits the media all of sudden your company stock price could take a nose dive. Having a proxy in place within a corporate setting is really not only common sense, but also a necessity in reality. While most company employees are hard working and above board there will always be one or two who are not. Having the ability to catch and deal with them quickly is very much desired. Well I will end the article on that note and as always hope it was of use to you.

Securing Your OCS Deployment

Taking a look at the security concerns involved with unified communications and how to add security to OCS.

Office Communications Server (OCS) is Microsoft’s Unified Communications solutions for enterprises, but as with all UC deployments, applications that enable voice, video, IM, file transfers and application sharing can pose security issues. In this article, we address those concerns and discuss OCS’s built-in security features, configuration choices for best security practices, and integrated software solutions (both from Microsoft and third parties) to add security to OCS.

A unified communications system is vulnerable to such threats as eavesdropping or sniffing, identity/IP address spoofing, RTP replay, and so forth, as well as viruses/worms, man-in-the-middle and denial of service (DoS) attacks. Because the confidentiality and integrity of your communications are critical to your business, it’s essential to protect against all of these threats.

Built-in security features in OCS 2007

OCS 2007 provides many new features that LCS 2005 didn’t have, including:

• Enterprise VoIP
• Multi-party IM
• On-premise web conferencing that allows participation by outside users who don’t have enterprise credentials

In addition, features such as presence and federation support have been improved and enhanced.

With new features come new security challenges, but Microsoft has addressed many of these with built-in features. As always, the best security is multi-faceted, so the security framework upon which OCS is built has many components.

Active Directory

Windows server security in a domain is built around the Active Directory, and OCS uses AD to store global settings (used by multiple OCS servers in a forest), data identifying the roles of OCS servers, and user settings.

You must prepare AD for OCS by extending the schema to include OCS classes and attributes, creating OCS objects and attributes and add permissions on objects in each domain. You do this in one of two ways: by using the LcsCmd.exe command line tool on the OCS CD, or by using the Setup.exe deployment tool for OCS 2007. The command line tool can be run remotely. The deployment tool has a graphical interface and wizards to guide you through each task.

The specific steps to prepare AD include:

• Prep Schema (run once)
• Prep Forest (run once)
• Prep Domain (run on every domain where you deploy OCS)

For step by step information on how to prepare AD for OCS, see the Microsoft Office Communications Server 2007 Active Directory Guide. Active Directory Guide.

Authentication

OCS can use standard Windows authentication protocols, depending on the user:

• Kerberos v5 is the most secure and is used for internal clients with AD credentials.
• NTLM is used for clients outside the LAN who have AD credentials.
• Digest protocol is used for on-premise conferencing clients outside the LAN who don’t have AD credentials (they must, however, have been invited to use on-premise conference and must have been supplied with a valid conference key).

Network encryption

To protect data traveling over the network, OCS 2007 encrypts communications by default. Endpoint authentication and encryption are accomplished by using Transport Layer Security (TLS) and Mutual Transport Layer Security (MTLS). Server-to-server SIP communications use MTLS and client-server SIP communications use TLS. These protocols protect against man-in-the-middle and eavesdropping.

TLS and MTLS are also used to encrypt instant messages. TLS encryption is optional for internal client-to-client IMs. OCS communications with public IM servers is encrypted; however, it is up to the public IM provider to encrypt communications between the public IM server and the outside client.

The Secure Real-time Transport Protocol (SRTP) is used to encrypt streaming media. SRTP protects RTP data by adding authentication, confidentiality and replay protection.

Public Key Infrastructure

Server authentication for OCS 2007 is based on the use of digital certificates issued by a trusted CA. This can be an internal or public CA (you may need a public CA if the OCS server needs to communicate with systems outside the LAN). OCS is designed to work with a Windows 2003 Public Key Infrastructure (PKI).

For OCS, all server certificates are required to support Enhanced Key Usage (EKU) to authenticate the servers. This is used by MTLS. Server certificates must also include at least one Certificate Revocation List (CRL) distribution point.

Federation security features

Like its predecessor, Live Communications Server 2005 (with SP1), OCS 2007 has the capability of federating with the major public instant messaging providers (MSN, Yahoo! and AOL). It also supports “enhanced federation,” which allows peer enterprises to be discovered using DNS SRV records. OCS 2007 includes new security features for the federation model. These include:

• Restriction on how many users a federated peer can communicate with over a specified time period. This is designed to prevent “directory harvesting” by which an attacker tries different user names to find a valid one.
• Restriction on the rate at which the Access Edge Server will accept messages from the federated peer, based on analysis of the traffic.

Administrators can also restrict access by adding domains to the Deny list, or blocking peer certificates via the certificate store.

Blocking unwanted or dangerous IMs

You can use the Intelligent IM filter to block unwanted or potentially harmful instant messages and file transfers. You can configure the filters to use the criteria you want, in order to selectively block IMs and file transfers. For example, you can block IMs containing hyperlinks or you can allow the IM to go through with the hyperlink disabled. You can block files with specific extensions.

More information

For much more detailed information on using OCS’s built in security features, see the Microsoft Office Communications Server Security Guide.

Hardening your servers and clients

The OCS server, along with other servers in your infrastructure, should be “hardened” by locking down both the operating systems and applications as much as possible. You can do this through Group Policy. TheWindows Server 2003 Security Guide provides specific information on how to harden Server 2003 servers.

Unused services on your servers should be disabled. The SQL Server database used to store OCS information should be protected. In short, best network security practices become even more important when you have an OCS server on the network. And of course, all servers should be kept updated with security patches and the latest virus signatures.

Client machines must also be configured for best security. You can use OCS group policy to disable the appropriate features and set the client for media encryption. Of course, the latest service packs and security updates should be installed on the client machines.

And don’t forget other OCS devices, such as OCS-compatible phones. You can use the Office Communications Server Software Update Service to automatically update all unified communications devices deployed in your organization.

To evaluate the overall health of your OCS 2007 servers and topology, you can download the Office Communications Server 2007 Best Practices Analyzer.

Microsoft integrated security solutions

In June, Microsoft released a public beta version of Forefront Security for OCS. This is the latest in the Forefront family of enterprise security products and allows you to scan for malicious software using multiple engines, and filter instant messages and files by keywords. It also includes automated signature updates and IM notification alerts.

Forefront Security for OCS is integrated with Access Edge role in OCS 2007 Enterprise edition, which secures messages to and from external public IM clients and federated networks as well as internal communications.

Third party security add-ons

Third party security products designed to protect OCS 2007 include:

• Trend Micro IM Security for Microsoft Office Communications Server
• Akonix L7 Enterprise,, for adding unified policy and risk management for OCS

Summary

Microsoft OCS 2007 is Microsoft’s answer to the unified communications question. It goes way beyond the scope of LCS 2005 and now manages all types of real-time communications, including VoIP and conferencing. In today’s threat-filled world, communications applications are among the most vulnerable, so it is important to consider security first when deploying OCS. This article has provided an overview of security considerations relating to OCS 2007.