Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm helping a customer with an exposed MSSQL 2005 server. They will not budge on a firewall or VPN solution... and there logs are full of signs of attacks.

What can be done to protect a exposed SQL 2005 Server without additional hardware?

By exposed I mean if you point SSMS at the public IP with the right credentials you are connected.

share|improve this question
Removed the IP address to protect the innocent (just in case it was a real one). – Kara Marfia Jul 6 '10 at 18:03
@ Kara Marfia It was google ;) I wouldn't post the real one! I kinda wanted to see who would say something. – NitroxDM Jul 6 '10 at 18:15
It's still present in the revision history anyway ;) – Mark Henderson Jul 7 '10 at 2:48
up vote 0 down vote accepted

Slightly old, but still has some good information. MSDN chapter on Securing Your Database Server.

You could also purchase a software firewall, such as Zone Alarm or Outpost.

share|improve this answer

One cheap trick is to move the listening port off the default 1433. Clients can connect using the explicit port syntax, like tcp:,12345 if the port is 12345. This eliminates the vast majority of bots scanning 1433 for sa,blank vulnerability. This of course does not solve the company from the other responsibilities involved: strong password policies, recycle passwords, monitor logs for suspicious activities etc etc.

Another thing they should consider is implement DirectAccess. DA eliminates most if not all of old VPN solutions drawbacks and companies scared by the Helpdesk costs of VPN should seriously consider DA instead.

And finally, there is the obvious question why do they need TDS access from the internet? Knowing what is the requirement, we may recommend alternative, less dangerous, solutions.

share|improve this answer
WHY - The individual who started the company set it up and it's his way or the highway. There is a few people there that see a need for some changes. That is how I got involved. – NitroxDM Jul 8 '10 at 14:28

Configure an IPSEC policy that permits connections to the SQL Server ports based on a whitelist of IP addresses/ranges, as previously mentioned. That means the OS will bear the burden of ignoring the traffic (which is why the network devices are obviously preferred). Make sure the firewall is up to protect all of the OS ports, especially those related to RPC, SMB, etc. Make sure the IPSEC policy ONLY allows connection to the SQL Server port. You shouldn't need to open a port for the SQL Browser Service (udp/1434).

If you can, alter the port SQL Server is listening on (probably tcp/1433) to some other port (make sure the IPSEC policy accomodates). If it's not on a well-known port, especially if it's a higher port, that will stop most of the scans against the system. The users will just need to know to connect via server,*port* instead of just server.

share|improve this answer

(That public IP belongs to Google, so the edit probably wasn't necessary)

The best thing you can do to secure a SQL server of any stripe is to whitelist the hosts that are allowed to connect to it, and to make sure to run as few other services as possible on that machine.

Another good practice is to severely restrict the access possible from the web side. If the web app is only allowed to run a few dozen stored procedures, then there are practically no attack vectors from an exploited website. On the other hand, if it can run arbitrary queries, then you're going to have problems.

Never run a webserver on your database machine: that's a huge, unnecessary attack vector that should be avoided whenever possible. Webservers and webservices are very often exploited. If your database is attached to the same machine, then it is far more likely to be taken down as well.

The easiest way to achieve all of this (without adding any new hardware) is to enable IPSEC, and tunnel requests from your web server to your database server. Here is a basic IPSEC tutorial.

If you have to have them on the same server, you can get a little security by only allowing local connections, but that's no help if your website gets exploited.

To disable remote connections, go to Server->Properties->Connections and uncheck "Allow Remote Connections to this Server".

MSSQL Remote disable picture

share|improve this answer
I think he doesn't even have a web application. It's simply the SQL port open to the internet. – mryan1 Jul 6 '10 at 21:38
@myran1: Well, that makes it easy then. Just set it to accept only connections from the local host. That's in the general server security options. Wouldn't trust it myself, though...Databases are almost always more secure than webapps. – Satanicpuppy Jul 7 '10 at 2:22
mryan1 is correct. It's simply the SQL port open to the internet. – NitroxDM Jul 8 '10 at 14:15

I'd strongly consider cutting all ties with a company that insists on putting their DB on the net without any form of IPSec, firewalling, or private connections. I hope they at least use some form of encryption.

It's a major liability waiting to happen; possibly a lawsuit or criminal negligence (depending on the data involved).

share|improve this answer
I'm considering dropping them as a customer. The biggest issue with them is politics. Even if I drop them I bet there are several one-man-band shops that would find this post usefully. – NitroxDM Jul 8 '10 at 14:27

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.