我在数据中心的防火墙外部安装了SQL Server 2005服务器。 它完全是最新的补丁等。
还有一些老的MSSQL蠕虫（Slammer）， STILL感染了全世界数以千计的服务器，他们正在寻找感染服务器。 当他们find一台服务器时，即使感染企图不成功，他们也会开始进行数十次连接尝试，从而使SQL Server瘫痪。
在过去的5年左右，这种情况已经发生了（平均每隔几个月就会发生一次），我只是使用本地安全策略来阻止每个被感染的IP地址。
但是，这已经开始变老了。
有没有configuration选项，可选的修补程序，会阻止它甚至听这些连接尝试？
我已经考虑过三种解决scheme：
提出的问题的答案：
如果没有可以接受的解决scheme，我将生活在现状中。
你基本上已经设置了最坏的情况，显然决心坚持下去。
把服务器公开从互联网上获取只是要求你find麻烦。 正确的解决scheme是设置一个VPN并使用它。 我很好奇你为什么不想要。 它为连接到服务器的过程添加了一个步骤，并为环境提供了一个主要级别的安全性，因为人们无法直接访问您的SQL Server。
从公共互联网上简单地访问你的服务器要容易得多，只是为了节省VPN中的步骤更为危险。
谁又能说，像SQL Slammer这样的另一个类似于SQL Slammer在networking上销毁SQL Server的错误不会再发生在SQL Server的风险之中。
在回答你的问题时，没有办法告诉SQL Server忽略这些连接请求，因为它们是合法的连接请求。
既然你已经消除了你的问题中可能的“最好的”解决scheme，我想到的一个build议就是在服务器端安装基于Linux的防火墙，并使用一些方法将这些故障logging到fail2ban可以接收的地方然后在防火墙中阻止它们。 这将基本上自动化您手动进行的过程。 我不确定你的SQL服务器如何logging这些故障，以便fail2ban可以使用它们。
另一个select是看看像Snort这样的系统，可以检测到攻击并处理它。
服务器的用途是什么？ 我想你连接到它的东西，pipe理它或使用它？ 其他服务器和/或用户是否也连接到它，它们位于何处，以及它们如何处理？
一般来说，永远不要把应用程序服务器置于互联网上。
正如凯文所说，在最坏的情况下，可能会面临一些智能问题，比如微软的ISA或者TMG，因为这是一个微软的应用程序。 但是任何能够自动检测和处理攻击的东西都可以…
否则 – build立一个标准的encryption链接绝对是最好的方法。 你应该在SQL Server和你的内部networking之间build立一个点到点的隧道 – 我不明白这样做会不会增加任何麻烦。 为了在旅途中获得远程访问，您可以使用任何最适合您的VPN连接到您的networking，然后通过隧道。 所有的操作系统平台都内置了这些东西。
如果你真的需要站在互联网的中间，但只有你需要连接到它，至less设置ipsec，让它只接受来自特定Windows域中特定机器的stream量。
你说增加一个额外的威胁保护服务会增加你的可乐成本，但不一定。 你可以在同一台机器上运行这些服务，如果它有足够的umpf，不会使用任何额外的机架空间。 你甚至可以在虚拟机上运行这些服务，而从用户（和僵尸）的angular度来看，它仍然出现在主操作系统的前面，它们将SQL连接到本地任务上，并将公共接口上的端口1433 ）连接到入侵检测器（是主机或虚拟机上的一项服务），并将其连接到主要服务。
需要连接多less个地址到你的服务器，以及它们有多活跃？ 不会维持一个时间表，而是比只使用黑名单更有效？ 把这个好事比起来，要比列举坏事更实际。 客户端从固定地址的两个地点连接，具体允许这些地址。 客户端2连接一个ISP，发送dynamic地址？允许他们的ISP IP池通过，让某种自动黑名单（fail2ban或这样）尝试捕获也在该范围内的坏主机。
即使您在“路上”需要访问，您也不需要访问每个 IP地址。 如果仅仅是你（你没有说明你的用户库的大小和性质）需要公开地连接，那么某种敲门解决scheme会起作用吗？ 虽然一旦你开始在这个方向上讲一个适当的VPN它可能是一样容易设置。
这两个选项显然会增加额外的复杂性，所以你必须权衡这个危险，以决定是否值得一试。 但海事组织的危险性非常高 – 下一个零日攻击可能会在你遇到新闻之前触发你，所以你不会有任何预警，只能依靠你的备份，而且MS非常迅速地发布修补程序 – 所以什么也不做。在我的书里不是一个可行的解决scheme。 我知道你不想听到这个消息，但是我是在这种情况下会吟诵“VPN，VPN，VPN”的人之一。
丹尼是对的。 。 。 但是，如果您决定提前尝试设置IPSEC，并且只允许TCP / 1433上的IPSECencryption连接。