No matter how you've hardened your SQL Server systems, a weak network design can still undermine the best of database security controls. It's easy to assume that all's well inside the network perimeter. The external firewall is all-protecting -- at least that's the common belief.
Firewall or not, database security weaknesses at the network layer are introduced for one simple reason: convenience. IT administrators have been in a constant battle between security and convenience, long before security was cool. Be it a less-visible internal system or an Internet-facing e-commerce application, the time and effort required to implement the solution ASAP often beat out any attempt to deploy things securely. It's the path of least resistance. It's "time to market." It's whatever it takes to get it done and then move on to put out the next fire. Sure, you reach a solution more quickly, but it's not good for business. We've all been guilty of such practices.
The convenience element is what leads to putting SQL Server systems on the network where they shouldn't be. Oftentimes, the servers are directly accessible from the Internet. I've recently seen this very thing: a SQL Server system directly accessible from the Internet – all because business partners needed easy access to the data. A better plan, such as a VPN, introduced too much of an, ahem, inconvenience. Suffice it to say the outcome was not good.
David Litchfield's Database Exposure Survey 2007 confirms that SQL Servers are exposed everywhere. According to Litchfield's research, there are around 368,000 SQL Servers directly accessible from the Internet -- the majority of which are not up to date on patches. What are people thinking? Apparently, the Slammer worm attack on easily-accessed SQL Server systems years back wasn't a strong enough warning.
The Internet issue is obvious, but don't forget about the internal network. I hear about and see a lot of people "VLANing" everything,
yet, it's often very simple to track down and connect to SQL Server systems from anywhere inside the building. They're just sitting there – along with all the other servers and workstations – waiting to be poked, prodded and attacked by curious or rogue insiders. With all of the fancy security features built into the network switches, routers and firewalls on most networks, they're still not being used at even their most basic levels. Even old-fashioned packet filtering can do wonders to protect a SQL Server system – if it's used.
It doesn't really matter if it's a critical enterprise application or a benign installation of SQL Server 2005 Express, every database counts. One compromised SQL Server system leads to attacks on others. Check all of your databases to see just how accessible they are. Look at them from every angle: in front of the firewall, behind the firewall and beside the firewall. It pays to use good tools too. SQLPing is a great start for finding live SQL Server systems. Once you track them down, move on to more advanced vulnerability scanners such as GFI LANguard Network Security Scanner and QualysGuard and, finally, database-specific scanners such as AppDetectivePro and NGSSQuirrel to find out how they can be exploited.
Once you take a step back and look at the big picture, it'll be obvious just how important your network infrastructure is when it comes to protecting your databases. Find the flaws and plug the holes using network-layer controls whenever you can. You'll ward off internal and external attacks and be one step closer to reasonable and practical SQL Server security.
Kevin Beaver is an 
