去年，当我们在实验室中测试Blue Coat公司的安全网关设备时，该公司的产品经理列出了一张给人深刻印象的安全特性清单，当时我想，这家公司在接入控制安全方面真是下功夫了。然而，当我们给设备接上电源、进入这款设备的管理界面时，这款设备提供的Web和Telnet管理方式使我改变了想法，这两种方式都没有提供安全性认证或加密，而且都是缺省启动，攻击者轻易就可以截获口令字，修改设备的配置，甚至关闭设备。从这个角度看，这台“安全网关”其他安全特性都是虚设的了。一台接收以明文方式发送口令的系统能有多安全呢？令人不安的是，又有多少网管员能够记住关闭这些缺省设置呢？
Blue Coat公司现在已经不再缺省支持这些访问方式了。但是缺省设置存在漏洞这一现象还普遍存在，甚至一些著名网络设备厂商和安全厂商提供的设备也存在这方面的漏洞。在过去一年多时间的测试中，我经常遇到存在缺省设置漏洞的设备。这类例子有很多，但是为了方便起见，我们只讨论其中的一些有代表性的例子。
SSH：安全外壳SSH提供命令行界面的安全访问。尽管SSH比Telnet更具安全性，但至少从1998年起，利用SSHv1漏洞进行攻击的例子就比比皆是。令人难以置信的是，SSHv1是许多路由器可供用户使用的惟一选择。SSHv2修补了SSHv1的安全漏洞。一些交换机支持SSHv2，但是这些交换机的缺省设置却是支持SSHv1接入。此外，还有一些安全产品只支持SSHv1。
SNMP：同SSH一样，目前存在多种版本的SNMP。只有最新版本，即SNMPv3能够提供强大的认证功能和加密功能，可惜只有少数网络设备支持SNMPv3。尽管一些网络设备提供商在以太网交换机产品线中添加了对SNMPv3的支持，但是缺省设置却不支持这种安全管理方式。
HTTP：几乎所有的网络设备都可以通过Web界面进行管理。有时，Web方式是惟一的管理方式。Web管理提供了便利，但是它的便利性和安全性常常是相互矛盾的。Web服务器可以要求口令字，但没有加密。Web服务器有着悠久的缓冲区溢出和其他安全漏洞的安全史。对于用户来说，最好不要将HTTP用于管理，更不要缺省启动它。对于厂商来说，如果打算提供用于Web管理方式，最好不要使用不安全的端口和协议来提供它。
SSL/TLS：由于设备使用证书进行认证，因此安全套接层(SSL)和传输层安全(TLS)在缺省设置上提供了较好的安全性。但是SSL/TLS安全性可能会误导用户。有多少在线购买者点击过浏览器上的挂锁图标来检查证书？又有多少用户十分了解证书路径，知道证书是否有效？在最近一次IDS测试中，来自Barbedwired Technologies和Lancope的产品采用了“自我签署的”证书，也就是说这两家公司自己为自己的产品的真实性提供担保，实际上这种作法是不可取的，只有可信赖的第三方才能为“安全设备”提供担保，可信赖的第三方应当是著名的优秀证书机构，而不是设备本身。
当我与厂商讨论以上问题时，我得到的回答是：其他安全机制可以消除设备本身的安全漏洞。对此我表示异议。例如，防火墙可以防止攻击者利用内部系统上的弱点，但是防火墙并不是包治一切的灵丹妙药，更不能阻挡内部的攻击，需要引起注意的是，添加第二台安全设备对于解决脆弱的安全缺省设置没有一点用处。
最后，我们要向网络产品制造商提出这样一个问题：既然花费了数百万美元为设备开发安全特性，但却在设备的缺省配置中留下漏洞，这样做又有什么意义呢？
