Firewalling 90% complete & tested, questions about writing tone

Dagmar d'Surreal dagmar.wants at nospam.com
Thu Apr 29 11:21:40 PDT 2004


On Wed, 2004-04-28 at 20:38, F. R. Wesselmann wrote:
> Sounds like you did a good bit of work there!
> 
> Your idea of interface and source/target abstraction is beautiful -- it 
> ought to be easier now to have the script that starts the web server 
> also change the firewall rules permitting access to it!

That was the exact idea.  The only cases in which it might not function
properly are instances where services are brought up, and an interface
changes substantially (new IP address, for example) and _then_ the
services are brought down.  Removal of iptables rules kind of assumes
that everything is the way it was when they were brought up.  Still,
this isn't anything that a reboot won't eliminate, and in the meantime
it will just mean netfilter directives get left around that don't
actually do anything.  I don't see this as a super-huge problem since on
a multi-interfaced system, you typically want to bind the services
themselves to a given interface if at all possible, and you may as well
restart them when that IP changes anyway.

> However, I am a little concerned about the new rules language of it. 
> Between ipchains and iptables etc. this may seem convenient but it adds 
> another level of complication and interpretation.  Now you have to first 
> figure out what the new command does and then make sure that the actual 
> firewall rules come out right, too.

This shouldn't be a problem.  I'm still going back through and
correcting the use of the SCRIPT_DEBUG variable so that everything it
executes will be logged to syslog so someone can see for sure what's
going on.  I'm assuming everyone has logger installed, although I don't
know what package it comes with off the top of my head it's been
reliably appearing on all my LFS installs.  Also at this point syslogd
should be up and running so it shouldn't create any problems there,
either.

I am _not_ writing support for ipchains for three reasons.  The first
being people really shouldn't be using it with 2.4.x kernels.  The
second being people shouldn't _need_ it since this abstraction layer is
there to take care of the problem of them not knowing iptables syntax. 
The third being that since the functions will be coming from that one
file someone that really wants to throw away the ability to use
netfilter's connection tracking, they could just rewrite the functions
to use ipchains and swap out the script with their own and never have to
modify any of the init scripts.  (Eventually something else is liable to
replace iptables, and again, this abstraction gets us out of that hole
as well.)

...there is also the FIREWALL_SCRIPT variable which holds the name of
whatever script should be run to set up firewalling rules _instead_ of
using these commands, for those people who are using fwbuilder or their
own custom script to set up firewalling who don't want to let go of it
for whatever reason.  

> It would be nice if we could somehow "overload" the iptables syntax to 
> work with your abstractions, i.e. "de-multiplex" any lists into 
> identical, explicit rules for each list element...

The thing winds up internally breaking out into a *bunch* of nested for
loops because there's only so many types of multi- matches netfilter can
do right now.  If, for example, protocol isn't specified, and the
service is one that's listed for both tcp and udp in /etc/services, the
support script will execute iptables twice, once for tcp and once for
udp.  Again, if at some point in the future netfilter gets a way to
easily match multiple protocols (or something) with one invocation of
iptables, only the one script needs to be modified to support it.
-- 
The email address above is phony because my penis is already large enough, kthx. 
              AIM: evilDagmar  Jabber: evilDagmar at jabber.org




More information about the hlfs-dev mailing list