Securing Servers and Farms

It would be remiss to begin a chapter on securing SharePoint without discussing a critical security component that is often overlooked and taken for granted—the password. As is the case with security in the physical world, most crimes are committed against persons and organizations by people we know. When administration, user, and default passwords stay the same for too long, inevitably someone with that knowledge and a grudge is going to do harm. Having a strict policy of changing passwords on a regular basis and making those passwords strong is still one of the best defenses we have against a potential security breach.

A password weakness can exist at either the Active Directory level or the local machine level, and both can be exploited by malware/viruses or an insider. Additionally, the presence of the single sign-on feature, which is also discussed in this chapter, means a compromise of one password may lead to a compromise of data on other systems.

Be sure to enforce a strict password policy for all users on your domain. Your policy should include both complexity requirements as well as password expiration.

You may want to consider implementing a policy to periodically test passwords across the enterprise. There are great tools for this such as THC Hydra, LophtCrack, and others that can check for blank and simple passwords.

Although this is an important topic, we have to limit the scope of this chapter to focus on configuring SharePoint security, but remember that your system is only as secure as its weakest link.

Internet/extranet portals and sites

Internet and extranet portals and sites are probably the most exposed to security threats by nature of their accessibility on the Internet. This section discusses the following areas:

• Securing your server farm against risks present in an anonymous access environment

• How to secure server-to-server communications when publishing content between internal and external servers and server farms

Securing servers in an anonymous access environment

When anonymous access is enabled on a Web site, anonymous users are able to browse the site, including lists, libraries, folders within lists and libraries, list items, or documents that inherit their permissions from the site. Once anonymous access has been enabled by the server administrator, it allows members of the site’s Owners group to grant anonymous access to lists and libraries on a site or to block anonymous access on a site. A word of caution is appropriate with regard to granting anonymous access because it is inherently less secure. Anytime you expose a site to unauthenticated users there are more chances for hackers to try to access or deny service to your site.

Granting anonymous access is not recommended in an intranet environment because there are limitations, security risks, and other issues of concern. A better way to grant broad access to content in an intranet is via the Authenticated Users group. When you add this group for access, all authenticated users can access the site, and their actions can be traced back to who was logged in.

Enabling anonymous access using central administration

To enable anonymous access using the central administration utility, follow these steps:

1.	From the server desktop click Start Programs Administrative Tools SharePoint 3.0 Central Administration.
2.	In Central Administration click Application Management in the left navigation or click the tab on top.
3.	Under Application Security click Authentication providers.
4.	Click the zone for which you would like to enable anonymous access.

5.	From the Edit Authentication page, as shown in Figure 10.1, click the box to enable Anonymous Access and then click Save. Figure 10.1. Edit Authentication page [View full size image]

To enable Anonymous Access in the site:

1.	From the home page of the MOSS 2007 site to grant the anonymous access, click Site Actions Site Settings Modify All Site Settings.
2.	Under Users and Permissions click Advanced permissions.
3.	Click Settings Anonymous Access and the page shown in Figure 10.2 appears. Figure 10.2. Change Anonymous Access Settings [View full size image]

The Anonymous Access Settings page allows you to specify what parts of your Web site (if any) anonymous users can access. If you select Entire Web site, anonymous users can view all pages in your Web site and view all lists and items which inherit permissions from the Web site. If you select the Lists and libraries option, anonymous users can view and change items only for those lists and libraries that have enabled permissions for anonymous users.

Securing server-to-server communications during content publishing

One of the new scenarios available with SharePoint 2007 is the ability to use features that were previously available only with Microsoft’s Content Management Server to create content and then have it published via workflow to an internet or extranet site. Publishing content from one server to another exposes the data to security threats.

Some common threats are

• Network Eavesdropping: Using network monitoring software, an attacker could intercept data moving from the Web server to the application server and from the application server to other systems and databases.

• Unauthorized Access: Via ports used by SharePoint, an attacker could try to communicate directly with the server.

Most servers are hosted behind a firewall, and we consider a firewall a minimum security requirement. The lines between internet and extranet are easier to cross with a technology like SharePoint, and properly configuring security in these environments is critical.

A typical firewall configuration that may be deployed for both Internet and extranet scenarios is shown in Figure 10.3.

We suggest the following countermeasures:

• Network Eavesdropping: A network attacker may place a packet-sniffing tool on the network to capture your network traffic. Countermeasures to prevent this type of attack can include:

  • Using secure authentication, such as NTLM-based Windows authentication. Windows authentication does not send packets over the network.

  • Encrypting SQL Server authentication credentials. SQL Server credentials can be encrypted automatically by installing a server certificate on the database server.

  • Using SSL to encrypt browser-to-server communications and IPSec to encrypt all IP traffic that flows between two servers.

• Unauthorized Access: Common unauthorized access attacks may include:

  • Port scanning to detect listening services.

  • Banner-grabbing that may give away services available on the server as well as the version of software running.

  • Password attacks against a default account.

Countermeasures to prevent unauthorized access attacks may include:

• Solid firewall policies that will block traffic from any port with exceptions for those your application uses.

• IP filtering and IPSec policies that prevent unauthorized hosts from establishing connections.

• Disabling any services that are not being used, which reduces that threat surface for attacks.

Encrypting MOSS application connection strings

The usual location of connection strings is in your web.config or machine.config files. This allows a developer to access the connection strings and application settings easily through the ConfigurationManager in ASP.NET 2.0, which could lead to a security risk if these connection strings are not encrypted.

You are not limited to a specific type of encryption in MOSS 2007, and you are able to create your own encryption providers. ASP.NET 2.0 has two technologies available for you to use, however: Windows Data Protection API (DPAPI) or RSA. DPAPI uses the MOSS server machine key to encrypt and decrypt your data, while RSA lets you use public keys.

The easiest way to encrypt your connection strings is using the DPAPI encryption through the command line. Because the key is the server machine key, any intruder to the machine could gain access to this key and use it to decrypt your connection strings. Also, the encrypted data would be usable only on the machine it was encrypted on, with the correct machine key.

RSA encryption allows machine-level and user-level containers for key storage. This enables you to have some control over user access to sensitive information. For example, in a shared hosting environment, you would want to implement RSA encryption on a user level, allowing users to access only their own encrypted connection string data.

Configuring antivirus settings

Because documents don’t always end up on a SharePoint site directly from a virus-protected client machine, it is important to configure virus protection on your SharePoint servers. The server-based virus protection products protect the server from viruses, worms, and Trojan horses in all of the major file types.

1.	First install the virus software on every Web front-end server in your farm.
2.	Open Central Administration by clicking Start Programs Administrative Tools SharePoint 3.0 Central Administration.
3.	On the Operations page, go to the Security Configuration section and click Antivirus.
4.	From the Antivirus page, in the Antivirus Settings section, choose from the following options: Scan documents on upload Scan documents on download Allow users to download infected documents Attempt to clean infected documents
5.	Go to the Antivirus Time Out section, and in the Time out duration (in seconds) box type a value for how long to wait for the virus scanner to time out.
6.	Go to the Antivirus Threads section, and in the Number of threads box enter a value for the number of threads that the virus scanner can use.

Managing blocked file types

Another way to help secure all of your servers is to limit the types of files that can be stored on the machines. By eliminating EXE files and VBA files, for example, you can reduce the threat of worms and Trojan horses on the servers and network. Table 10.1 shows a list of the file types that are blocked by default and their extensions.

Table 10.1. File Types Blocked By Default

File Extension	File Type	File Extension	File Type
.ade	Microsoft Access project extension	its	Internet Document Set file
.adp	Microsoft Access project	.jse	JScript Encoded script file
.app	Application file	.ksh	Korn Shell script file
.asa	ASP declarations file	.lnk	Shortcut
.ashx	ASP.NET Web handler file. Web handlers are software modules that handle raw HTTP requests received by ASP.NET.	.mad	Shortcut
.asmx	ASP.NET Web Services source file	.maf	Shortcut
.asp	Active Server Pages	.mag	Shortcut
.bas	Microsoft Visual Basic class module	.mam	Shortcut
.bat	Batch file	.maq	Shortcut
.cdx	Compound index	.mar	Shortcut
.cer	Certificate file	.mas	Microsoft Access stored procedure
.chm	Compiled HTML Help file	.mat	Shortcut
.class	Java class file	.mau	Shortcut
.cmd	Microsoft Windows NT command script	.mav	Shortcut
.com	Microsoft MS-DOS program	.maw	Shortcut
.config	Configuration file	.mda	Microsoft Access add-in program
.cpl	Control Panel extension	.mdb	Microsoft Access program
.crt	Security certificate	.mde	Microsoft Access MDE database
.csh	Script file	.mdt	Microsoft Access data file
.dll	Windows dynamic-link library	.mdw	Microsoft Access workgroup
.exe	Program	.mdz	Microsoft Access wizard program
.fxp	Microsoft Visual FoxPro compiled program	.msc	Microsoft Common Console document
.hlp	Help file	.msh	Microsoft Agent script helper
.hta	HTML program	.msh1	Microsoft Agent script helper
.htr	Script file	.msh1xml	Microsoft Agent script helper
.htw	HTML document	.vb	Microsoft Visual Basic Scripting Edition file
.ida	Internet Information Services file	.vbe	VBScript Encoded Script file
.idc	Internet database connector file	.vbs	VBScript file
.idq	Internet data query file	.ws	Windows Script file
.ins	Internet Naming Service	.wsc	Windows Script Component
.isp	Internet Communication settings	.wsf	Windows Script file
		.wsh	Windows Script Host Settings File

To changed blocked file types, follow these steps:

1.	From the Operations page in Central Administration, go to the Security Configuration section and click Blocked file types.
2.	From the Blocked Files Types page, type the file extensions that you want to block on separate lines in the text box.
3.	To remove blocked file extensions, delete the extension in the text box.
4.	Click OK.

Architect your administrator security

There are many levels of administrator security permissions in MOSS. By defining your administrator roles before the installation, you establish a strategy for managing your portal throughout its deployment.

The administrative levels that you need to consider are

• Shared services administrators: These administrators are responsible for configuring and maintaining the shared services. It is possible to give permissions to particular items in shared services, like personalization features such as profiles and audiences, but that granularity should be necessary only in the most distributed environments. This level of administration is not necessary for WSS installations.

• Central admin: Central administration permissions are specific to the SharePoint farm. There are both operations and application administrative tasks like creating and extending Web applications that your administrators with central admin permissions will perform.

• Site owners: Site owners are allowed to configure the overall site settings for the site, such as content types and navigation.

It is recommended that you configure security groups that grant permissions to each of the administrative levels described above.