Re: LFS Paper on Secure Servers

Bob Morgan wrote:

>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.)
>  
>
Seems reasonable.  Someone can easily substitute one program for another 
in the paper.  For an LFSer, no problem.  If someone is building for the 
first time, I don't recommend many deviations.

>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.
>
I did discuss that.

>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.  
>
Hmm.  Like what?  The only thing servers need is to be able to access 
the HW.  The options for iptables should always be enabled.

>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.  
>
That is an interesting idea.

>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).
>  
>
I had thought of that.  The problem with that is that the klogd needs to 
be able to read the System Map.  I don't know if there is a way to have 
it read from another location or not.

>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.
>  
>

I look forward to hearing your experiences.

>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).
>  
>
Going back and discussing old software is beyond the scope of the 
paper.  That kind of thing is documented at the CERT.

>6.  I also have experimented with ipsec-tunnel, which is an encrypted
>ip/ip tunnel 
>
Well beyond the scope of my paper.  Remember that the first step is 
analysis.  I gave one example of a DNS server.  There is no reason I can 
think of for a DNS server to be on a VPN. 

>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). 
>

You can use tar and pass it a file with a list of files/directories to 
exclude.  Then you can backup a live system.
I've replicated several systems that way, although I used Knoppix 
instead of tomsrtbt for partitioning and copying the files. 

>Again, thanks for the fine looking paper.
>

Thanks for the discussion.

  -- Bruce


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