Iptables initialization

Dagmar d'Surreal dagmar.wants at nospam.com
Thu Feb 12 14:54:49 PST 2004

Okay, since all I've been seeing lately on this list are some pretty
specific technical solutions (which are being pretty carefully examined,
and I like that) to a very small set of problems, I'm going to pose a
more high-level (as opposed to the minutae of stack protection) problem
to the list for analysis and see what kind of further interest this
stirs up.

To clarify the nature of what kind of thinking is needed, I want to
point out that much of the brain work in security engineering does not 
actually involve meddling with source code.  Quite often the main work
is done just by isolating what's called "best practices" and
implementing those in the configuration and/or design stages of
deployment.  (i.e., I don't want to hear about patching the kernel for
this--it's the wrong solution)  This is, quite often, the thing that
system administrators overlook the most often when they finally get
around to securing their systems.  I've seen multiple incidents where
the sysadmin installed some really hardcore service daemon, only to have
it knocked over immediately through some fundamental flaw because they
had no concept of best-practices and were deploying solutions to
specific incidents as they happened.

Here's the problem... at the moment neither of the books (LFS, BLFS)
seem to give in-kernel firewalling more than a passing glance.  HLFS is
the obvious place for this to go, because frankly, the presence of a
network connection is the _reason_ most people bother to secure their
devices.  Now that that's been said, here's an axiom which will be
mentioned specifically in the book (or I'll bury the editors in
references from people who make _seven_ figures a year) that's called
the Principle of Least Privilege.

PRINCIPLE OF LEAST PRIVILEGE: That which is not explicitly allowed, is
automatically denied.

(With respect to a host's participation in a network, it means that the
machine should initially respond to *no* packets whatsoever.  When a
host is acting as a firewall, it is especially important that this be
the case, and as to routers, it's actually documented in an RFC for
machines acting as routers that they should have their policies in place
before enabling any interface for routing.)

In theory, this means that your security policies should always begin
with the most restrictive policy possible (i.e., no one is allowed to do
anything), and then add policy that allows the users who need access the
ability to do the specific things they need to do.  In practice, one
often encounters design issues that make actually implementing these
policies involve serious reconstructive surgery on a system
configuration (generally that is a sign someone did it wrong to start

Since in the LFS-bootscripts firewalling is not atomically tied to the
starting of the network (and trust me on this, trying to do it on a
per-interface basis is not a clean solution... been down that road and
came back tired) we're in somewhat better shape than we could
be--however, solving this issue appears to require doing some things
differently than I had initially hoped for, and it's going to require
adding some new functionality to _many_ of the init.d scripts.  I've
just about got this all solved, but I want to see if there are any fresh
ideas to this end before I publish my solutions because someone just
might come up with something unique and useful.

Mind you, what folks should be thinking about is a generic method (i.e.,
a best practice) for implementing firewalling rulesets, not a list of
specific firewall rules that people should use.

(hint: firewalling rules that won't match are a waste of CPU cycles)

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