Re: [fw-wiz] Provocative Query: Are firewalls obsolete in a world involving enterprise WebService SOA

Thanks Marcus,

I agree my definition of a firewall was badly phrased. When using the
term firewall before, people usually said "oh you mean packet filtering"
and so forth. I was just trying to capture that firewalls operate at
various layers and there are various kinds of firewalls (proxies and so

Maybe I should rephrase this post to the following for others reading
the post:

My argument is that it appears to me that (secure) Enterprise Web
Service applications, particularly those involving access control, are
typically focused at the application-domain only, rather than taking a
more holistic approach to also include the underlying infrastructure
(for example, firewalls). As a result, infrastructure configurations may
unintentionally hinder and prohibit the normal operation of the Web Service.

Thus, the ideal firewall configuration is one that is aligned with the
application supported by the system, that is, it permits valid
application traffic, and, preferably, no more and no less.

What I presume is that Web Service developers assume the underlying
infrastructure is magically available. Also there seems to be a tendency
to tunnel (for example SOAP) over http or https.

From this point of view, Semantic Web developers may form the opinion
that firewalls are redundant as they typically have ports 80 and 443
accessible (and forward traffic to specialized user-space programs for
further packet processing). Maybe they are correct! Have you any comments?

In my opinion, deploying a network level firewall (such as Linux
Netfilter) provisioned for Enterprise Web Services is not simply about
opening port 80 on the server for all traffic; one may wish to deny
certain nodes (IP addresses, etc.), only accept HTTP traffic from some
nodes, require other nodes to use HTTPS and also deal with HTTP traffic
that is tunneled through proxies available on other ports.

While low level infrastructure such as firewalls may not solve all
security issues ( as good as an application based XML firewall would) in
regard to Web Service applications, I believe they have a role to play
in applying the belt-and-braces approach to security best practices.

What I am really looking for is some concrete documents, publications,
administrator experience that helps support my gut feelings of the role
of network firewalls within an enterprise SOA environment.

What is actual practice of enabling Web Services? whats kinds of
requests are made by application developers to administrators? Surely
its not just please open port 80 and 443 to all.
linux iptables example: iptables -A FORWARD -p tcp --dport http,https -j

Presumably a network administrator may need to restrict both incoming
and outgoing web service traffic, for example to a specific web service
on a server to/from selected business partners IP subnets:
iptables -A FORWARD -i eth0 -s -d -p tcp --dport http -j ACCEPT
iptables -A FORWARD -o eth1 -s -d -p tcp --sport
http -j ACCEPT

While the Web service application maybe able to handle DoS attacks,
presumably a network administrator can help at the lower layers and thus
help in providing a holistic security approach:
iptables -A FORWARD -i eth0 -d tcp -dport http --syn -m
limit --limit 5/s -j ACCEPT

Are these real scenarios in your opinion regarding network based
stateful firewalls that an overall enterprise security policy may
require implemented in helping to maintain a holistic security approach?

Marcus points out this is a classic "Incoming traffic" problem. In
practice is there a concern about outgoing practice. Presumably yes,
thus there is a need for additional firewall rules other than simple
generic http and https access.

Again, scenarios are welcome to justify firewalls role (in particular
network-level firewalls) in enterprise SOA other than simply permitting

I am trying to counter the argument I got before about how trivial it is
to configure a firewall for enterprise web services due to the fact that
http and https are generally open and also the fact that others say that
firewalls are indeed obsolete from this point of view. (They are to an

kind regards,

some inline comments below.

Marcus J. Ranum wrote:
william fitzgerald wrote:
Are firewalls obsolete in a world involving enterprise Webservice SOA?

Short answer: No

Longer answer: That's like asking if brains are obsolete in a world where
everyone is busy blowing theirs out. It's kind of one of those "does not
compute" kind of questions. Firewalls will continue to be useful to the
increasingly small population of people who actually understand anything
about security.

More importantly, your question is hard to answer because you choose to
attempt (unsuccessfully because I am not going to let you get away with
it) to redefine established terminology. For example:

I use the term firewall loosely to mean network access control. That is,
its a mechanism to prevent unwanted packets.

Considering that firewalls were initially and foremost layer-7 devices, until
they devolved to being packet-centric in the mid 1990s, you're using the
term wrong.
Interesting point about them first been layer 7 devices.

A firewall is a system or systems that sit between two networks
at different levels of trust and enforces a security policy on communications
between them. If you actually use the definition of "firewall" that many of us
have been using since the late 1980s, such a system will never be obsolete
as long as there are untrustworthy systems.

The current information I have found (web service orientated!) tends to
say firewalls are obsolete when talking about enterprise SOA given that
once port 80 and 443 is open on the firewall the SOS services are
exposed and hence protection happens at the application layer.

What you have done is rediscovered the "incoming traffic problem" -
which is a primary property of firewalls that has been well-understood
since the early 1990s. You're correct that many firewalls (especially
the packet-oriented ones or the so-called 'stateful' ones) don't do
anything useful at layer-7, and serve primarily to force traffic to an
application service which needs to be tough enough to withstand
direct attack specific to that service. And, yes, with things like
"everything tunnelled over web services" remote procedure calls,
the complete set of protocol options at layer-7 is too large to be
controlled, enumerated, or understood - which means that effectively
you are doomed to intermittent epic failures.

Back in the old days, we had similar situations and they amounted
to "block everything except incoming telnet" - well, of course you
can do anything over telnet, just like you can over these newfangled
web frobozzes.

The XML firewalls and whatnot that people are scratching their
heads about are an attempt to regain control over the command
set of options being allowed back and forth through the firewall.
At this point, because the options-set is pretty much beyond
enumeration, you're doomed to epic fail because the only perceived
alternative is to enumerate dangerous options ('default permit' and
'enumerating badness' 'antivirus') rather than enumerating accepted options
('default deny' and 'enumerating goodness') - essentially ceding
the initiative to the bad guys.

So - to summarize - your question PREDICATES the intent
to go about the problem all wrong. That is, of course, an accurate
reflection of how the industry chooses to approach the problem,
and how "web services" are currently designed. So my response
to that is that it's an approach that is doomed to endless
small failures and lots and lots of maintenance. Because, by
choosing the path of duct tape and endless patching, it's
now inherent in the design. By the way, I use the word "design"
loosely; my observation is that there's very little that can
be called "design" about web/web2 services.

None of this should be taken (please) as an attack on you.
It's frustration because the ideas you're expressing are bad
ideas that many of us have fought a long rearguard action
against, knowing we'd fail from the beginning.


William M. Fitzgerald,
PhD Student,
Telecommunications Software & Systems Group,
ArcLabs Research and Innovation Centre,
Waterford Institute of Technology,
WIT West Campus,
Office Ph: +353 51 302937
Mobile Ph: +353 87 9527083

firewall-wizards mailing list

Relevant Pages

  • Re: [fw-wiz] Firewall rules order and performance
    ... Some firewalls no longer parse the configuration ... New connections / s is generally limited by ruleset size and complexity. ... As I recall, several years ago Lucent had an Oalgorithm for packet filtering on some of their high end routers that leveraged some tricky algebra, but it was limited to 256 not very complex rules. ... This is why every vendor specifies throughput based on large packets - ask them for 64-byte packet throughput and watch them squirm. ...
  • Re: Firewall for win95?
    ... :they must provide to secret service and law ... windows firewalls. ... packet against a particular firewall rule configured by the user. ... a 'back door'): when you are using a firewall ...
  • Re: Firewall for win95?
    ... :they must provide to secret service and law ... windows firewalls. ... packet against a particular firewall rule configured by the user. ... a 'back door'): when you are using a firewall ...
  • Re: NAT is not a mechanism for securing a network.. but.. HELP!
    ... a spoofed packet, which seems to come from inside, and sniff inside, if the ... a NAT router can provide good security ... > between NAT routers and firewalls. ... The rest of the features of the "Personal Firewalls" ...
  • Re: Updating a VB6 across the Internet
    ... Can you host the update download on an HTTP? ... I wrote an update function into the program using FTP calls. ... Many corporate firewalls do not allow users to use FTP. ...