我在数据中心的防火墙外托管了一台 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 ......这在我的情况下是不切实际的。
如果没有可接受的解决方案，我将接受现状。
您基本上已经设置了最坏的情况，并且显然决心坚持下去。
正如您所发现的，将服务器从 Internet 上公开访问只是自找麻烦。正确的解决方案是设置 VPN 并使用它。我很好奇你为什么不想。它在连接到服务器的过程中增加了一个步骤，并为环境提供了主要级别的安全性，因为人们无法直接访问您的 SQL Server。
虽然从公共互联网简单地访问您的服务器要容易得多，但仅仅为自己省去 VPN 接入的步骤就更加危险了。
谁能说另一个让 SQL Slammer 破坏整个网络的 SQL Server 的 bug 不会再次发生，因为您的 SQL Server 处于危险之中。
在回答您的问题时，没有办法告诉 SQL Server 忽略这些连接请求，因为它们是合法的连接请求。
由于您已经消除了问题中可能的“最佳”解决方案，我可以提出的一个建议是在服务器前面安装一个基于 Linux 的防火墙，并使用某种方法将这些故障记录到 fail2ban 可以接收它们的地方然后在防火墙中阻止它们。这将基本上自动化您现在手动执行的过程。我不确定您如何让 SQL 服务器记录这些故障，以便 fail2ban 可以使用它们。
另一种选择是查看像Snort这样可以检测到攻击并进行处理的系统。
服务器有什么用？我想你连接到它是为了什么，管理它还是使用它？其他服务器和/或用户是否也连接到它，它们位于何处以及如何处理它？
一般来说，永远不要像这样将不受保护的应用程序服务器放在互联网上。
正如 Kevin 所说，在最坏的情况下，在它前面加上一些智能的东西——比如 Microsoft ISA 或 TMG，因为它一开始就是一个 Microsoft 应用程序。但是任何可以自动检测和处理攻击的东西都可以......
...否则 - 建立标准的加密链接绝对是最好的方法。您应该在 SQL Server 和您的内部网络之间建立一个点对点隧道——我不明白如何以正确的方式进行操作会增加任何麻烦。要在旅途中获得远程访问，您可以使用最适合您的任何 VPN 连接到您的网络，然后通过隧道。所有操作系统平台都内置了这些东西。
如果你真的需要让它站在互联网的中间，但只需要连接到它，至少设置 ipsec 让它只接受来自特定 Windows 域中特定机器的流量。
您说添加额外的威胁防护服务会增加您的托管成本，但并非必须如此。如果它有足够的 umpf 并且不会使用任何额外的机架空间，您可以在同一台机器上运行这些服务。您甚至可以在虚拟机中运行这些服务，同时从连接输入的用户（和僵尸）的角度来看，它们似乎仍然位于主操作系统之前 - 将 SQL 仅用于本地职责并从公共接口传递端口 1433（s ) 到入侵检测器（是主主机或虚拟机中的服务），并让它在它认为合适的时候将连接传递到主服务。
需要多少个地址连接到您的服务器，它们的动态程度如何？维护一个while列表会不会比只使用黑名单更有效？列举好的比列举坏的要实用得多。客户端一从两个具有固定地址的位置连接？，特别允许这些地址。客户端 2 从分发动态地址的 ISP 连接？允许他们通过 ISP 的 IP 池并让某种自动黑名单（fail2ban 等）尝试捕获也在该范围内的坏主机。
即使您在“在路上”时需要访问，您也不需要从那里的每个IP 地址访问。如果只有您（您没有说明您的用户群的规模和性质）需要公开连接，那么某种端口敲门解决方案会起作用吗？虽然一旦你开始朝那个方向谈论一个合适的 VPN，它可能同样容易设置。
这两个选项显然都增加了额外的复杂性，所以你必须权衡危险来决定像它们这样的东西是否值得。但是 IMO 危险非常高 - 下一个零日漏洞可能会在新闻发布之前袭击你，所以你没有预警，只需要依靠你的备份和 MS 非常快速地发布一个修补程序 - 所以什么都不做会在我的书中不是一个可行的解决方案。我知道你不想听到它，但我是在这种情况下会高呼“VPN，VPN，VPN”的人之一......
丹尼是对的。. . 但是，如果您决心像这样尝试设置 IPSEC，并且只允许 TCP/1433 上的 IPSEC 加密连接。