Problem solve Get help with specific problems with your technologies, process and projects.

Empirical Hacker - Protect your database server, part 1

The Weakest Link: Protect your database server

By Luis F. Medina

Will you be another statistic? Is the connection to your database server mutually exclusive? Has database security become an empirical concept among database administrators in your company? If the probability of an attack in the future is determined by your observations of security threats in the past, how do you know that your server is not being hacked right now? In my previous article, "Protect your firewall -- set embryonic limits," we focused on the importance of knowing the latest traffic volume -- and limiting flood attacks -- to your servers. Today, we'll begin a three-part series on how to protect your database server and explore the configuration between your IIS (front-end) servers and your SQL database server (or servers).

Join me on a journey to explore the security vulnerabilities in your network and reduce your chances of becoming another statistic.

Mutually exclusive
First, let's go over some basic steps. (You probably already know this stuff, but read along and you will find your first security weak link.) It is vitally important that your database runs on a dedicated server with no other applications or services, such as IIS (Internet Information Server) or FTP (File Transfer Protocol). Failure to run in "dedicated mode" will open up additional ports or sockets and put your database server security at risk. Whether you're running SQL on Windows 2000 or Oracle on Unix, the operating system -- by default -- starts unnecessary services or processes that open up additional TCP/IP ports; these non-database specific ports must be stopped and permanently disabled.

Front-end communications to your database server must be mutually exclusive over a non-default specified TCP/IP port. Prevent your database server from responding to broadcast requests from clients and force protocol encryption to protect confidential data from being viewed by users. The Default Port, Force Protocol Encryption, and Hide Server option can be set in the SQL 2000 Server Network Utility. Be prepared to restart the MSSQL$<Instance name> service for changes to take effect.

Relative frequency
Is the empirical hacker about to run the code of his choice against your server again? Last month Microsoft reported another security vulnerability (Q326573) that affects MDAC versions 2.5, 2.6 and 2.7. A patch (see MS02-040) is available to fix the "Unchecked buffer in MDAC function that could enable a SQL server compromise" with above versions. This vulnerability has a moderate rating, but is the security level of your database server moderate? How secure are your IIS servers? Have you implemented security (in other words, a router with ACL) between your Web servers and your database server?

Let's look inside your SQL server configuration.

Your SQL Instance name should be a unique name and not the default name of your server. Before changing the SQL default port, verify that your custom application is not statically coded to communicate with SQL on port 1433 only -- in other words, check for any dependencies to port 1433. Specify a custom destination path for SQL Program Files and SQL Data Files. Do not use the default installation path of %localdrive%Program FilesMicrosoft SQL Server, because this is a predictable path (just like winnt) and hackers already know it. Restrict access to your database server and configure Microsoft Data Access Component (MDAC) on required front-end servers only. (We'll address changing the winnt path later in the series. Right now, your database security is top priority.)

Collectively exhaustive
Just as a server that lacks the appropriate service pack and hotfixes is a target for hackers, an improperly configured server is equally vulnerable to an outside or inside attack. Your SQL server is no exception, just more challenging for hackers. Your database server, and especially your production servers should not use Client for Microsoft or File and Print Sharing services at the O/S level -- even if the servers are protected by a hardware or UNIX-based firewall.

Make sure you disable NetBios over TCP, LMHOST Lookup, and do not register your database server connection's address in DNS; use the invalid IP address of the server instead. Disable all of the Windows 2000 services except for the following: Event Log, MSSQL$<Instance Name>, Plug and Play, Security Accounts Manager and SQLAgent$<Instance Name>.

Remember to perform a full backup of your server before changing the state of the server. Make sure that you change the services from automatic to manual mode first, then clear the event log, reboot the server, and test connectivity from your application and SQL Client to your database. Once you have confirmed that your server is properly working and there are no critical events in the event log, change the services from manual to disabled state. In the event that you have to change a service in disable mode to automatic mode, and you cannot obtain the properties for the service, one way to make the change is in the Registry. Change the hexadecimal number in the Value Data field from 4 to 2 of the REG_DWORD "Start" of the Hive key:


When was the last time you applied a SQL service pack or hotfix? Or updated the version of MDAC drivers on your Web servers and on your database server?

Below is part one of my SQL Security Checklist. In my second part of the "protect your database server" mini-series, we'll focus on security trace template, authentication modes, Source Name (DSN) configuration, and Enterprise Manager.

The mode
SQL Security Checklist, part one:

  1. Use a custom installation path for SQL program files and SQL data files.
  2. Change the default TCP/IP (1433) port for SQL connections.
  3. Implement security between your front-end servers and the database server.
  4. Restrict access to your database server to front-end servers that require a connection.
  5. Block all TCP/IP and UDP ports except for the SQL port you plan to use.
  6. Disable unnecessary O/S services and processes; uninstall non-SQL programs.
  7. Apply TCP/IP filtering in the O/S level and only accept your SQL port.
  8. Make sure that you are running the most stable and secure MDAC version and patch/hotfix.
  9. Disable unnecessary SQL network libraries, components and agents.
  10. Confirm server role is SQL only and do not run IIS on the same server.
  11. Customize Auto Start SQL Service and Agent to use local System Account.
  12. Use Mixed Mode for Authentication Mode and set unique password for SA account.
  13. Apply service packs and hotfixes at O/S and SQL level.
  14. Restrict Enterprise Manager access.

Did you pass the test? Does your SQL server configuration already include the security tips in this article? If yes, kudos! It's been my experience that some of these basic steps have often been overlooked by experienced IT professionals. If you're serious about security, you must pay attention to details and leave no room for hackers.

Please write to me and let me know whether this article has brought to light any potential weak links in your network.

Luis Medina is the author of "The Weakest Link Series," which offers network managers an opportunity to identify ongoing network security issues. Luis also answers security questions in SearchNetworkings Ask the Expert section. Submit a security question to Luis here or view his previously answered Ask the Expert questions.

This was last published in August 2002

Dig Deeper on Working With Servers and Desktops

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.