Common SQL Server Security Mistakes

After demonstrating some attack methods, there is always one question from the crowd… “How do I prevent this?” It’s a great question and I would like to summarize my last few posts and answer that question. In the alternate ending the attacker actually got to see the DBAs password in plain text. So here is a list of things you can do to prevent that and why they work.

Don’t allow direct access to SQL server from the internet. Forcing attackers to jump through several hoops and pivot their attacks exponentially increases the difficulty.

Patch your servers. SQL has had a great track record for exploits specific to the database engine. Unfortunately, SQL only runs on Windows which has not had a great track record. Most exploits that fall into metasploit have a patch released by Microsoft… eventually. You need to make sure you get that KB hotfix. Make sure you are auditing your patching process.

Don’t enable the SQL Authentication protocol. This will block common tools that use SQL authentication and the known account ‘sa’. They won’t be able to connect with SQL Authentication so there is no way they will be able to brute force the password. Windows integrated is better. <– period

Don’t enable or use the ‘sa’ account. If it’s enabled, it can be brute forced.

Leave password policies in place. If the attacker is allowed infinite attempts, it’s just a matter of time before they get in. It’s a good thing if your application goes offline when someone tries a bunch of incorrect passwords. A: you identify an attack in progress or B: you identify an idiot.

Use policy based management to manage a large number of servers. You can create a policy to prevent the ‘sa’ account from being enabled. Common attacks try very old methods, the idea is that you may know your security up and down, but you don’t know where all your servers are.

Use PBM to secure xp_cmdshell. Don’t allow sysadmins to execute windows commands. PBM can not only tell you a server is out of compliance but it can prevent enabling this feature in the first place.

Use PBM to prevent escalation to ‘sysadmin’ privileges. Don’t lock yourself out but you should prevent other new DBAs from handing out this privilege like candy.

Use least privilege methods for service accounts. When installing SQL Server, use a domain user account and don’t give it any privileges. The SQL Server install will automatically grant the permissions it needs.

Use complex passwords. If an attacker does dump the windows password hashes, a complex password will make it very inconvenient to crack. Use several character classes and more than 14 characters on passwords you don’t have to type frequently. Don’t use dictionary words or number/character substitutions for common words. (eg l33t h4ck0r)

Don’t grant other people sysadmin or local Windows admin on the SQL Server. Even good intentions can cause terribly configured vulnerable servers.

Consider creating outbound firewall rules. Does your SQL Server need the ability to browse web (80/443)? Does your SQL Server need to connect to other sql servers? (1433) Try removing the gateway from your network settings.

Use non-standard SQL Server ports. This can get painful but one of the first steps for attackers is scan the network for open ports. It can be more challenging to identify the software if it’s on a non-standard port. Just a suggestion, but you should pick a port that isn’t used by highly vulnerable software.

That should give you a few layers of security to chew on. At this point the most important thing to do is create a recovery plan. Just assume that the attackers will win someday. Create a plan to rebuild from the ground up and restore data. Use the old data to preform forensic analysis on so you can prevent future similar attacks and maybe even identify the attacker who causes us so many gray hairs.