Plan security hardening for server roles within a server farm (Windows SharePoint Services)

Applies To: Windows SharePoint Services 3.0

Topic Last Modified: 2009-04-15

• About security hardening

• Application server recommendations

• Secure communication with the Microsoft SQL Server database

• File and Printer Sharing service requirements

• Service requirements for e-mail integration

• Windows SharePoint Services services

• Accounts and groups

• Web.config file

• Secure snapshot additions

Use this article to plan server farm security. The tasks in the article are appropriate for the following security environments:

• Internal IT hosted

• External secure collaboration

• External anonymous access

About security hardening

In a server farm environment, individual servers play specific roles. Security hardening recommendations for these servers depend on the role each plays.

The server hardening recommendations are built on top of the recommendations provided in the following security guides that are provided in Microsoft patterns & practices (https://go.microsoft.com/fwlink/?LinkId=73704&clcid=0x409):

• Securing Your Web Server (https://go.microsoft.com/fwlink/?LinkId=73705&clcid=0x409)

• Securing Your Database Server (https://go.microsoft.com/fwlink/?LinkId=73706&clcid=0x409)

• Securing Your Network (https://go.microsoft.com/fwlink/?LinkId=73707&clcid=0x409)

These guides follow a methodical approach to securing servers for specific roles and for securing the supporting network. The order in which settings are applied and applications are installed and hardened is prescribed as well, starting with applying patches and updates, then hardening networking settings and operating system settings, and then followed by application-specific hardening. For example, Securing Your Web Server (https://go.microsoft.com/fwlink/?LinkId=73705&clcid=0x409) recommends that you install and harden Internet Information Services (IIS) only after patching and hardening the operating system. Additionally, this guide prescribes installing the Microsoft .NET Framework only after IIS is fully patched and hardened.

The categories of security settings that are methodically prescribed in Securing Your Web Server (https://go.microsoft.com/fwlink/?LinkId=73705&clcid=0x409) are detailed in the following figure.

Additionally, each of the three guides includes a secure snapshot and a list of recommended security settings for either the specific server role or for the network. The snapshot lists are organized by categories that correspond to security settings illustrated in the preceding figure.

The security design and hardening guidance provided in this article is based on the guidance published in these three guides. This guidance assumes that you will use these guides as a baseline for securing and hardening your server farm.

This article describes the exceptions or additions to the snapshots that are recommended for your environment. These are detailed in table format by using the same categories and order as the three security guides. This format is intended to make it easy to identify and apply specific recommendations as you use the guides.

The guide Deployment for Windows SharePoint Services 3.0 Technology (https://go.microsoft.com/fwlink/?LinkId=76140&clcid=0x409) includes instructions for applying specific security guidance that is not covered in the patterns & practices security guides.

The nature of server-to-server communication within a server farm and the specific features provided by Windows SharePoint Services 3.0 are the primary reasons for specific hardening recommendations. This article also describes how key communication channels and Windows SharePoint Services 3.0 features affect security requirements.

Application server recommendations

In Windows SharePoint Services 3.0, application server roles are not typical middle-tier application servers that are packaged inside Enterprise Services applications. Consequently, the recommendations in Securing Your Application Server (https://msdn2.microsoft.com/en-us/library/aa302433.aspx) do not apply for Windows SharePoint Services 3.0 application servers. Instead, use the guidance provided in Securing Your Web Server (https://go.microsoft.com/fwlink/?LinkId=73705&clcid=0x409) to harden Windows SharePoint Services 3.0 application servers:

• Apply the guidance for networking and operating system settings to all application servers in the server farm. This guidance is contained in the following categories: patches and updates, services, protocols, accounts, files and directories, shares, ports, registry, and auditing and logging.

• Apply the guidance for hardening IIS and other Web settings only on the application server that hosts the Central Administration Web site. This guidance includes the following categories: IIS, Machine.config, code access security, LocalIntranet_Zone, and Internet_Zone.

In addition to using the secure snapshot in Securing Your Web Server (https://go.microsoft.com/fwlink/?LinkId=73705&clcid=0x409), also apply the recommendations provided in the Secure snapshot additions section later in this article.

Secure communication with the Microsoft SQL Server database

Securing Your Database Server (https://go.microsoft.com/fwlink/?LinkId=73706&clcid=0x409) recommends restricting access to two default Microsoft SQL Server communications ports: TCP port 1433 and UDP port 1434. For secure server farm environments, the recommendation is to:

• Block UDP port 1434 entirely.

• Configure SQL Server named instances to listen on a nonstandard port (other than TCP port 1433 or UDP port 1434).

• For additional security, block TCP port 1433 and reassign the port used by the default instance to a nonstandard port.

• Configure SQL client aliases on all front-end Web servers and application servers in the server farm. After you block TCP port 1433 or UDP port 1434, SQL client aliases are necessary on all computers that communicate with the SQL Server computer.

This approach provides a much higher degree of control over how SQL Server is deployed and run, including the ability to ensure that only authorized computers can communicate with the SQL Server computer.

The hardening steps for creating a SQL client alias must be completed prior to installing Windows SharePoint Services 3.0. When you run Setup for Windows SharePoint Services 3.0 and you are prompted to enter the name of the SQL Server computer to which to connect, you will need to enter the name of the SQL client alias.

Blocking the standard SQL Server ports

The specific ports used to connect to SQL Server are affected by whether databases are installed on a default instance of SQL Server or a named instance of SQL Server. The default instance of SQL Server listens for client requests on TCP port 1433. A named instance of SQL Server listens on a randomly assigned port number. Additionally, the port number for a named instance can be reassigned if the instance restarts (depending on if the previously assigned port number is available).

By default, client computers that connect to SQL Server first connect by using TCP port 1433. If this communication is unsuccessful, then the client computers query the SQL Server Resolution Service listening on UDP port 1434 to determine on which port the database instance is listening.

The default port-communication behavior of SQL Server introduces several issues that affect server hardening. First, the ports used by SQL Server are well-publicized ports and the SQL Server Resolution Service has been the target of buffer overrun attacks and denial-of-service attacks, including the "Slammer" worm virus. Even if SQL Server is patched to mitigate security issues in the SQL Server Resolution Service, the well-publicized ports remain a target. Second, if databases are installed on a named instance of SQL Server, the corresponding communication port is randomly assigned and can change. This behavior can potentially prevent server-to-server communication in a hardened environment. The ability to control which TCP ports are open or blocked is essential to securing your environment.

Consequently, the recommendation for a server farm is to assign static port numbers to named instances of SQL Server and to block UDP port 1434 to prevent potential attackers from accessing the SQL Server Resolution Service. Additionally, consider reassigning the port used by the default instance and blocking TCP port 1433 as well.

There are several methods you can use to block ports. You can block these ports by using a firewall. However, unless you can be sure that there are no other routes into the network segment and that there are no malicious users that have access to the network segment, the recommendation is to block these ports directly on the server that hosts SQL Server. This can be accomplished by using Windows Firewall in Control Panel.

Configuring SQL Server database instances to listen on a nonstandard port

SQL Server provides the ability to reassign the ports that are used by the default instance and any named instances. In SQL Server 2000, you reassign ports by using SQL Server Network Utility. In SQL Server 2005, you reassign ports by using SQL Server Configuration Manager.

Configuring SQL client aliases

In a server farm, all front-end Web servers and application servers are SQL Server client computers. If you block UDP port 1434 on the SQL Server computer or you change the default port for the default instance, you must configure a SQL client alias on all servers that connect to the SQL Server computer.

To connect to an instance of SQL Server 2000, you install the SQL Server client tools on the target computer and then configure the SQL client alias. You install these by running Setup for SQL Server and selecting SQL Server Client Tools.

To connect to an instance of SQL Server 2005, you install SQL Server client components on the target computer and then configure the SQL client alias by using SQL Server Configuration Manager. To install SQL Server client components, run Setup and select only the following client components to install:

• Connectivity Components

• Management Tools (includes SQL Server Configuration Manager)

SQL Server client components work with SQL Server 2000 and can be used instead of the SQL Server client tools.

Hardening steps

Configure SQL Server

Configure a SQL Server 2000 instance to listen on a nondefault port

Use SQL Server Network Utility to change the TCP port that is used by an instance of SQL Server 2000.

1. On the SQL Server computer, run SQL Server Network Utility.

2. On the Instance(s) on this server menu, select the instance. Ensure that you have selected the intended instance. By default, the default instance listens on port 1433. Named instances of SQL Server 2000 are assigned a random port number, so you might not know the current port number assigned to a named instance when you run SQL Server Network Utility.

3. In the Enabled Protocols pane on the right side of the SQL Server Network Utility interface, click TCP/IP, and then click Properties.

4. In the Network Protocol Default Value Setup dialog box, change the TCP port number. Avoid using any of the well-known TCP ports. For example, select a higher-range port number, such as 40000. Do not select the Hide Server check box.

5. Click OK.

6. In the SQL Server Network Utility dialog box, click OK. You will receive a message indicating that the change will not take effect until the SQL Server service is restarted. Click OK.

7. Restart the SQL Server service and confirm that your SQL Server computer is listening on the port you selected. You can confirm this by looking in the event viewer log after restarting the SQL Server service. Look for an information event similar to the following event:

   Event Type:Information

   Event Source:MSSQLSERVER

   Event Category:(2)

   Event ID:17055

   Date:3/6/2008

   Time:11:20:28 AM

   User:N/A

   Computer:computer_name

   Description:

   19013:

   SQL Server listening on 10.1.2.3: 40000

Configure a SQL Server 2005 instance to listen on a nondefault port

Use SQL Server Configuration Manager to change the TCP port that is used by an instance of SQL Server 2005.

1. Use SQL Server Configuration Manager to change the TCP port that is used by an instance of SQL Server 2005.

2. On the SQL Server computer, open SQL Server Configuration Manager.

3. In the left pane, expand SQL Server 2005 Network Configuration.

4. Under SQL Server 2005 Network Configuration, click the corresponding entry for the instance that you are configuring. The default instance is listed as Protocols for MSSQLSERVER. Named instances will appear as Protocols for named_instance.

5. In the right pane, right-click TCP/IP and click Properties.

6. Click the IP Addresses tab. For every IP address assigned to the SQL Server computer, there is a corresponding entry on this tab. By default, SQL Server is listening on all IP addresses assigned to the computer.

7. To globally change the port that the default instance is listening on, perform the following:

   1. For each IP except IPAll, clear all values for both TCP dynamic ports and TCP Port.

   2. For IPAll, clear the value for TCP dynamic ports. In the TCP Port field, enter the port that you want the instance of SQL Server to listen on. For example, enter 40000.

8. To globally change the port that a named instance is listening on, perform the following:

   1. For each IP including IPAll, clear all values for TCP dynamic ports. A value of 0 for this field indicates that SQL Server uses a dynamic TCP port for the IP address. A blank entry for this value means that SQL Server 2005 will not use a dynamic TCP port for the IP address.

   2. For each IP except IPAll, clear all values for TCP Port.

   3. For IPAll, clear the value for TCP dynamic ports. In the TCP Port field, enter the port that you want the instance of SQL Server to listen on. For example, enter 40000.

9. Click OK. You will receive a message indicating that the change will not take effect until the SQL Server service is restarted. Click OK.

10. Close SQL Server Configuration Manager.

11. Restart the SQL Server service and confirm that the SQL Server computer is listening on the port you selected. You can confirm this by looking in the event viewer log after restarting the SQL Server service. Look for an information event similar to the following event:

    Event Type:Information

    Event Source:MSSQL$MSSQLSERVER

    Event Category:(2)

    Event ID:26022

    Date:3/6/2008

    Time:1:46:11 PM

    User:N/A

    Computer:computer_name

    Description:

    Server is listening on [ 'any' <ipv4>50000]

Configure Windows Firewall

Configure Windows Firewall to block default SQL Server listening ports

1. In Control Panel, open Windows Firewall.

2. On the General tab, click On. Ensure that the Don't allow exceptions check box is cleared.

3. On the Exceptions tab, click Add Port.

4. On the Add a Port dialog box, enter a name for the port. For example, enter UDP-1434. Then, enter the port number. For example, enter 1434.

5. Select the appropriate option button: UDP or TCP. For example, to block port 1434, click UDP. To block port 1433, click TCP.

6. Click Change Scope and ensure that the scope for this exception is set to Any computer (including those on the Internet).

7. Click OK.

8. On the Exceptions tab, locate the exception you created. To block the port, clear the check box for this exception. By default, this check box is selected, which means that the port is open.

Configure Windows Firewall to open manually assigned ports

1. Follow steps 1-7 in the previous procedure to create an exception for the port you manually assigned to a SQL instance. For example, create an exception for TCP port 40000.

2. On the Exceptions tab, locate the exception you created. Ensure that the check box for the exception is checked. By default, this check box is selected, which means that the port is open.

   Note

   For more information about using Internet Protocol security (IPsec) to secure communication to and from your SQL Server computer, see the Microsoft Knowledge Base article 233256: How to Enable IPSec Traffic Through a Firewall (https://go.microsoft.com/fwlink/?LinkId=76142&clcid=0x409).

Configure a SQL client alias

Configure a SQL client alias

If you block UDP port 1434 or TCP port 1433 on the SQL Server computer, you must create a SQL client alias on all other computers in the server farm. You can use SQL Server client components to create a SQL client alias for computers that connect to SQL Server 2000 or SQL Server 2005.

1. Run Setup for SQL Server 2005 on the target computer and select the following client components to install:

   1. Connectivity Components

   2. Management Tools

2. Open SQL Server Configuration Manager.

3. In the left pane, click SQL Native Client Configuration.

4. In the right pane, right-click Aliases, and select New Alias.

5. In the Alias dialog box, enter a name for the alias and then enter the port number for the database instance. For example, enter SharePoint_alias.

6. In the Port No field, enter the port number for the database instance. For example, enter 40000. Ensure that the protocol is set to TCP/IP.

7. In the Server field, enter the name of the SQL Server computer.

8. Click Apply, and then click OK.

Test the SQL client alias

Test connectivity to the SQL Server computer by using Microsoft SQL Server Management Studio, which is available by installing SQL Server client components.

1. Open SQL Server Management Studio.

2. When you are prompted to enter a server name, enter the name of the alias that you created, and then click Connect. If the connection is successful, SQL Server Management Studio is populated with objects that correspond to the remote database.

   Note

   To check connectivity to additional database instances from within SQL Server Management Studio, click the Connect button and select Database Engine.

File and Printer Sharing service requirements

Several core features depend on the File and Printer Sharing service and the corresponding protocols and ports. These include, but are not limited to, the following:

• Search queries   All search queries require the File and Printer Sharing service.

• Crawling and indexing content   To crawl content, the index component sends requests through the front-end Web server. The front-end Web server communicates with content databases directly and sends results back to the index server. This communication requires the File and Printer Sharing service.

The File and Printer Sharing service requires the use of named pipes. Named pipes can communicate by using either direct-hosted SMB or NBT protocols. For a secure environment, direct-hosted SMB is recommended instead of NBT. The hardening recommendations provided in this article assume that SMB is used.

The following table describes the hardening requirements that are introduced by the dependency on the File and Printer Sharing service.

For more information about disabling NBT, see the Microsoft Knowledge Base article 204279: Direct hosting of SMB over TCP/IP (https://go.microsoft.com/fwlink/?LinkId=76143&clcid=0x409).

Service requirements for e-mail integration

E-mail integration requires the use of two services:

• Simple Mail Transfer Protocol (SMTP) service

• Microsoft SharePoint Directory Management Service

SMTP service

E-mail integration requires the use of the SMTP service on at least one of the front-end Web servers in the server farm. The SMTP service is required for incoming email. For outgoing e-mail, you can either use the SMTP service or route outgoing email through a dedicated e-mail server in your organization, such as a Microsoft Exchange Server computer.

Microsoft SharePoint Directory Management Service

Windows SharePoint Services 3.0 includes an internal service, the Microsoft SharePoint Directory Management Service, for creating e-mail distribution groups.

When you configure e-mail integration, you have the option to enable the Directory Management Service feature, allowing users to create distributions lists. When users create a SharePoint group and they select the option to create a distribution list, the Microsoft SharePoint Directory Management Service creates the corresponding Active Directory directory service distribution list in the Active Directory environment.

In security-hardened environments, the recommendation is to restrict access to the Microsoft SharePoint Directory Management Service by securing the file associated with this service, which is SharePointEmailws.asmx. For example, allow access to this file by the server farm account only.

Additionally, this service requires permissions in the Active Directory environment to create Active Directory distribution list objects. The recommendation is to setup a separate organizational unit in Active Directory for SharePoint objects. Only this organizational unit should allow write access to the account used by the Microsoft SharePoint Directory Management Service.

Windows SharePoint Services services

Do not disable services that are installed by Windows SharePoint Services 3.0. The following services are installed on all front-end Web servers and application servers and appear in the Microsoft Management Console (MMC) Services snap-in (alphabetical order):

• Windows SharePoint Services Administration

• Windows SharePoint Services Search

• Windows SharePoint Services Timer

• Windows SharePoint Services Tracing

• Windows SharePoint Services VSS Writer

If your environment disallows services that run as a local system, you can consider disabling the Windows SharePoint Services Administration service only if you are aware of the consequences and can work around these. This service is a Win32 service that runs as a local system.

This service is used by the Windows SharePoint Services Timer service to perform actions that require administrative privileges on the server, such as create IIS Web sites, deploy code, and stop and start services. If you disable this service, you cannot run deployment-related tasks from the Central Administration site. You will need to use the Stsadm.exe command-line tool and run the execadminsvcjobs command to complete multi-server deployments for Windows SharePoint Services 3.0 and to run other deployment-related tasks.

Accounts and groups

The secure snapshots in the patterns & practices security guides provide recommendations for securing accounts and groups.

For recommendations on planning for accounts, see Plan for administrative and service accounts (Windows SharePoint Services).

For recommendations on planning for administrative and user roles, see Plan for security roles (Windows SharePoint Services).

Web.config file

The .NET Framework, and ASP.NET in particular, uses XML-formatted configuration files to configure applications. The .NET Framework relies on configuration files to define configuration options. The configuration files are text-based XML files. Multiple configuration files can, and typically do, exist on a single system.

System-wide configuration settings for the .NET Framework are defined in the Machine.config file. The Machine.config file is located in the %SystemRoot%\Microsoft.NET\Framework\%VersionNumber%\CONFIG\ folder. The default settings that are contained in the Machine.config file can be modified to affect the behavior of applications that use the .NET Framework on the whole system. For recommendations about configuring Machine.config files, see Securing Your Web Server (https://go.microsoft.com/fwlink/?LinkId=73705&clcid=0x409).

You can change the ASP.NET configuration settings for a single application if you create a Web.config file in the root folder of the application. When you do this, the settings in the Web.config file override the settings in the Machine.config file.

When you extend a Web application by using Central Administration, Windows SharePoint Services 3.0 automatically creates a Web.config file for the Web application.

The Secure snapshot additions section later in this article lists recommendations for configuring Web.config files. These recommendations are intended to be applied to each Web.config file that is created, including the Web.config file for the Central Administration site.

For more information about ASP.NET configuration files and editing a Web.config file, see ASP.NET Configuration (https://go.microsoft.com/fwlink/?LinkID=73257&clcid=0x409).

Secure snapshot additions

This section lists the additions to snapshots in the patterns & practices security guides that are recommended for Windows SharePoint Services 3.0 environments. These are detailed in table format by using the same categories and order as the patterns & practices security guides.

This format is intended to make it easy to identify and apply specific recommendations as you use the patterns & practices security guides. Except for a few noted exceptions, these hardening recommendations are intended to be applied before running Setup for Windows SharePoint Services 3.0.

For more information about communication between specific server roles in a server farm, see Plan security hardening for extranet environments (Windows SharePoint Services).

Securing your network snapshot additions

The following table describes recommendations for securing your network additions.

Securing your Web server snapshot additions

The following table describes recommendations for securing your Web server additions.

Securing your database server snapshot additions

The following table describes recommendations for securing your database server additions.

Download this book

This topic is included in the following downloadable book for easier reading and printing:

• Planning and architecture for Windows SharePoint Services 3.0, part 2

• Planning an Extranet Environment for Windows SharePoint Services

• Security for Windows SharePoint Services 3.0

See the full list of available books at Downloadable books for Windows SharePoint Services.