By Kurt Seifried [email protected]
How you install Linux will have a big impact on how much you will be able
to secure. If you install Linux from an untrusted source you could potentially
end up with an installation that has backdoors or other security issues. If you
install packages you do not need and forget about there is a greater chance that
someone will be able to break in. As well there are security tasks that are best
accomplished during installation, attempting to do them post install can be
troublesome.
Verifying packages and files
Some sources of install packages and files are safer then others. Buying
Linux on CD from a large vendor such as Red Hat at a large store is relatively
safe and the chances of acquiring a trojan'ed CD set is very unlikely.
Installing Linux via ftp from a remote ftp server provides an attacker many
avenues to replace packages with modified versions. The good news is that most
vendors have addressed this problem.
Using public/private key cryptography most vendors have a keypair that they
use to sign packages, you can verify these signatures with the public key. These
public keys can be downloaded online and most vendors include them on their
CD's. A list of vendor key names, ID's, fingerprints and the keys themselves are
available <a href="../vendor-keys/">here</a>.
You first need to download the vendors PGP or GnuPG key, for example Red
Hat’s signing key has the identity of "[email protected]"
and the fingerprint is:
CA20 8686 2BD6 9DFC 65F6 ECC4 2191 80CD DB42 A60E
Generally speaking you can download the vendor keys from their websites, and
many vendors ship the key on their CD’s. To verify a directory full of RPM’s
this simple script will automate the task:
[user@server RPMS]# for a in *.rpm
> do
> rpm -K $a >> ~/sign-log
> done
The file sign-log should consists of lines like:
ElectricFence-2.2.2-5.i386.rpm: md5 gpg OK
ImageMagick-5.2.2-5.i386.rpm: md5 gpg OK
ImageMagick-devel-5.2.2-5.i386.rpm: md5 gpg OK
Inti-0.5preview-1.i386.rpm: md5 gpg OK
Installation Media
You cannot secure your installation very well if an attacker manages to
compromise the system before you even install it. While it is rare for an
attacker to try and compromise installation media it is certainly possible. The
first step is to verify the packages and installation files on your installation
media, this can be done by checking GnuPG signatures on the RPM's/etc, and the
other files, although finding the signatures of the other files or MD5 sums is
relatively tricky it is possible. The next step is to secure the system
providing the files and the path between this system and the machine you are
installing the software on. This is very easy for example with a CD-ROM, and
much more tricky if doing an FTP or NFS install over the Internet from a system
you do not control. It is strongly suggested you use a server that you control
to host installation files.
CD's
CD's are typically the easiest to install from, and relatively secure. If you
purchase CD's from the vendor it is unlikely that they have been somehow
compromised, all you do is simply boot from them and install the software. You
can leave the machine offline for the installation typically, and if you burn
the updates onto a CD you can easily update the system, again without needing to
bring it online. It is strongly recommended to keep a set of vendor CD's around
so that you can cleanly install critical systems as needed.
Harddrive
Installing from a local harddrive is also a relatively secure way of
installing Linux. Simply partition the drive first (if you are installing Linux
to it) and then copy the files onto a prepared partition, boot the system and
away you go. Installing from the harddrive provides many of the benefits of
installing from CD without the need to burn CD's. As well you can easily copy
all the updates to the drive and then install them on the first reboot and bring
the system completely up to date. Additionally with the increased availability
of external harddrives utilizing parallel, FireWire and USB ports it is
relatively easy to plug a harddrive into a system without needing to take it
apart (assuming of course the installation floppy disk supports it).
Network (FTP / NFS)
These two methods are very convenient, all you need is a single floppy disk
(typically) and a server with all the files. Simply mirror the directory
structure you need (typically something like /pub/redhat/7.1/en/i386) and then
make it accessible via ftp (anonymous or username/password required) or via NFS
(to the IP or subnet you use for installations). The files only need to be
readable, there is absolutely no need for writing to them and in fact you are
probably better off removing the write bit for all to prevent "accidents". These
network methods can also be combined with the automated installations such as
KickStart, or you can do you own custom installation of sorts (by removing
packages you do not want for example). If you choose to do network installs it
is critical that the NFS/FTP server remains secure, to this end I highly
recommend using a protected subnet, not attached to your main network if
possible.
Automating installs
Automating installs can relieve tedium and prevent security problems. If you
have to do 100 Linux installs chances are you will make error if you have to do
them each manually. However if you can create an automated installation that is
secured then it is much less likely that you will have problems.
Red Hat Kickstart
Red hat provides a facility for automating installs, which can be very
useful. Simply put you create a text file with various specifications for the
install, and point the Red Hat installer at it, then sit back and let it go.
This is very useful if rolling out multiple machines, or giving users a method
of recovery (assuming their data files are safe). You can get more information
at: https://www.redhat.com/mirrors/LDP/HOWTO/KickStart-HOWTO.html.
The configuration file can also be placed on a tftp server, in a directory named
for the IP address of the client, thus using a dhcp/tftp server you can
completely automate installs for machines if you know the MAC address of the
client machine.
Filesystem layout and structuring
There are a number of common attacks/exploits in Linux (and UNIX) that can be
reduced in risk and significance with a proper directory and partition
structure. One of the most common denial of service attacks is to fill up the
disk space with junk data, this can also happen unintentionally with software
that experiences a problem. This is typically defended against by assigning root
a set percentage of the disk space as reserve (usually 5-10%), so on a 10 gig
disk users would not be able to use the last 500 megs, this would be reserved
for root. This doesn't do you any good however if something running as root,
that generates log files, goes nuts, or is attacked and made to generate massive
log files. The next big attack that takes advantage of disk setup would be /tmp
races, and core dumps, programs that create links or files improperly without
checking to make sure they exist first, especially programs that run as root. An
attacker can then link /tmp/foo to /etc/passwd and potentially add a user
account, wipe the password database out, and so on.
Mounting options can be used to mount a partition read only, not allow
execution of programs, and other useful things. You may encounter difficulties
when using these options however, for example if you mount /usr as read only you
will have significantly more work when upgrading system components, especially
on critical servers (such as e-commerce machines) that need to be up and
running, but also require critical updates. More useful options are "nosuid" (no
setuid or setgid files), "noexec" (no executables) and "nodev" (no device
files).
So with this in mind we have several guidelines:
- Put filesystems that users can write to on separate partitions
- Put filesystems with critical system components/configuration on separate
partitions
- Consider mounting some partitions with system binaries as read-only (this
will make upgrades more difficult however), mounting /bin/, /sbin/ and /etc/
separately however will make booting the system tricky (depending on your
configuration), test this before using it in a production environment.
Some notes on the various flags
noexec, if you mount /tmp noexec for example you can copy a binary in, but it
will not run, however if you execute it using ld-linux.so it will work fine:
[seifried@stench /tmp]$ ./date
bash: ./date: Permission denied
[seifried@stench /tmp]$ /lib/ld-linux.so.2 ./date
Thu Aug 24 21:59:08 MDT 2000
[seifried@stench /tmp]$
| Dir. |
nodev |
noexec |
nosuid |
read-only |
separate |
comments |
| / |
yes |
yes |
yes |
yes |
good idea |
Ideally you should mount / totally restricted and then have
directories like /boot/ separate, this also forces you to configure the
directories properly since any "dangerous" directory (for example /dev/)
will be "broken" (i.e. nodev would severely break /dev/). This is only
recommended if you are going all out. |
| /boot/ |
yes |
yes |
yes |
ok |
good idea |
Critical directory with kernel images, if an attacker
replaces your kernel or deletes it you have a lot of problems. |
| /bin/ |
yes |
no |
no |
ok |
tricky |
Directory with important system binaries, do not mount
noexec or nosuid, your system will not work correctly. Mounting read-only
will prevent trojans, and make updating software significantly more
difficult. |
| /dev/ |
no |
yes |
yes |
no |
yes |
Mounting /dev/ with the nodev option will severely break
your system, as will mounting it read only. /dev/ is usually less then a
few megs, and the ability to write to device files can result in huge
damage, and system compromise. |
| /etc/ |
yes |
yes |
yes |
no |
tricky |
Critical directory with system configuration information,
usually the first target for an attacker. There should be no binaries in
here (although some Unix systems do keep binaries in /etc/, Linux is not
one of them). Mounting it read only will not allow you to change
passwords, or other important settings so is not recommended. |
| /home/ |
yes |
good idea |
yes |
no |
yes |
/home/ is the primary area where users keep their files and
work with them (assuming they can log in), if you provide services like
IMAP this is where their mail folders will be. You should make it a
separate partition since users have a tendency of eating up space rapidly,
as well it will prevent them from making hard links to files and then
using setuid programs that dump core for example and wiping out system
files. Mounting it noexec is probably a good idea, however depending on
the type of work users do it may seriously hamper them, mounting it nosuid
is a good idea and shouldn't really affect users. |
| /lib/ |
yes |
no |
yes |
ok |
good idea |
Most programs will rely on libraries in this directory, if
they are damaged or compromised you will have a hard time cleaning up.
There are executable files in here (.so's, etc.), so setting it noexec
would not be advised, but setting it nosuid is probably wise. |
| /mnt/ |
yes |
good idea |
good idea |
ok |
no need |
/mnt/ is typically used to mount removable devices, such as
/mnt/floppy/ or /mnt/cdrom, as such it rarely contains anything other then
a few directories, making it separate is not a real issue since anything
in it will be mounted as well. |
| /opt/ |
yes |
no |
no |
no |
good idea |
Typically this directory is used for optional packages,
vendor software and the like, oftentimes this stuff needs setuid bits to
work properly (a good reason to separate it since a lot of vendors have
terrible software security). |
| /proc/ |
|
|
|
|
|
/proc/ is a virtual filesystem |
| /root/ |
yes |
no |
no |
no |
good idea |
root's private playground usually, many people use it
instead of /usr/local/ when testing things/etc |
| /sbin/ |
yes |
no |
no |
ok |
tricky |
Directory with other important system binaries, do not
mount noexec or nosuid or you will break your system. Mounting read-only
will prevent trojans, and make updating software significantly more
difficult. |
| /tmp/ |
yes |
yes |
yes |
no |
yes |
Temporary directory for use by users and system, mount read
only will break things, make it separate because many exploits consist of
making hard links in tmp to files, and then having a program misbehave and
destroy/modify the target file maliciously. Binaries, especially setuid
binaries should not be allowed in /tmp/ since any user can modify them
usually. |
| /usr/ |
yes |
no |
no |
ok |
good idea |
This directory is where the majority of software will be
installed, along with source code and other stuff typically, mounting it
separately is a good idea since it tends to contain relatively important
software (especially in /usr/bin and /usr/sbin). Mounting it read only
will prevent an attacker from inserting trojan software, but will make
upgrades significantly harder. I wouldn't bother mounting it read only
unless you also mount /bin/ and /sbin/ read only. |
| /var/ |
yes |
yes |
yes |
no |
yes |
/var/ is used for a lot of things, least of which includes
system logging. This partition should be separate since attackers can
attempt to fill it up by flooding the log files, and other user data is
stored here, such as mail (/var/spool/mail usually). Software that stores
data here includes: Mail servers (Sendmail, Postfix, etc.), INN (Usenet
news), Proxy software like Squid (WWW/FTP proxy), and so on. There should
be no binaries at all here, just log files and data. Setting it noexec may
break programs, Red Hat 7.0 places various binaries used for anonymous ftp
with WuFTPD and arpwatch binaries in /var/ for example. You can place
those files on another partition and symlink the directories to within
/var/. |
Hardening your installation
So you've got a fresh install of Linux (Red Hat, Debian, whatever, please,
please, DO NOT install really old versions and try to upgrade them, it's a
nightmare), but chances are there is a lot of extra software installed, and
packages you might want to upgrade or things you had better upgrade if you don't
want the system compromised in the first 15 seconds of uptime (in the case of
BIND/Sendmail/etc.). Keeping a local copy of the updates directory for your
distributions is a good idea (there is a list of errata for distributions at the
end of this document), and making it available via NFS/ftp or burning it to CD
is generally the quickest way to make it available. As well there are other
items you might want to upgrade, for instance imapd or bind. You will also want
to remove any software you are not using, and/or replace it with more secure
versions (such as replacing RSH with SSH).
Bastille Linux
If you are running Mandrake / Red Hat or a similar Linux you can use the
Bastille Linux hardening script available at: https://www.bastille-linux.org/. It will disable various
servers, install login banners and generally automates many of the tasks a
security administrator will have to do in any event.
Harden SuSE
Harden SuSE is a script specifically for SuSE Linux and available from: https://www.suse.de/~marc/.
Usage can be automated.
Summary
Linux, like most UNIX systems uses a directory structure based off of /,
which directories like /home, /tmp, /usr, and so on. These directories can be
placed on the same partition, or separate partitions, separating them properly
can have security (and performance) benefits. There are also a number of
mounting options that can be used to prevent common problems and attacks.
