Not upgrading? Keep SQL Server 2000 secure |
 |
By By Kevin Beaver, CISSP
15 Nov 2005 | SearchSQLServer.com |
|
|
SQL Server 2005 is finally here with many new security features, but you may not be planning an upgrade for another year or so. You still need the utmost in database security for your SQL Server 2000 system(s). Fear not! There are several tried-and-true ways to lock down your network's crown jewels stored in SQL Server 2000 for which you can get just about as much bang for your buck.
Before you do anything, find out which vulnerabilities currently exist in your server. To do this, I suggest you use one of the enterprise-grade vulnerability-assessment tools such as Qualys Inc.'s QualysGuard or Internet Security Systems Inc.'s Internet Scanner. These tools will not only find missing patches that the lower-end tools report, but they'll also dig several layers deeper to find and exploit (to a certain extent) any existing weaknesses you may not have known about otherwise.
Secondly, I highly recommend that you use one of the enterprise-grade database vulnerability-assessment tools such as NGS Software Ltd.'s NGSSquirrel for SQL Server or Application Security Inc.'s AppDetective for Microsoft SQL Server. These tools take the vulnerability-assessment process a step further by finding SQL Server-specific vulnerabilities that no other tool or manual assessment would uncover -- especially in a short time period. In my experience, the number of vulnerabilities in database configuration, access control, DoS, etc., rooted out by these tools never fails to be an eye-opening experience for even the most security-savvy DBAs. On a related note, believe it or not, the Microsoft Baseline Security Analyzer (MBSA) does a pretty decent job checking for SQL Server misconfigurations, so you'll do well to at least run MBSA if nothing else.
Once you find existing vulnerabilities and plug the holes where practical, it's time to batten down the hatches with a handful of SQL Server security defenses. You may discover that you've already addressed some of these after implementing the recommendations outlined by the vulnerability-assessment tools above, but it won't hurt to double check. Remember to keep usability in mind and document your work in case you need to back out any changes.
- Use Windows only authentication mode rather than mixed mode for database connections to limit attacks that can be carried out across the Internet.
- Create custom database roles to establish more granular access controls and help keep users accountable.
- It's embarrassingly obvious, but true -- your SA account needs a strong passphrase. Otherwise, it can be brute-forced or cracked with a dictionary attack if an attacker can gain network access.
- Another obvious one is to place your database server behind a firewall rather than risk being a victim of a direct Internet attack (Slammer worm anyone?).
- Place your database in a separate network segment (DMZ) from your Web and application servers (if possible) to prevent a successful compromise of one host that puts SQL Server at risk. It's not foolproof, but it can create another layer of security, which is a primary goal.
- Limit the privileges of your SQL Server services to limit what attackers can do if they are able to compromise the system. Even Microsoft recommends running SQL Server Engine/MSSQLServer and SQL Server Agent Service/SQLServerAgent as a regular Windows user account with regular privileges.
- Enable auditing connections to SQL Server (especially failures) so you can keep track of what's going on. Ideally, look for a log management/alert system such as GFI Software Ltd.'s LANguard Security Event Log Monitoring or something similar to bring these infractions to your attention rather than having to manually search for them.
- Be careful with file and share permissions on your server to ensure that only those who need access have access (the NTFS file system is essential).
- Test for and lock out null session connections to insiders and outsiders alike from making null connections to your server and gleaning usernames, security policy information and more. Here's a tip on doing this.
- Don't let applications execute SQL commands directly. Otherwise your underlying database structure can be determined and commands can be run directly via SQL injection and blind SQL injection.
There are literally hundreds of ways you can lock down SQL Server, but these provide the most value. Once your SQL Server is secure, you should check your work by running the vulnerability-assessment tools again. In fact, the only way to know for sure if your SQL Server 2000 systems are secure on an ongoing basis is to run these tools consistently moving forward -- perhaps once a quarter, twice a year or after any major changes.
If you can justify third-party add-ons, consider a database intrusion detection system such as Application Security Inc.'s AppRadar or even the more generic Internet Security Systems' BlackICE Server Protection -- the latter of which is an excellent option to get the most bang for your buck when it comes to intrusion detection and prevention.
In addition, consider a database encryption solution such as Application Security's and NetLib's Encryptionizer. Combine layered defenses such as these with a reasonably hardened database and it might be all you need to have the next best thing to Fort Knox.
About the author: Kevin Beaver is an independent information security consultant, author, and speaker with Atlanta-based Principle Logic LLC. He has more than 17 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 and The Practical Guide to HIPAA Privacy and Security Compliance (Auerbach). He can be reached at kbeaver@principlelogic.com.
|
|
|
|
