This is going to be a really long posting if I go into the level of detail that I want. So I'm going to have to break this up over several postings. This will be the introduction and table of contents posting. As I add more postings on this topic, I'll update this posting accordingly. Once I have enough content, I'll probably add it to the Popular Topics link list on the right.
A while back we purchased a Sidewinder firewall as part of our strategy to achieve PCI compliance. The plan that we're enacting is to isolate our entire cardholder environment behind the Sidewinder. In most cases, a simple and cheap stateful inspection firewall would be sufficient for that, but we've also got some web applications that process credit card data and we need to comply with section 6.6 of the DSS as well. That calls for an Application Layer Firewall (or a source code audit, but we decided on Application Layer Firewall).
Now don't get me wrong, I love my Sidewinder. I have referred to it as the coolest device ever attached to the Internet, although it has lost at least 5% of its coolness since they changed the name to something dumb that I wont repeat. But there are some things about the Sidewinder that make me sad. For example, it's not open source so I don't really know how it works. As a security guy that makes me uncomfortable. I also don't like that the configuration files aren't plain text. I can't put them into a revision control system and quickly see what changes were made without my knowledge by some other firewall administrator. And of course there is the fact that Sidewinders are expensive. So I thought I would take some time and see if I couldn't build an open source alternative to the Sidewinder for people who aren't fortunate enough to have one. This isn't going to be as full featured as a Sidewinder, but it will be more secure than a simple Stateful Inspection Firewall and it will help meet the requirements of section 6.6 of the PCI DSS. Remember, though, that your acquiring bank is the referee as far as what meets the requirements and what doesn't. You may want to check with them and see if you can use this instead of some commercial product.
So I guess this is a good time to talk about what exactly an Application Layer Firewall is. In a nutshell, it's a firewall that operates at the Application layer of the OSI. More practically speaking, it's a firewall that acts as a proxy server and makes decisions about passing traffic based on the payload of the connections it proxies. When you make a request of a web server that is protected by a proxy firewall, your connection actually terminates at the firewall, and the firewall initiates a new connection to the web server. Before initiating the connection, the firewall might look at what resources you're asking for and make the decision to deny the connection. This model is inherently more secure than a stateful inspection firewall that only looks at the destination address and the destination port. The downside is that proxy firewalls are usually slower and there aren't proxies available for every service that runs out there. I know there are people that will argue with me about my belief that a proxy firewall is more secure by its very nature than a stateful inspection firewall, and I don't feel like getting into an argument about that. So I'll put it this way: PCI DSS section 6.6 calls for an Application Layer Firewall. If you're not using something that operates at the Application layer of the OSI model then you are not compliant. Again, keep in mind that your acquiring bank is the referee, not me. For a good explanation of why Application Layer Firewalls are necessary, check out this link: http://jeremiahgrossman.blogspot.com/2009/04/disagree-with-concept-or-implementation.html (make sure you read my comments in the comments thread because everything I say over any media is worth reading).
What is our open-source application layer firewall going to look like when it's done? Well basically we're going to be using OpenBSD for our operating system, and we're going to use PF to handle any stateful inspection or natting that we might need. We're going to use Apache with mod_proxy, mod_ssl, and mod_security to act as a proxy for our http/https/ftp traffic and provide application-layer security. Can your stateful inspection firewall look for Cross Site Scripting or SQL injection in the http part of your traffic? Can it perform input validation for your applications before the traffic gets to the servers? Mod_security can, and that is why it rules ass over simple stateful inspection. We're going to use OpenBSDs relayd to act as a generic proxy for ports where we don't have a full application proxy to work with.
I'm also going to make use of a back-end server that doesn't have much on it. It's a very simple setup that will be used to make sure that our firewall is passing services. I have all of this running on virtual machines. The backend machine has a host-only network that connects to an interface on the firewall. The firewall has the host-only network and another nic that is bridged to my real network. That's where the "public" ip addresss will be reached by the clients. So watch this space as I start to fill in the How To posts.
Here is part 2.