Although it might seem like your database server is fair game for any would-be hacker, you can take many steps to limit the attack surface of your server. You might find that some of these steps are simply common sense, whereas others have a more subtle benefit. However, you will discover that some of the more drastic measures, although effective, are an administrative nightmare and would be implemented only in a high-risk environment. Some of these preventative measures are as follows:
Service packs and patches Keep abreast of all service packs and fixes available for your operating system and database applications. Software vendors publicize vulnerabilities and fixes as soon as they become known.
Physical security Your database servers should always be maintained in a physically secure environment. Potential attackers can exist on the outside and inside of your organization.
Firewall rules Block UDP port 1434 at your firewall. As mentioned previously, this port was the point of compromise for the Slammer worm, and SQL Server does not require this port to make it function.
Disable unused features If your system does not require SQL Mail or some other feature, disable it. Even SQL Agent does not necessarily need to run if you have no scheduling or alert requirements. In disabling these features, you narrow the attack surface of your server.
Analysis tools You can use various tools that are designed to scan your systems for potential vulnerabilities. The Microsoft security auditing tool, Microsoft Baseline Security Analyzer (MBSA), reports on server-wide security.
Audit shared folders for permission levels Ensure that you have not configured convenient shares on your NTFS folders to facilitate moving files around. Also bear in mind that if you install your SQL Server under a Windows domain account, that account is automatically granted access to all the folders that SQL Server needs to touch. If you subsequently change the user under which SQL Server runs, those permissions are not revoked, and an unnecessary level of access remains.
Service account and sa account Typically the two most frequently attacked accounts, these should always have complex passwords. Use complex passwords for every account if Mixed Mode is configured. The SQL Server method of storing passwords is not especially secure. In addition, you cannot enforce password rules.
Guest account Remove this from all databases except master and tempdb, which require this account to be able to function correctly. The guest account, if present, provides a well-known but unnecessary level of privilege.
Input validation Always configure this in your applications to prevent opportunities for SQL injection. Never permit ad-hoc querying of databases via Internet applications. Instead, use stored procedures to access database resources.
Database and IIS servers These should be on separate physical hardware systems, preferably with the database server behind a firewall to screen it from external users. Doing so provides a further layer of security and prevents your SQL Server from being advertised over the Internet.
Windows domains Use these where possible to take advantage of integrated security, which offers many advantages over SQL Server security.
Trusted connections For example, when you are using the command-line query tool osql, use the E where possible in place of the too-often-seen, hard-coded passwords in batch files and so forth.
SQL Server service account In a Windows domain, this should be a domain user. This does not need to be the Local System account or a member of domain administrators. Also, in most cases, it does not need to be a local administrator, either. Operating on a policy of least privilege ensures that even if the server is compromised and the attacker can issue commands in the context of the service account, he remains limited by the privileges of that account.
Sample databases The Northwind and pubs databases in SQL Server have standard users and a schema that is well publicized. For this reason, you should always remove them from a production system.
Model database Because it provides a template for all databases you create, it should also model the security template you require in your enterprise. This ensures that every database on your system has a minimum level of security regardless of who creates it.
Public role Audit permissions on a regular basis. Because every database user is automatically given membership of the public role, it is critical that you retain strict control.
Extended stored procedures Severely limit permissions to all potentially vulnerable system-stored procedures, and audit permissions on a regular basis. This mitigates the risk of permissions being accidentally or deliberately granted by an unwitting developer or someone who has more malicious intent.
Network libraries Enabling only the network libraries that your system requires narrows the potential attack surface of your SQL server.
SSL (Secure Sockets Layer) Use if possible to encrypt traffic between clients and database servers.
