服务防火墙模式

在本文的样例中——模式取自于 Arnon Rotem-Gal-Oz 正在写作中的新书《SOA 模式》，Arnon 解释了如何利用服务防火墙（Service Firewall）拦截进出消息，并使用专用软硬件对它们进行审查。

我曾在安全消息（Secured Message）和安全基础设施模式（Secured Infrastructure patterns）中提到：“消息穿行于无人区中”。当消息穿越这样的区域时，你可以使用安全消息或安全基础设施对其实施保护。但是，如果发送者本身就心存不良，我们该如何应对呢？当攻击者给我们发送一条恶意消息（如将病毒作为 SOAP 附件）时，设法确保收到的这条邪恶消息原封未动以及无人看它，并没有实质帮助。

问题

为了说明恶意发送者可能发起的攻击类型，让我们看看其中的一个例子。下图 1 是一个 XML 拒绝服务（XDoS）攻击。在这种类型攻击中，恶意发送者给消息附上大量的数字签名。对该类型攻击没有提防的那些分析器（Parser）会检查每个签名，导致服务处理速度降低到正常水平之下。

图 1：图解 XDoS 攻击。恶意发送者准备一条看起来有效，但实际携带了大量数字签名的 XML 消息。无戒心的分析器将尽力验证所有这些签名，这将占用大量 CPU 时钟周期，导致服务不可用。

图 4.4 示范了利用入口消息（incoming messages）的攻击，它只是我们需要应对的其中一种威胁；出口消息（outgoing messages），则是另一不得不处理的相关威胁或问题。此时，我们需要确保私人或机密信息没有泄露于服务之外。在这种情形下，我们需要找出一种方法确保接受者只能获得契约允许流出服务的信息。

你如何保护服务以防御恶意入口消息和阻止出口消息泄露信息？

一种对付恶意发送者的方法是使用安全基础设施模式（参见本章前文），同时要求证书给客户端授权。这意味着没有证书的客户端无权与系统联系。这种方式有一个问题，只有当服务消费者数量可控且服务不向公众开放（如暴露在互联网上）时才工作很好。另一个缺陷是证书无法应付内部攻击，因为他们已被授权访问系统。

另一招就是将屏蔽恶意内容的安全逻辑作为业务逻辑的一部分。这样会带来几个问题。因为，对于每个服务来说，都面临很多公共威胁，这样你将使代码重复。此外，由于业务逻辑被安全逻辑感染，这使得代码书写以及维护难度加大。

更好的选择是将安全抽出到另一个组件中。现在，让我们来仔细的看看这种方法。

解决方案

不管怎样，SOA 消息毕竟是应用级组件。对 SOA 来说，消息概念既不新颖，也不独特。对于低级别的 OSI 栈（网络层）消息，我们（计算机业界）已经拥有了很多经验，尤其是 TCP 打包器（packer）和 UDP 数据报文（datagram）。TCP 与 UDP 和 SOA 消息几乎没有相似点，有趣的是，就本模式的目的来说，是减轻它们共同面对的威胁。既然威胁类似，我们就可以将已创建的、用于 TCP 的相同解决方案用于 SOA 消息。

实现服务防火墙，对出入消息进行拦截，并用专用软硬件审查它们。

图 2 服务防火墙模式。服务防火墙位于外部世界和真实服务（或边沿）之间。服务防火墙扫描、验证和审计出入消息。一旦消息被认为有问题，它要么被过滤，要么被净化。

服务防火墙模式是边沿组件模式（Edge Component pattern）的应用。上图 2 显示了服务防火墙如何运作。首先它拦截所有进出消息并检查它们。消息一旦被拦截，服务防火墙就可以扫描它是否含有恶意内容，如病毒，或以前例中提到的 XDoS 攻击。另外，服务防火墙能够验证消息，如确保它们符合契约、验证属性类型和大小等。当消息被认为有问题时，服务防火墙可以审计和记录消息，然后决定是将其过滤，还是将有问题的内容净化后让其通过。

服务防火墙扮演服务的首道防线。如下图 3 所示，当请求到达防火墙时，它被扫描和验证。然后，被授权的请求被路由到真正的服务（或另一个边沿组件）。

图 3 当请求到达防火墙时（图示中的 XML 防火墙），它进行有效性筛选，如，防火墙可以检查 XML 是否匹配预定义的 XSD。被授权的请求允许通过，反之则被拒绝。

服务防火墙背后的思想很简单，但是实现则有些复杂，为了实现每个环节（扫描、验证、过滤等），不得不完成许多功能。在此之上，你需要一种方法确保服务防火墙对所有得到的消息都起作用。

技术映射

如第一章所提到的模式结构，技术映射一节将简单地看下如何使用现有技术实现模式，并说说当前技术实现模式的例子。

实现服务防火墙模式最简单的做法是创建一个特定边沿组件，你将在此实现审查和验证逻辑。一旦完成防火墙逻辑，你就可以将它部署到非军事化区（DMZ）。将真正的服务部署在正规（regular）防火墙之后，你就准备就绪了。边沿组件将阻塞伪装成"好"的有害请求，正规防火墙将阻塞其它攻击。

不使用正规防火墙实现服务防火墙会有一些问题，因为攻击者可以只调用被实际服务使用的那些端点（endpoint），从而完全绕开服务防火墙。对于这种情形，可以依靠你所使用技术的拦截能力。如，下图 4 显示了由 Windows 通信基础（WCF）提供的拦截入口消息的相关扩展点。

图 4 WCF 提供一些扩展点，用来控制在进入或离开服务时消息的处理方式。你可以使用它们中的 4 个（图中标出的）来实现服务防火墙模式中定义的不同角色。

如图 4 所示，有 4 种相关扩展点（来自 WCF 所支持的一些扩展点），你可以使用类来担任服务防火墙中的不同角色。你可以让类验证地址、验证契约、审查消息和审查参数–对出入消息都适用。在消息进入和离开服务时，你可以使用如代码清单 1 中的代码将这些类添加为拦截器。

代码清单 1：为 WCF 处理的进出消息增加拦截器的 WCF 代码片段。你可以使用这些拦截器实现服务防火墙模式，对任何进出的消息进行验证、扫描等。

public void SetInterceptors(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
{
   foreach (ChannelDispatcher ChannelDisp in serviceHostBase.ChannelDispatchers) 
       {
           foreach (EndpointDispatcher EndPointDisp in ChannelDisp.Endpoints) 
           {
               EndPointDisp.DispatchRuntime.MessageInspectors.Add(new MyMessageInspector());
               foreach (DispatchOperation op in EndPointDisp.DispatchRuntime.Operations)
                       op.ParameterInspectors.Add(new MyParameterInspector());
           }
       }
}

另一种实现服务防火墙的途径是使用硬件或嵌入式设备。有些公司（象 Layer7、IBM、Vordel 等）就生产 XML 防火墙设备。使用 XML 设备的优势在于，你可以将它们与你的其它防火墙部署在 DMZ，让它们作为首道防线。另一个优势则是，它们专为 XML 处理进行了优化，因此执行设备效率将高于自编码方案。使用硬件 XML 防火墙的一个缺点在于它的安装成本（每个单元大约好几万），另一个就是增加了维护的复杂度，这既来自于管理额外的硬件类型，更多的来自于管理 SOA 契约的加倍（包括服务中的和设备中的）。

不论你使用设备还是使用代码实现服务防火墙模式，它都将使你的服务安全性得到加强，因为它帮助阻止如拒绝攻击的威胁，或甚至仅节省服务本身验证相关的努力。

质量属性

正如本章开头所提的，安全模式的质量属性一节讨论模式所能阻止的威胁。

服务防火墙模式是一个非常通用的模式，它可用来应对多种类型的威胁。下表显示了威胁种类和服务防火墙模式对于该类威胁所采取的防范措施。

威胁 防范措施 篡改 - 验证签名，确保无人改变请求和响应的内容。

• 验证消息不是坏格式（mal-formed）。

信息泄露 - 扫描出口消息是否含有敏感内容。

• 将回复地址限制于一个封闭的组中。

拒绝攻击 - 在验证每个签名前，先检查 XML 以预防 XDoS 攻击。

• 阻塞攻击者。
• 限制请求者的地址于一个封闭的组中。
• 扫描附件是否有病毒。

权限升级 - 检查入口消息是否有注入攻击（injection attack）。

• 通过验证契约和元素大小，来检查入口消息是否缓冲区溢出（buffer overrun）。

表 1 威胁种类和防范措施。列出了服务防火墙实现可以采取的措施，以及这些措施可以减轻的威胁。

除了服务防火墙模式可以减轻的特定威胁，我们亦可从更广的范围看看质量属性。如第四章中的很多模式一样，服务防火墙模式是安全模式。值得注意的是，与其它大多数安全模式不同，在项目临近结束时添加它相对容易。你应该记住，这不是完全免费的，如你仍需测量对于系统效率的影响，因它将增加关于契约维护等的管理费用。

随着我们接近本章的结尾，接下来就该讨论维护模式了。下一个模式——认证提供者模式，将完成这个转换，因为它包含了安全和可维护性两方面的内容。

查看英文原文： Service Firewall Pattern