Re: LFS Paper on Secure Servers

Bruce Dubbs writes:
 > EC wrote:
 > 
 > >Great job. Very interesting and useful. I will probably test it in a few
 > >weeks for my own environement. I no security expert, though.
 > >  
 > >
 > Thanks for the feedback.
 > 
 > >I do have small comments/questions/suggestions..
 > >1) The use of sendmail as an MTA .. since it is secure oriented, isn't is
 > >more interesting to put postfix or qmail instead ?
 > >
 > 
 > Possibly.  I'm more familiar with sendmail and I wanted to use the same 
 > MTA as our other systems. 
 > 
 > >2) Going to nALFS for the build will be great. I am newbie to LFS, but have
 > >already built dozens of LFS with it. It works great, profiles are quick to
 > >write, easy to maintain/change.
 > >
 > 
 > I'm not sure that nALFS is appropriate for this because I make several 
 > changes to the 'stock' LFS.  It may be possible to do that and go back 
 > and modify the nALFS build.  I'll look at that when I get the chance.
 > 
 > >3) isn't it interesting to use grsecurity in such environement ? Again, I'm
 > >no expert, but building such an security oriented system with grsecurity and
 > >a well desgined ACL seems useful.
 > >
 > 
 > This is a possibility too.  However the paper was written from a 
 > relatively mainstream perspective.  As I said in the risk analysis, not 
 > every possible security component is needed for the threat.  Also, since 
 > it is a dedicated system with no normal users, ACLs seems to be overkill 
 > for this specific server.  They may be appropriate for other types of 
 > servers.
 > 
 > You bring up some great points for me to consider.  Thanks again.
 > 
 >   -- Bruce

Bruce, others,

This looks like a fantastic paper, and it is here just in the nick of
time for what I am doing.  I got into LFS for the purpose of building
the latest model firewall I could think of.  I like the LFS philosophy
of just building what is necessary, and as I observed on the base lfs
mail list, it was a great education tool as well.  You don't get that
from a commercial distro.  They give you too many programs that they
want to install, too many obscure install, and worse, startup scripts,
too many open ports, etc.  Some of the install scripts don't ever get
turned off either (I had my mail config blown away by a dormant install
script that put it back to default when I went to load some minor package,
and that is the only time in a year my mailserver has failed to receive
my mail/spam).  I liked the simple appearance of the scripts that I saw go by
just now.

My comments, based on just a very quick scan of the paper, and with
the plan in my mind for a firewall instead of a nameserver, are:

1.  I have managed to avoid sendmail like the plague, and have always
run postfix here, and am pleased with it.  (In other words, one
more vote for postfix over sendmail.)

2.  I just found that kernel 2.4.26 was released, and compiled it just
this morning (haven't tested it yet), so this next observation is
fresh on the top of my head:  I didn't see anything in the paper
about kernel versions or options.  The reason I was compiling the
kernel was to avoid some of the last few kernel compromises I was reading
about (CERT I think), so I was wanting to get to at least 2.4.24 or 25.
Also, there is always a process of deciding what modules to put
in or deliberately leave out for this or that application, and of
course diverse applications like firewalls, nameservers, fileservers
and webservers will want different options for both security and
performance reasons.  I have also been around discussions of the
relative merit of running a monolithic kernel as opposed to a
module-enabled kernel for a firewall, just to prevent an attacker
from adding something extra to the kernel as a module.  I have also
been around discussions of firewalls based on readonly booted systems
such as floppy or cdrom based systems and the like where the code cannot
be corrupted by an attacker, and the system can be cleaned up instantly
just by rebooting.  This attempt will be modular, and primarily
to facilitate some multiple diverse netcard drivers where the image
will probably be installed on firewalls on several different lans.

For reasons related to overflowing partitions with entries during
an attack, I have been planning for /var/log to be on a separate
partition as one more step to prevent a DoS attack from killing
more important parts of the system if the attack succeeds in filling
up the disk with log entries.  In a somewhat related thought, having
a separate /boot partition, and commenting it out in /etc/fstab can
help a tiny bit to keep the kernel contents away from an attacker
(one can always mount it manually long enough to install a replacement
kernel if need be - also related to the issue of monolithic vs modular).

3.  I saw (in a later post on this thread) a comment about
tripwire vs. aide, and also about grsecurity, and I guess I need
to find out more about these other two packages besides tripwire,
but otherwise nothing more to comment about these items here other
than I will want to check them out along the way.  Thanks for the tip.

4.  I had built lfs 5.0 and am just start planning to add the various
things to it under blfs when your paper came along.  I was going
to add iptables, openssh/ssl, pam, and the like to it, and this
paper arrives at the perfect time to make use of it.  Maybe a
nameserver will happen later on.  While I already have the base
lfs image up and running, I will be in a position to make use of
a lot of what you have in the paper, and if I run into anything
I will let you know about it, either questions or observations.
Mind you, I am not a security expert either, but I have been
accumulating a mental list of what to stay away from for years.

5.  While it might be a repeat of what is on cert and other security
related sites, this could be a good place for something like a blacklist
of what versions of common items to stay away from.  For instance
there is a bad version of apache that had an exploit awhile back,
and what kernel/iptables versions had holes in the code, and the like.
I don't remember them all off the top of my head (hence the problem).

6.  I also have experimented with ipsec-tunnel, which is an encrypted
ip/ip tunnel (something like ipsec-tunnel and ringstrom.mine.nu to
search on) and it looks on the surface like a swell tunnel, for
applications that need that sort of thing to connect lans together
over the internet.  For my situation I will probably be adding
some of these to the mix, as some of the connectivity may be with
802.11 radio gear, and wep is of course compromised from the
very beginning.

7.  One other thing that I have been doing around here lately, and that
I always have been concerned about, is easily making reload images of
systems, either to reload a system identically after some kind
of failure, or to replicate the system onto more boxes.  My rather
simplistic approach is to get it like I want to replicate or
restore it, maybe clean up things like logs and maybe user accounts,
then bring it down and boot it from a floppy.  Tomsrtbt works fine,
and I just mount the whole system under /mnt, and use a pipe of
tar and netcat (or nc on tomsrtbt), and squirt the whole thing
over a network connection to another system with sufficient
disk space where the archive tarball can be written to a disk,
and probably transferred to a CD.  Since the system to be replicated
is inactive, you don't get the things in ram like all of /proc and core
that you would see if the system was running (and of course no
blurry image of the contents of /var as it changes along the
way through the archival).  Then to replicate or restore, one can
actually start with tomsrtbt to partition a system as desired
(remember that /etc/fstab will have to change if the partitioning
isn't identical to the original, although the data will find it's
way correctly - also a way to do a total repartition rearrangement).
Then run the process in reverse, or maybe unpack the tarball from
the CD, or whatever.

I did this exact thing when I got LFS built, just at the point
before configuring grub.  I wrote it to a CD (I also wrote off a
copy of the toolchain to another CD so I could restore back to that),
and configured grub on the target box, that I made a conventional
partition layout of just the target system minus the toolchain,
and booted the target.  I never did bother to directly boot
the finished lfs product on the toolchain host.  I did make
use of the grub bootloader floppy, in addition to tomsrtbt,
but that was all that I needed as I recall to start that target
system from a blank hard disk.

I bring this up in the hope that someone will make a good effort
to write some docs in how to do all of this.  All I have ever seen
is docs about how to configure ONE copy of something, assuming that
it is the only one of those installations one will ever need, or
that it pretends to last forever without needing restoring.  I
would hate to have to get all of my systems up and running like
I want them, and have to start from scratch and rebuild them,
but from reading the available materials, it would appear that
this is all that is documented to be done.

Again, thanks for the fine looking paper.

Bob Morgan

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-security
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page