10 Common SQL Server mistakes

Posted on Posted in Database, IT, Security

Database are the heart of a business systems

SQL Server by the nature of what it does (holding your systems and client data) unsurprisingly is high on this risk fact when it comes to breaches of your system. the costs and fine the ICO are now enforcing on business for loss of data is more and more common.some 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 prejudicial activities upon a SME can be devastating.

So here is a list of things Accede IT think you need to look at, our top 10 Common SQL Server mistakes we have found and what you can do to prevent them:


  1. Vanilla Installs – Memory – For me  any software provider that needs to use a SQL Server, be it as a standalone system or share via instance needs to be kicked for their professionalism if they havent set the memory available for the instance properly. Out of the box if you have installed SQL server and clicked next, next, next, OK. You can guarantee that your SQL instance will take the default setting for min server memory which is 0, and the default setting for max servermemory is 2147483647 MB  (thats 2097151GB of Memory ( Ram and Virtual Memory in total ). Now I don’t know many SME that can afford hardware to this spec, but if there are any then please get in touch. Most servers/machine running will have around 8 to 16GB of Ram with an addition virtual memory (slower disk memory) of maybe 2-3 times that. So the system is expecting to run with this memory and guess what it cant so it slow things down. so by telling SQL how much actual memory it can use SQL can then ensure it manages threads and process properly. 
  2. Vanilla Install – CPU –  Again its school boy error made by simple accepting the vanilla setting. SQL server as a rule will take all resource it can. This means you could be starving the operating system of key important CPU time. And guess what SQL cant run with out the operating system being stable. So be sensible and allocate the cpu cores properly.
  3. SQL Server is not running – Again during the installation you need to be particular careful on how the SQL Server Service is setup. Some people again accept the Local Service or Network Service accounts. Don’t do this is a recipe for attacker to come flocking. Our suggest best Practices as a minimum is to run separate SQL Server services under separate Windows accounts. Whenever possible, use separate, low-rights Windows or Local user accounts for each SQL Server service. 
  4. Installing SQL Server on a domain controller -For security reasons, we recommend that you do not install SQL Server 2014 on a domain controller. SQL Server Setup will not block installation on a computer that is a domain controller, but the following limitations apply:
    • You cannot run SQL Server services on a domain controller under a local service account. Domain Account are a bigger risk when used for running services, a domain account will evidently mean you open access to the wider domain of server you may have

    • After SQL Server is installed on a computer, you cannot change the computer from a domain member to a domain controller. You must uninstall SQL Server before you change the host computer to a domain controller.

    • After SQL Server is installed on a computer, you cannot change the computer from a domain controller to a domain member. You must uninstall SQL Server before you change the host computer to a domain member.

    • SQL Server failover cluster instances are not supported where cluster nodes are domain controllers.

    • SQL Server Setup cannot create security groups or provision SQL Server service accounts on a read-only domain controller. In this scenario, Setup will fail.

  5. SA ( Sql Account ) – Please Please please don’t make this a simple password, it frightens me to death when I go to an istallation and find the setup is for SQL server userame: sa and password as you guessed it password. The sa account ( if you us mixed mode or SQL only ) s the heart to your installation. You wouldnt leave the key to your house in the door, so don’t make it easy for the hacker . The fact is this password and user wont be used very often so make the password something obscure and preferable over 14 characters and you should be ok. Better still if you can disable SQL Authentication protocol., This will block common tools that use SQL authentication and the known account ‘sa’. The hackers then 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
  6. 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. We can help you audit these patches so you have a controlled approaches to patch management.
  7. 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  or at least start warning you oer somebody who looks after our systems when someone tries a bunch of incorrect passwords. A: you identify an attack in progress or B: you identify a forgetful user.
  8. Don’t grant other people sysadmin or local Windows admin on the SQL Server. Even good intentions can cause terribly configured vulnerable servers. Be strict about who can access this levels of permissions.
  9. hackersOutbound firewall rules. Does your SQL Server need the ability to browse the web (80/443)? I would hope that anyone logged on to the server wouldnt be able to free surf the net, as you run the risk of nasty getting in ?Does your SQL Server need to connect to other sql servers? (1433) Try removing the gateway from your network settings.
  10. Use non-standard SQL Server ports. This can get painful but one of the first steps for attackers is scan the network for known 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. The default SQL Server port is 1433.

We have covered just 10 Common SQL Server mistakes, if your software providers have made these mistakes what others have they made. Our Principal SQL Specialist, James in MCITP SQL server Administration certified and can help you ensure you are safe from the world of hackers.

[wpseo_address oneline=”1″ show_state=”0″ show_phone=”1″ show_email=”1″]

Views All Time
Views Today