思科首次攻破新一代防火墙，给人留下深刻印象

以前的 12 第二页

在我们的例子中，我们使用了非常隐秘的“等几分钟”超级黑客技术来避开Skype过滤器。虽然ASA CX最初屏蔽了Skype，但只要我们再等几分钟，电话就会接通。在其他情况下，如H.323会议、Microsoft Exchange和Sophos反病毒更新，ASA CX根本不能工作，即使这些应用程序是它的全部功能。

我们一年前的测试都是基于笔记本电脑客户端，包括Mac和Windows。然而，在ASA CX中，我们添加了一个新的改变，即尝试使用手持设备运行两种常见的应用程序:Facebook和LinkedIn。当我们使用本地应用程序连接到这些服务时，ASA CX没有完成它的工作。

我们确实看到ASA CX团队从他们同行的错误中吸取了教训。例如，在去年的测试中，我们仅通过使用基本的HTML界面就能够绕过所有其他下一代防火墙试图阻止谷歌Mail。这一伎俩在ASA CX上并不奏效，无论我们尝试什么，它都顽固地阻止我们。

ASA CX也完全支持IPv6，如果它阻止了IPv4上的应用，同样的阻止也适用于IPv6，无论我们使用的是笔记本电脑还是iPad。

我们还测试了ASA CX使用基于用户和组的标识作为应用程序控制的一部分的能力。任何尝试过部署基于身份的网络或NAC的人都知道，最难的部分之一是从用户或设备收集身份。

ASA CX有两种可用的机制:一种是专属门户方法，它适用于某些客户用户环境，人们没有太多机会抱怨。另一种称为“被动认证”，它依赖于在网络中的Windows域控制器上安装思科代理。当Windows用户登录到他们的域连接的PC上时，这将在Windows事件日志中生成一个附带的日志条目，该日志条目碰巧具有PC的明显IP地址以及用于登录的用户名。我们很容易地在我们实验室的域控制器上安装了这个代理，并且能够将ASA CX身份验证控件链接到用户身份。黑色。

碰巧我们的实验室有一些内部NAT正在进行，以简化路由，当我们为这样的测试快速构建网络时，这就混淆了ASA CX，因为用户到ip的映射不正确。同样的问题也会发生在任何带有NAT的PC和域控制器之间的网络中。当然，还存在可伸缩性问题——如果一个域就足够了，那就太好了，但有些企业在他们的广域网上有几十个甚至数百个域。当然，这只适用于带有域的Windows个人电脑——Windows个人电脑仍然是企业网络的主导力量，但不是现在提供计算的唯一方式。更别提当一个人从局域网断开时并没有真正的追踪。

这一切都不是思科的错——任何尝试嗅探Windows登录信息或从日志中获取信息的供应商都将遇到同样的问题。还有其他的技巧和技术，不同的NAC供应商已经创造了来解决这个基本问题，但唯一100%真正的解决方案是在连接PC上有一个客户端工具，它收集身份验证信息并与强制设备积极交互。

这给我们带来了ASA CX的一个严重问题:所有思科针对NAC的产品，以及所有思科针对安全移动的产品，都不能与ASA CX交互。当涉及到远程访问VPN时，这个问题尤其可笑——即使远程访问隧道连接到ASA CX，它也不会将用户身份信息传递给CX。

即使在像ASA CX这样的v1.0产品中，也未能实现这一明显的链接，这是糟糕的产品管理。

SSL解密

如果下一代防火墙的主要优点之一是应用程序和协议的识别和控制，那么SSL解密是一个基本要求。在ASA CX中，SSL解密由一组单独的策略规则处理，本质上定义了哪些流量被解密，哪些流量没有被解密。从管理的角度来看，对ASA CX的SSL解密部分的配置和控制是非常出色的。我们首先在ASA CX中安装了我们自己的认证机构，这是我们实验室所有系统都信任的，这是一个简单的事情。然后，我们对所有的流量启用解密，然后让它打开。

乍一看，ASA CX工作得很好，在非标准端口上捕获SSL，甚至将应用程序标识扩展到加密的会话中。在大多数情况下，ASA CX SSL解密很好，在我们有限的实验室测试中没有产生任何性能问题。但这并不完美。

我们遇到的最大问题是应用程序对加密流量的识别。尽管ASA CX在解密和重新加密SSL通信方面做得很好，但应用程序标识引擎对许多协议都不能正常工作。它并非完全失败——大多数人关心的最重要的协议HTTP被成功地解包和识别。但是，想要识别和控制可能被策略阻止的非http其他协议的安全管理人员无法看到加密的会话。例如，ASA CX非常擅长识别标准和非标准端口上的未加密IMAP。但是，如果我们在标准IMAP-over-SSL端口上打开到IMAP服务器的连接，ASA CX不会将流量识别为IMAP，而只是SSL。使用标准端口的SMTP也遇到了同样的问题。一旦通信被加密，ASA CX就没有识别这些协议。对于HTTP流量，没有问题——ASA CX将加密的HTTP解包，并在加密会话中识别出应用程序，如谷歌Mail和Facebook。

在早期，我们还遇到了一些ASA CX不喜欢的SSL协商的小问题，因此被不恰当地阻止了。这首先出现在我们实验室的iPhone和iPad上，它们开始表现不佳，无法与iCloud母船通信。这个问题很容易在ASA CX日志中看到，但是没有简单的解决方案，只能在iCloud上免除某些IP地址的SSL解密。问题解决了，但是维护和文档的麻烦开始了。我们不知道这对其他对照组有什么影响。例如，我们试图阻止应用程序在iTunes上安装，但没有成功。这是因为SSL没有被正确解密，还是只是iTunes屏蔽中的一个漏洞?

另一个减慢我们速度的问题与思科预加载的受信任的根认证机构列表有关。只有当服务器提供一个由ASA CX信任的证书时，ASA CX才会进行中间人SSL解密。思科不会发布它信任的ca列表，让您自己猜测和调试。我们的大多数测试都很好，但我们确实遇到了一些完全合法的服务器，直到我们追踪到它们的CA和中间CA证书，ASA CX才会信任它们。缺少ca列表使调试变得困难，而且没有合法的理由将此列表保密——所有具有类似信任设置的其他产品，如Windows和Mac OS X，都很乐意让您查看和编辑受信任ca列表。

ASA CX在我们的无效证书测试中表现不佳，可能会对终端用户隐藏已撤销的或不正确的证书。当服务器将证书作为SSL握手的一部分传递给ASA CX时，ASA不会对该证书进行全面检查。然后，它用自己创建的证书替换证书——任何撤销信息都会丢失。简单地说，ASA CX没有正确地实现数字证书和X.509世界中的主要机制，导致了一个很小但非常重要的漏洞，特别是在鱼叉式钓鱼攻击世界中。

下一代的可见性和管理

我们发现带有Cisco Prime Security Manager (PRSM)的ASA CX提供了出色的应用类型和流量统计的可视性，具有强大的深入挖掘功能和设计良好的界面。然而，ASA的整体管理是快速的，我们发现很难评估管理界面的其余部分。

对于那些不想使用命令行接口的人来说，ASA的标准管理接口是ASDM (Adaptive Security Device Manager)，这是一个基于java的GUI，用于处理ASA配置和管理的大多数方面。ASDM已经发展成为一个稳定而强大的产品。ASDM并不是管理防火墙最优雅的界面，它与它生成的命令行配置紧密相连，但它是可靠的，并且可以相当快地完成工作。

Prime是思科新的管理界面，旨在跨安全、交换和路由产品线工作。在管理防火墙时，思科称之为PRSM，这是一种基于web的GUI，可以直接在ASA上运行，也可以在单独的管理服务器上运行。尽管支持机顶盒操作，但我们认为任何拥有多个ASA CX的经理都应该选择一个独立的管理设备，尽管这需要额外的成本(5个设备的标价为3,000美元)。

如果没有独立的管理服务器，PRSM会在处理包的同一个CPU上运行主机报告、日志存储和管理，从而给防火墙带来风险。现场安装的PRSM可以快速演示PRSM的功能，但我们更喜欢将日志发送到单独的服务器，这样任何分析和调试都不会降低生产设备的速度。

ASA CX仅由PRSM管理，这在下一代防火墙规则和ASA管理的其余部分之间造成了分离。无论这个接口多么奇怪，因为它而降低ASA的等级有点不公平——思科告诉我们，防火墙配置迁移到PRSM(从ASDM)是他们2013年ASA线的首要任务。

所以，是的，今天，网络管理员需要通过一些变通来管理防火墙，但我们看到的是一个转型中的产品。尽管PRSM的可见性能力非常出色，但是网络管理人员会发现，与ASDM相比，PRSM的配置能力是笨拙和令人失望的。防火墙规则分散在没有关键信息的网页上，使得政策分析和编辑变得困难;策略对象的名称尽可能没有帮助，接口中到处都是冗余和不一致的术语。我们希望这个糟糕的配置界面作为ASDM功能迁移到PRSM的一部分被清理干净。

我们如何测试

我们使用了我们的方法2012下一代防火墙测试这样读者就可以对思科ASA CX与Barracuda、Check Point、Fortinet、Palo Alto Networks和SonicWALL的竞争进行评估。

因为思科ASA CX不支持反恶意软件和传统的IPS，我们没有重复这些测试。

我们还稍微改变了应用程序识别测试，以包括更广泛的客户端，包括智能手机和平板设备。我们强调了这些客户的表现，以便读者能够更公平地比较ASA CX与竞争产品的覆盖面和准确性。