Endpoint Protection

 View Only

FOCUS on Linux: Installing Linux 

Mar 31, 2000 02:00 AM

by Peter Merrick

Introduction

A large number of organisations and individuals are utilising Linux servers in their production environments (especially as Internetwork servers). The problem remains however, that Linux, when installed "straight out of the box" is relatively insecure. This is supported by the relatively large number of Linux hosted web sites that are being defaced (for example, see http://www.attrition.org/mirror/attrition/). To overcome these security problems, a multiple staged approach to securing Linux needs to be undertaken.

These steps include:

  • Secure initial installation of Linux;
  • Performing post installation security measures;
  • Implementing an appropriate auditing and logging regime; and
  • Implementing an appropriate ongoing security management program.

This article will discuss the first two steps in securing a Linux server. The second two steps will be discussed in a follow up article.

When the decision has been made to use Linux, one of the first questions that needs to be dealt with is what is the purpose of the device. The answer to this question is very important as it will help determine which steps are needed to secure the box. In particular, the answer to this can be used to develop an deployment plan which will outline which services need to be installed, what users need access to the machine, how the users will access the machine (eg console, SSH session, telnet session etc), and network details.

So that consistency can be maintained, this article is a step by step guide to securing a Redhat Linux Server (version 6.1) running Apache HTTP Server Version 1.3.11. The principles utilised in this example should apply to most Linux distributions in most deployment examples. I chose this installation example as it is a very common scenario out in the real world and it utilises an application that is well known for its strong application security.

The test device that this is being installed on is a Compaq ProLiant 1850 R. This device has 256 Mbs of Ram and a 4.2 Gb hard disk drive. While it is not overly powerful, it still runs nice and fast, and is an ideal server for this type of deployment.

Initial Installation

Securing a Linux system obviously needs to start at the beginning: the installation. This may sound trivial, but it is something that is often overlooked by many administrators. To prepare for installation, a number of issues need to first be considered.

* DO NOT CONNECT TO THE NETWORK

Firstly, it is very important that throughout the installation the Linux box is NOT connected to the Internet or another untrusted network. In many instances systems have been hacked within a short period of being connected to an untrusted network. The best way to achieve this is to simply leave the ethernet cable unplugged. Connectivity to the Internet should only occur after the system has been fully secured. To perform an installation like this requires that any software packages be installed via CD or other removable media.

* INSTALLATION MEDIA

Secondly, it is important to determine what type of media you are going to install Linux from. There are many installation methods available, including FTP, HTTP, NFS, CD-ROM, SAMBA, HDD etc. Many of these install methods require network connectivity in order to perform. Because step 1 requires a stand alone PC, we will presume that the install media selected is CD-ROM. As well as the obvious security benefits, CD-ROM is also beneficial as it is a quick and easy method of installing Linux. CD distributions are also easily available (eg see http://www.redhat.com/ or http://www.cdrom.com/). One word of caution: If you get the Linux distribution from a non-trusted location, make sure to verify the source code before you begin the installation. After you install the CD, the installation process begins.

* INITIAL SELECTIONS (LANGUAGE, KEYBOARD, MOUSE)

The first three screens that require selections are language selection, keyboard configuration and mouse configuration. I will not delve into details here as these selections have no security relevance. Needless to say, your selections should reflect your hardware. If you are unsure about these stages, I suggest reading the Installation HOWTO or buying an Installing Linux book (of which, many titles are available at http://www.amazon.com/).

* INSTALLATION TYPE - CUSTOM

After these selections the real install begins. Firstly, you are required to choose the Install type. Here, your best selection is "custom". This selection is more appropriate than the others as it gives you more control and flexibility over the installation options, thereby allowing you to choose the more secure options.

* DISK PARTITIONING AND FORMATTING

You are then required to partition your hard disk. From a security perspective, partitioning is quite an important step that is often overlooked by many administrators. Generally, it is best to make the root drive (/) as large as possible. However, several additional partitions are needed. In particular, it is necessary to create separate partitions for /var and swap. By creating a separate partition for /var you are creating a place where all logs and emails will go. This can then prevent these log and email files from quickly filling (and thus, possibly crashing) the root partition. Qmail will also reside under /var (/var/qmail to be precise). Swap space is roughly twice the size of the RAM in the system. I will also create an /export/home partition where Apache will reside.

On the test server I am building, the sizes of these partitions are (on a 4.2Gb disk):

 /  =  700 Mb; /var  =  1.5 Gb; swap  =  500Mb; and /export/home  = 1.5Gb. 

After the partitions have been set they will need to be formatted. It is always wise to check for bad blocks during formatting as it is extremely inconvenient to discover your disk is faulty after you have implemented it in your production environment.

* INSTALLING LILO

Next you are required to set your LILO (the LInux LOader) configuration. LILO is a boot system loader which allows a user to select an image to boot when the machine is initially turned on. LILO can also be used to pass further parameters to the command line. It is recommended that you do not install LILO unless you have a specific need. In the case of a dedicated production web server there is no need, so it has not been installed. If you decide you do need LILO, it does require securing. However, this has to be done post installation and has therefore been discussed below in chapter 4. It is also recommended that you take the opportunity to create a bootdisk. Taking this opportunity can certainly save you a lot of bother later on.

* NETWORK CONFIGURATION

Then it is necessary to set the network configuration. Because you do not have network connectivity as yet (remember, the ethernet cable should be unplugged!), it is best to leave this blank. That is, do not add any network details. Adding network details will be one of the last steps you perform before you connect your server to the Internet. Configuring your network details will be outlined in Chapter 4.

* USER ACCOUNT CONFIGURATION

After the time zone has been chosen you are required to configure any accounts. As this machine is a dedicated web/email server, I will create only one user. Therefore, it is necessary to create a root password and create one additional account. Here, it would be wise to create a root password that conforms with good password practice. That is, create a password with a minimum of eight characters and also use a mixture of alpha, numeric and special characters. This will mean that the possibility of a successful brute force attack is reduced considerably. The reason I am creating an additional user account is that generally I use the root account as little as possible. If I am going to log in to check that everything is running okay I will log in with a non root account. As such, I have also created a user account called "work" with a strong password. When I log in with this account if I need to perform root level tasks, I will use the 'sudo' command to perform root tasks.

* AUTHENTICATION CONFIGURATION

Authentication configuration comes next. Good security practice suggests enabling both MD5 and shadow passwords. MD5 enables long passwords to be used whilst shadow passwords prevents all users from reading the encrypted passwords (ie, the shadow password file is only readable by root). If you are in a NIS (Network Information Service) environment, you are required to set the NIS domain and broadcast server here. NIS is a distributed database system that lets many computers share password files, group files, and other critical files over a network. This distributed nature means that NIS is not an ideal configuration from a security perspective, especially in an Internetwork environment. As the test server is a web server, from a security perspective, I would not even consider including it as part of a NIS system.

* PACKAGE SELECTION AND THE INSTALL

Next comes the important part: the package selection. One of the principles of sound security is not to install software you do not intend to use. This definitely applies to this phase. The aim here is to only select those packages which are essential to the functionality of the machine. The less software that resides on the machine means the less potential security vulnerabilities that you have (ie less packages = more secure). The packages you are required to install depend very much on the purpose of the machine. For example, there is no need for a dedicated web server to have X-Windows or even a compiler installed, whilst a users desktop workstation probably does have a requirement to have X-Windows installed.

As such, it is recommended to "select packages individually". This requires going through each individual package and determining whether or not there is a requirement to have it installed. Generally, package selection is a judgement call. When doing this, keep in mind that it is easy to add any "forgotten" packages after the install.

One note here. Generally, a web server etc would not require a compiler. However, because we need to install further applications (the latest version of Apache) we obviously need a compiler. We will remove the compiler later in the process.

Hopefully after you have selected your packages you have no unresolved dependencies. If not, it is time for the operating system to be written to your hard disk. Hopefully, with minimal packages being installed and with a relatively speedy system, this should occur quickly.

Adding and securing the Applications

* GETTING AND INSTALLING PATCHES

After the base install has been completed and the machine has been rebooted, it is then necessary to apply any necessary patches and also add any necessary application software.

As this machine does not yet have network connectivity, it is necessary to download these files via another PC. One of the more secure measures to do this is to download the software to a PC and then burn the necessary software to a CD-ROM. This CD-ROM can then be used to add the software to the half built server.

Firstly, it is necessary to download and apply any patches. For Redhat 6.1, these patches can be found at http://www.redhat.com/errata. These patches come in three different forms, including: security advisories, bug fixes and package updates. I would certainly recommend that you install the necessary patches from each of these categories. These patches are implemented by package, therefore you only need to implement those patches that have relevance for your system. As such, it is necessary to go through each one and use judgement to determine whether or not it is needed.

Implementing the patches is an easy process. Once you have downloaded the relevant patches and burnt them to cd-rom, it is then just an easy process of applying the following syntax at the command line:

 rpm - Uvh filename.rpm 

Also remember, to check back at the Redhat site regularly for new patches.

* GETTING AND INSTALLING APPLICATIONS

After the patches have been applied, it is then necessary to install relevant applications. It is always a wise idea to check with the application vendor to make sure you have the most recent version of the application. In this instance, we are installing Apache (available from http://www.apache.org). A visit to the relevant web sites indicates the most recent versions for Linux is Apache Web Server 1.3.11.

After downloading this application and burning it to CD-ROM it is then necessary to install it on the test server.

Installing Apache is a relatively simple process. Again, without going into details, all necessary details are available at http://www.apache.org/docs/install.html. As mentioned in chapter 2, apache will be installed into /export/home/apache. I will not detail the exact steps on installing an Apache server as they are covered appropriately elsewhere. A stock standard install of Apache still needs a number of steps to be completed before it can be considered secure. However, those steps are beyond the scope of this article and will be dealt with appropriately in an upcoming article.

*BASTILLE LINUX

It is also apt here to consider installing Bastille-Linux (http://www.bastille-linux.org). From the Bastille Linux home page: "The Bastille Hardening script attempts to provide the most secure, yet functional, Redhat 6.0 system available." Bastille Linux is a script that attempts to appropriately harden a Redhat 6.0 system. It acts fairly similar to tools available for other operating systems, such as Titan for Sun Solaris. Presently, Bastille-Linux is only available (and has been thoroughly tested) for Redhat 6.0. However, it should shortly be availble for other versions of Redhat and hopefully other distributions of Linux.

If it is available for the version of Linux you are running, it would be wise to download and install this script. Just remember that if you do use Bastille-Linux, it should be performed immediately after Redhat has been installed (ie even before patches are added).

Post Installation

Once Redhat has been loaded and rebooted, it is then possible to go about adding the specific applications (in this case Apache Web Server) and hardening the Redhat installation. After the applications have been loaded, it is necessary to "harden" the installation. "Hardening" consists of a number of phases, including amongst others: eliminating unnecessary services and ensuring filesystem security is appropriate etc.

* SECURING SERVICES

A linux installation by default has a large number of useful services. Unfortunately, many of these services are the main method by which your system can be attacked. As such, it is necessary to remove any unneeded services. The first place to check for services is the /etc/inetd.conf file. This configuration file for the inetd meta-daemon. This file specifies the services that the /usr/sbin/inetd meta-dameon will listen for.

It is thus necessary to comment out (ie disable) any uneeded service within /etc/inetd.conf . This is done by adding a hash (#) before each unneeded service. The list of remaining services in inetd.conf can then be checked by issuing the following command from the command prompt:

 grep -v "^#" /etc/inetd.conf 

After this process, there were no remaining services on my server.

It is then necessary to check the .rc scripts for unnecessary services. Under RedHat, /etc/rc.d is broken into numerous subdirectories: init.d and rc0.d through rc6.d. The 0-6 corresponds to the runlevel specified in /etc/inittab. This will generally be a runlevel of 3 providing you do not boot straight to an X-Windows interface (on my web server, X-Windows is not even installed. The .rc scripts are used to start services from the initialisation process. To stop unneccesary services from starting it is necessary to replace the capital S that the script name begins with with a small s. Redhat also has a utility for stopping these scripts. This can be started by running:

 /usr/sbin/setup.  

If the script has a capital K, it means it has already been stopped. In this installation, after I had stopped any unneeded startup scripts, the only rc.d scripts that were running were: S10network, S20random, S40crond, S75keytable, S85httpd, and S99local. Out of interest, you can then determine how many services are running by issuing the command:

 ps aux | wc -l  

When performing this step, just remember that if you don't understand what the script does, investigate it further, then decide what action to take. Just remember, the fewer startup scripts running, from a security perspective, the better off you are.

* SECURING LILO<

Another important security measure that needs to be dealt with is the LInux LOader (LILO). In this instance, we did not install LILO. However, LILO is a common part of most Linux installations, so we will touch on it briefly. LILO is a boot system loader which allows a user to select an image to boot when the machine is initially turned on. LILO can also be used to pass further paramaters to the command line.

LILO is usually installed and then forgotten about. However, this is a risk as a malicious user can pass various paramaters to LILO which can then bypass common security measures. An example of this is if the user passes the following paramaters to the LILO prompt:

 linux init=/bin/sh 

These parameters then allow the user to boot straight to linux and gives the user root privileges (albeit it in read only mode) without requiring a password. By allowing dangerous parameters to be passed, some level of control needs to be implemented. This control can be added in the /etc/lilo.conf file. Ideally, the /etc/lilo.conf file should look similar to the following:

 	Boot=/dev/had       map=/boot/map       install=/boot/boot.b       Prompt 	timeout=10 	 	image=/boot/vmlinuz-2.2.12-20            label=linux            initrd=/boot/initrd            read-only            root=/dev/hda1            restricted 	    password=PASSWORD 

This example sets a timeout of 1 second. If no command is received in 1 second, it will continue to boot the default configuration. The other important difference in this file is that the user is required to enter a password if any command is passed. It is important to note that the password is stored in plain text in this file. As such, it is necessary to change the mode to 640. This will allow only root to read/write the file and will remove any permissions for other system users. This can be done by passing the following command:

 chmod 640 /etc/lilo.conf 

* FILE PERMISSIONS

The Linux filesystem is very similar to that utilised by other UNIX systems. Within this filesystem each file has an appropriate mode.

Each file has file permissions which shows what the file is and what kind of file access (eg read, write, execute) is granted to various users. As with most UNIX systems, these file and directory permissions can create problems and can be taken advantage of to exploit the system. As such, it is necessary to lock down file and directory permissions so they can only be utilised by users who require that level of access.

An example of this is the /bin/mount file. This file has standard permissions of -rwsr-xr-x, meaning that a general user can execute this file. This file is used to mount a file system to the file tree. From a security perspective a general user should not be required to do this. As such, many of these files are open to abuse on a system. To counteract this, file and directory permissions need to be changed to reflect their required usage.

Filesystem security goes well beyond the scope of this article and as such, will be dealt with in a future article. Needless to say, a good starting point is to go through critical directories (eg /etc, /bin, /usr/sbin, /usr/bin etc) and consider whether files and directories have the appropriate permissions. If they do not, alter them to appropriate permissions.

* SECURING AND MANAGING SUID ROOT BINARIES

Within a Linux system, it is very important for the administrator to have control over SUID root programs as by default, Linux installs many programs as SUID root. SUID root (Set User ID root) programs are those programs that are allowed to do functions under the permissions of root, not of the user (the way normal programs operate). The problem with SUID root programs is that they often get executed with the wrong permissions meaning that security problems can often arise.

To counteract any potential security problems, it is necessary for the administrator to know all the SUID files on the system.

To determine a list of SUID files, the following command can be issued:

 find / -type f -perm +6000 -exec ls -l {} \; > suidfiles.txt 

This will output the list of SUID programs to a file called suidfiles.txt. From here, you can then analyse these files individually and determine whether or not they need to be SUID or whether they could even possibly be removed. If the program is one that is generally not required by a user, it can be unsuided by removing the SUID bit. This is performed by issuing the following command:

 chmod -s programname 

It is also recommended that you regularly check your list of SUID files. If you discover new SUID files on your system, it is possible that you have been compromised and a backdoor has been created.

* OTHER NECESSARY STEPS

There are a number of additional steps that should be taken to secure your Linux box.

Firstly, it is necessary to secure your system account structure. The file /etc/passwd contains accounts for many system utilities. Many of these you are unlikely to need (eg gopher, news, mail, ftp etc). As such, it is suggested that you totally remove any unneeded system accounts from your password file. Whilst on the subject of password security, it would be wise to double check that shadow passwords have been implemented. This can be done by running the commands "pwconv" and "grpconv".

At this stage we only want root to log in from the console. As such, it is wise to ensure the file /etc/securetty only contains ttyx locations, that is, from the localhost only. You may also want to utilise /etc/security/access.conf to implement control over what users can login from where. On the system I built, root logins were restricted to the console and general administration is performed via an SSH session (which is considered in the next article) from a trusted workstation. If you have a large number of users, you may also wish to utilise /etc/security/limits.conf and /etc/security/time.conf to implement further controls over user usage of the system.

* CONFIGURING THE NETWORK

After these steps have been performed, it is necessary to configure the network. For this, you will need all necessary network details, such as IP address, hostname, gateway, DNS server details etc.

* PLUG IN THE ETHERNET CARD

Within Linux, there is a nice utility (netconfig) that simplifies this process. It is just simply a matter of adding the necessary details and rebooting. Don't forget to finally plug your ethernet card back in.

When the machine has rebooted, you will finally be up and running. Just remember that at this stage we still have the compiler installed as this will be required for setting up additional tools (eg logging tools, auditing tools etc) in the next article in the series. We will look at removing this compiler after those tools have been implemented.

Conclusion

This article has provided a basic step by step guide to securely installing a Linux Web Server. It has hopefully demonstrated that minimising software; eliminating unneeded services and ensuring are all part of the securifying process.

However, the initial security measures are NOT going to guarantee that your box remains secure and does not easily get hacked. To ensure ongoing security requires an ongoing security management framework. This framework should provide appropriate auditing and logging (and continual review of these logs); use of host based security tools (eg installing and using tripwire etc); use of secure sessions; and many more.

In the next article, we will look at designing and implementing this ongoing security management framework.


Relevant Links

Defaced Sites
Attrition.org
attrition.org

Distributions
CDROM.COM
cdrom.com

Redhat
redhat

EverythingLinux
EverythingLinux

Patches
Redhat Patches
Redhat

Applications
Apache
apache.org

Apache Installation
apache.org

Bastille Linux
Bastille Linux

This article originally appeared on SecurityFocus.com -- reproduction in whole or in part is not allowed without expressed written consent.

Statistics
0 Favorited
6 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Related Entries and Links

No Related Resource entered.