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 have a SQL Server 2005 server hosted outside my firewall at a data center. It is fully up-to-date on patches, etc.

There's some old MSSQL worm (Slammer?) that STILL infects thousands of servers worldwide, and they hunt for servers to infect. When they find a server, they start making dozens of connection attempts, which brings SQL Server to its knees, even though the infection attempt is unsuccessful.

Over the past 5 years or so that this has been happening (on average, about once every few months), I've just blocked each infected IP address using the Local Security Policy.

But that's starting to get old...

Is there a configuration option, optional hotfix, something that will stop it from even listening to these connection attempts?

Three solutions I've already considered:

  • Blocking all incoming connections on 1433 other than from a "whitelist" of IPs is not an option. I need access while on the road, at home, etc.
  • Blocking 1433 on the WAN and then using a VPN to get to it is not an option. Dealing with such things would add more headaches than just blocking a rogue server occasionally.
  • Changing from port 1433 to something else is not an option--it would require me to deal with the IT dungeon to get another outbound port exception from the office, and I'm lucky to have convinced them to allow 1433 outbound for me.

Answers to questions posed:

  • We have zero budget. I'm looking for a solution to fix MSSQL's apparent vulnerability to being placed in a state of DOS by these infection attempts. If Microsoft's answer is to block the port, I don't consider that a solution.
  • I realize that most people would rather hide a server's soft underbelly behind a firewall rather than to actually harden it.
  • I'm not on a "Windows domain"--half the time I connect for database-related tasks, it's from an OS X machine, either from home or the road.
  • Having another box on-site to serve as a firewall / intrusion detection would double my colocation fees. Not practical.
  • Please believe me w/r/t VPNs... it's just not practical in my situation.

If there is no acceptable solution, I'll live with the status quo.

share|improve this question

You've setup basically the worst case scenario and are apparently determined to stick with it.

Putting the server publicly accessible from the Internet is just asking for trouble as you have found out. The correct solution is to setup a VPN and use that. I'm curious why you don't want to. It adds a single step to the process of connecting to the server and provides a major level of security to the environment as people can't access your SQL Server directly.

While it's much easier to simply access your servers from the public Internet it's much more dangerous just to save yourself the step of VPNing in.

And who's to say that another bug like that one that let SQL Slammer destroy SQL Servers all over the net won't happen again with your SQL Server at risk.

In answer to your question, no there's no way to tell the SQL Server to ignore these connection requests as they are legitimate connection requests.

share|improve this answer
+1 for making it clear that any workaround is only good until the next bug comes around that destroys his SQL server – Kevin Kuphal Aug 4 '09 at 21:44
Who's to say that another bug won't allow someone to break through the VPN or remotely exploit the firewall software/firmware? Microsoft's patches have provided adequate security from known exploits for the past 10 years I've had this sort of setup.The MSFTP and W3SVC services get pinged 100x more often by exploit attempts and show no signs of slowing down. – richardtallent Aug 4 '09 at 21:49
None is saying that this would not happen, but the whole point of most web services is to be a public service and at that point you can not hide it away at all. Does your SQL Server instance absolutely need to be a public service? Anything that doesn't have to be available to direct ungated connections from the unwashed masses should not really be listening directly on a public interface in these hack-happy times. – David Spillett Aug 4 '09 at 22:24
There's no guaranteeing that VPN services won't be attacked. But cracking a VPN service requires busting through a domain account. Domain accounts by default lock down after a few bad attempts. The sa account however you can try every combination possible and the account won't ever lock out. It's bad form on the hacker to hit the server so often that the database goes down. If they were doing there job correctly you'd never see the problem unless you were logging failed login attempts. – mrdenny Aug 5 '09 at 2:08
Not to mention the fact that the VPN connections are encrypted, where the SQL Connection isn't. Yes web servers get attacked all the time. That's why they should be in a DMZ, protecting the rest of the systems from them. So that when the web servers are compromised the rest of the systems aren't. – mrdenny Aug 5 '09 at 2:10

Since you've eliminated the likely "best" solutions in your question, one suggestion I could come up with would be to front the server with a Linux based firewall and use some method to log these failures to a place where fail2ban could pick them up and then block them in the firewall. This would basically automate the process you're doing manually now. I'm not sure exactly how you'd have your SQL server log these failures so that fail2ban could consume them though.

Another option would be to look at systems like Snort that could detect the attack and deal with it.

share|improve this answer

What is the use of the server? I figure you connect to it for something, managing it or using it? Are other servers and/or users also connecting to it, where are they situated and what do they do with it?

Generally, never put application servers unprotected on the internet like that.

As Kevin says, at worst case, front it with something intelligent - like a Microsoft ISA or TMG perhaps, as it's a Microsoft application to begin with. But anything that can detect and handle the attacks automatically will do...

...otherwise - establishing a standard encrypted link is definitely the best way to go. You should have a point-to-point tunnel between the SQL Server and your internal network - I don't see how doing it the right way would add any headaches. To gain remote access while on the road, you connect to your network using whatever VPN suits you the best and then go over the tunnel. All OS platforms has these things built-in.

If you really truly need to have it standing in the middle of the internet, but only you need to connect to it, at least set up ipsec to have it only accepting traffic from specific machines in a specific windows domain.

share|improve this answer

You say that adding an extra threat protection service would increase your colo costs, but it doesn't have to. You could run those services on the same machine if it has enough umpf which would not use any extra rack space. You could even run those services in VMs while still appearing to be in front of the main OS from the point of view of users (and zombies) connecting in - put SQL on local-only duty and pass port 1433 from the public interface(s) to the intrusion detector (be is a service on the main host or in a VM) and have it pass connections through to the main services as it sees fit.

How many addresses need to connect to your server, and how dynamic are they? Would not maintaining a while list as well be more effective than using only a blacklist? Unemerating the good is far more practical than enumerating the bad. Client one connects from two locations with fixed address?, allow those addresses specifically. Client 2 connects from an ISP that hands out dynamic addresses?, allow they ISP's IP pool through and let some sort of automated blacklist (fail2ban or such) try catch bad hosts that are also in that range.

Even though you need access when "on the road" you aren't going to need access from every IP address out there. And if it is just you (you've not stated the size and nature of your userbase) that needs to connect that openly, would some sort of port-knocking solution work? Though once you start talking in that direction a proper VPN it probably just as easy to setup.

Both these options obviously add extra complication, so you'd have to weigh then against the danger to decide if anything like them is worth while. But IMO the danger is very high - the next zero day exploit could hit you before it hits the news so you'd have no forewarning and would just have to rely on your backups and MS releasing a hotfix very very quickly - so doing nothing would not be a viable solution in my book. I know you don't want to hear it, but I'm one of the people who would chant "VPN, VPN, VPN" in this sort of situation...

share|improve this answer

Denny is right . . . BUT if you're determined to ahead like this try setting up IPSEC and only allow IPSEC encrypted connections on TCP/1433.

share|improve this answer

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.