Plan security hardening for server roles within a server farm (Search Server 2008)

Applies To: Microsoft Search Server 2008

 

Topic Last Modified: 2009-08-04

Note

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

In this article:

  • About security hardening

  • Application server recommendations

  • Secure communication with the Microsoft SQL Server database

  • File and Printer Sharing service requirements

  • Office Server Web services

  • Connections to external servers

  • Search Server 2008 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:

  • External secure access

  • 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 the recommendations provided in the following security guidance in Microsoft patterns & practices:

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 also, starting with applying patches and updates, then hardening networking settings and operating system settings, and then application-specific hardening. For example, Securing Your Web Server 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 following figure illustrates categories of security settings that are methodically prescribed in Securing Your Web Server.

Categories of security settings

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 previous figure.

The security design and hardening guidance provided in this article are 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 we recommend for your environment. These are described in table format by using the same categories and order as the three security guides. This format is intended to make it easy to determine and apply specific recommendations as you use the guides.

The guide Deployment for Search Server 2008 includes instructions for applying specific security guidance that is not covered in the Microsoft patterns & practices security guides.

The nature of server-to-server communication in a server farm and the specific features that are provided by Microsoft Search Server 2008 are the primary reasons for specific hardening recommendations. This article also describes how key communication channels and Search Server 2008 features affect security requirements.

Application server recommendations

Note

The information in this section does not apply to Microsoft Search Server 2008 Express. It applies to the full version of Microsoft Search Server 2008 only.

In Search Server 2008, 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 do not apply for Search Server 2008 application servers. Instead, use the guidance provided in Securing Your Web Server to harden Search Server 2008 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, 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 recommends restricting access to two default Microsoft SQL Server communications ports: TCP port 1433 and UDP port 1434. For more secure server farm environments, we recommend that you do the following:

  • Block UDP port 1434 completely.

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

  • For additional security, block TCP port 1433 and reassign the port that is used by the default instance to a non-standard 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 computer that is running SQL Server.

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

The hardening steps for creating a SQL client alias must be completed before you install Search Server 2008. When you run Setup for Search Server 2008 and you are prompted to enter the name of the SQL Server computer to which to connect, you must enter the name of the SQL client alias.

Blocking the standard SQL Server ports

The specific ports that are 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 that are used by SQL Server are well-publicized ports and the SQL Server Resolution Service is the target of buffer overrun attacks and denial-of-service attacks, including the "Slammer" worm virus. Even if SQL Server is patched to reduce 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 necessary to help secure 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 a potential attacker from accessing the SQL Server Resolution Service. Additionally, consider reassigning the port that is used by the default instance and blocking TCP port 1433 also.

There are several methods that you can use to block ports. You can block these ports by using a firewall. However, unless you will know for 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 done by using Windows Firewall in Control Panel.

Configuring SQL Server database instances to listen on a non-standard 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 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 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 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. Therefore, you might not know the current port number assigned to a named instance when you run Server Network Utility.

  3. In the Enabled Protocols pane on the right side of the 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 Server Network Utility dialog box, click OK. You will receive a message that states 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 that 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 non-default 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 then 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 that states 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 that 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 that 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 that you manually assigned to a SQL instance. For example, create an exception for TCP port 40000.

  2. On the Exceptions tab, locate the exception that 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 how to use Internet Protocol security (IPsec) to help secure communication to and from your SQL Server computer, see the Microsoft Knowledge Base article 233256: How to Enable IPSec Traffic Through a Firewall.

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 in 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 internal 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.

  • Index propagation If the query role is installed on a different server than the index role, the index server copies content indexes to the query servers. This action requires the File and Printer Sharing service and the corresponding protocols and ports.

The File and Printer Sharing service requires you to use named pipes. Named pipes can communicate by using either direct-hosted SMB or NetBIOS over TCP/IP (NetBT) protocols. For a secure environment, direct-hosted SMB is recommended instead of NetBT. 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.

Category Requirement Notes

Services

File and Printer Sharing

Requires use of named pipes.

Protocols

Named pipes that use direct-hosted SMB

Disable NBT

Named pipes can use NBT instead of direct-hosted SMB. However, NBT is not considered as secure as direct-hosted SMB.

Ports

TCP/UDP port 445

Used by direct-hosted SMB.

For more information about disabling NBT, see the Microsoft Knowledge Base article 204279: Direct hosting of SMB over TCP/IP.

Office Server Web services

Note

The information in this section does not apply to Microsoft Search Server 2008 Express. It applies to the full version of Microsoft Search Server 2008 only.

The Office Services Web service is used by Search Server 2008 as a communication channel between Web servers and application servers. This service uses the following ports:

  • TCP 56737

  • TCP/SSL 56738

Connections to external servers

Search Server 2008 can be configured to access content that resides on server computers outside the server farm. If you configure access to content on external server computers, ensure that you enable communication between the appropriate computers. In most cases, the ports, protocols, and services that are used depend on the external resource. For example:

  • Connections to file shares use the File and Printer Sharing service.

  • Connections to external SQL Server databases use the default or customized ports for SQL Server communication.

  • Connections to Oracle typically use OLE DB.

  • Connections to Web services use both HTTP and HTTPS.

The following table lists features that can be configured to access content that resides on server computers outside the server farm.

Feature Description

Content Crawling

You can configure crawl rules to crawl content that resides on external resources, including Web sites, file shares, and Exchange public folders. When crawling external content sources, the index role communicates directly with these external resources.

For more information, see Plan to crawl content (Search Server 2008).

Search Server 2008 services

Do not disable services that are installed by Search Server 2008.

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):

  • Office SharePoint Server Search

  • 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 them. 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 credentials on the server, such as to 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 have to use the Stsadm.exe command-line tool and run the execadminsvcjobs command to complete multi-server deployments for Search Server 2008, and to run other deployment-related tasks.

Accounts and groups

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

For recommendations about how to plan for accounts, see Plan for administrative and service accounts (Search Server 2008).

For recommendations about how to plan for administrative and user roles, see Plan for security roles (Search Server 2008).

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 on the whole system that use the .NET Framework. For recommendations about how to configure Machine.config files, see Securing Your Web Server.

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, Search Server 2008 automatically creates a Web.config file for the Web application.

The Secure snapshot additions section later in this topic 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.

Secure snapshot additions

This section lists the additions to snapshots in the Microsoft patterns & practices security guidance that we recommend for Search Server 2008 environments. These are described 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 determine and apply specific recommendations as you use the Microsoft patterns & practices security guides. Except for some noted exceptions, these hardening recommendations are intended to be applied before you run Setup for Search Server 2008.

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

Securing the network snapshot additions

The following table describes recommendations for securing the network additions.

Component Characteristic exception

All

No additional recommendations

Securing your Web server snapshot additions

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

Component Characteristic

Services

Enable:

  • File and Printer Sharing

  • Office SharePoint Server Search

  • World Wide Web Publishing Service

Ensure these services remain enabled after you run Setup:

  • Office SharePoint Server Search

  • Windows SharePoint Services Administration

  • Windows SharePoint Services Search

  • Windows SharePoint Services Timer

  • Windows SharePoint Services Tracing

  • Windows SharePoint Services VSS Writer

Protocols

Enable:

  • SMB

Disable:

  • NetBT

Accounts

If the Microsoft Directory Management Service is enabled as part of e-mail integration, configure your Active Directory environment to allow write access to the account that is used by the Microsoft Directory Management Service (the server farm account).

For additional guidance about how to configure accounts, see Plan for administrative and service accounts (Search Server 2008) for Search Server 2008 account requirements and recommendations.

Shares

No additional recommendations

Ports

  • Open TCP/UDP port 445.

  • Open TCP ports 56737 and 56738 for the Office Server Web services.

  • If UDP port 1434 is blocked on the SQL Server computer and databases are installed on a named instance, configure a SQL client alias for connecting to the named instance.

  • If TCP port 1433 is blocked on the SQL Server computer and databases are installed on the default instance, configure a SQL client alias for connecting to the named instance.

  • Ensure that ports remain open for Web applications that can be accessed by users.

  • Block external access to the port that is used for the Central Administration site.

Auditing and logging

If log files are relocated, ensure that the log file locations are updated to match.

IIS

See guidance for IIS later in this topic.

Sites and virtual directories

No additional recommendations

Script mappings

No additional recommendations

ISAPI filters

No additional recommendations

IIS metabase

No additional recommendations

.NET Framework

See guidance for the .NET Framework later in this topic.

Machine.config: HttpForbiddenHandler

No additional recommendations

Machine.config: Remoting

No additional recommendations

Machine.config: Trace

No additional recommendations

Machine.config: compilation

No additional recommendations

Machine.config: customErrors

No additional recommendations

Machine.config: sessionState

No additional recommendations

Code access security

Ensure that you have a minimal set of code access security permissions enabled for your Web application. (The <trust> element in Web.config for each Web application should be set to WSS_Minimal (where WSS_Minimal has its low defaults as defined in 12\config\wss_minimaltrust.config) or your own custom policy file, which is minimally set.)

LocalIntranet_Zone

No additional recommendations

Internet_Zone

No additional recommendations

Web.config

Apply the following recommendations to each Web.config file that is created after you run Setup:

  • Do not allow compilation or scripting of database pages via the PageParserPaths elements.

  • Ensure <SafeMode> CallStack=""false"" and AllowPageLevelTrace=""false"".

  • Ensure that the Web Part limits around maximum controls per zone is set low.

  • Ensure that the SafeControls list is set to the minimum set of controls that that you must have for your sites.

  • Ensure that your Workflow SafeTypes list is set to the minimum level of SafeTypes needed.

  • Ensure that customErrors is turned on (<customErrors mode=""On""/>).

  • Consider your Web proxy settings as needed (<system.net>/<defaultProxy>).

  • Set the upload.aspx limit to the highest size that you reasonably expect users to upload (default is 2 GB). Performance can be affected by uploads larger than 100 MB.

Securing your database server snapshot additions

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

Component Characteristic exception

Services

No additional recommendations

Protocols

No additional recommendations

Accounts

Manually and regularly remove unused accounts.

Files and directories

No additional recommendations

SQL Server settings

See guidance for SQL Server settings later in this topic.

Shares

No additional recommendations

Ports

  • Block UDP port 1434.

  • Consider blocking TCP port 1433.

Registry

No additional recommendations

Auditing and logging

No additional recommendations

SQL Server security

No additional recommendations

SQL Server logins, users, and roles

No additional recommendations

SQL Server database objects

No additional recommendations

See Also

Concepts

Plan server farm security (Search Server 2008)
Review the secure topology design checklists (Search Server 2008)
Plan for secure communication within a server farm (Search Server 2008)
Plan security hardening for an extranet (Search Server 2008)