The key to a secure SharePoint installation is limiting the number of nonessential services on your servers. Be thoughtful in your server farm design and limit the external exposure of critical services, such as SQL Server connections. In addition, Windows Updates are imperative to hardening the Windows Server operating system.
If your server farm is Internet-facing, use caution when configuring the Windows Server system. When possible, restrict access to nonessential ports using firewalls or the Windows Server native IP Security Policies MMC snap-in. This book obviously cannot provide a comprehensive list of ports, but the following ports should be the minimum set that have restricted access:
NetBIOS ports 135, 137–139, and SMB port 445 The NetBIOS and SMB ports provide basic functionality, such as file and print sharing, but they can also be an entry point for hackers. For this reason, restrict these ports to internal use only. These ports should be blocked on externally facing firewalls or routers or restricted with the native IP Security Policies.
Caution | Much of the intra-farm communication, such as index propagation, is via NetBIOS, so never restrict NetBIOS traffic between SharePoint servers in the same farm. You should only restrict inbound NetBIOS access. |
SQL Server ports 1433 and 1434 You should restrict access to TCP 1433 and UDP 1434 to prevent malicious hackers and code, such as the Slammer Worm, also known as W32.Slammer, from unauthorized access. Worms like this one are self-propagating and can infect an entire network within hours. Depending on the payload programmed into the worm, it can have devastating effects. You should also limit the access to your SQL Server installation to prevent authenticated, but unauthorized activity from those within your organization. If your servers exist in different, secured subnets, then consider encrypting all intra-farm traffic with IPsec. For example, if your WFEs are in a dedicated subnet, encrypting traffic to the SQL Server and SharePoint application servers further secures your installation. Optionally, you can open firewall or router ports to allow this intra-farm installation.
For more information on selecting IPSec peer authentication, browse to http://go.microsoft.com/fwlink/?LinkId=76093&clcid=0x409, "Selecting IPSec Authentication Methods."
For information on isolating services via IP Security Policies, see http://www.microsoft.com/technet/security/guidance/architectureanddesign/ipsec/default.mspx.
Central Administration TCP Port The port selected during installation should be protected and isolated to a single subnet when possible. Verify that your firewall or router Access Control Lists (ACLs) do not allow external access to this port. If your server farm is managed remotely, consider using Virtual Private Networks (VPNs) or Windows Terminal Services to manage your farm via Central Administration. Figure 7-11 shows an example of Central Administration and the TCP port it uses.
Tip | You should never change the Central Administration TCP port via IIS Manager. To correctly change the TCP port, execute Stsadm -o setadminport -port <port>. |
Shared Services Provider TCP Port The Shared Services Provider (SSP) TCP port should be restricted in much the same way as Central Administration. Exceptions should be made for the administrators of the SSP. You will probably want to delegate administration of Search, Indexing, User profiles, and similar tasks to someone other than yourself. For this reason, be careful not to exclude the IP address address or range of which the SSP administrators are a part.
Note | Although you want to create a dedicated Web application to ease disaster recovery of My Sites, this practice also allows you to restrict access to SSP Administration when My Sites are not placed in the same Web application. Otherwise, the SSP Web application TCP port must be open to allow My Site access to users. |
Figure 7-11: The TCP port number used by Central Administration appears after the "-" in the URL.
You can isolate and effectively protect your server farm by exclusively using Windows Server IP Security Policies, but this practice does not scale well. Using IP Security Policies in a large environment can introduce complexities with inter-server processes and client-server processes. For this reason, most medium-scale and larger implementations protect the majority of their server surface area with firewalls, routers, and proxy servers. The following is an example of securing a medium-scale server farm.
To properly secure a medium-scale server farm, consider placing the Web front-end (WFE) servers in a screened subnet, with the SQL Server and Application servers in a different, well-secured subnet.
For more information on screened subnets, browse to http://www.microsoft.com/technet/security/bestprac/bpent/sec3/datasec.mspx.
If security is paramount in your organization, you can use two screened subnets to further secure your network. In Figure 7-12, IPSec is used only intra-farm, not for all traffic. The additional firewall protects the SQL Server from vulnerabilities.
Figure 7-12: Isolate the Web front ends and SQL Server traffic to reduce the external surface area available to hackers.