说句实话，你公司中安装的大多数的SQL Server都可归结为以下两种中的一种。第一种类型就是安装了SQL Server的开发人员用的机器(即，多种安装类型中的一种――桌面版本，标准版本，企业版本或者明显的开发版)。第二种类型就是微软的SQL Server桌面引擎(MSDE)的供各种应用程序使用的各种安装，其中包括使用MSDE作为信息存储的备份、网络管理或者其他的工具包。这两种类型的变化之中有一个共同点，就是大多数都完全不需要外在的连接，除了通过主机上驻留的应用程序。
现在，做个简单测试:有多少不需要接受来自网络中其他机器的连接的安装总是在监听那些连接?答对了――几乎全部都是。在最近的一项渗透测试活动中，我发现公司中大约有90%的SQL Server安装只被安装在同一台机器上的软件使用，从来没有接受过网络中其他机器的连接。此外，在这90%里面，除了2台机器之外都同时有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_MACHINESOFTWAREMicrosoftMSSQLServerMSSQLServerSuperSocketNetLibProtocolList
只是编辑那里的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安装的默认选择可以很大限度的坚固你的基础设施。
