Hello Ray,
Thank you for the valuable insights.
Please allow me to clarify something on the topic of writing rules in
XML format. I agreed that if we take on the task of 're-writing' the
rules in different format (XML or not); we don't solve anything and
still have to face the inherit problems. However, if we take the
approach of describing the network and services; then we might have a
chance of solving the rule problems.
For example, if the XML file only describes the services that s/he
wants to run on the network; the services part of the XML file may look
like this:
<services>
<service id="ftp_1" type="ftp">
<port>default</port>
<host>my_ftp_server.mydomain.com</host>
</service>
<service id="web_1" type="web">
<port>default</port>
<host>my_web_server.mydomain.com</host>
</service>
</services>
...
Then, the access defintion part can be further described as follow:
<access>
<allow service_id="ftp_1">
<network>private</network>
</allow>
<allow service_id="web_1">
<network>private</network>
<network>public</network>
</allow>
</access>
Other attributes or elements can further describing each access policy
(ie. loging or not, hard or silent rejection...)
Now, once the networks & services are defined, other tools can then
translate (transform) this file into the appropriate native rules for
the applications to use. Basically, the transform engine will determine
the order of the rules; may be based on a hardcode or selectible
strategy, which can be again identified by the user.
Cheers,
Ly
----
Ray Olszewski wrote:
>
> Before I get into the substance of a reply, I should take a moment to
> mention that I have been working with Scott's company for the past year or
> so. I've referred to that work a bit in the past, here and on the LRP list.
> I still do some work for Scott on the side, though I now have a full-time
> job elsewhere (again, as many of you know).
>
> With that detail out of the way ... Scott, I think this attempt doesn't get
> to the essence of the design problem. It is no trick to rewrite ipchains
> rule arguments in XML format, or Windows .ini-style format, or probably in
> Middle English; the complexity is dealing with the logic of ruleset
> construction in a way that actually gains something from the rewrite.
>
> The big problem with ipchains rulesets is that order matters. Often,
> mistakes (mine especially) involve trying to open a port *after* I've closed
> it ... that is, putting an ACCEPT rule in place below a more general DENY
> rule that moots the ACCEPT rule. Or trying to forward packets that the input
> chain has DENY'd. Or other mistakes at that level. I rarely get an
> individual rule wrong.
>
> XML'ing the syntax of a single rule won't make it any easier to handle that
> part. I'm not sure what would; the general problem probably needs the full
> flexibility of the ipchains process, so any rewrite of it will remain
> equally complex (except possibly in trivial ways, the kinds of changes that
> make it easier to avoid typos.
>
> For that matter, I'm doubtful that XML'ing will help get individual rules
> right. That requires a rule pre-screener, and why not just let it write its
> output in "ipchains-native" format?
>
> Now one really interesting extension of this discussion would be to come up
> with an XML (or other) format that could be translated into rules for
> ipfwadm, ipchains, AND netfiler (as well as ipportfw, ipmasqadm, and
> whatever 2.4.x uses here). I suspect this is impractical, since the 3 tools
> have different capabilities, sufficiently different that either the
> capabilities set of the format would be too limited for netfilters or leave
> out too much for ipfwadm. But then you could think in terms of using such a
> tool to generate firewall rulesets for any OS that supported firewalling,
> not just Linux.
>
> In practice, though, I think this just won't fly.
>
> Successful simplifications generally involve trading flexibility for
> simplicity. The LRP/LEAF image approach reflects this -- many images are
> customized, or at least semi-customized, for particular circumstances. No
> one familiar with the range of LRP/LEAF image choices would try, for
> example, to adapt Ken Hadley's PPPoE image to a static-address connection.
> Why do the work? It misses the point of the customization, and there are
> other images better suited to that use.
>
> In a way, Dave Cinege always had the right idea about this problem ... write
> some scripts that simplify the basics, and expect the advanced user to do
> the complicated bits by hand. His line between what his network.conf does
> for you and what he expects you to do for yourself in network_direct.conf
> may not be the exactly right place to draw the line, but having such a line
> is a good idea.
>
> Generalizing this approach involves finding the (say) dozen configurations
> that account for 95% of the use of firewalls when installed by
> non-specialists (I'm trying to distinguish a typical home setup from, say,
> our colo'd site, where a fully bespoke firewall is a reasonable solution).
> Then set up rule-generation procedures that fit them, possibly even using an
> existing mechanism like the "ipmasq" package available for Debian.
>
> To judge from the traffic on the LRP list, the place to concentrate
> flexibility is in handling weird services. There are real problems getting
> NetMeeting right, or Napster, or ICQ, or a bunch of other services I myself
> don't use. If we got that right, and we had a simpler procedure for either
> proxy-arp'ing or static-NAT'ing addresses for the crowd who buys 5-IP DSL,
> and we better detected situations where the external address is in
> private-address space, we'd eliminate 90% of the *firewall* troubleshooting
> that happens.
>
> Do all that plus write an auto-detector for NICs that works, and the
> LRP/LEAF troubleshooting business would all but vanish.
>
> This is the approach LRP/LEAF has taken for connection types for years, with
> a range of ststic, dynamic, PPPoE, dialup ppp, and other images available.
>
> At 01:53 PM 2/3/01 -0800, Scott C. Best wrote:
> >Ly:
> > Going to take a stab myself here...
> >
> ><RULE>
> > <CHAIN>input</CHAIN>
> > <ACTION>policy=deny</ACTION>
> ></RULE>
> ><RULE>
> > <CHAIN>input</CHAIN>
> > <ACTION>flush</ACTION>
> ></RULE>
> ><RULE>
> > <CHAIN>input</CHAIN>
> > <ACTION>ADD
> > <INT>external</INT>
> > <SOURCE_IP>anywhere</SOURCE_IP>
> > <SOURCE_MASK>0</SOURCE_MASK>
> > <DEST_IP>255.255.255.255</DEST_IP>
> > <DEST_MASK>32</DEST_MASK>
> > <PROTOCOL>tcp</PROTOCOL>
> > <LOGGING>no</LOGGING>
> > <FLAGS>syn</FLAGS>
> > <POLICY>deny</POLICY>
> > </ACTION>
> ></RULE>
> >
> > A starting point?
> >
> >-Scott
> [old stuff deleted]
>
> --
> ------------------------------------"Never tell me the odds!"---
> Ray Olszewski -- Han Solo
> Palo Alto, CA [EMAIL PROTECTED]
> ----------------------------------------------------------------
>
> _______________________________________________
> Leaf-devel mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/leaf-devel
--
"If you find yourself digging a deeper and deeper hole... stop digging."
- Anonymous
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
