MSSQL 2005 on port 1433 gets DOS from infected servers

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.

Solution 1:

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.

Solution 2:

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.

Solution 3:

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.