On Fri, Sep 21, 2007 at 11:12:10PM -0400, [EMAIL PROTECTED] wrote: > Douglas A. Tutty wrote: > ... > > I don't understand the logic of having multiple firewalls on one box. > > If one box can handle the throughput requirements of all the NICs, why > > not just one big firewall? > > There are lots of places where multiple firewalls are better than a > single firewall. If one believed in the idea of "a perfect VM > environment", it could make sense to do that. > > 1) Unrelated projects: If Project A and Project B are not related, > keeping them on separate firewalls can simplify the rule sets and > administration. > > 2) Separate administration: If you run a data center with lots of > different people managing different systems, "They" can administer their > systems without having access to (or messing with) "My" systems' > firewall. When they screw up their rules, they don't break my systems > (and I guess it works the other way, too. :) Note this has some > cross-training benefit, too. I can be the Firewall Deity, but I do want > to go on vacation. Fred may be a Firewall Jester, but with a bit of > practice, he could possibly back me up very effectively. So, Fred > manages a firewall for his projects, when he screws up, he learns > lessons on a simple system, and when I am not there, he can babysit > the "big" firewall, and if I get run over by a bus, he knows how to > keep all the systems running. > > 3) Isolation: I had set up a firewall for a web app some time back. I > had ZERO trust in the skills of the web developers, and even less for > their security programming skills (and similar trust in my skills to > audit their code). So, I stuck their app on its own firewall, > completely isolated from our production environment. I also made sure > that the various machines in the thing were each attached to their own > leg of the firewall, so that we really had several layers of security > between the Internet (bad guys) and the database (the valuable stuff). > You would have to knock over Apache, then the app, then the DB to get to > the data. Even then, they get to a DB Server which had ONLY THE BARE > MINIMUM data required to accomplish the task at hand. If it wasn't for > this design, you can be sure that database server would end up serving a > lot of things as, $18k Oracle licenses don't grow on trees. :) > (I'm actually rather amazed they went for this. If you look at all the > money they spent on the non-free parts of this system, it ended up > costing probably $10/hit this site has received). If this firewall > ended up getting knocked over, they would still have no access to the > real company jewels, just a few shiny pebbles. This entire system could > also be picked up and moved to some other location without much > difficulty, if we wanted to co-locate the system. > > > If you spend too much money on a commercial firewall product, you might > wish to convince yourself that "centralized administration" is best, > and all that and want to run everything through one monster firewall, > but for real-life, there are places where it makes more logical sense > to split things up.
Hi Nick. I understand your reasons. To me they look like reasons for separate firewalls on separate boxes. In the scenarios you mention, would you put separate firewalls on one machine? If I was going to put them all on one machine, I'd separate the administration of the box itself (me) from the people responsible for rule sub-sets. E.g. if one sub-firewall is dealing with traffic between NICs 1 & 2 (call it channel A), another between NICs 3 & 4 (call it channel B), I'd have the channels A and B admins submit rules sub-sets via rsync to the box. My script would then sanity check (ensure that they only dealt with the interfaces they were assigned) then incorporate all of them into a master rule-set that would then get tested and then put on-line. I would think that this, being only one firewall, would be simpler than several firewalls in VMs on one box; possibly more secure given the comments in this thread about the porus isolation between VMs. That's just how I would think of it. OTOH, I've never done any virtualization and never been into a proper data center. Doug.
