端口 1433 上的 MSSQL 2005 从受感染的服务器获取 DOS

Question

我在数据中心的防火墙外托管了一台 SQL Server 2005 服务器。它在补丁等方面是完全最新的。

有一些旧的 MSSQL 蠕虫（Slammer？）仍然会感染全球数以千计的服务器，并且它们会寻找要感染的服务器。当他们找到一台服务器时，他们开始进行数十次连接尝试，这使 SQL Server 屈服，即使感染尝试未成功。

在过去 5 年左右的时间里，这种情况一直在发生（平均大约每几个月一次），我只是使用本地安全策略阻止了每个受感染的 IP 地址。

但这开始变老了......

是否有一个配置选项，可选的修补程序，东西，这将阻止它，甚至听这些连接尝试？

我已经考虑过的三种解决方案：

• 除了来自 IP 的“白名单”之外，阻止1433 上的所有传入连接不是一种选择。我需要在路上、家里等时访问。
• 在 WAN 上阻止 1433 然后使用 VPN 访问它不是一种选择。处理这些事情会比偶尔阻止流氓服务器更让人头疼。
• 从端口 1433 更改为其他端口不是一种选择——它需要我处理 IT 地牢以从办公室获得另一个出站端口异常，我很幸运地说服他们允许我出站 1433。

对提出的问题的回答：

• 我们的预算为零。我正在寻找一种解决方案来修复 MSSQL 明显易受这些感染尝试置于 DOS 状态的漏洞。如果微软的答案是阻止端口，我不认为这是一个解决方案。
• 我意识到大多数人宁愿将服务器的软肋隐藏在防火墙后面，而不是真正将其加固。
• 我不在“Windows 域”上——有一半时间我连接数据库相关任务，它来自 OS X 机器，无论是在家中还是路上。
• 在现场使用另一个盒子作为防火墙/入侵检测将使我的托管费用翻倍。不实用。
• 请相信我 w/r/t VPN ......在我的情况下这不切实际。

如果没有可接受的解决方案，我将维持现状。

Answer 1

您基本上已经设置了最坏的情况，并且显然决心坚持下去。

正如您所发现的那样，将服务器从 Internet 公开访问只是自找麻烦。正确的解决方案是设置一个 VPN 并使用它。我很好奇你为什么不想。它为连接到服务器的过程添加了一个步骤，并为环境提供了主要级别的安全性，因为人们无法直接访问您的 SQL Server。

虽然简单地从公共 Internet 访问您的服务器要容易得多，但仅仅让自己省去 VPN 连接的步骤就危险得多。

谁能说另一个让 SQL Slammer 破坏整个网络的 SQL Server 的错误不会再次发生，并且您的 SQL Server 处于危险之中。

在回答您的问题时，没有办法告诉 SQL Server 忽略这些连接请求，因为它们是合法的连接请求。