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
