hi all!
Ly, I think we are getting somehere here, we actualy started to work out the
schema (not the schema, actualy a demo XML).
I think Ray mentioned somehing about order, XML is like a table it's order
is it's rowsource/recno, so when you read a XML file the parser has to call
the $IPCHAINS or whatever subsequently for each rule defenition on the XML,
eliminating the order problem.
I sugest we separate a firewall script (a real ipchains scrip) in different
categories. can anyone provide a good complicated example? My intentions are
not to provide a ipchains specific conf file, instead a learning base for
the evolution to netfilter or the old ipfwadm.
so I'll try to explain my thoughts... I'll make just a simple draft:
<chain>
<id>input</id>
<dev>eth0</dev>
</chain>
<chain>
<id>forward</id>
<dev>eth0</dev>
</chain>
<chain_desc id='input'> <!-- under this element we can put all the input
rules -->
<rule id='nothing passes'>
<cmd> A </cmd>
<proto> all </proto>
<src_ip> 0.0.0.0 </src_ip> <!-- single or range -->
<src_mask> 0 </src_mask>
<src_port> 21 </src_port> <!-- single or range -->
<dst_ip> 0.0.0.0 </dst_ip> <!-- single or range -->
<dst_mask> 0 </dst_mask>
<dst_port> 21 </dst_port> <!-- single or range -->
<masq> 0 </masq>
<fragment> 0 </fragment> <!-- 0: not present, 1: set ,2: !set -->
<target> DENY </target>
</rule>
<rule>
....
</rule>
</chain_desc>
<chain_desc id='forward'>
...
</chain_desc>
is this suitable? I haven't got too much time, so I did this very simple and
it may contain some bugs.
please comment.
pedro
> From: Anh (Ly) Vuong [mailto:[EMAIL PROTECTED]]
>
> 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
>
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
