我正在帮助一位客户处理暴露的 MSSQL 2005 服务器。他们拒绝使用防火墙或 VPN 解决方案……而且他们的日志中充满了攻击迹象。
如何在不增加硬件的情况下保护暴露的 SQL 2005 Server？
所谓暴露，是指如果你将 SSMS 指向公共 IP只要有正确的凭证，您就能连接。
答案1
有点旧了，但仍然有一些很好的信息。MSDN 章节“保护您的数据库服务器”。 http://msdn.microsoft.com/en-us/library/Aa302434
您还可以购买软件防火墙，例如 Zone Alarm 或 Outpost。
答案2
一个便宜的技巧是将监听端口从默认的 1433 移开。客户端可以使用显式端口语法进行连接，例如tcp:74.125.19.104,12345如果端口是 12345。这消除了绝大多数扫描 1433 以查找 sa,blank 漏洞的机器人。当然，这并不能解决公司所涉及的其他责任：强密码策略、回收密码、监控日志以查找可疑活动等。
他们应该考虑的另一件事是实施直接访问。DA 消除了大多数（如果不是全部）旧 VPN 解决方案的缺点，担心 VPN 帮助台成本的公司应该认真考虑 DA。
最后，还有一个显而易见的问题为什么他们需要通过互联网访问 TDS 吗？了解了需求后，我们可能会推荐其他危险性较低的解决方案。
答案3
配置 IPSEC 策略，允许根据 IP 地址/范围白名单连接到 SQL Server 端口，如前所述。这意味着操作系统将承担忽略流量的负担（这就是为什么网络设备显然更受欢迎的原因）。确保防火墙已启动以保护所有操作系统端口，尤其是与 RPC、SMB 等相关的端口。确保 IPSEC 策略仅允许连接到 SQL Server 端口。您不需要为 SQL Browser 服务 (udp/1434) 打开端口。
如果可以，请将 SQL Server 正在监听的端口（可能是 tcp/1433）更改为其他端口（确保 IPSEC 策略可以适应）。如果它不在众所周知的端口上，尤其是如果它是更高的端口，这将停止针对系统的大多数扫描。用户只需知道通过服务器，港口而不仅仅是服务器。
答案4
我强烈考虑与那些坚持将其数据库放在网络上而没有任何形式的 IPSec、防火墙或私人连接的公司断绝一切联系。我希望他们至少使用某种形式的加密。
这是一个即将发生的重大责任；可能是诉讼或刑事疏忽（取决于所涉及的数据）。