Securing the SharePoint Portal Server 2003 s SQL Server Database

Securing the SharePoint Portal Server 2003's SQL Server Database

SQL Server has a strong relationship with SharePoint Portal Server 2003 because it is the back-end to SharePoint. The SharePoint configuration and content databases are stored in SQL Server. Therefore, it is highly recommended to follow security best practices on SQL Server to minimize vulnerabilities.

The enforcement of SQL Server security should be one of the most important tasks SQL Server database administrators commit themselves to, especially in today's insecure computing world. At present, there are numerous SQL Server security best practices that should be followed. The following sections discuss some of them.

SA Account and Strong Password

It is common to find SQL Server installations that have either a weak or blank SA password. The latest service pack such as SQL Server Service Pack 3a addresses the issue of blank passwords by informing administrators. However, it does not force administrators to create passwords, which leaves SQL Server exposed to security vulnerabilities. By default, the SA account is assigned to the sysadmin fixed server role, and it has full access and control over SQL Server.

It is good practice to ensure that all SQL Server installations have a strong SA password regardless of what role they play in the enterprise. A strong password should contain a combination of numbers, letters, and symbols. It should also be treated with the same respect as a Windows administrator account. For example, administrators should not use the SA account to log on to SQL Server and should not allow applications the privilege to use the SA account as a logon service. Separate accounts utilizing Windows authentication should be created to grant users and applications access to SQL Server; therefore, if the account is compromised, the SQL Server is not exposed because the user account does not have full administrative rights.

To change or assign a strong SA password, perform the following steps:

1.	Choose Start, All Programs, Microsoft SQL Server, Enterprise Manager.
2.	In Enterprise Manager, first expand the desired server group and then expand a server.
3.	Expand the Security container and then click Logins.
4.	In the right-hand pane, right-click on the SA account and then click Properties.
5.	In the SQL Server Login Properties dialog box, type in the new strong SA password in the Password field, as shown in Figure 15.24, and click OK. Figure 15.24. SQL Server Login Properties dialog box for the SA account.
6.	In the Confirm New Password box, retype the new complex password, and click OK as shown in Figure 15.25. Figure 15.25. Confirm Password dialog box.
7.	Restart Microsoft SQL Server Services, including the SQL Server agent.

Choosing Between SQL Windows Authentication or SQL Server Mixed Mode Authentication

SQL Server 2000 can function in one of two security modes. Both authentication methods, either Windows Authentication Mode or SQL Server Mixed Mode, provide administrators and applications access to SQL Server and its resources, such as databases, tables, or stored procedures. Windows Authentication Mode utilizes Active Directory user accounts, and SQL Server Mixed Mode utilizes either Active Directory user accounts or SQL Server built-in accounts for validating access to SQL Server. Both security methods provide and control access to SQL Server. However, Windows authentication is far more enhanced with regard to security because it leverages security features and functionality built into Active Directory.

Additional Active Directory security features include mandatory complex passwords. Passwords can be stored using reversible encryption, and accounts can be set to expire at a desired time. In addition, domainwide security policies such as password, account, and Kerberos policies can be enforced on Active Directory user accounts. SQL Server Mixed Mode does not offer the same level of security and policies on built-in SQL Server user accounts; therefore, it is recommended that SQL Server operate in Windows Authentication Mode.

Follow these steps to enable Windows Authentication Mode:

1.	Choose Start, All Programs, Microsoft SQL Server, Enterprise Manager.
2.	In Enterprise Manager, first expand the desired server group and then select a server.
3.	Right-click on desired SQL Server and then click Properties.
4.	On the Security tab, select the Windows Only option to audit all authentication attempts and then click OK as shown in Figure 15.26. Figure 15.26. Changing authentication modes.

Enabling SQL Server Security Logs

The previous sections discuss ways of minimizing security vulnerabilities on SQL Server. Now that SQL Server has been hardened, it is beneficial to enable auditing. Security auditing on SQL Server monitors and tracks activity to log files that can be viewed through Windows Application Logs or SQL Server Enterprise Manager. SQL Server offers four security levels with regard to security auditing:

• None Disables auditing so that no events are logged

• Success Audits all successful login attempts

• Failure Audits all failed login attempts

• All Audits all login attempts

Security auditing is set to None by default. It is a best practice to set security auditing to All. At the very least security auditing should be set to Failure so that failed logins can be saved, viewed, and acted upon.

Follow these steps to enable security auditing on all events:

1.	Choose Start, All Programs, Microsoft SQL Server, Enterprise Manager.
2.	In Enterprise Manager, first expand the desired server group and then select a server.
3.	Right-click on the desired SQL Server and then click Properties.
4.	On the Security tab, select the Audit Level option All, and then click OK as shown earlier in Figure 15.26.
5.	Restart SQL Server to make auditing changes effective. Open SQL Server Service Manager (choose Start, All Programs, Microsoft SQL Server, Service Manager) and click Stop; then click Start/Continue to restart services, as shown in Figure 15.27. Figure 15.27. SQL Server Service Manager.

Allocating SQL Server Ports

SQL Server uses TCP/IP and Named Pipes as the default method for client access. The default TCP/IP ports SQL Server uses are port 1433 and UDP 1434. These two ports should not be opened on the firewall, and packets should be filtered. If clients require external connectivity to SQL Server, it is a best practice to establish a secure VPN connection to the SQL Server instead of opening ports 1433 and UDP 1434 on the firewall. In addition, it is also possible to encrypt SQL Server data between client and server using SSL and a certificate. Encryption prevents data from being spoofed while in transit.

In 2003 SQL Servers around the world were subjected to the SQL Slammer worm. This was one of the fastest computer worms in history, infecting 90% of unpatched SQL Server computers around the world in just 10 minutes. In fact, the SQL Slammer worm was scanning approximately 55 million systems per second within 3 minutes of its release, which resulted in the crippling of SQL Server computers, corporate networks, and the Internet.

The SQL Slammer worm exploited vulnerability on SQL Servers exposed directly to the Internet through port 1433 and UDP 1434. It is equally important to know that Microsoft addressed the patch seven months prior to the SQL Server attack; however, many database administrators did not patch their SQL Server computers with the latest Microsoft updates. Once again, this information stresses the need for ongoing security, patch management, and application of the latest service packs and updates.