netfilter firewalling problems and solutions

Dagmar d'Surreal dagmar.wants at nospam.com
Thu Feb 19 16:32:21 PST 2004


On Thu, 2004-02-19 at 13:33, Archaic wrote:
> On Thu, Feb 19, 2004 at 11:52:03AM -0600, Dagmar d'Surreal wrote:
> > 
> > Being able to back out changes like this practically requires one to
> > adopt a package management system of some sort, and is going to be
> > mentioned explicitly once I get around to explanation of why people
> > should be separating the build process out and onto some other machine. 
> > (In practice, there's also no real need to have an entire compiler suite
> > on one's firewall, unless you want to help script kiddies put together
> > their rootkit.)
> 
> Need is purely a POV situation. I like keeping the compiler on an
> encrypted fs in case I need it, however there is validiaty to package
> management as well. I don't think the book should default to removing
> the compiler or assume any particular package manager. The first is an
> admin policy decision and the latter is an admin preference decision. We
> need to stick with specifics, and where apropo, list more than one
> possibility, if only for an educational boost.

I can tell you from personal experience once you get above five or six
boxes, it becomes increasingly problematic to maintain them by building
packages on the hosts themselves.  I'm not recommending any specific
package manager because anything that can turn a bunch of binaries into
a single file that you can drop into other machines will do the trick
for the purposes of rollbacks.  As to the other point you made...

"...don't think the book should default to removing the compiler..."

Basically, I don't think it's entirely necessary to remove the compiler,
but rather more efficient to never install one when building the
filesystems for production machines.  Someone maintaining more than one
LFS machine will likely find it not particularly difficult to build the
initial development environment, and then use it to create the
production filesystem to copy it to wherever.  From what I saw this
morning of the CVS, we're kind of treading on Gerard's toes a bit in the
current format, and we'd probably be better off taking (in part) the
approach that an HLFS filesystem is being deployed _from_ that to make a
new system.  (You know, like pop another drive or more partitions in,
put the hardened filesystem on those, and then start booting that or
move it into a new chassis.)

So far LFS doesn't really address much of anything in the way of change
management, which becomes important when you've got people who actually
depend on your facilities to get their work done.  Maintenance windows
and service levels tie into that so I'll also begin outlining those as
well in the next several days.  (Not to put into the book, but so that
the people reading and wanting to help will have an idea of what these
entail... I'm very sure we've got a lot of nod-and-smile going on when
people say things like RBAC and MAC.)

On another front, I'm about two days away from being really sure of the
netfilter stuff I've put together, BTW.  I came very close to creating a
hooks script for dhclient to do some of the work until I went back and
re-read the RFC on DHCP and spotted some reasons why I shouldn't.  I've
mainly got disaster and minor break tests (netfilter suddenly missing,
etc) to do to be sure I can recommend both sane and elegant solutions to
tying things together.

...and wow do I need to get another 4x8 whiteboard.  I have been severly
missing having one.
-- 
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