Secure your Windows NT system (run at least the baseline security checklist)
Install SQL Server on an NTFS partition (same goes for your databases).
Install the latest service pack for SQL Server and any additional security patches (for installing these you can make use of this script).
Check your network configuration for SQL server and remove any protocol libraries you don't need.
For the TCP/IP library, run SQL Server on a different port than 1433. Especially if you need your SQL Server to be open to the Internet.
Block the SQL Server ports (default: TCP 1433, UDP 1434), block NT SMB (tcp 139, udp 137,138) and block RPC at your internet border/firewall.
Use the option to encrypt communication when connecting to your SQL server (SSL) otherwise data is transmitted in plain text and can be captured with a packet sniffer.
Use only integrated windows authentication (also called trusted connections) if possible, this way passwords are not sent in plain text and you have all your features of domain policy like account lockout...
If you need SQL authentication, make sure all accounts have strong passwords (SQL server does not require strong passwords and also has no account lockout). Be sure to check the 'sa' account (see next recommendation). You can use this code to check for accounts with null passwords:
Use master
Select name,
password
from syslogins
where password is null
System administrator (SA) is a special login provided for backward compatibility. By default, it is assigned to the sysadmin fixed server role and cannot be changed. Although sa is a built-in administrator login, do not use it routinely. Instead, make system administrators members of the sysadmin fixed server role, and have them log on using their own logins. Use sa only when there is no other way to log in (for example, when other system administrators are unavailable or have forgotten their passwords).
Make sure only the specified accounts have access to your databases. Be sure to check the guest access (= an authenticated user who has access to an instance of SQL Server, but does not have a user account to access a particular database). In SQL Server 2000 the guest account has no access to newly created user databases. The guest account requires access to master and tempdb, but you can safely remove others if you don't need guest access to your databases. Also check the public role (all users permitted to access a database become members of the public role within each database), be sure to check that they can't issue SELECT statements against system tables.
Remove the procedure xp_cmdshell or at least make sure only system administrators can execute this (default setting in SQL 2000), especially because this runs in the context of SQL Server account (example: xp_cmdshell 'net user root /ADD' will add a new user and xp_cmdshell 'net localgroup /ADD Administrators root' will add this user to the Administrators group (this will only work if the SQL Server account has administrative privileges - see next recommendation).
Secure the account SQL Server is running in. Use a domain account or a local account (if you don't need a connection to other sql servers), but don't use the local system account or an administrator account. The account should have the "Log on as a Service" privilege. Notice that when using Enterprise Manager to make this change, the ACLs on files, the registry, and user rights are done for you. Another good reason for not using the local system account is because the procedure xp_regread will allow you to read the registry key: HKEY_LOCAL_MACHINE\SECURITY\SAM\Domains\Account (xp_regread ‘HKEY_LOCAL_MACHINE’,’SECURITY\SAM\Domains\Account ‘,’Administrator’) which contains hashed passwords and can be cracked using brute force.
Enable auditing for successful and failed logins. To do this go to the properties of your SQL server in Enterprise Manager and go to the tab named security and set the audit level to 'All'.
Do not send error reports to Microsoft. Doing so opens an outbound connection that could possibly be abused. Microsoft introduced this feature in Service Pack 3 of SQL Server 2000.
Check your end-user application(s) for SQL Injection holes and other flaws it might have. Especially if this application is a website you are making publicly available on the Internet.
