In a previous tip, 10 hacker tricks to gain access to SQL Server, I outlined various ways SQL Server can be compromised. Here I'm going to expand upon a couple of vulnerabilities that I see time and time again when performing security assessments.
How to discover vulnerable SQL Server systems
I often find that SQL Server-based systems are not adequately protected by a firewall. Yep, the tried-and-true firewall -- the one thing you'd think everyone has -- is still not in place in all situations where SQL Server protection is needed. If this is your setup, you can forget SQL injection attacks; if SQL Server is not protected from the elements, an attacker can access your system directly, whether it's by obtaining a remote-command prompt by exploiting an operating system vulnerability or by cracking operating system or SQL Server passwords. The fact of the matter is that bad things can happen when SQL Server is hanging out in the wind. Firewalling shields the system from an external hacker's point of view and protects it from unauthorized insider access or, ideally, both.
Start testing for vulnerabilities by running SQLPing to locate vulnerabilities, both outside and inside. You can use a port scanner and try to map things out, but the best (free) tool for this is called SQLPing2 from Chip Andrews at SQLSecurity.com.
In Figure 1, I show a sanitized SQLPing2 scan I ran to find some internally accessible systems. Notice that SQLPing2 found systems running SQL Server, the version number, port and even a system with no sa password. It also can discover multiple SQL Server instances running on UDP port 1434, which can be loaded with user name and password lists for more extensive password cracking. I'll cover SQL Server password cracking in a future tip.
Figure 1: Using SQLPing2 to discover SQL Server systems on the internal network.
The beauty of this tool is that you can use it to test your network from the outside world and to see what your firewall is (or isn't) blocking. It does all of this in just a few seconds.
How to lock down vulnerable SQL Server systems
So, now that you've discovered "naked" SQL Server systems running on your network, accessible by people who shouldn't be able to connect, what do you do about it? You've got three cut-and-dried options:
1. Put your SQL Server behind a firewall
I know it sounds obvious, but many applications are written so that SQL Server must be readily accessible by various systems, which often means it doesn't have a network firewall or DMZ network protecting it. Developers and network managers alike think that's the only way to provide such access, or business partners and customers may want it a certain way, but we all know that everything's negotiable.
2. Enable Windows Firewall on your SQL Server system
I know it doesn't sound very "enterprise-like," but it can work -- very well. This is especially true when you're trying to protect SQL Server systems that are already behind a firewall but need protection from unauthorized internal access. Once you enable the Windows Firewall, just create a new port to allow SQL Server traffic from specific systems, as shown in Figure 2.
Figure 2: Use the Windows Firewall to protect SQL Server from unauthorized access.
Usually there are only a select few network systems that need to connect to SQL Server – most do not. The Windows Firewall is a perfect solution here. Whichever firewall option you use, don't forget to allow/block both TCP port 1433 and UDP port 1434 (the latter if you're running multiple database instances on the same server).
3. Protect SQL Server using a database-centric firewall, intrusion detection and monitoring system.
This is a more costly yet enterprise-worthy option. Consider protecting SQL Server with tools like Application Security Inc.'s AppRadar, Imperva Inc.'s SecureSphere or Guardium Inc.'s SQL Guard. These systems go beyond mere port blocking and network access control and actually monitor and block database access and transactions themselves.
I recommend using network and host firewall and IPS controls first -- they will buy you a lot of protection against both internal and external attackers. However, if you perform a vulnerability assessment and still discover security holes, check out the database security solutions I mentioned in option three. Otherwise, just enjoy the absolute peace of mind you will have by locking down the SQL Server system.
About the author: Kevin Beaver, CISSP, 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. Beaver has written five books including Hacking For Dummies (Wiley), Hacking Wireless Networks For Dummies, (Wiley) and The Practical Guide to HIPAA Privacy and Security Compliance (Auerbach). He can be reached at kbeaver@principlelogic.com.
More information from SearchSQLServer.com
Tip: Ten hacker tricks to exploit SQL Server systems
Tip: Using Metasploit for real-world security tests
Checklist: How to test SQL Server security
