BT

Service Firewall Pattern

Posted by Arnon Rotem-Gal-Oz on Jun 18, 2007 |
In this sample pattern from Arnon Rotem-Gal-Oz' in-progress book SOA Patterns, Arnon explains how to use a Service Firewall to intercept incoming and outgoing messages and inspect them in a dedicated software component or hardware.

I mentioned in the Secured Message and Secured Infrastructure patterns that messages travel in "no-man's land". You can use the Secured Message or the Secured Infrastructure patterns to protect the messages while they travel that space - but what do we do if the sender is malicious? When an attacker send us a malicious messages (e.g. with a virus as a SOAP attachment) it wouldn't really help us that we managed to ensure that this malicious message gets to us intact and without anyone else seeing it.

The Problem

To illustrate the type of attacks a malicious sender can cause let's look at one of them a little closer. Figure 1 below an XML Denial of Service (XDoS) attack. In this type of attack a malicious sender attaches a lot of digital signatures to a message. Parsers that aren't ready for this type of attack examine each of these signatures causing the service to slow down under the load.


Figure 1: Illustration of a XDoS attack. A malicious sender prepares an XML that looks valid but is loaded with a lot of digital signatures. An unsuspecting parser will try to verify each of these signatures while hogging down CPU cycles which can result in unavailability of the service.

Attacks using incoming messages as demonstrated in Figure 4.4 are one type of threat we need to handle, another related type of threats or problems has to do with outgoing messages. Here we need to make sure that private or classified information does not leak outside of the service. In this type of scenarios we want to find a way to make sure they hold only information allowed in the contract flows out of the service.

How can you protect a service against detect malicious incoming messages and prevent information disclosure on outgoing messages?

One option for dealing with malicious senders is to apply the Secured Infrastructure pattern (mentioned earlier in this chapter) and require certificates for authorizing clients. This means that clients that do not have a certificate will not be allowed to contact the systems. One problem with this approach is that it is only good when the number of service consumers is controlled and not open for the general public (e.g. exposed on the internet). Another limitation of the certificate approach is that it doesn't handle attacks by insiders since they are authorized to access the system.

Another option is to incorporate the security logic that screens malicious content as part of the business logic. There are several problems with this approach the problem with this approach is that you get code duplication as there are many threats that are common to all services. Another problem is that you the business logic is tainted with the security logic which makes it harder to write and maintain.

The better option is to externalize the security to another component. Let's look at this option more closely.

The Solution

SOA messages are application level components - however. the notion of messages is not new or unique to SOA. We (the computer industry) already have a lot of experience with messages on a lower level of the OSI stack - the network level, specifically TCP packers and UDP datagrams. TCP and UDP have few similarities with SOA messages, the interesting ones, for the purpose of this pattern are the threats they face. Since the threats are similar maybe we can also use the same solutions we've found to work for TCP and use them for our SOA messages.

Implement the Service Firewall pattern and intercept incoming and outgoing messages and inspect them in a dedicated software component or hardware.


Figure 2 The Service Firewall Pattern. The Service Firewall sits between the outside world and the actual service (or Edge). The Service Firewall scans, validate and audit both incoming and outgoing messages. Once a message is identified as problematic it can either be filtered out or cleansed.

The Service Firewall pattern is an application of the Edge Component pattern. Figure 2 above illustrates how the Service Firewall operates. First it intercepts each incoming and outgoing message and inspects it. Once intercepted the Service firewall can scan the message for malicious content such as viruses or XDOS attacks as mentioned in the sample scenario. Additionally, the Service Firewall can validate messages by making sure they conform to the contract, verifying property types and sizes etc. When a message is identified as problematic the Service Firewall can audit and log the message and then decide whether to filter it out or cleanse the problematic content and let it through.

The Service Firewall acts as a first line of defense for the service. As illustrated in Figure 3 below, when a request arrives at the firewall it is scanned and verified, requests that were authorized are then routed to the real service (or another Edge Component).


Figure 3 When a request arrives at a Service Firewall (an XML firewall in this illustration) it is screened for validity, for instance they firewall can check that an XML matches the predefined XSD. Authorized requests get through and unauthorized requests are rejected.

The idea behind a Service firewall is simple, the implementation, however is a little more complicated since there is a lot of functionality that has to be implemented to get each of the roles (scan, validate, filter etc.). On top of that you need a way to make sure the Service Firewall gets all the messages to be able to work.

Technology Mapping

As mentioned in the patterns structure in Chapter 1, the technology mapping section takes a brief look at what does it mean to implement the pattern using existing technologies as well as mention instances where current technologies implement the pattern.

The simplest way to implement the Service Firewall pattern is to create a designated Edge Component where you would implement the inspection and validation logic. Once the firewall logic is done you deploy it on the DMZ. Deploy the real service behind a regular firewall and you are all set. The Edge component will block unwanted requests that play "nice" and the regular firewall will block the other attacks.

Implementing the Service Firewall pattern without using a regular firewall is a little more problematic as an attacker can just call the endpoints that is used by the actual service and bypass the Service Firewall altogether. In these situations you can rely on the interception capabilities of the technology you use. For instance, Figure 4 below shows the relevant extension points offered by Windows Communications Foundation for intercepting incoming messages.


Figure 4 WCF supports a few dozens of extension points to control the way a message is handled when in enters or leave the service. You can use four of these extension points (depicted above) to implement the different roles defined in the Service Firewall pattern.

As illustrated in Figure 4 there are four relevant extension point (out of the few dozens of extension points supported by WCF) where you use classes to perform the various roles of the Service Firewall pattern. You can have classes that and verify addresses, verify contract, inspect the messages and inspect parameters - both for incoming and outgoing messages. You can then use code like in Code listing 1 to add these classes as interceptors when a message passes in or out of the service.

Code Listing 1 a WCF code snippet to add interceptors to incoming and outgoing messages handled by WCF. You can use these interceptors to implement the Service Firewall pattern and validate, scan etc. any message that passes in or out.
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());
          }
      }
}

Another implementation option for the Service Firewall pattern is using hardware or embedded appliances. For instance, there are several companies like Layer7, IBM, Vordel and a few others that produce XML firewall appliances. The advantage of using XML appliances is that you can deploy them along with your other firewalls in the DMZ and have them serve as the first line of defense. Another advantage is that these are platforms optimized for XML handling so the performance impact of the appliances is lower vs. self coded solution. One disadvantage of using hardware XML firewalls is setup costs (tens of thousands per unit) another disadvantage is increased maintenance complexity which comes both from managing an additional hardware type and more so from the double management of your SOA contract (both in the service and in the appliance).

Whether you use an appliance or implement the Service Firewall pattern in code it can really boost the security of your services by helping prevent threats like denial of service attacks or even just save some validation efforts for the service itself.

Quality Attributes

As noted in the beginning of this chapter, the quality attributes section for security patterns discusses the threats that the pattern helps prevent.

The Service Firewall pattern is a very versatile pattern and it can be made to handle many types of threats. The table below shows the threat categories and the actions that an implementation of the Service Firewall pattern can take to protect against threats in this category.

Threat Threat Actions
Tampering
  • Verifying signatures and to make sure no one changed the content of request or a reaction
  • Validating that messages are not mal-formed
Information Disclosure
  • Scanning outgoing messages for sensitive content
  • Restricting reply addresses to a closed groups
Denial of Service
  • Preventing XDoS attacks by examining XMLs before validating each signature
  • Blocking known attackers
  • Restricting Requestors addresses to a closed group
  • Scanning attachments for viruses
Elevation of Privilege
  • Examining an incoming message for injection attacks
  • Examining an incoming message for buffer overruns by validating contract and sizes of elements

Table 1 Threat categories and actions. List of the action that implementations of the Service Firewall can take and the threats these actions mitigate.

In Addition to the specifics of the threats that the Service Firewall pattern helps mitigate, we can also look at it from the wider scope of quality attributes. Like most of the patterns in chapter 4, the Service Firewall pattern is a security pattern. It is interesting to note that unlike most other security patterns it is relatively easy to add it on towards the end of a project. You should note however that it is not a completely free ride and for instance you still have to measure its impact on system performance, it can add an overhead in regards to contract maintenance etc.

As we get nearer to the end of this chapter it is about time to start talking about manageability patterns. The next pattern - the Identity Provider pattern, helps make this transition as it has both security and manageability aspects.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Is this not the same as the "Perimeter Service Router Pattern"? by Anil John

Perimeter Service Router Pattern

If it is, it may be good to synchronize the pattern name. If not, would appreciate how this is different. Just as an FYI, the implementation of the Service Router Pattern for us was an XML Security Gateway as well, for exactly the reasons that you noted.

Re: Is this not the same as the by Arnon Rotem-Gal-Oz

Hello Anil,
I wasn't aware of your pattern until now. I'll have to read more thoroughly before I can tell you exactly what's different. It dies seem that both patterns have the same main idea. I'll add a "also known as" and attribute your effort in my book

As a side note, I would say that it shouldn't be too surprising that similar patterns emerge since you discover patterns as you grapple with real-life problems and since some of these problems are common enough, the solutions to them will probably also be similar.

Arnon

Re: Is this not the same as the by Arnon Rotem-Gal-Oz

OK - so what's the difference,
Well, as I said in the initial reply the main idea of introducing an mediator is similar.
However there are a few differences
1. The Service Firewall pattern is a little more structured as it builds on the Edge Component pattern which is a more general, not security sepecific service mediator pattern
2. I think I take a more architectural point of view vs. your pattern which talks about a deployment implementation. for instance. As you can see in the technology mapping section, the Service Firewall pattern can be implemented to guard services inside a private network and not just moving from a DMZ to a private network. The pattern talks about the principle and it isn't even tied to web-services.

3. My problem statement is more focused on security - but I guess that just a minor semantic issue

As I said in the previous post- since the main idea is similar I'll add an attribution to your pattern in the book

Arnon

Re: Is this not the same as the by Anil John

Anrnon,

>I'll add an attribution to your pattern in the book

I cannot take credit for that body of work :-)

Those web service security patterns that I pointed to, the Perimeter Service Router pattern just being one, were developed by Microsoft's patterns and practices group. I happened to be one of the external technical reviewers of that work and hopefully made some minor contributions to shape it so the attribution should point to the MS PAG folks.

I also happened to have used them in guiding the implementation of web services security in my work environment, so I am familiar with them from the implementation perspective.

Regards,

- Anil

Re: Is this not the same as the by Anil John

Arrgh! Arnon, my apologies for misspelling your name in the message above! - Anil

OT: Which application used to draw diagrams? by legolas wood

Hi
Maybe it is very OT to ask this question, but can some one tell me which application used to draw diagrams for this article?

thanks

Re: OT: Which application used to draw diagrams? by Arnon Rotem-Gal-Oz

In the book I use both Sparx Enterprise Architect and Microsoft's Powerpoint 2007. The diagrams here are all Powerpoint 2007 :)
Arnon

Re: OT: Which application used to draw diagrams? by legolas wood

Thank you for letting me know, Hope i can use them to demonstrate some concepts in my university documents and work reports.
Thanks

What are your thoughts on using an appliance as Service Firewall/Gateway? by Rag Ramanathan

I am involved in building an appliance that provides all the functionality of Service Firewall as listed here, and more. Some customers are deploying this as "Universal Service Gateway" The concept is very similar to having (Web) Firewall, and routers.

I was curious on your thoughts and experience around this.

Thank you.
Rag

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

9 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT