James Carlson wrote: > Tony Nguyen writes: >> Hi Darren and all, >> >> As part of the Visual Panels project, >> >> http://opensolaris.org/os/project/vpanels >> >> we're proposing a generic firewall framework for Solaris. The framework >> utilizes IPfilter to provide a simple mechanism to configure a firewall >> on Solaris systems.
Hi James, Thanks for the valuable feedback. My responses inline. -tony > > This looks pretty nifty. I have a few high-level questions about it, > though: > > - There are a bunch of open source firewall construction toolkits > and 'ease of use' GUIs around for doing this sort of work, > including several for IP Filter. (I think FirewallBuilder is a > popular one, but there seem to be others as well, and I'm no > expert in that marketplace. I've always just edited the files by > hand.) > > I didn't see any mention of these other systems in this document. > Would it be possible to add a section that addresses how this new > feature compares to one or two of the known popular existing > tools, and (longer term) how we plan to keep ours viable and what > issues users may have in transitioning over from one of the > others? Agree. I'll add section to capture this analysis after our discussion. I'm not too familiar with these firewall toolkits. However, looking at FirewallBuilder and TIS Internet Firewall Toolkit, I see clear advantages for our proposed solution. It's worth to repeat is to provide a simple mechanism for casual, OpenSolaris, users to harden their Solaris systems. - very simple user model. While FirewallBuilder is able to produce highly customized configurations, it requires good understanding of firewall concept and knowledge of the system networking configuration. Setting up FirewallBuilder requires specifying path, file, local address, create objects for each service, *configure* firewall for the objects, compile, and run. Our firewall only requires changing properties and enable service(s). - well integrated with Solaris. Enough said :^) - support IPfilter configuration generated by other tools. Our framework should satisfy the needs of most casual users. However, advanced users can always use tools such as FirewallBuilder to generate IPfilter rules that can be consumed by the proposed framework. > - Related to that: are there any standards (formal or otherwise) for > policy rule languages? It seems to me that having consistent > policy rules across multiple machines (not just Solaris) would be > an important goal for administrators, and being able to speak some > common language would be an important step to achieving that. > I believe such standard doesn't yet exist since IPfilter rules are quite flexible. Darren will correct if I'm wrong :^) > If no viable standards exist, and we don't want to create one for > some reason, is it at least possible to synchronize policy among > cooperating Solaris machines? I see only "system-wide" as the > largest grouping described in the document. Synchronize? Do you mean configuring a policy and populate that policy to other machines? > > Has any investigation been done on interoperability and deployment > with multiple machines? Can you clarify? I've run it on my desktop and multiple lap machines and some preliminary tests with CIFS server/client. > - One of the big high-level problems with IP Filter (as it is with > _all_ firewall software) is visualizing how the rules perform. > That is, being able to ask "what if?" questions concerning traffic > from other hosts. (Something like: "which rules would match if I > received a TCP SYN packet for destination address a.b.c.d and port > 25 from host foo.bar.com, and what would be the resulting action > taken by the system?") > > As someone who uses this stuff frequently, this is often a sore > point. It can be hard to determine whether you've gotten > everything just right unless you log into some remote system and > start attacking your original machine. > > Would it be possible to have something like "tcpdmatch" for this > tool? > Very good suggestion and would be really helpful for testing. At this point, I don't think we'll include this in our initial integration but it will be on my list of enhancements.
