[EMAIL PROTECTED] wrote:
> ...
> 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.
The problem in XML is that there is no 'order' enforcing in the XML
spec; thus with SAX the order might be different from the DOM interface;
then the parsing becomes dependent to a particular API. Ofcourse one can
put in the ID attribute for the element to provide order hints, but
still that's not the strength of the XML.
I still wonder if there is a way to detect the invalid order, thus
iliminate the order inside the XML.
> 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.
Agreed.
Separation of network descriptions and firewall rules is good. If we
think in terms of services & network, can we specify the rules? For
example: "I have an FTP service, on default port, on the DMZ network,
and I would like to offer this service to both the public & private
networks", can a utility generate that rule correctly?
Thanks,
Ly
-----
> 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
--
"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
