The ultimate SQL Server security faux pas: Overlooked systems

The ultimate SQL Server security faux pas: Overlooked systems

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

    Requires Free Membership to View

    Login

    By submitting your registration information to SearchSQLServer.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSQLServer.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

Premium Access

Register now for unlimited access to our premium content across our network of over 70 information Technology web sites.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in February 2010

  • 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.

There's more to learn...
"Do you need to be worried about a large number of SQL Server Express installations? Potentially, yes. If Express is storing sensitive data, important data, or something along those lines, you might think about relocating that data into the data center."
-- Don Jones,
Why is SQL Server Express installed everywhere?

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:

  1. 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.
  2. Determine how the SQL Server systems are at risk using vulnerability scanners and ethical hacking techniques.
  3. 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  kbeaver@principlelogic.com.


Join the conversationComment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.

    Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.

    Back to top