Microsoft SQL Server 2000 Security

The SANS Institute Page 1 of 6 Microsoft SQL Server 2000 Security The following is a checklist of security guidelines to follow in securing Microsoft SQL Server 2000. It is divided into categories: 1) Setup and General Issues, 2) Authentication, Users and Logins, 3) Permissions, 4) Logging, and 5) Applications. Within each category, the guidelines are described as Mandatory, Recommended or Paranoid; these labels are intended to help you prioritize your actions and to weigh the relative importance of each …

Setup and General Issues • [Mandatory] The Internet firewall should block all packets going to or coming from the database servers. Consider regulating traffic from the internal LAN as well. SQL Server primarily uses TCP 1433 for data sessions and UDP 1434 for pre-session handshaking. But be aware that SQL Server can also use UDP 137, TCP 139 and TCP 135. • [Mandatory] Stay abreast of the latest Service Packs and hotfixes, and install them as soon as feasible; however, do not blindly install Service Packs or hotfixes without first testing them on non-production servers, and without first backing up the production server. Keep in mind that SQL Server has Service Packs separate from the operating system’s Service Packs. • [Mandatory] Physically secure database servers and their backup media in locked, access-controlled rooms. Provide electronic surveillance when appropriate. • [Mandatory] In general, disable services or features of SQL Server that you are not currently using, such as SQL Mail. • [Mandatory] Scan the database server with the Microsoft Baseline Security Analyzer (MBSA) or similar auditing tool to reveal common insecurities. • [Mandatory] Regularly audit all shared folders on the database server to ensure that all permissions are minimal and that none of the shares are unnecessary. Be especially wary of shared folders that permit Write access. • [Mandatory] When replicating databases over the Internet, set up a router-to- router Virtual Private Networking (VPN) tunnel to connect the two LANs. When replicating over untrusted internal networks, use IPSec to encrypt the replication traffic. • [Mandatory] Assign a long and complex password to the SQL Server service account (preferably 25 characters or more, with 15 characters the minimum)….. • [Mandatory] The setup program for SQL Server should have done this already, but set the NTFS permissions on all database-related files, including the SQL Server binaries, to permit only Read & Execute to Authenticated Users, and Full Control for System, Administrators and the SQL Server service account. If you change the SQL Server service account, do it using Enterprise Manager so that permissions will be changed automatically. • [Mandatory] Use NTFS audit settings (SACLs) to track failed access to database-related files. • [Mandatory] The setup program for SQL Server should have done this already, but, on the following registry keys, remove all permissions for the Everyone group and grant Full Control to the SQL Server service account and local Administrators, then audit all failed access and all successful writes to them as well: HKLM\Software\Microsoft\MSSQLServer (for a default instance) or HKLM\Software\Microsoft\Microsoft SQL Server\ Instancename (for a named instance, if any). • [Mandatory] Delegate authority over the server and its databases by utilizing fixed server and database roles appropriately, or by creating your own custom roles, so that excessive power is not being placed in the hands of those who don’t need it. In short, do not simply place everyone in the sysadmin role out of convenience. • [Mandatory] All database and server management scripts should be stored in an access-controlled NTFS folder. Audit all access. Scripts should not contain hard- coded passwords. Consider digitally signing these scripts using the Windows Script Host (WSH) 5.6 or later, and warn on the attempted execution of scripts that fail signature verification. • [Recommended] Disable cross-database ownership chaining (KB810474). It is disabled by default after SP3 is applied to SQL Server 2000. • [Recommended] Regularly audit what the Public role has access to. This role is roughly equivalent to the Everyone group in the operating system. Remove or limit the rights of the Public role whenever possible, but do not explicitly deny permissions for it (simply remove them). • [Recommended] Regularly audit who has Execute permission on all stored procedures, especially xp_cmdshell. The Guest and Public logins rarely need the Execute permission. When in doubt, grant permission only to the sysadmin role. • [Recommended] When using UDL files, assign restrictive NTFS permissions and audit all access to the files. Avoid storing passwords in UDL files by using Integrated Windows authentication.