netfilter firewalling problems and solutions

Dagmar d'Surreal dagmar.wants at nospam.com
Thu Feb 19 19:49:52 PST 2004


On Thu, 2004-02-19 at 19:05, Archaic wrote:
> On Thu, Feb 19, 2004 at 06:32:21PM -0600, Dagmar d'Surreal wrote:
> > 
> > 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 don't disagree. I just see it as more gray than black and white. Some
> people will want a compiler on their machine at all times. This book
> shouldn't cater to just the guy admining dozens of boxes (of course it
> shouldn't ignore that guy, either).

For what I have in mind as preamble to design strategies, leaving out
the compiler on a production host will seem an obvious solution.  So
long as we don't put things into a state where a compiler is required in
the filesystem for the machine to function (heh) it shouldn't require
more than a footnote later in the technical sections.

> > 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.
> 
> Yeah, Robert was hoping for just such a thing as well so nothing (in the
> initial building of the system) ever gets overwritten byu another
> package and for zero fragmentation. It would obviously be a lot easier
> if everything recognized DESTDIR...

There are incredibly magical things waiting for he who learns about
union mounts.  :)

> > 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.
> 
> I didn't intend for a mirror image of the book, but it became rather
> necessary the more Robert built the toolchain. We just have to go
> through a "chap5" in order to produce the desired effect. Sure, it would
> be nice to avoid that and just start with a chap6 with LFS assumed as
> the host (original goal) but it didn't hold up in reality. So, no matter
> what little fancy methods we throw in, we're still basically building
> LFS with a bunch of patches and some modified commands. The real
> difference isn't that, anyway, but rather the extensive education on
> particular security-related topics. Nevertheless, I will talk to Gerard
> and get his reaction to it. I never intended to (and still don't)
> compete with LFS. It's merely an extension. We go beyond LFS, just like
> BLFS, just with many of same packages. And this project is still run
> under the permission and services of lfs.org.

Okay, so it's the alpha-state of the book that's giving this impression
then.  *whew*

> 
> > (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.)
> 
> I don't see that as necessary, nor would I consider it different if all
> else was the same. If it is indeed treading on toes, this change would
> only be a facade to the fact that it still was treading on those toes.
> 
> > 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.)
> 
> Might as well write it as if it was going in the book, because it may
> very well. This won't be a small book if peoples' visions for it are
> fulfilled. Basic admin practices are intended to be taught here. We're
> trying to teach and give a well rounded (if somewhat simplistic)
> education on which people can later extend with more specific reading.
> I.E. we should look to be a good 'foundation' of starting knowledge that
> people new to this venture can grasp enough to get basic ideas.

Hey, so long as we're addressing specific problems and weaknesses, we
can go a looooong way with this IMHO.  As to the style of writing I use,
well... it wouldn't be the first time something I've written in 20
minutes has become a canonical text.

> > 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.
> 
> Good stuff, Dag. All your work is greatly appreciated. I'm trying to put
> together the xml pieces now, though there is some uncertainty about the
> newxml (which is what I was trying to write). If things keep going this
> quickly, I'll just dump the newxml stuff and port the lfsxml over to our
> needs.

I'm big on being able to _reproduce_ results, and HLFS will probably
look a lot better than my growing stack of spiral-ringed notebooks. 
It's no major bother for me to publish my dev work because at the moment
I'm banging on two new service firewalls here at home, one of which is
going back to my parent's(*) place once I've gotten it stabilized. 

I eagerly look forward to the day when I may again divvy my entire hard
drive between just two OS installations.

(* ...probably my biggest challenge ever.  Parents can complain and
whine more effectively than mere customers could dream of.  ;)  )
-- 
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