Serious About Security

Even with Microsoft’s ramped-up security efforts, your systems are still only as secure as you make them. Here are some common-sense measures you can take to safeguard your SQL Server systems.

Michael Otey

November 25, 2002

2 Min Read
ITPro Today logo in a gray background | ITPro Today

In this age of rampant viruses and increasingly sophisticated system attacks, securing your SQL Server system means more than just protecting your data—it also means protecting your network. Attackers can use a compromised SQL Server system as a prime jumping-off point for accessing other systems in your network. This year, Microsoft finally got serious about security. In January, Microsoft launched its much publicized 3-month security initiative, halting all new development, hunting for security holes, and training its developers to be security-conscious. But even with Microsoft's ramped-up security efforts, your systems are still only as secure as you make them. Microsoft and other companies might give you the lock, but you have to turn the key.

A few common-sense measures can go a long way toward securing your SQL Server systems. For starters, if you're using SQL Server standard or mixed-mode security, consider moving to integrated security. Integrated security isn't only easier to manage, but it also removes the need to send SQL Server login IDs across the network. Sending IDs across the network can easily expose your system to attack, especially if you have a wireless network bridged into your wired network. If integrated security isn't an option for you, make sure the password for the sa account isn't blank—that goes for your development systems, too. Not only is a blank password easy for potential hackers to guess, but several worms explicitly look for this vulnerability. With SQL Server 2000, Microsoft made it more difficult to use a blank sa password, but most businesses still have plenty of SQL Server 7.0 and 6.5 systems where this is a likely scenario. Another common-sense security measure is to block TCP port 1433 and UDP port 1434 on your firewall if your SQL Server systems don't require direct Internet access—and few do. Then, make sure you've applied the latest round of security patches. Just because you haven't been hit by the latest exploit to require a hotfix doesn't mean you're safe. Many attackers use these exploits as inspiration to create their next attacks, counting on the fact that many administrators won't have applied the required hotfixes.

Granted, keeping up with security hotfixes is difficult, but Microsoft has made it easier for SQL Server administrators by releasing a cumulative security patch for SQL Server 2000 (available at http://support.microsoft.com/default.aspx?scid=kb;en-us;q316333&sd=tech) and for SQL Server 7.0 (available at http://support.microsoft.com/default.aspx?scid=kb;en-us;q327068&sd=tech). While you're at the Microsoft site, download the free Microsoft Baseline Security Analyzer (MBSA) at http://support.microsoft.com/default.aspx?scid=kb;en-us;q320454&. This tool scans your systems for common security misconfigurations, missing security hotfixes, and other vulnerabilities.

Finally, any system that is openly physically accessible isn't really secure. To learn more about SQL Server security, visit SQL Server Magazine's sister Security Administrator Web site (http://www.secadministrator.com) and Chip Andrews' SQLSecurity.com site (http://www.sqlsecurity.com). Microsoft also offers a valuable SQL Server security white paper at http://www.microsoft.com/sql/techinfo/administration/2000/securitywp.asp.

Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.

You May Also Like