Just when you think you've gotten your SQL Server security under control, a monster rears its ugly head. Up from the dark regions of your network crop SQL Server systems you forgot you had or didn't even know about. You then realize you've only scratched the surface toward having your SQL Server security under control.
It's a testament to the system complexity growing out of control on today's networks. I see it in my work quite often: legacy SQL Server 2000, MSDE, and SQL Server 2005 Express systems are scattered about with no one managing them. They're basically out of sight, out of mind.
I hear things like:
- "Oh yeah, I forgot about that system."
- "Our development team put that up and didn't let us know about it."
- "We're waiting to decommission that server as soon as our vendor gets us on their new platform."
Whatever the reasoning is, these systems are present and often create some serious business risks, especially when you consider the realities of the insider threat.
The biggest thing I come across is SQL Server systems that have no password on the sa account, providing anyone on the network unfettered access to the system. All it takes is someone on the network running SQL Server Management Studio Express and anything is fair game. By that I mean a malicious user can connect to the system and change SQL Server security settings, set up a backdoor account, browse and extract production data – you name it, it's really simple to do.
Another concern is that these unmanaged SQL Server systems are often unpatched and therefore vulnerable to attack. Using free tools such as NeXpose Community Edition and Metasploit, a rogue insider can track down these SQL Server systems, find out how they're vulnerable and then exploit certain OS, SQL Server, and third-party application vulnerabilities to gain full control of the system – all without ever being noticed.
I think the underlying problem here goes back to one of the fundamental issues with information security: we don't know what we have and therefore can't secure what we don't acknowledge. Here's what you can do to get things under control:
- Discover what you've got. This starts with a good system inventory and network diagram -- but you have to go deeper. Using a port scanner such as SuperScan v3.0 to periodically look for live systems listening on the default SQL Server ports (TCP 1433 and UDP 1434) is a good start. In fact, there's an even better tool by Chip Andrews called SQLPing (currently in version three) that not only scans for default SQL Server instances but can also find systems that are protected by a personal firewall or running on odd ports.
- Determine how the SQL Server systems are at risk using vulnerability scanners and ethical hacking techniques.
- Plug the holes by setting reasonable passwords, applying patches, or hardening the systems. Otherwise, segment them off the main network or decommission them altogether.
It's one thing to be proactive with security on your highly-visible SQL Server systems but quite another to track down all the other systems that can create just as many risks. Just remember that if you want to have a secure SQL Server environment, you need to look at the whole picture.
Kevin Beaver, is an information security consultant, keynote speaker and expert witness with Atlanta-based Principle Logic LLC. Kevin specializes in performing independent security assessments. Kevin has authored/co-authored seven books on information security, including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley). He's also the creator of the Security on Wheels information security audio books and blog providing security learning for IT professionals on the go. Kevin can be reached at firstname.lastname@example.org.