Dagmar d'Surreal dagmar.wants at
Mon Apr 12 20:16:40 PDT 2004

On Fri, 2004-04-09 at 22:58, Robert Connolly wrote:
> On April 10, 2004 01:24 am, Kendrick wrote:
> > Robert Connolly wrote:
> > >Updated again :)
> > >
> >
> > just a question how will things from blfs be addressed? hints or
> > somthing  ie how to properly secure a mailserver with av/spamassasn
> > etc?  and/or the ideas behind what needs secureing on a mail server may
> > also go with apache and the sql server.  I know there atleast was a bad
> > bug in mod_ssl?  that allowed root duno if it affects v2 or any thing of
> > that nature but  due to that bug being in 1.3? i mention it for that
> > reason?  I was cerous since it is probably beyond the hlfs book will it
> > be addressed some how or left totaly to the user to find.
> There are plans to have a blfs section part of the hlfs book. Mail service 
> could use its own subdirectory since it has so many ways of being used. I can 
> think of a million ways of going nuts with securing services, and how they 
> relate to eachother. Scenarios would need to be written I suppose.

That's almost a certainty.  I never found a really decent way of
explaining hardening without just showing someone the most restrictive
way of configuring things for specific tasks.

> The blfs 
> packages are just as important as the core, they're also the most likely 
> sources of security holes. So we don't want to leave everyone to figure it 
> out on their own. Do you have a suggestion for a server scenario? I think an 
> ipnat serving apache and dhcpd would be a good start... but it would also 
> need sshd, so maybe thats a better start. But before adding sshd I wanted to 
> review the pam setup.. but I have some other stuff I wanted to review before 
> that. There was also talk about modifying the boot scripts for iptables to 
> come up before the interfaces do, and I'd like to add frandom/erandom to the 
> make_dev script, which isn't ready yet. :\

I've got a much better solution now, which for reasons I'm probably
going to blame on temporary insanity later, involves an API of bash
functions so that the directives to open ports for network services can
be embedded in the init scripts abstractly.  Whoever is actually still
using ipchains or bpf can deal with writing those scripts... I was going
to punt the entire iptables schlamiel onto the list last week and wound
up making a last-minute change to syntax to try to do some things even
more intelligently and am still picking up the broken pieces.

If I have any will to live after rearranging the functions again, I'll
try to get chain support added, but I'm not making any promises.  In any
case, I am _very_ sure now that the most correct way to handle in-kernel
firewall support is going to be by adding this stuff to the init

If anyone has any objection to any of the following, speak up now:

 - In the absence of an EXTRANET_IF setting in /etc/sysconfig/network it
will be assumed the interface with the default route points at the

 - In the absence of an INTRANET_NET setting in /etc/sysconfig/network
it will be assumed that the _only_ network that should be valid for the
internal interface will be of that netblock.

 - Destination addresses on incoming rules are going to have to be
rather loose at first until some stuff settles down with the way
interfaces are configured.  There's a very ugly problem still lurking
with this, particuarly where DHCP-managed interfaces are concerned.

 - Folks will still have two options... The smart one of not messing
with firewalling and letting the init scripts handle the work (the
changes I'm putting in will make firewalling pretty much _mandatory_),
and the stubborn one of writing their own monolithic script by hand (or
by using fwbuilder which doesn't completely suck), which will silently
neuter any and all of the built-in stuff.

 - No, there will be no custom chains created by any of this for now,
partly because it breaks the purpose of the API (and makes removing
rules not so easy anymore).
The email address above is phony because my penis is already large enough, kthx. 
              AIM: evilDagmar  Jabber: evilDagmar at

More information about the hlfs-dev mailing list