[ale] rc.local

[Michael H. Warfield]

On Thu, 2006-06-01 at 13:02 -0400, Bob Toxen wrote:

> > > While I've not looked at the code for iptables-save and iptable-restore,
> > > I'm willing to bet that iptables-save does either use "iptables -n -L"
> > > or makes the system calls itself (or uses /proc files) and parses it
> > > into the /etc/sysconfig/iptables format (that basically has rules and
> > > policies, which is all IP Tables is anyway).

> > 	Both makes the system call themselves.  Certainly neither calls
> > iptables to do their dirty work.  A simple strings on the binaries can
> > tell you that.  And the only references into /proc are for
> > iptables_names, which only gives the names of the tables
> > (nat,mangle,filter) and nothing more, and sys/kernel/modprobe.

> Ok.  I don't really care about the implementation.  I'm impressed that
> they apparently use a system call that quickly dumps each entire chain
> (or entire tables).

	More importantly, that restore is "atomic".  It loads the rules from
the file, up to a given COMMIT, and then commits them all at the same
time.  That can be significantly different than if you are loading the
rules one rule at a time.  Consider that some of the rules and matches
and states may interact.  A match on state may be impacted by other
rules you want enabled and disabled simultaneously.  Simple cases, the
rules may all be orthogonal.  But that may not always the case with
stateful firewalls.

	:

> > 	Yeah, I already understand that you don't like netfilter and you
> > disagree with the netfilter team.  But that's their statement and their
> > position and they wrote it.  For complex initial loads, you can just as
> > easily use a shell script to generate a restore file and load it using
> > iptables-restore.  After that, you can use individual iptable commands
> > to update the rules in the tables on the fly as conditions change.
> > Anything you can do with individual calls to iptables at initialization
> > time can be done equally well and more efficiently using this method.
> You're not responding to what I wrote and you seem to miss my point.

> Using the raw iptables and -save and -restore to make changes (other than
> temporarily for testing) is like patching a compiled binary rather than
> changing the source -- in this case the original shell script.

> > > > 	Running the iptables command for each command is extremely inefficient
> Running the iptables command for each rule *is* very inefficient --
> because Rusty didn't think to allow it to read a file of rules from stdin
> or a file and because he "flunked" Data Structures Class where we were
> taught that you should leave a pointer to the end of a linked list to make
> appending to the list fast.

	Actually, he did.  It's called iptables-restore.  :-)  And it can load
arbitrary rules from a file or from stdin.  Yeah, maybe he could have
named it differently (iptables-bulkload, iptables-loader, iptables-???),
but it's really a bulk loader / batch processor, even though he intended
it to "-restore" saved tables from "-save".  It also could be documented
a WHOLE LOT better (like the man page doesn't list half the options and
it doesn't mention the fact that it will use an unadorned parameter as a
file name to load from).  It doesn't have to flush the tables (-n
--noflush option) so you can use it to bulk load changes on top of
existing rule sets (I don't use it that way, but you can).  I can see
where you might have liked that functionality to have been implemented
as an integral part of the base iptables command.  But the functionality
does exist.  Just not where you thought it was.

	I don't know if it will allow you to delete rules that way or insert
into chains after specific rules that way.  Might be worth a giggle or
two just to see what happens if "restore" gets a -D or -R instead of a
-I or -A.  AFAICT...  It acts almost like a batch processor for the
iptables command except that the transactions are atomic on the explicit
commit rather than after each rule change, and the syntax is a bit
different when manipulating policy and creating chains.  It actually
seems a much more general processor than simply restoring the dumps spit
out from iptables-save.

	IAC...  You certainly can use iptables-restore to append (or insert)
blocks of rules onto existing chains without disturbing other chains or
other rules on the same chains.  You've got me thinking now and I may
see what other hidden talents and capabilities iptables-restore may
have.  I typically have built dynamic rule sets of atomic functions in
iptables by building them into independent chains first and then using
those chains as jump targets after their built.  This may be another way
to implement the same tricks...  Hmmm...  This is worth playing with...

	:

	Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part