Plan security hardening (SharePoint Foundation 2010)
Applies to: SharePoint Foundation 2010
This article describes security hardening for Microsoft SharePoint Foundation 2010 Web server, application server, and database server roles, and gives detailed guidance about the specific hardening requirements for ports, protocols, and services in Microsoft SharePoint 2010 Products.
In this article:
Secure server snapshots
Specific port, protocol, and service guidance
Secure server snapshots
In a server farm environment, individual servers play specific roles. Security hardening recommendations for these servers depend on the role each server plays. This article contains secure snapshots for two categories of server roles:
Web server and application server roles
Database server role
The snapshots are divided into common configuration categories. The characteristics defined for each category represent the optimal hardened state for Microsoft SharePoint 2010 Products. This article does not include hardening guidance for other software in the environment.
Web server and application server roles
This section identifies hardening characteristics for Web servers and application servers. Some of the guidance applies to specific service applications; in these cases, the corresponding characteristics need to be applied only on the servers that are running the services associated with the specified service applications.
| Category | Characteristic |
|---|---|
Services listed in the Services MMC snap-in |
Enable the following services:
Ensure that these services are not disabled:
Ensure that these services are not disabled on the servers that host the corresponding roles:
|
Ports and protocols |
|
Registry |
No additional guidance |
Auditing and logging |
If log files are relocated, ensure that the log file locations are updated to match. Update directory access control lists (ACLs) also. |
Code access security |
Ensure that you have a minimal set of code access security permissions enabled for your Web application. The <trust> element in the Web.config file for each Web application should be set to WSS_Minimal (where WSS_Minimal has its low defaults as defined in 14\config\wss_minimaltrust.config or by your own custom policy file, which is minimally set.) |
Web.config |
Follow these recommendations for each Web.config file that is created after you run Setup:
|
Database server role
The primary recommendation forSharePoint 2010 Products is to secure inter-farm communication by blocking the default ports used for Microsoft SQL Server communication and establishing custom ports for this communication instead. For more information about how to configure ports for SQL Server communication, see Blocking the standard SQL Server ports, later in this article.
| Category | Characteristic |
|---|---|
Ports |
|
This article does not describe how to secure SQL Server. For more information about how to secure SQL Server, see Securing SQL Server (https://go.microsoft.com/fwlink/p/?LinkId=186828).
Specific port, protocol, and service guidance
The rest of this article describes in greater detail the specific hardening requirements for SharePoint 2010 Products.
In this section:
Blocking the standard SQL Server ports
Service application communication
File and Printer Sharing service requirements
Service requirements for e-mail integration
SharePoint 2010 Products services
Web.config file
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 is restarted (depending on whether 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, the client computers query the SQL Server Resolution Service that is listening on UDP port 1434 to determine the port on which 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 updated 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.
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 2005 and SQL Server 2008, you reassign ports by using SQL Server Configuration Manager.
Configuring SQL Server 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 Server client alias on all servers that connect to the SQL Server computer.
To connect to an instance of SQL Server 2005 or SQL Server 2008, you install SQL Server client components on the target computer and then configure the SQL Server 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)
For specific hardening steps for blocking the standard SQL ports, see Harden SQL Server for SharePoint environments (SharePoint Foundation 2010).
Service application communication
By default, communication between Web servers and service applications within a farm takes place by using HTTP with a binding to port 32843. When you publish a service application, you can select either HTTP or HTTPS with the following bindings:
HTTP binding: port 32843
HTTPS binding: port 32844
Additionally, third parties that develop service applications can implement a third choice:
- net.tcp binding: port 32845
You can change the protocol and port binding for each service application. On the Service Applications page in Central Administration, select the service application, and then click Publish.
Communication between service applications and SQL Server takes place over the standard SQL Server ports or the ports that you configure for SQL Server communication.
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, servers that include crawl components send requests through the front-end Web server. The front-end Web server communicates with content databases directly and sends results back to the servers that include crawl components. 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 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 | Requirements | Notes |
|---|---|---|
Services |
File and Printer Sharing |
Requires the use of named pipes. |
Protocols |
Named pipes that use direct-hosted SMB Disable NetBT |
Named pipes can use NetBT instead of direct-hosted SMB. However, NetBT is not considered as secure as direct-hosted SMB. |
Ports |
Either of the following:
|
Disable NetBT (ports 137, 138, and 139) if it is not being used |
For more information about how to disable NetBT, see the Microsoft Knowledge Base article 204279, Direct hosting of SMB over TCP/IP (https://go.microsoft.com/fwlink/p/?LinkId=76143).
Service requirements for e-mail integration
E-mail integration requires the use of two services:
SMTP service
Microsoft SharePoint Directory Management service
SMTP service
E-mail integration requires the use of the Simple Mail Transfer Protocol (SMTP) service on at least one of the front-end Web servers in the server farm. The SMTP service is required for incoming e-mail. 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
SharePoint 2010 Products include 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, which lets users create distribution 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 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, you might 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 set up a separate organizational unit (OU) in Active Directory for SharePoint 2010 Products objects. Only this OU should allow write access to the account that is used by the Microsoft SharePoint Directory Management Service.
SharePoint 2010 Products services
Do not disable services that are installed by SharePoint 2010 Products (listed in the snapshot previously).
If your environment disallows services that run as a local system, you can consider disabling the SharePoint 2010 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 SharePoint 2010 Timer service to perform actions that require administrative permissions on the server, such as creating Internet Information Services (IIS) Web sites, deploying code, and stopping and starting services. If you disable this service, you cannot complete deployment-related tasks from the Central Administration site. You must use Windows PowerShell to run the Start-SPAdminJob cmdlet (or use the Stsadm.exe command-line tool to run the execadmsvcjobs operation) to complete multiple-server deployments for SharePoint 2010 Products and to run other deployment-related tasks.
Web.config file
The .NET Framework, and ASP.NET in particular, use 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.
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, SharePoint 2010 Products automatically create a Web.config file for the Web application.
The Web server and application server snapshot presented earlier 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/p/?LinkID=73257).
See Also
Other Resources
Resource Center: Security and Authentication for SharePoint Foundation 2010