Description

We will keep the latest copy of the SQLSecurity.com Lockdown script at this area of the site. Script will perform a lockdown of a SQL Server to the most secure possible configuration as a baseline for further modifications. This should help administrators deploy more secure systems by forcing them to only enable required functionality. This is an open project and feedback is encouraged. I will maintain the script but will entertain all additions/comments/changes.
The current goals of the project include:

• Must support named instances
• Must not break future Service Pack and hotfixes installations
• Must strive to disable rarely used functionality but not break common applications (80-20 rule)
• Must be easily runnable from the command prompt for mass distribution

Please provide feedback on the Discussions page if you have any comments about the script or proposed changes.

How to Execute Script

From the command prompt type:

osql -S (servername) -E -i lockdown.sql

You must have System Administrator (sysadmin) access on the target machine via Windows Authentication for the script to run. It can also be run via standard SQL Server authentication but this is not recommended as the script resets the 'sa' account password to a strong, unknown value on execution.  
 

I have received some great comments and incorporated many ideas from the feedback. Thanks to all of you. There are a couple of points I need to make so that I can stem the flow of emails on these issues:

Disabling Adhoc functionality on data access providers does NOT break most applications. It only prevents use of the OPENROWSET, OPENQUERY, and OPENDATASOURCE functionality which can be abused to access other systems. See http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf

The script does not drop any extended stored procedures as I find this practice breaks too many useful tools (Enterprise Manager) and can prevent proper service pack installation. In addition, it provides very little protection since rogue sysadmins and attackers can easily add them back. The better solution is to deny access to many sensitive procedures to all but members of the sysadmin role.