Re: Provocative Query: Are firewalls obsolete in a world involving enterprise WebService SOA

[william fitzgerald <wfitzgerald () tssg org>]

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 
forth).

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 
ACCEPT

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 193.1.1.0/0 -d  -p tcp --dport http -j ACCEPT
iptables -A FORWARD -o eth1 -s 192.168.1.1 -d 192.168.1.1 -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 192.168.1.1-p 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 
http.

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 
extent!)

kind regards,
Will.

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.
>
> mjr. 

-- 
William M. Fitzgerald,
PhD Student,
Telecommunications Software & Systems Group,
ArcLabs Research and Innovation Centre,
Waterford Institute of Technology,
WIT West Campus,
Carriganore,
Waterford.
Office Ph: +353 51 302937
Mobile Ph: +353 87 9527083
Web: www.williamfitzgerald.org
      www.linkedin.com/in/williamfitzgerald
      www.ryze.com/go/wfitzgerald



_______________________________________________
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards