After all the database breaches and hype over locking down SQL Server, I still come across many SQL Server systems riddled with holes. SQL Server 2005 aside – a DBMS that comes pretty secure out of the box for those who've dared to deploy it – there are still many SQL Server 2000 and older systems waiting to be attacked via buffer overflows, SQL injection, missing patches and more. The good news is that things can be done outside SQL Server in Internet Information Server (IIS) and Windows to add some muscle and secure your database to prevent malicious attacks.
Many vulnerabilities are very easy to root out as I outlined in a previous article,
If you're like most database administrators and developers, you probably don't want to tweak the database environment for fear of taking down production applications. Likewise, you're reluctant to rewrite anything either; it will take too long or cost too much. Both are valid concerns. Working outside IIS and Windows to lock down SQL Server and prevent attacks is definitely a feasible option. These defenses won't cost you too much and most will have a negligible affect on system performance. So, if you know in the back of your mind that something needs to be done about SQL Server security, but you can't find a good place to start, check out these tips:
1. Outside of SQL server, one of your strongest defenses is going to be input filtering and validation for form fields and URL query strings. If you're running an IIS version previous to 6.0, you absolutely must run Microsoft's IIS Lockdown and install UrlScan. This will harden default IIS settings and perform input validation to help filter out junk requests. I hesitated in recommending this because it seems so obvious, but you'd be surprised at how many servers I come across that still don't have it installed.
2. Implement a commercial lockdown tool such as eEye's SecureIIS or Port 80 Software's ServerMask to obfuscate, filter or block IIS attacks that go beyond what defenses IIS Lockdown and UrlScan have to offer.
3. Install a host-based firewall/intrusion detection program to block out all other malicious requests at the application and network-protocol levels. My long-time favorite is Internet Security Systems' BlackICE. I'm always intrigued by what it catches and blocks in real time. The following figure shows some interesting attacks it found. Notice the two probes aimed at SQL Server.
Figure 1: BlackICE events
The BlackICE technology is used in Proventia and RealSecure enterprise products as well if you're looking for something more manageable across your network.
4. Whether you're running mixed-mode or Windows-only authentication, ensure local and domain Windows accounts associated with IIS and SQL Server are well guarded and audited for abuse. Everything is put at risk if an account is compromised by a rogue insider abusing tools like ElcomSoft's Proactive System Password Recovery or Ophcrack Live CD. Most of this comes back to the need for strong passphrases.
5. Ensure that all SQL Server-related files are loaded on partitions formatted with NTFS. Nothing else will do, for now at least.
6. A more drastic change but a secure layer nonetheless is to put SQL Server on a dedicated server on a network segment other than the "untrusted" one IIS runs in (typically the publicly-accessible DMZ). Once your SQL Server is on the "trusted" network (typically the internal LAN segment), you can create firewall rules to allow only the IIS server to talk to the SQL Server. You can do the same with internal network segmentation to keep out those trusted insiders with prying eyes. Just know that this segmentation is not completely foolproof. If someone compromises the IIS server in the DMZ and all the stars are properly aligned, there's a chance they can still reach the SQL Server system.
7. Enable IIS and Windows security logging. This won't prevent an attack but it sure will help investigate and recover from one when it does occur. Check out GFI's LANGuard Security Event Log Monitor and Network Server Monitor, as well as these other event log monitoring tools.
8. If you can't stand it any longer and feel like you need to dig into SQL Server, check out this SQL Server Group Policy Template and this SQL Server Lockdown Script both by Chip Andrews. They offer both Windows and SQL Server-related controls that can help lock things down.
9. Don't overlook the fact that SQL Server systems are susceptible to malware attacks. There's absolutely no reason why basic antivirus and antispyware software shouldn't be installed on a SQL Server system. You may want to consider excluding SQL Server directories and related files from real-time scans for performance reasons, but make sure everything else is protected. If anything, this will buy you protection from an IIS perspective, blocking worms and other malware targeting that application.
10. Finally, I'd be remiss if I didn't recommend installing the latest patches for Windows, IIS, SQL Server and whatever else comes up as outdated on your servers. It's no longer an empty pie-in-the-sky threat that software flaws can be exploited by a malicious user -- it's today's reality. Check out Metasploit and Core Security Technologies' CORE IMPACT for some proof in the pudding that anyone can own your system in just a couple of minutes by exploiting even the most obscure vulnerabilities related to missing patches -- even ones unrelated to SQL Server.
Remember that poorly written applications cannot be completely protected, so get to the root of the problem when you can. Only rely on these preventive measures short-term but rest assured that they're still way better than the alternative.
About the author: Kevin Beaver is an independent information security consultant, author, and speaker with Atlanta-based Principle Logic, LLC. He has more than 18 years of experience in IT and specializes in performing information security assessments. Kevin has written five books including Hacking For Dummies (Wiley), Hacking Wireless Networks For Dummies, and The Practical Guide to HIPAA Privacy and Security Compliance (Auerbach). He can be reached at firstname.lastname@example.org.
This was first published in July 2006