Block the SQL Advertisement Service. Because attackers can easily locate and query available SQL Server 2000 servers by querying the SQL Advertisement Service, you can protect your system by preventing SQL Server from answering these queries. Open the SQL Server Network Utility and click TCP/IP, Properties. Then, select the Hide server check box, and click OK. You'll need to restart SQL Server for the changes to take effect. When changing the Hide server setting, note that you're changing the TCP port that SQL Server uses from port 1433 to port 2433. Changing the default SQL Server listening port creates more complexity for ASP applications that connect to SQL Server because you need to configure such applications to use the nonstandard port. Because of this additional step, most administrators don't make this change.
Limit client access. You can also help protect your system by considering how clients interact with SQL Server and how open your SQL Servers are to queries from wanted and unwanted clients. In many environments, any client on the internal network can access SQL Server. Decreasing the number of clients that can access a system directly decreases the potential for attack. Where possible, place SQL Servers on a segmented network that provides access only to servers or clients that must access SQL Server data. To limit direct access, you can also deploy a multitiered application in which the only system that accesses SQL Server is the server running the application's data-access code.
Disable defaults that make you vulnerable. After an attacker has gotten into a SQL Server system by using the sa account, complete server compromise is easy. By default, SQL Server installs many stored procedures to perform OS tasks such as reading and writing to the Windows registry. The most powerful of these is the xp_cmdshell extended stored procedure, which lets SQL Server run command-line tools. If SQL Server is configured to start as LocalSystem or an account in the local Windows Administrators group, an attacker can use the following set of SQL commands to create a Windows user account in the local Windows Administrators group:
xp_cmdshell 'net user SQLPen /add'
<Click Go>
xp_cmdshell 'net localgroup Administrators SQLPen /add'
<Click Go>
An attacker can also use xp_cmdshell to invoke the Trivial FTP (tftp.exe) client utility in the system32 directory. Attackers can use this utility to install malicious programs such as Trojan horses, remote-control software, keyloggers, or rootkits. Rootkits are perhaps the deadliest form of malicious software because many rootkits are capable of completely hiding their presence from DBAs while giving attackers complete access to the OS. Remove the tftp.exe utility unless you need TFTP-client functionality on your SQL Server.
You can eliminate access to xp_cmdshell by opening Query Analyzer and executing the following command:
DROP PROCEDURE xp_cmdshell
<Click Go>
However, this command doesn't remove the stored procedure. The only way to remove the stored procedure is to unregister the xplog70.dll file. But because legitimate stored procedures depend on this .dll file, this step is impractical. And even if you remove the command, an attacker who has sysadmin-level access can reenable xp_cmdshell. If you do disable this stored procedure, you can use Profiler to determine whether anyone has reenabled it—a sure sign of intrusion.
Due Diligence
Using Windows integrated authentication is a more secure choice than using mixed authentication. But when you have to use mixed authentication, diligently practicing the techniques in this article will help you reduce the risk of a security breach. Although adhering to these best practices won't guarantee the security of your SQL Servers, it will lower the level of risk associated with using the sa account and help guard against the many tools designed to attack it.
End of Article
Prev. page
1
2
[3]
next page -->
