Firewalling 90% complete & tested, questions about writing tone

Dagmar d'Surreal dagmar.wants at
Wed May 5 10:48:57 PDT 2004

On Wed, 2004-05-05 at 12:13, Kelly and Jennifer Anderson wrote:
> Hash: SHA1
> Dagmar d'Surreal wrote:
> | On Thu, 2004-04-29 at 18:16, Kelly Anderson wrote:
> |
> |
> |>It's not too hard to solve that problem.  Something along these lines
> |>will take care of it.  Have your iptables script write the interface's
> |>IP to /var/run/dhcpc/iptables-${IF_UNSECURE).info.  This is part of a
> |>script that I put in /etc/cron.hourly.  You can probably figure out how
> |>you'd want to incorporate it in your stuff.
> |
> |
> | This is one of the nearly unsolveable points I've got left over.  A tip:
> | if you use ISC's dhclient, you have /etc/dhclient-exit-hooks that gets
> | called everytime something DHCP-related happens, so you don't have to
> | put that code into a cron job.  Whatever you put into
> | /etc/dhclient-exit-hooks will be able to know about it the moment the
> | host's IP address changes.  If you're using a monolithic firewalling
> | script this will work, but I've not been able to come up with an easy
> | way to do the same thing for a modular rulesets in anything remotely
> | approaching an elegant fashion.
> Sorry I didn't reply to this sooner, but I've got a lot of irons in the
> fire.
> I'm not using dhclient, but instead dhcpcd.  My approach works for
> either client.
> What part of your code would break if you simply rerun your firwall
> script?  K.I.S.S. is ultimately elegant when applied to firewalls.

That question is moot.  There is no single firewall script involved. 
I've got a _support_ script that should be sourced into each init script
which has a daemon that needs network access.  Usually one or two
commands added to the start and stop portions of the script are all that
will be necessary to add the firewalling rules for the daemon in a
human-readable way.  This ties the existence of the rules to the
activity state (either down or up) of the daemon and reduces
administration and change managment labor, since at this point, any
packaged replacement of a given daemon will automatically bring the
necessary firewalling rules with it.  This also reduces the chance
someone will typo or otherwise make a mistake, since much of what goes
on inside the support script winds up doubling as sanity checks as a

For those people who still want a monolithic script for their
firewalling, support is provided for that as well.  For example...

  if [ -z "$FIREWALL_SCRIPT" ]; then
    permit_inbound from ANYWHERE to DMZNET for http
  apachectl start

At one point I'd considered making the check for the firewall script's
existence completely transparent and putting it inside the
permit_inbound function (so they would silently do nothing), and then I
decided there's bound to be some people who will want to use both

...and for those who noticed, yes, in the last 48 hours the use of the
automagic tokens have become more flexible, and I wound up writing a
function that makes DMZ detection reasonable under certain
circumstances, namely, when the CIDR size of the DMZ network is smaller
than that of the intranet network.  I ran into a tangle in the logic
necessary to add all the rules to make the above example happen
properly.  (It actually requires interfaces*2 rules to work.)  If I
can't get it all sorted out this weekend, I'll post the work thus far
here and solicit more eyeballs.

P.s.: Pardon me if I miss some emails this week.  My primary email ISP
(Speakeasy) have managed to demolish their own systems and I'm in the
process of resubscribing dozens of lists from a different address.
The email address above is phony because my penis is already large enough, kthx. 
              AIM: evilDagmar  Jabber: evilDagmar at

More information about the hlfs-dev mailing list