Security Considerations for Server and Site Configurations (Windows SharePoint Services 2.0)

  • Article

When you host content on a Web service, you must make decisions about how best to protect the content from unauthorized users, and to what degree the content needs to be protected. The decisions you make influence the way you configure your servers and sites. There are pros and cons to each configuration, and your organization's requirements for security will always be different than another organization's requirements.

Microsoft Windows SharePoint Services, like most other Web services, supports multiple configurations, each of which has different trade-offs in functionality, performance, ease of deployment, and security. This topic discusses eight specific ways of deploying content with Windows SharePoint Services, and lists each method's pros and cons from a security standpoint. Choose the configuration that best meets the needs of your data and your organization.

Regardless of which deployment you choose, implementing security best practices takes precedence over your deployment choice. Installing the latest service packs, patches and stopping or removing unused services are the first steps in securing your deployment. Additional information for securing servers is available in the Windows Server 2003 Security Guide.

Windows Server 2003 R2 includes Windows SharePoint Services as a role in the Security Configuration Wizard (SCW). You can use this wizard to reduce the attack surface of your front end web servers. SCW will disable unnecessary services and enable only the ports necessary for Windows SharePoint Services to function. Additional information is available on the Security Configuration Wizard for Windows Server 2003 page.

1. Physical Isolation: Separate Networks

The most secure way of deploying Windows SharePoint Services content is to isolate the content from all untrusted users. You can do this by removing all network cables between untrusted clients and the server running Windows SharePoint Services or by creating a separate physical network dedicated to the Windows SharePoint Services content.

This option has obvious drawbacks in functionality and ease of deployment. Users will not be able to use their existing network credentials to authenticate on the server running Windows SharePoint Services and creating multiple physically isolated networks is a costly deployment option.

2. Physical Isolation: Separate Server Computers

The next most secure way to deploy Windows SharePoint Services content is to put each site on its own server computer. This helps mitigate a security exploit on one site that grants the attacker control of the server computer from being used to attack other sites based on Windows SharePoint Services.

Again, this option has serious drawbacks for ease and cost of deployment. Each new Windows SharePoint Services site requires a new server computer. This is a waste of server resources if the sites cannot keep the server computers busy all the time, and it is an administrative drain to manage multiple server computers.

3. Process Isolation: Separate Application Pools

The next most secure way to deploy Windows SharePoint Services is to put each site in its own application pool on the same server computer. Application pools in Internet Information Services (IIS) provide a way for multiple sites to run on the same server computer but still have their own worker processes. This mitigates an exploit on one site which allows the attacker to inject code onto the server from attacking other sites. Each site has its own worker process and identity which prevents two processes from interacting.

While this configuration is easier to deploy than separate server computers, deploying Windows SharePoint Services sites using separate application pools still has significant performance and deployment issues. Because each application pool has its own process, you cannot deploy more than 10 to 20 Windows SharePoint Services sites on a server by using different application pools. The memory overhead of each application pool is about 30 to 50 MB. Beyond ten to twenty sites, the server will run out of memory to hold all the site processes.

4. Logical Isolation: Separate Virtual Servers

The next most secure way to deploy Windows SharePoint Services is to put each site into its own virtual server with a unique domain name but using the same application pool. This method gives each site its own domain name, which helps prevent cross-site scripting attacks.

However this method still suffers from the scalability limitations of multiple virtual servers. Each ASP.NET page generates a separate DLL for each virtual server, even if the source file of the ASP.NET pages is the same. The separate DLLs consume memory and will prevent more than 100 Windows SharePoint Services sites from running on the same server.

5. Logical Isolation: Separate Host Headers

Windows SharePoint Services also supports hosting multiple domain-named sites in a single virtual server. This is called host header mode because Windows SharePoint Services uses the host header or domain name to resolve the different sites. This scales much better than separate virtual servers and still helps prevent cross-site scripting attacks between two Windows SharePoint Services sites. Windows SharePoint Services can host up to two million sites per server computer in host header mode.

The downside of this configuration is in the additional deployment costs. In this configuration, each site requires a separate DNS entry in the domain controller.

6. SharePoint Site Isolation: Separate Site Collections

Windows SharePoint Services also supports hosting multiple site collections using the same virtual server and the same domain name. Site collections can be scaled out across multiple database servers for additional storage capacity and throughput. The upside of this configuration is scalability and ease of deployment. Windows SharePoint Services can host up to 2 million sites in a single domain. Creating a site collection does not require any DNS entry and can be easily automated and delegated to end-users. Windows SharePoint Services includes Self-Service Site Creation so users can even create their own sites.

However, while Windows SharePoint Services enforces security on the site, the sites are still vulnerable to cross-site scripting attacks from other sites within the domain.

7. SharePoint Site Isolation: Separate Sites

Windows SharePoint Services also supports multiple subsites and workspace sites within a single site collection. Windows SharePoint Services can host up to 250,000 subsites within a given site if the subsites are organized into folders of no more than 1000 subsites each.

The upside of this configuration is seamless navigation around the site collection. There is no built-in navigation from one site collection to another, but there is navigation from one subsite to another within a site collection.

The downside is reduced scalability—because all sites must be stored in the same content database, it is difficult to increase either storage capacity or throughput. Also, as with site collections, separate sites are vulnerable to cross-site scripting attacks from other sites within the domain.

8. SharePoint Site Isolation: Separate Lists

Finally, Windows SharePoint Services supports list- and library-level security. You can deploy content in a single site using separate lists and document libraries for different content. The upside of this configuration is seamless navigation around the site and global visibility of all objects. Users will be able to see that a library exists, even if they have no permission to read documents inside the library.

However, this is the least secure way to deploy Windows SharePoint Services content. The content is vulnerable to cross-security scripting attacks. Users in parent sites can also delete or deny access to content in subsites.

For more information about list-level security, see the Windows SharePoint Services Help system.

Other Security Issues

In addition to the eight deployment configurations list above, there are two other security issues worth mentioning that apply to all configurations: secure sockets layer and anonymous access.

  • Secure Sockets Layer (SSL)

    All of the deployment configurations above are vulnerable to network sniffing attacks unless the communication between the client and server is encrypted. Windows SharePoint Services supports the standard IIS SSL functionality to encrypt content between client and server. There is a substantial performance penalty for using SSL, but it the only way to protect data from hackers who can monitor the network. When using basic authentication, SSL is highly recommended because basic authentication sends user names and passwords over the network and SSL protects that data.

  • Anonymous Access

    Windows SharePoint Services supports anonymous access, but it is disabled by default. Any server that allows anonymous access is more vulnerable than a server that requires authentication. Anonymous sites can be attacked by anyone. Servers that require authentication can only be attacked by users who have some permission on the network.

For more information about Windows SharePoint Services architecture, including server farms, virtual servers, application pools, site collections, and sites, see the following topics:

For information about SSL and anonymous access in Windows SharePoint Services, see the following topics:

For more information about installing Windows SharePoint Services, see the following topics: