Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Linux Administrator's Security Guide
Prev Home Next

Linux Installation

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.

Contents

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.

Linux Administrator's Security Guide
Prev Home Next

 
 
  Copyright Kurt Seifried 2001 [email protected]. Published under the terms of the Open Content License Design by Interspire