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