说句实话你公司中安装的大多数的SQL Server都可归结为以下两种中的一种第一种类型就是安装了SQL Server的开发人员用的机器(即多种安装类型中的一种——桌面版本标准版本企业版本或者明显的开发版)第二种类型就是微软的SQL Server桌面引擎(MSDE)的供各种应用程序使用的各种安装其中包括使用MSDE作为信息存储的备份网络管理或者其他的工具包这两种类型的变化之中有一个共同点就是大多数都完全不需要外在的连接除了通过主机上驻留的应用程序
现在做个简单测试:有多少不需要接受来自网络中其他机器的连接的安装总是在监听那些连接?答对了——几乎全部都是在最近的一项渗透测试活动中我发现公司中大约有%的SQL Server安装只被安装在同一台机器上的软件使用从来没有接受过网络中其他机器的连接此外在这%里面除了台机器之外都同时有TCP/IP和netlibs (命名管道网络库)在启用和监听
这里我们有一个非常好的有关过分表面领域的例子就是说当机器暴露在这个层次上的时候没有调用任何的相关措施那么遇到偶然的发现暴力攻击以及可能的远程缓沖溢出攻击就是明显了最近对于MSDE Release A 微软开始在缺省情况下安装MSDE的时候不再启用任何的netlibs 以便于帮助您最小化暴露的表面区域然而许多MSDE较老的安装仍旧如此并且持续监听
过分的netlib 支持问题的解决方案是简单的任何不需要外界连接的SQL Server或者MSDE实例都应该禁用所有的netlibs 除非是共享内存netlibs 这个在缺省情况是开启的共享内存netlib只在与使用它们的应用程序在同一台机器上并且不允许来自外界主机的连接的SQL Server环境中存在
如果你使用的是SQL Server修正是非常简单的只要为你想要保护的每个SQL Server实例中载入Server Network Utility并且禁用所有的netlibs (在启用协议中)即可然后停止并重新开始SQL Server实例以便于修改生效
如果你使用的是MSDE你就得费一点事当然如果在同一台机器上存在SQL Server安装并且Server Network Utility也是安装的你就可以在下拉列表中看到MSDE实例然而你可以用与前面描述的针对SQL Server实例完全一样的方式删除netlibs
如果你没有访问主机上的Server Nerwork Utility那么你需要编辑注册表键值来直接控制对netlib 的支持这个键位于
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServerSuperSocket\NetLibProtocolList
只是编辑那里的REG_MULTI_SZ 删除任何数值数据(TCP/IP 和命名管道在默认情况下是tcp np)再一次你需要停止并重新开始MSDE实例以便于修改生效
将所有的netlibs 都禁用了之后只有共享内存netlib还能够与SQL Server进行通信这对于理解netlib 和你的应用程序非常重要:为了连接到本地SQL Server/MSDE实例上你不能再使用本地机器的名字(或者IP地址)作为连接字符串中的服务器的名字你需要用点或者单词(local)来置换服务器名字或者IP地址一些应用程序的行为彼此不同那么需要确保彻底地进行测试使用那些字符串中的某一个作为服务器的名字可以告诉本地SQL Server客户端网络子系统使用共享内存netlib 来替代基于网络的库
现在你知道了如何移动netlib 同时还仍然连接到SQL Server实例上你应该告诉你的开发人员这是如何完成的因为他们很有可能安装本地SQL Server/MSDE环境的次数最多让环境不再监听可以保护他们在远程位置热点或者其他公共环境中的时候不受到攻击而在这些环境中他们很有可能会受到攻击最小化表面区域是安全难题中的一个关键部分让这个方法成为所有的新的SQL Server/MSDE安装的默认选择可以很大限度的坚固你的基础设施