Pav Cherny

Contents

Security Dependencies in a SharePoint Environment
Enabling Network Access Protection
Establishing Domain Isolation
Implementing Server (and Workstation) Isolation
Conclusion

SharePoint security hardening requires an end-to-end approach that addresses the full spectrum of security dependencies and risks within and across server farms. In particular, recent innovations and technologies available out of the box with Windows Server 2008, such as Network Access Protection (NAP) with Internet Protocol Security (IPsec) enforcement, can help to increase SharePoint security. Yet detailed Microsoft recommendations for SharePoint security hardening in a Windows Server 2008 environment are hard to find. The Windows Server 2008 Resource Center for SharePoint Products and Technologies doesn't include a security guide. In addition, the security-hardening guides for Windows SharePoint Services (WSS) 3.0 and Microsoft Office SharePoint Server (MOSS) 2007 are still based on Microsoft patterns and practices that are dated June 2003 and were only partially updated in January 2006—which was still long before the release of Windows Server 2008 and Internet Information Services (IIS) 7.0, in any case.

Clearly, revised guidelines are highly overdue, and not just because we have long since moved on from Windows 2000, SQL Server 2000, IIS 5.0 and Microsoft .NET Framework 1.1, but also because the old ways of dealing with security hardening have proven insufficient time and again. It's simply not enough to secure a SharePoint farm as an isolated server island, as if SharePoint farms exist in a vacuum. The reality is that not a single security-hardening step in a SharePoint farm matters if the Active Directory forest is insecure, if the intranet environment is infested with spyware and rootkits or if users inadvertently or maliciously violate security policies by, for instance, downloading and installing file-sharing software from questionable sources.

It's possible to tackle these issues by using Windows Server 2008 technology. It's the key to achieving a high level of security in a SharePoint environment, end to end, from the client computers all the way up to the database servers.

In this article, I discuss SharePoint security aspects in an intranet environment based on Windows Server 2008. This discussion entails analyzing general SharePoint security dependencies beyond the limits of an individual farm and then deploying NAP with IPsec enforcement with corresponding security and isolation rules to mitigate risks. For SharePoint administrators, an obvious advantage of NAP is that it can stop unmanaged client computers from accessing SharePoint resources and downloading documents. Another, perhaps less obvious, advantage is that you can divide your intranet into separate logical networks through domain and server isolation. In this way, you can protect the inbound and outbound client-to-server and server-to-server communication and also limit traffic to desired front-end servers. Assuming that up to 30 percent of a company's SharePoint sites reside on rogue departmental farms, inadequately secured and out of the IT department's control, the benefits of restricting client traffic cannot be overemphasized. As always, the companion material includes worksheets with step-by-step instructions for following my explanations in a test environment.

Security Dependencies in a SharePoint Environment

Considering the complexity of SharePoint-based solutions, the sheer volume of data stored in SharePoint sites and the often contradictory security and productivity requirements in an enterprise, it can be tough to determine how and where to get started with SharePoint security hardening. Perhaps the first step is to retire the long-held notion that our intranets are friendly environments, sufficiently protected through perimeter firewalls and virus scanners. Firewalls and scanners don't block a malicious user from attaching a PS2 or USB hardware keylogger to a client computer—no drivers required. They also won't keep a zero-day rootkit from turning your mobile computers into zombies while they are connected to an inadequately secured environment at home, in hotels or airports or at customer sites. It may sound harsh, but categorizing your internal environment as hostile helps in terms of recognizing critical security dependencies within and across SharePoint farms.

Let's see what critical issues we can discover in a straightforward test lab, such as the one depicted in Figure 1 and outlined in the companion worksheet "Deploying a Test Environment With Multiple SharePoint Farms and a Network Policy Server." This SharePoint environment isn't secure. In fact, my deployment worksheet violates several security best practices and ignores important dependencies. I usually get away with it, assuming that there are no security requirements in test labs. Of course, I could have done worse by installing SharePoint on a domain controller or by granting security accounts administrative permissions, but these intentional configuration errors are not necessary. From a security perspective, my test environment is already bad enough.

Figure 1 An Insecure Test Environment with Multiple SharePoint Farms

For starters, I use the domain- administrator account to log on to all servers and workstations and install all systems while they were connected to the Internet. This is risky. It's better to avoid logging on to an unsecured computer by using a domain-administrator account. Likewise, it's a best practice to install and patch computers in a separate, secure staging environment prior to deployment. Windows Automated Installation Kit (AIK) and Windows Deployment Services (WDS) offer a good solution, yet I didn't take advantage of these technologies in my test lab for reasons of complexity. Because I took shortcuts, my Active Directory environment might already be compromised—and with it all my SharePoint farms. The game is over before it even started! A SharePoint farm can never be more secure than its Active Directory environment.

Domain-administrator accounts are very sensitive accounts indeed. You're also in a sensitive area when you access SharePoint resources, such as the SharePoint 3.0 Central Administration site and SharePoint site collections. Accessing a SharePoint site implies running ASP.NET code under the identity of the current user on the front-end server. If that current user happens to be a domain administrator, then the code runs with administrative privileges. You should deny domain administrators and local server administrators access to the SharePoint Web applications because it's possible to exploit their elevated privileges, such as extracting security accounts and passwords, as explained in the January 2009 column. If an attacker can trick a SharePoint administrator into deploying a malicious component or enabling inline ASP.NET code, the attacker might also be able to determine the security-account passwords and subsequently gain access to all sites in all farms that use those accounts.

In my test lab, I ignored these security-account dependencies and administrative risks, configured the WSS farm and the HR farm with the same security accounts and used the domain-administrator account to work with SharePoint 3.0 Central Administration in both farms. Sharing security accounts between farms is a bad idea, especially if they have different security requirements. A farm that shares its accounts depends on the other farm for security—and can therefore never reach a higher level of security than that of the other farm.

Using separate security accounts is an important best practice, but a compromised farm can still provide an avenue for attacks on other farms in the same Active Directory environment. For example, it doesn't take much effort to turn a compromised SharePoint server into an internal phishing platform. An attacker might enable Basic authentication or get a malicious component into an established SharePoint farm that sends a "WWW-Authenticate" header to the users and intercepts the returned credentials in plaintext, as illustrated in Figure 2. Because users trust their internal SharePoint sites, it's likely that they will enter the requested credentials without hesitation—and the attack succeeds.

Figure 2 A compromised SharePoint farm can enable attacks on other farms.

Of course, it's difficult to compromise a properly maintained SharePoint server, but that's not the point. The point is preventing security breaches on systems that aren't properly maintained from spreading to sensitive systems with higher-level security. Therefore, at least for the most sensitive SharePoint resources, such as an HR farm with personally identifiable information, you must consider these access dependencies, which basically imply that a SharePoint farm can only be as secure as the least-secure sites that the farm administrators, site-collection administrators, and site users can access with their user accounts.

Don't forget to include the client computers in your analysis of access and usage dependencies. Again, my test environment sets a poor example because any user can use any workstation to access any resource, and the computers aren't equipped with virus scanners or the latest security patches. Just imagine a user with the rights of a farm or site-collection administrator logging on locally to a spyware-infested client computer or to a computer in an unlocked office, where an attacker can easily attach a hardware keylogger. Farms and site collections are compromised as soon as the attacker gains access to an administrator account and password on any computer in any location. File-sharing software on client computers also poses security risks, as client computers tend to store content from SharePoint sites locally, manually, or automatically downloading that information into temporary files. Hence, a SharePoint farm can never be more secure than the client computers that the users use to access the farm's resources.

Of course, there are further weaknesses in my test environment. I invite you to study the relevant sections in the SharePoint security-hardening guides and continue this review on your own. You should recognize at least a handful of additional issues, such as that the SharePoint 3.0 Central Administration sites and search roles are hosted directly on front-end servers that service site content, that there's no antivirus solution on the servers, that the WSS farm and the HR farm share a common and unprotected database server, that all computers in the test environment have direct access to the database server, and that the network communication takes place in plaintext. None of this is desirable, so let's tackle some of these security issues.

Enabling Network Access Protection

There are many steps you can take to increase the security in a SharePoint environment, such as controlling physical access to computers and the network, configuring vLANs and access control lists (ACLs) on routers, and securing infrastructure servers (DNS servers, DHCP servers, domain controllers, and so forth) through deploying Microsoft Forefront Security for SharePoint and Active Directory Rights Management Services (AD RMS). Physical access controls and basic TCP/IP networking and router configurations are beyond the scope of this column and AD RMS has been discussed in previous columns, so that leaves us with NAP, IPsec, HTTP over Secure Sockets Layer (SSL), and Forefront Security as the next logical topics. This column focuses on NAP and IPsec. HTTP over SSL and Forefront Security will be addressed in future columns.

NAP with IPsec offers at least three key advantages for an internal SharePoint environment:

• You can enforce system health policies and automatically remedy compliance issues on client computers running Windows XP Service Pack 3 and Windows Vista;
• You can implement an additional layer of network security through IPsec and Windows Firewall across an entire Active Directory forest;
• You can establish encrypted communication channels through Encapsulating Security Payload (ESP) within a SharePoint farm and between servers and client computers.

A bonus is the ability to manage the network communication centrally through Group Policy and audit network access. In short, NAP with IPsec is an important enabler of an effective end-to-end security strategy for SharePoint.

At the core, NAP with IPsec relies on a clever distribution mechanism for X.509 certificates. On the client computer, system health agents (SHAs) inform the NAP agent about their compliance status through statement-of-health (SoH) documents, which the NAP agent consolidates in a system statement of health (SSoH). It passes the SSoH to the IPsec NAP Enforcement Client (NAP EC) on the client computer, which in turn passes the SSoH to the NAP Enforcement Server (NAP ES). This is the Health Registration Authority (HRA) that obtains system-health certificates from a certification authority (CA) for compliant computers. Figure 3 illustrates how a NAP client obtains a health certificate.

Figure 3 NAP Client/Server Communication to Exchange Health Information and Certificates

To determine that the requesting computer is compliant, the NAP ES passes the SSoH in a RADIUS message to the Network Policy Server (NPS). The NPS again passes the SSoH to the NAP Administration Server, which in turn extracts the individual SoHs from the SSoH and forwards them to the corresponding System Health Validators (SHVs). The SHVs analyze the SoH information and return a statement-of-health response (SoHR), which the NPS consolidates in a system-statement-of-health response (SSoHR) that the NAP system then passes back to the SHAs on the client computer. Through SoH and SoHRs, SHVs communicate with their corresponding SHA counterparts. For example, the SoHR from an antivirus SHV can instruct the corresponding antivirus SHA to download the latest version of the signature file from a remediation server to bring the client computer back into compliance.

On the server side, NAP also compares the SoHRs to the configured network and health policies and issues a system-health certificate if the client computer is compliant. The NAP client receives the certificate from the NAP ES and stores it in its computer certificate store. The certificate is now available for Internet Key Exchange (IKE) negotiation to establish IPsec security associations with trusted communication partners. The NAP client renews the system-health certificate whenever it is about to expire or when an SHA indicates a health-status change to the NAP agent. The bottom line is that compliant computers receive a health certificate and noncompliant computers don't. For deep technical details, I highly recommend the white paper "Network Access Protection Platform Architecture." The companion worksheet "Configuring Network Access Protection" describes the steps to deploy a basic NAP infrastructure in a test lab.

Establishing Domain Isolation

Even in my humble little test lab with NPS and HRA roles on a single server, you can immediately notice the benefits of NAP. As soon as you enable NAP on the client computers through Group Policy settings, NAP strongly encourages you to install the latest security patches and a virus scanner. The NAP client informs you about missing security components, and the network status includes a notification informing you that network access may be limited until the computer meets health requirements. At this point, however, noncompliant computers still have access to all servers in the network because we haven't yet configured IPsec policies. Without IPsec policies that request or require authentication for inbound and outbound connections, the NAP infrastructure really isn't much more than a health-certificate distribution mechanism. We need to implement domain isolation for NAP to be effective.

Implementing domain isolation means dividing the internal network into segments of restricted, boundary, and secure networks through IPsec enforcement policies. The objective is to prevent noncompliant computers from accessing any servers in the internal network—with the exception of those servers that the noncompliant computers must be able to access to become compliant and obtain a health certificate. In Figure 4, this concerns the NAP server NPS01. The difference between the boundary segment and the secure segment is that the IPsec policy for the boundary segment requests authentication for inbound and outbound connections and thus permits fallback to plaintext communication with noncompliant computers, while the secure segment requires authentication for inbound connections, which prohibits fallback to plaintext and blocks noncompliant computers. You can use the companion worksheet "Configuring IPsec Policies for Health Enforcement" to implement this segmentation.

Figure 4 Restricted, Boundary, and Secure Networks for NAPNAP

The domain controller in Figure 4 is a special case. You can request or require IPsec-protected communication between domain members and domain controllers if your computers run Windows Vista or Windows Server 2008 (see the companion worksheet "Configuring IPSec for Domain Controller Communication"), but this configuration is not supported for Windows Server 2003 and Windows XP. If you decide not to use IPsec for domain-controller communication, DC01 becomes part of the restricted network; requesting IPsec moves the domain controller into the boundary segment and requiring IPsec makes the domain controller a member of the secure segment. The configuration depends on your specific situation and needs. If possible, I recommend using IPsec.

Implementing Server (and Workstation) Isolation

Establishing NAP with IPsec enforcement and domain isolation serves as the first significant milestone towards security hardening. All client computers must now meet reasonable health requirements before they can access any internal SharePoint resources. Next, you can focus on segmenting the SharePoint environment into multiple tiers to achieve a fine level of communication control, end to end, including the communication of client computers. Figure 5 illustrates a possible segmentation strategy based on the role of each individual computer in the internal network.

Figure 5 An Improved Test Environment with Multiple SharePoint Farms

As you'll notice in Figure 5, my test environment now includes additional systems. Among other things, I changed the configuration of the WSS and HR farms and specified separate security accounts, moved the HR configuration and content databases to a separate SQL server and deployed separate computers for SharePoint 3.0 Central Administration and the SharePoint Search role in both farms. Check out the various worksheets in the companion material, which illustrate how to accomplish these steps.

Securing the communication between the tiers is now a straightforward process, thanks to our NAP with IPsec preparation work. Through Group Policy, you can centrally manage all rules for Windows Firewall with Advanced Security to lock down inbound and outbound communication on clients and servers to the most restrictive levels. I recommend disabling rule merging in Group Policy to prevent local administrators from applying conflicting firewall and connection security rules on any domain member. For example, you can lock down UDP and TCP port 1434 on the database servers, open a custom TCP port for the default SQL Server instance, encrypt the traffic, open only the TCP ports that your Web applications use on the front-end servers, and block all non-HR computers from accessing any server or client computer in the HR department.

References

	Network Access Protection Web site go.microsoft.com/fwlink/?LinkId=69752
	SharePoint Products and Technologies Web site
	Windows SharePoint Services TechCenter technet.microsoft.com/windowsserver/sharepoint
	Windows SharePoint Services Developer Center msdn2.microsoft.com/sharepoint
	Microsoft SharePoint Products and Technologies Team Blog blogs.msdn.com/sharepoint

An interesting question is whether you should also block sensitive computers from accessing nonsensitive computers—for instance, should you keep HR clients from accessing non-HR SharePoint servers in the WSS farm. This is an example where security and productivity requirements collide. For productivity reasons, I think it's impossible to refuse HR people access to company-wide SharePoint sites such as sites in my WSS farm, which implies that the WSS farm must conform to the same security standards as the HR farm. So in both farms, I had to move the SharePoint 3.0 Central Administration sites and search roles to a separate computer and apply firewall and connection security rules. Of course, you should also designate dedicated, nonprivileged accounts for SharePoint administration in both farms and apply further security-hardening steps. Joel Oleson has posted a great summary list of security-hardening steps on his SharePoint Land blog. I highly recommend following Joel's advice in an IPsec-enabled infrastructure that provides a rock-solid foundation for end-to-end SharePoint security hardening.

Conclusion

SharePoint farms don't exist in a vacuum. They exist in an environment that includes client computers, infrastructure servers, and networking equipment. That means you must attend to these components if you want to achieve better security through SharePoint securing-hardening. It's impossible to secure a SharePoint farm in an insecure Active Directory environment. It's impossible to secure a SharePoint farm if the client computers are infested with spyware. It's impossible to secure a SharePoint farm if an attacker can highjack user accounts, administrator accounts, or security accounts anywhere.

Windows Server 2008 technology provides the basis to cast a broad security net over an Active Directory forest through Network Access Protection with Internet Protocol Security enforcement, Windows Firewall with Advanced Security, and Group Policy management. Taking advantage of these technologies in a SharePoint environment is definitely worth the effort. You can control and secure the communication between workstations, servers, and domain controllers; you can enforce system health standards; you can implement domain isolation; and you can enforce separate tiers in the internal SharePoint environment. Through membership in security groups or organizational units, Active Directory automatically determines the policy settings that apply to each domain member, including client computers, database servers, front-end servers, and middle-tier servers for administration and other purposes. You can establish general policies for each tier and specific policies for each computer type and server role. You can prevent users from hosting SharePoint on client computers by blocking all incoming connections, and you can prevent departments from hosting unapproved and insecure SharePoint farms that might provide avenues for attacks on other farms in the internal network.

But don't go overboard with restrictions. Keep in mind that many departmental business processes rely on SharePoint deployments outside of the data center. After all, SharePoint is a business-critical collaboration platform in the enterprise.

Pav Cherny is an IT expert and author specializing in Microsoft technologies for collaboration and unified communication. His publications include white papers, product manuals, and books with a focus on IT operations and system administration. Pav is President of Biblioso Corp., a company that specializes in managed documentation and localization services.