Judging from reader feedback, my security ranting last week tapped a visceral vein within the SQL Server community. And with the recent debilitating Denial of Service (DoS) attacks on major Web sites, I couldn't have picked a better time to beat the SQL Server security drum. Here are a few more security horror stories, straight from readers’ email, and some tools and resources you can use to lock down your SQL Server databases.

Greg Gonzalez of Intercerv writes, "Nice and very timely article on SQL Server security, in particular the common issue of either forgetting or neglecting to set an sa password. We recently showed a client how wide open its e-commerce database was. The database used a combination of Remote Data Services (RDS)—basically ODBC over Port 80, installed by default with NT Option Pack—and a SQL Server with no sa password applied. This SQL Server was actually behind a Cisco PIX firewall and had an unpublished IP address, so it wasn’t directly Web-accessible. However, it’s often simply a matter of using RDS to get into a Web box over Port 80, then knowing or guessing a DSN name, SQL Server name, or its internal IP to get to a back-end SQL Server. In this case, thousands of credit cards were exposed--not to mention that with sa permissions, you can run xp_cmdshell, delete files, map shares to other machines, etc."

As Greg alluded to, nefarious types can use the adctest.asp page that ships with the NT 4.0 Option Pack to perform a quick vulnerability check on your system. And several months ago, Intercerv reported a similar RDS attack that used the Microsoft Access ODBC driver. For more information about this RDS_based Access attack, check out the threads.

Another reader (a well-known SQL Server expert who remains anonymous to protect his client) writes, "I just left a dot-com company that had a SQL Server exposed to the Internet: null passwords, all ports to the SQL Server wide open. And they wouldn't even let me change passwords or provide any other kind of security because it would break the apps. (Yes, I had credit card numbers in the database.)"

Finally, Chip Andrews of Computer Associates writes, "Good job spreading the word about slack SQL Server security setups. I’ve had a site at http://www.sqlsecurity.com since last year singing the same tune. I'm glad to see SQL Server security issues get some attention. Please keep up the good work!"

We've all worked on or witnessed unsecured databases. Such exposures are scary enough on a closed, private LAN, but they’re downright petrifying now that the Information Superhighway runs right through our vital information systems. The point is still responsibility: Let’s not blame the computer when it’s our laziness and lack of knowledge that leaves our databases unprotected. Education and diligence are our only weapons. Here are a few things you can do to stay on top of SQL Server security:

  • Review the security alerts that many FAQ sites post, such as those at http://www.ntsecurity.net. Also, consider subscribing to the free Windows 2000 Magazine Security UPDATE. I'm working on a comprehensive list of security information resources that I'll share in an upcoming article. (Send me your favorite sites, and I'll include them in the list!)
  • Investigate Database Scanner from Internet Security Systems. Many readers have shared positive comments about this risk-assessment product, which helps identify security exposures. For more information about Database Scanner, you can read a product review by independent consultant Michael Hotek. (Let me know about other SQL Server-focused security products so I can include them in a future column.)
  • Visit Chip’s site, mentioned earlier, for some practical SQL Server security tips and techniques.

Oops! In my January 20 review of upcoming SQL Server shows, I mentioned SQL Connections 2000, slated May 14 through 18 in New Orleans, but I forgot to include a URL for registration information. If you’re interested in attending the show or if you want more information, see http://www.sqlconnections.com.