我在数据中心的防火墙外托管了一台 SQL Server 2005 服务器。该服务器的补丁等都是最新的。
有一些旧的 MSSQL 蠕虫（Slammer？）仍然感染了全球数千台服务器，并寻找要感染的服务器。当他们找到一台服务器时，他们开始进行数十次连接尝试，这会使 SQL Server 瘫痪，即使感染尝试没有成功。
在过去 5 年左右的时间里，这种情况一直发生（平均每隔几个月一次），我只是使用本地安全策略阻止了每个受感染的 IP 地址。
但这已经开始变得陈旧了...
是否有配置选项、可选修补程序，某物这会阻止它监听这些连接尝试吗？
我已经考虑过三种解决方案：
- 阻塞全部除了来自“白名单” IP 之外，1433 上的传入连接不是一种选择。我需要在路上、在家等情况下进行访问。
- 在 WAN 上封锁 1433，然后使用 VPN 访问它，这不是一个好办法。处理这样的事情比偶尔封锁流氓服务器更麻烦。
- 从端口 1433 更改为其他端口不是一个选择——我需要处理 IT 问题才能获得另一个出站办公室的端口异常，我很幸运地说服他们允许我使用 1433 出站。
问题的答案：
- 我们的预算为零。我正在寻找一种解决方案来修复 MSSQL 的明显弱点，即这些感染尝试会使其处于 DOS 状态。如果微软的答案是阻止端口，我不认为这是一个解决方案。
- 我意识到大多数人宁愿将服务器的软肋隐藏在防火墙后面，也不愿真正地加强它。
- 我并不在“Windows 域”中——我连接数据库相关任务的时间有一半是通过 OS X 机器进行的，无论是在家里还是在路上。
- 在现场安装另一个设备作为防火墙/入侵检测将使我的托管费用翻倍。不切实际。
- 请相信我关于 VPN 的说法......它对我来说并不实用。
如果没有可接受的解决方案，我将维持现状。
答案1
您基本上已经设定了最坏的情况，并且显然决心坚持下去。
你已经发现，将服务器置于互联网上公开访问只会带来麻烦。正确的解决方案是设置并使用它。我很好奇你为什么不想这样做。它为连接到服务器的过程添加了一个步骤，并为环境提供了较高的安全性，因为人们无法直接访问你的 SQL Server。
尽管从公共互联网访问你的服务器要容易得多，但是为了省去使用 VPN 的步骤却要危险得多。
并且谁能保证，类似让 SQL Slammer 摧毁整个网络的 SQL Server 的漏洞不会再次发生，从而使您的 SQL Server 面临风险。
回答您的问题，没有办法告诉 SQL Server 忽略这些连接请求，因为它们是合法的连接请求。
答案2
由于您已经排除了问题中可能的“最佳”解决方案，我能想到的一个建议是，在服务器前面安装基于 Linux 的防火墙，并使用某种方法将这些故障记录到 fail2ban 可以获取它们的地方，然后在防火墙中阻止它们。这基本上可以自动执行您现在手动执行的过程。但我不确定您如何让您的 SQL 服务器记录这些故障，以便 fail2ban 可以使用它们。
另一个选择是研究类似系统呼噜它可以检测攻击并进行处理。
答案3
服务器有什么用？我想您连接它是为了做某事，管理它还是使用它？其他服务器和/或用户是否也连接它，它们位于何处以及它们用它做什么？
一般来说，永远不要将应用服务器以这样的方式不受保护地放在互联网上。
正如 Kevin 所说，最糟糕的情况是，用一些智能的东西来应对它 - 比如 Microsoft ISA 或 TMG，因为它首先是一个 Microsoft 应用程序。但任何可以自动检测和处理攻击的东西都可以......
...否则 - 建立标准加密链接绝对是最佳选择。您应该在 SQL Server 和内部网络之间建立点对点隧道 - 我不认为以正确的方式建立隧道会带来任何麻烦。要在旅途中获得远程访问，您可以使用最适合您的 VPN 连接到您的网络，然后通过隧道。所有操作系统平台都内置了这些东西。
如果您确实需要让它位于互联网中间，但只有您需要连接它，至少设置 ipsec 使其仅接受来自特定 Windows 域中的特定机器的流量。
答案4
丹尼是对的...但是如果你决心继续这样做，请尝试设置 IPSEC 并仅允许在 TCP/1433 上进行 IPSEC 加密连接。