[ale] rc.local

[Bob Toxen]

On Thu, Jun 01, 2006 at 09:46:48AM -0400, Michael H. Warfield wrote:
> On Thu, 2006-06-01 at 00:11 -0400, Bob Toxen wrote:
> > On Wed, May 31, 2006 at 08:32:42PM -0400, Michael H. Warfield wrote:
> > > Hold the phone Bob...
> > 
> > > 	I think you are a little out of date and a little off base on some
> > > details...
> > I probably am.
> > 
> > > On Wed, 2006-05-31 at 17:26 -0400, Bob Toxen wrote:
> > > > On Wed, May 31, 2006 at 10:06:31AM -0400, Geoffrey wrote:
> > > > > Terry Bailey wrote:
> > > > > > Thanks, guys, that really fixed things.  Do you know if 
> > > > > > "/etc/sysconfig/iptables" and "service iptables save" work on SUSE 10?
> > > > > > If  so, I plan to remove Fedora and reinstall SUSE.

> > > > > To my knowledge, the application service does not exist on SuSE.

> > > 	Reread that...  He's saying that, the applications "service" (as
> > > in /sbin/service) does not exist on SuSE.  Yeah, I know, without the
> > > quotes, it's confusing to read at first but then it clicks just what
> > > he's saying.  He's not saying the "application service" as in the
> > > "iptables" service application.
> > I was referring to iptables-restore and iptables-save.

> 	1) Neither iptables-restore or iptables-save are shell scripts and
> never have been.  They're binary executables.
In my followup that you are responding to I didn't claim that they
were scripts and, in fact, did the "file" on them.

> [root at mtking sbin]# file iptables-save
> iptables-save: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
> for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> [root at mtking sbin]# file iptables-restore
> iptables-restore: ELF 32-bit LSB executable, Intel 80386, version 1
> (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped

> 	2) Neither resides anywhere under /etc.  They should reside in /sbin.
I never claimed they resided in /etc.

> > > > It's hardly an application.  The /etc/rc.d/rc3.d/S##iptables script
> > > > just scans the /etc/sysconfig/iptables file and, for rules, puts
> > > > the text "/sbin/iptables " in front of it and executes.  S##iptables's
> > > > "save" feature just does "iptables -n -L" and parses into the /sbin/iptables
> > > > format.

> > > 	No...  Not quite...
> > Well, when I mentioned S##iptables I meant iptables-save and iptable-restore.

> 	Then your explanation is even more off, since those are not shell
> scripts at all.
My original post about "all they do is save and restore the rule set"
was meant to apply to iptables-save and iptable-restore, not S##iptables.
After your initial reply I never claimed that iptables-save and
iptable-restore were shell scripts and I thought my response suggested
otherwise.

> > 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).

> > > 	Actually, it is correct that the /sbin/service (and I'll use that
> > > nomenclature to avoid further confusion) is in fact just a shell script
> > > (just not the one you were referring to).  Still an application.  It
> > > just happens to be a shell script application that runs the scripts
> > > in /etc/rc.d/init.d (not the ones in rc3.d which is run by the init
> > > program and the initialization scripts).  It'll run anything
> > > in /etc/rc.d/init.d even if it's not linked to any of the rc.d/rc?.d
> > > directories and even if it doesn't have the "chkconfig" comments that
> > > allow /sbin/chkconfig to configure the rc?.d links for you.  It's a
> > > pretty much agnostic frontend to the init scripts in init.d.
> > 
> > > 	Further note...  The /etc/rc.d/init.d/iptables script, specifically,
> > > (which is typically symlinked into various rc.d/rc?.d directories),
> > > which is run by the /sbin/service command (or run by hand if you are so
> > > included), does not put the text "/sbin/iptables" in front of each of
> > > the rules and then executes it.  In fact, it feeds the entire file
> > > wholesale into /sbin/iptables-restore (or /sbin/ip6tables-restore in the
> > > case of /etc/rc.d/init.d/ip6tables).
> > 
> > > 	Also, the "save" feature does not use iptables -L at all and uses
> > > ip[6]tables-save.  Both iptables-restore and iptables-save are core
> > > components of the iptables package (not RedHat specific at all) and are
> > > binary applications residing in /sbin.
> > Thank you for correcting my incorrectly believing that iptables-restore
> > and iptables-save are RedHat specific.  A quick check found them on
> > my Slackware systems.
> > 
> > > 	man iptables-restore
> > > 	man iptables-save
> > 
> > > > You are FAR better off just creating your shell script containing your
> > > > iptables rules.

> > > 	Not...  Just the opposite, in fact.
> > We will have to agree to disagree here.  The problem with these -- as is
> > typical with higher-level but brainless applications -- is that one loses
> > the power of shell script conditionals and comments.  For complex rule sets
> > (such as mine) that is unacceptable.

> 	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.

> > > (especially for large sets of rules or rules containing dependencies),
> > > from the standpoint of kernel processing, as the kernel tables have to
> > > be processed and searched and re-evaluated internally by the kernel each
> > > time a rule is individually added that way (this is per discussions on
> > > the netfilter mailing list and on the netfilter web site).  That's the
> > > whole reason for iptables-restore.  It's an atomic (atomic vis-a-vis the
> > > netfilter iptables, that is) load and the kernel only has to rebuild its
> > > internal tables once (per table that is).  That's what that "COMMIT" is
> > > at the bottom of the table load.  It tells iptables-restore that this
> > > table set is complete and to commit the load to the tables.  That's once
> > > for the filter table, once for the nat table, once for the mangle table
> > > (as required)...
> > What's a minute for a reload on a once a year reboot or the occasional
> > tweaking.  A better solution would have been a better internal table
> > configuration than just a sequential search.

> 	I don't believe it uses a sequential search and there-in lies the
> problem.  The tables are optimized for lookups, which are very frequent
> (line speed packet by packet) and not optimized for updates, which are
> relatively infrequent.  That optimization has to be rebuilt (reindexed?
> rehashed?) each time you update the rules.  If you insert a rule the
> kernel has to update it's understanding of the entire table for
> optimized lookups BECAUSE it's not a sequential search and lookup
> performance is paramount.
For checking a packet, it sure looks like a sequential search through
a linked list to me (though I did not do a thorough analysis).

See
  2.6.16.19:
    ipt_do_table() in ip_tables.c
  2.4.32:
    ip_fw_chk() in ipfwadm_core.c


> > > 	Running iptables individually for specific commands is fine for making
> > > changes or small tables but should not be used for initial loads or
> > > wholesale massive changes.
> > 
> > > 	Your comments MAY have been true for the older ipchains firewall, I
> > > certainly won't dispute that, but is no longer true of the newer
> > > netfilter/iptables packages.
> > Clearly, one can get faster bootups by using a shell script of rules
> > to generate the configuration and then doing iptables-save whenever that
> > shell script of rules is changed and allowing iptables-restore to be used
> > on normal bootup.  Thanks for the ideas and, ahem, corrections.

> > > > Btw, SuSE has firewall2 (maybe firewall3 or 4 by now) that is a real
> > > > wrapper for IP Tables.  I'm not impressed with it either because the
> > > > rules it builds are so convoluted that it is impossible to know what
> > > > really is allowed.  Build your own rules or copy them out of your copy of
> > > > "Real World Linux Security".
> > 
> > > > > -- 
> > > > > Until later, Geoffrey
> > > > 
> > > > > Any society that would give up a little liberty to gain a little
> > > > > security will deserve neither and lose both.  - Benjamin Franklin
> > > > We sure need Ben's wisdom now!
> > > > 
> > > > Bob Toxen
> > > > bob at verysecurelinux.com               [Please use for email to me]
> > > > http://www.verysecurelinux.com        [Network&Linux/Unix security consulting]
> > > > http://www.realworldlinuxsecurity.com [My book:"Real World Linux Security 2/e"]
> > > > Quality Linux & UNIX security and SysAdmin & software consulting since 1990.
> > > > 
> > > > "Microsoft: Unsafe at any clock speed!"
> > > >    -- Bob Toxen 10/03/2002
> > 
> > > 	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!
> > Bob

> 	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!
Bob