LFS Paper on Secure Servers
bdubbs at swbell.net
Tue May 4 21:48:50 PDT 2004
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
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
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.
More information about the lfs-security