Plan security hardening for SharePoint 2013
Applies to: SharePoint Server 2013, SharePoint Foundation 2013
Topic Last Modified: 2014-10-23
Summary: Learn about security hardening for SharePoint web server, application server, and database server roles, including specific hardening requirements for ports, protocols, and services.
In this article:
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:
The snapshots are divided into common configuration categories. The characteristics defined for each category represent the optimal hardened state for SharePoint 2013. This article does not include hardening guidance for other software in the environment.
In addition to hardening servers for specific roles, it is important to protect the SharePoint farm by placing a firewall between the farm servers and outside requests. The guidance in this article can be used to configure a firewall.
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.
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
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.
Follow these recommendations for each Web.config file that is created after you run Setup:
The primary recommendation for SharePoint 2013 is to secure inter-farm communication by blocking the default ports used for 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.
This article does not describe how to secure SQL Server. For more information about how to secure SQL Server, see Securing SQL Server (http://go.microsoft.com/fwlink/p/?LinkId=186828).
The rest of this article describes in greater detail the specific hardening requirements for SharePoint 2013.
In this section:
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 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 1433. If this communication is unsuccessful, the client computers query the SQL Server Resolution Service that is listening on UDP 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 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 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.
SQL Server provides the ability to reassign the ports that are used by the default instance and any named instances. In SQL Server, you reassign ports by using SQL Server Configuration Manager.
In a server farm, all front-end Web servers and application servers are SQL Server client computers. If you block UDP 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. In this scenario, the SQL Server client alias specifies the TCP port that the named instance is listening on.
To connect to an instance of SQL Server, 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:
Management Tools (includes SQL Server Configuration Manager)
For specific hardening steps for blocking the standard SQL Server ports, see Configure SQL Server security for SharePoint 2013 environments.
By default, communication between Web servers and service applications within a farm takes place by using HTTP with a binding to TCP 32843. When you publish a service application, you can select either HTTP or HTTPS with the following bindings:
HTTP binding: TCP 32843
HTTPS binding: TCP 32844
Additionally, third parties that develop service applications can implement a third choice:
net.tcp binding: TCP 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.
The HTTP/HTTPS/net.tcp bindings can also be viewed and changed using the Get-SPServiceHostConfig and Set-SPServiceHostConfig PowerShell cmdlets.
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.
The User Profile service application uses the Forefront Identity Management agent to synchronize profiles between SharePoint 2013 and Active Directory or a Lightweight Directory Access Protocol (LDAP) directory service. The Forefront Identity Management agent is installed on all servers in a SharePoint farm, but is only required on the server that is set up to synchronize with the directory store.
The Forefront Identity Management agent includes the following two services that must remain enabled on the server that is set up to crawl Active Directory or another directory store:
Forefront Identity Manager service
Forefront Identity Manager Synchronization service
Additionally, TCP 5725 must be open on the server that runs the Forefront Identity Management agent and is set up to crawl a directory store.
In Active Directory environments, the following ports must remain open for communication between the SharePoint 2013 server that synchronizes with the directory store and the server that is running Active Directory:
TCP&UDP 389 (LDAP service)
TCP&UDP 88 (Kerberos)
TCP&UDP 53 (DNS)
UDP 464 (Kerberos Change Password)
For more information about hardening requirements for the Forefront Identity Management agent, including port requirements for other directory types, see Management Agent Communication Ports, Rights, and Permissions (http://go.microsoft.com/fwlink/p/?LinkId=186832).
Several features of SharePoint Server 2013 can be configured to access data that resides on server computers outside of the server farm. If you configure access to data that is located 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 databases typically use OLE DB.
Connections to Web services use both HTTP and HTTPS.
The following table lists features that can be configured to access data that resides on server computers outside the server farm.
You can configure crawl rules to crawl data that resides on external resources, including Web sites, file shares, Exchange public folders, and business data applications. When crawling external data sources, the crawl role communicates directly with these external resources.
For more information, see Manage crawling in SharePoint Server 2013.
Business Data Connectivity connections
Web servers and application servers communicate directly with computers that are configured for Business Data Connectivity connections.
For more information, see Plan for Business Connectivity Services in SharePoint 2013.
Receiving Microsoft Office Excel workbooks
If workbooks opened in Excel Services Application connect to any external data sources (for example, Analysis Services and SQL Server), appropriate TCP ports need to be opened for connecting to these external data sources. For more information, see Overview of Excel Services in SharePoint Server 2013.
If Universal Naming Convention (UNC) paths are configured as trusted locations in Excel Services Application, the Excel Calculation Services application role uses the protocols and ports used by the File and Printer Sharing service to receive Office Excel workbooks over a UNC path.
Workbooks that are stored in content databases or that are uploaded or downloaded from sites by users are not affected by this communication.
E-mail integration requires the use of two services:
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.
SharePoint 2013 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, 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 2013 objects. Only this OU should allow write access to the account that is used by the Microsoft SharePoint Directory Management Service.
Both Project Server 2013 and InfoPath Forms Services maintain session state. If you are deploying these features or products within your server farm, do not disable the ASP.NET State service. Additionally, if you are deploying InfoPath Forms Services, do not disable the View State service.
Do not disable services that are installed by SharePoint 2013 (listed in the snapshot previously).
If your environment disallows services that run as a local system, you can consider disabling the SharePoint 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 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 2013 and to run other deployment-related tasks.
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 2013 automatically creates 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 (http://go.microsoft.com/fwlink/p/?LinkID=73257).