MSSQL 2005 on port 1433 gets DOS from infected servers

Question

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.

Answer 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.

Answer 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.

Answer 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.

Answer 4

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...

Answer 5

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.