Firewall Wizards mailing list archives
Re: Provocative Query: Are firewalls obsolete in a world involving enterprise WebService SOA
From: william fitzgerald <wfitzgerald () tssg org>
Date: Wed, 26 Mar 2008 18:14:04 +0000
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
Current thread:
- Provocative Query: Are firewalls obsolete in a world involving enterprise WebService SOA william fitzgerald (Mar 26)
- Re: Provocative Query: Are firewalls obsolete in a world involving enterprise WebService SOA Joe Nall (Mar 26)
- Re: Provocative Query: Are firewalls obsolete in a world involving enterprise WebService SOA Marcus J. Ranum (Mar 26)
- Re: Provocative Query: Are firewalls obsolete in a world involving enterprise WebService SOA william fitzgerald (Mar 26)
- Re: Provocative Query: Are firewalls obsolete in a world involving enterprise WebService SOA Magosányi Árpád (Mar 27)
- Re: Provocative Query: Are firewalls obsolete in a world involving enterprise WebService SOA Paul Melson (Mar 28)
- Re: Provocative Query: Are firewalls obsolete in a world involving enterprise WebService SOA ArkanoiD (Mar 27)