On Mon, 2003-12-08 at 06:21, Neil Hare wrote: > - should use client / management / server model > - client should be just that, a client. Nothing stored here. Only > connects to management. > - Management - here should be the logic. Check that rule objects are > valid (valid IP, Network definitions, etc.) Responsible for > "Serializing" the config and objects, either in Databases (LDAP, MySQL, > etc.) or in XML. Checks that one rule doesn't negate the next. Pushes > new policies to firewall. > - server (Check Point calls it the "Enforcement Module") Here's where > the rules get enforced. In fail over config, two gateways would need to > sync state information (VRRP). > - Client / Management / Server model should _allow_ all services to be > on different machines, but not _require_ it. > - Inter machine communication should be encrypted. Automatic SSH tunnels > probably the easiest (and quickest to implement). > - Should probably use some standard messaging protocol for communication > between client / management / server. Suggestions? Something based on XML? > - Management & Clients should also be protected by a firewall policy. I > never understood why Check Point ignores the fact that management and > client should also be protected. The paradigm you described sounds very robust and well thought out. However, I think that is this particular case, it adds an unjustifiable extra level of complexity. Now please hear out my reasoning before hitting "reply". We're writing a configuration tool (not a service) that will become part of the system-config-* suite of applications. The majority of our users will be using this tool to configure their own (one) machine from the desktop on that computer. I'm not interested in designing an enterprise-class firewall management suite. That's far beyond the needs of well over 99% of our users, and would take much longer to build. What I'm looking to build is a powerful but user-friendly iptables frontend. It shouldn't depend on any third-party database or communications software--that is, the user shouldn't have to install SSH or MySQL in order to configure their own box's iptables rule set. That's not to say that there isn't a place for such a firewall management suite as you've described. I'm just saying that the place isn't system-config-network. The program I've been working on follows the following principles: * Should be easy enough to use by people who don't even know what a firewall is so that they can harden their box, set up masquerading, etc. with extremely little effort. * Should avoid proprietary internal function that would limit its value outside of what the developer had envisioned. I.e., if you can do it with iptables, you should be able to do it with system-config-firewall. * Should be simple enough to write and test quickly, but still perform the required function. We need this tool yesterday, not next year. * Should inter-operate without any problems with other firewall management software (including iptables itself). To the user, system-config-firewall should behave as if the user was working on "the firewall" itself, no matter what the other config tools may do. That means directly accessing the kernel's current iptables rule set (for both read and write), as well as using already-standard repositories for saved rule sets (such as /etc/sysconfig/iptables). That means iptables-save format, rather than XML or third-party databases. The problem with creating your own internal rule store is this: Say the user creates his rule set with our tool. He then (for whatever reason) uses some other piece of software (e.g. iptables) to make a change to the firewall. He then goes back to our tool to view/edit the rule set. Our tool reads the rule set from its own store (that hasn't changed). The problem now is that our tool displays what it thinks the firewall should look like, rather than the actual true state. Also, any changes the user had previously made are undone when we active our own (stale) rule set. We could pompously suggest that ours is the only tool that matters, and the user shouldn't be messing around with other configuration tools, but that attitude is counterproductive and tends to make your product go unused. -- Tyler Larson Colorado, USA Timezone:MST (GMT-7:00)