可以做什么来保护暴露的SQL 2005服务器没有额外的硬件？

有点老，但还是有一些很好的信息。 关于保护数据库服务器的MSDN一章。 http://msdn.microsoft.com/en-us/library/Aa302434

您也可以购买软件防火墙，如Zone Alarm或Outpost。

一个便宜的窍门是将监听端口从默认的1433移开。客户端可以使用显式端口语法连接，如tcp:74.125.19.104,12345如果端口是12345）。这消除了绝大多数机器人扫描1433的空白，空白漏洞。 这当然不能解决公司从其他的责任：强密码政策，回收密码，监视可疑活动日志等。

他们应该考虑的另一件事是实现DirectAccess 。 DA消除了大多数（如果不是所有的）旧的VPN解决scheme的弊端，并且受到VPN的服务台成本的困扰的公司应该认真考虑DA。

最后，有一个明显的问题， 为什么他们需要从互联网上访问TDS？ 知道什么是要求，我们可能会推荐替代性的，危险性较低的解决scheme。

如前所述，configuration允许基于IP地址/范围的白名单连接到SQL Server端口的IPSEC策略。 这意味着操作系统将承担忽略stream量的负担（这就是为什么networking设备显然是首选）。 确保防火墙能够保护所有的操作系​​统端口，尤其是那些与RPC，SMB等相关的端口。确保IPSEC策略只允许连接到SQL Server端口。 您不需要打开SQL浏览器服务（udp / 1434）的端口。

如果可以，请改变SQ​​L Server正在监听的端口（可能是tcp / 1433）到其他端口（确保IPSEC策略适用）。 如果它不在一个知名的港口，特别是如果它是一个更高的港口，这将停止对系统的大部分扫描。 用户只需要知道通过服务器 ， 端口连接而不是仅仅服务器连接 。

（公众知识产权属于谷歌，所以编辑可能是没有必要的）

保护任何分区的SQL服务器可以做的最好的事情是将允许连接的主机列入白名单，并确保在该机器上运行尽可能less的其他服务。

另一个好的做法是严格限制从networking端访问。 如果Web应用程序只允许运行几十个存储过程，那么几乎没有来自被利用网站的攻击媒介。 另一方面，如果它可以运行任意查询，那么你将会遇到问题。

切勿在数据库机器上运行Web服务器：这是一个巨大的，不必要的攻击媒介，应尽可能避免。 Web服务器和Web服务经常被利用。 如果你的数据库被连接到同一台机器上，那么它更有可能被closures。

实现所有这些（不添加任何新硬件）的最简单方法是启用IPSEC，并将来自Web服务器的请求发送到数据库服务器。 这是一个基本的IPSEC教程。

如果你必须让它们在同一台服务器上，你只需要允许本地连接就可以获得一点安全性，但是如果你的网站被攻击了，这没有什么帮助。

要禁用远程连接，请转到“服务器” – >“属性” – >“连接”，然后取消选中“允许远程连接到此服务器”。

我强烈地考虑削减一个坚持把自己的数据库放在网上的公司，而不用任何forms的IPSec，防火墙或私人连接。 我希望他们至less使用某种forms的encryption。

这是一个等待发生的重大责任。 可能是诉讼或者犯罪过失（取决于所涉及的数据）。