Securing Linux, Part 2: Planning the installation

Lay the groundwork for a secure setup

Mario Eberlein (m_eberlein@de.ibm.com), IT Architect, IBM

Mario Eberlein is an IT Architect for on demand business applications. He joined IBM in October 1998 and is now working in customer projects within IBM Global Services. Mario holds a Bachelor of Science degree, is currently studying for his Master of Business Administration degree, and has seven years of Linux experience. He is leader of the IBM Linux Security Workgroup in the EMEA Central Region. Mario can be reached at m_eberlein@de.ibm.com.

Rene Auberger (rene.auberger@de.ibm.com), Software IT Architect, IBM

Rene Auberger is working as a Software IT Architect for the IBM Software Group. He is primarily working with customers from the public sector in Germany, a clientele that is strongly interested in Linux. In 1996 Rene started working with Linux and has used it ever since in various flavors and for different purposes. He is the technical leader of the Linux specialty within the Software Group in Germany, Austria, and Switzerland and can be reached at rene.auberger@de.ibm.com.

Wolfram Richter (wrichter@de.ibm.com), IT Architect, IBM

Wolfram Andreas Richter works as a Business Integration Consultant and IT Specialist for the IBM Software Group. Since joining IBM in October 1995, Wolfram has covered a broad range of subject areas, from application development to management education. He has eight years of Linux experience and holds a Bachelor of Science degree from the University of Cooperative Education in Stuttgart, Germany, as well as a Master of Business Administration degree from Henley Management College in the UK. In his spare time, Wolfram likes to do sports, ride his motorcycle, and to go out. You can reach him at wrichter@de.ibm.com.

Summary: Only the paranoid survive, and that is no less true when securing Linux® systems as any other. Fortunately, a host of security features are built into the kernel, are packaged with one of the many Linux distributions, or are available separately as open source applications. This second installment covers inventory assessment, risk analysis, identifying user categories and access privileges, and then moves on to a more detailed action plan and steps for safely acquiring a Linux distribution.

Tag this!

Date: 11 Nov 2004
Level: Introductory
Activity: 3330 views

In this series of articles, you'll see how to plan, design, install, configure, and maintain systems running Linux in a secure way. In addition to a theoretical overview of security concepts, installation issues, and potential threats and their exploits, you'll also get practical advice on how to secure and harden a Linux-based system. We will discuss minimal installation, hardening a Linux installation, authorization/authentication, local and network security, attacks and how to protect against them, as well as data security, virus, and malware programs.

Part 1 of this series started you on your way by providing a general understanding of security concepts and potential threats. This article takes you to the next stage, listing what you will need to keep in mind when planning a secure installation.

Security plan

The first step -- before inserting your distribution's CDs and launching the installer -- is to develop a security plan: determine what services the system will provide, which hardware will be used, what software is necessary, and how the installation will be organized. By making the effort to develop such a plan before the actual installation, lots of possible security issues can be identified and eliminated at a very early stage. This is beneficial as it helps to minimize the risk of a system intrusion or outage. Furthermore, it provides a sound basis for quickly reacting in case of attack or publication of software vulnerabilities and patches.

When considering a security strategy, it is important to note that there is always a tradeoff between security and usability of a computer system. The most sophisticated security features are pointless if they aren't used due to complex setup and maintenance and poor usability. In addition, what is the use of a highly complex, processing-power-consuming encryption alogrithm that effectively locks the system, leaving hardly any computing power for the original task to use?

You should perform the following steps to gather all the relevant information for developing a security plan:

Questions to answer during the inventory assessment

What hardware is used?

Name the hardware, its location(s), and any potential special security features (such as locked and fireproof rooms). List network interfaces, protocols, addresses, and associated names.
What software and operating system should be installed?

Name the applications and their quantity, check licenses for each piece of software.
What type of data is stored and what is its criticality?

Identify categories of data. For each identified category consider the data's criticality with respect to its confidentiality and privacy.
Who is responsible for the system?

Identify responsibility for the system (for example, a single system administrator, a dedicated IT service department, or a support vendor)

Conduct an inventory assessment

The first step towards a security plan is to assess the inventory to learn what exactly has to be secured (see the sidebar to the right). Such an inventory concentrates on physical hardware, network connections, and interfaces and defines the responsibility for the computer. All the findings from the inventory assessment should be documented. An appropriate means of documentation might be a spreadsheet containing all the relevant information for each computer.

Define network services and software

For each computer, it is important to define which network services it uses or offers and which software applications use or provide services. The network services (which might include, among other things, DNS, file transfer, printer and file sharing, Web/Internet, e-mail, and database) should be documented in a deployment plan, which should also contain the software package used and whether the computer is configured as a client, server, or both. Later, based on the list of software and services, you should install an absolute minimalist system that contains only the necessary software and thus has the lowest possibility of hidden security holes.

In addition to defining the software services, you also need to identify the protocols used for communication, which again brings up some security issues. Does network traffic need to be encrypted via HTTP over SSL (https), or is plain HTTP sufficient? Should the file transfer protocol force users to authenticate (for example, using sftp), or is an anonymous and unencrypted access suitable for the required security level?

Generally, client workstations are configured to use multiple network services. Servers, however, should be dedicated to provide one single service, because this eases configuration and leads to a lower probability of configuration errors. Services that should be used by a limited number of users in a network should be protected from unwanted access by a firewall. A firewall effectively implements a security policy governing the network traffic between two or more networks.

Perform a risk analysis

To find a suitable compromise between security and usability of a system, it is important to perform a risk analysis with respect to the type of data stored on the computer. The risk assessment is a first step to learning what type of security measures are needed to protect confidentiality, integrity, and availability of assets.

Based on the inventory assessment -- which states what type of data is stored -- the risk analysis concentrates on the likelihood that the system will be compromised and the consequences resulting from that. In other words, for every category of data defined in the inventory assessment, you need to make an assessment of the probability of gaining unauthorized access to the data and the impact of such an event. This assessment is quantified using three levels, high, medium, and low. The required security level is the average of the probability of an event and its impact.

Identify user categories and access privileges

You should list the main users, or categories of users, of a computer system with respect to their privileges and access rights. For desktop computers, this might be fairly easy, as the number of users is typically low. Nevertheless, it makes sense to define user categories based on similar work assignments or similar need for data sources and applications.

For servers, identifying user categories is usually quite complex. Administrators typically have access to the configuration of the service and operating system facilities. Apart from that, there are different users (local and remote ones) that use service corresponding to their needs. Public servers connected to the internet can basically be accessed by anyone, whereas users of internal servers might be categorized according to job role, department, or office location. So, if needed, you should distinguish between local and remote users as well as temporary or guest users. For the identified user categories, define which data resources they need to access and work with (for example, read, create, modify, or delete data).

Detailed action plan

Now that the overall environment and aim of this installation is well documented, you can get into the specifics -- what software to use, how to install and configure it, and so on. You should write your plan at a level of detail that allows you to answer any questions that arise during the installation process.

Source code reviews

Ken Thompson, one of the original creators of UNIX, discusses in Relections on trusting trust) a number of steps he took that managed to render source code useless for revealing a security issue.

First, he patched the login command to contain a back door that would let him log into any UNIX system with a certain password.

He then patched the C compiler to detect whenever the login command was being compiled. The C compiler would automatically insert the back door into the login program, so there was no need to keep the back door in the source of the login command.

Then, he modified the C compiler to detect when the C compiler itself was compiled from source and to automatically add the login-detection-and-patching code as well as the C-compiler-detection-and-patching code.

The result was a system where the source code did not contain any trace of a backdoor.

Choosing a Linux distribution and server software packages

These are actually two separate steps, but which you do first depends on your situation. In many situations, the distribution to use is already set because of organizational policies, enterprise license agreements, or available skills. Sometimes, you will focus instead on choosing software packages that will fulfill the installation's purpose; the distribution will then be chosen based on the package prerequisites, which distribution contains the packages out of the box, or the cost of the distribution. Often, however, it is a mixture of both, and you'll have to iteratively narrow down which to use. But you should never choose a distribution simply because you have the installation media lying around somewhere!

For every use case (mail server, file server, Web server, word processing, and so on) there are multiple software packages that fullfill the purposes. Especially when users do not interface directly with a software package (such as server software that is administered by a dedicated team), you are less limited in choosing a software package that is more secure. To evaluate the security aspects of various Web servers, mail transfer agents, database management systems, and such, or even whole distributions, a search on mailing lists such as BugTraq or Full Disclosure (see Resources for links to these) are a good starting point.

Judging the security of a software package based on historical problems is about as good as driving a car by looking out the rear window -- you won't know what's coming, but you have an indication on whether you're on a straight or a curvy road. Another issue you should keep in mind is that commonly used software packages receive more reviews than rather obscure ones. Just because "Tom's HyperWeb Server v0.0.2" does not have any known bugs disclosed on these mailing lists doesn't mean it doesn't have any.

To be able to audit any software package on a source-code level is often cited as an advantage of open source software. However, real-life constraints such as available time, skills, and budget make such an approach unrealistic in nearly all cases, so you have to rely on the integrity of the programmers and/or package maintainers and distributors.

You should also document how you intend a service to be run. Some things to consider:

Using xinetd allows you to fine-tune which service is being offered to whom, to enforce limits to prevent denial-of-service attacks, and to log service invocations in a central place.
TCP wrappers provide a means to limit a service to certain ranges of requesting addresses and to log requests.
chroot jails create an environment that is a subset of your actual installation. Even if the service is compromised, only this subset environment is affected. As it is based on hiding parts of the directory tree, it works best for servers that operate on a small and distinct set of files that can be easily included into that tree.

Additional software packages

In addition to the software you need for the planned use cases, the installation process will most likely install other software as well. Software you need (the actual operating system: Linux kernel, shared libraries, basic utility programs, and so on), software you want (packages that enhance security, such as quotas, firewall, and auditing), and software you do not want (unnecessary packages).

For convenience reasons, the distributors often add software packages to the default installation that are not necessary to keep the system running and fulfilling its purpose. On systems that run without user interaction, such unnecessary software includes graphical user environments, multimedia software, and games.

Any piece of software installed on a machine inherently ties up resources and reduces the machine's security, containing potential bugs that may be exploited:

Unnecessary services can be used by an outside attacker to execute code on the server, such as by using buffer overflows (see Resources for a link to a discussion of this vulnerability).
Administrators are only human and therefore prone to making mistakes. A piece of software not installed cannot be misconfigured, thereby closing down additional potential security holes.
Even if the software is not constantly running and not exposed to the network, it adds to the burden of the administrator who needs to apply security fixes when bugs are found. Assume that a flaw in one of the services has been found and a break-in has occurred. The attacker is now able to execute programs under a user's security context on the server. Now any program available on that machine may be used by an attacker, whether to elevate his/her privileges, to retrieve security-relevant information, or to attack other systems, possibly further inside the organization's firewall.
Social engineering techniques used to trick legitimate users (or even the administrators) into running programs that result in a security exposure are an additional reason to have as few programs installed as possible.

Regarding the packages enhancing security you should consider installing the following:

Quotas: Quotas should be used to limit the resources available to users (including users for daemons such as ftpd or httpd). This defeats local denial-of-service (DoS) attacks such as using all available process IDs with a "fork bomb," starting lots of copies of a memory-hungry program, or consuming the whole free space of a partition. Most of the current distributions include quotas and the package is in most cases called "quota." Other limits besides disk quotas can be implemented by PAM, which should be installed by default. The configuration of those limits will be described in the next article of this series.
Firewall: Generally, a firewall prevents network communications according to a defined rule set. So its basic task is to help avoid network intrusions by blocking unwanted traffic. Network firewalls work on the TCP/IP stack level and decide whether packets may pass or not (depending on the rule set).
Intrusion detection: The main task of an intrusion detection system (IDS) is to detect attacks or intrusions into the network or the computer by identifying security breaches such as incoming shellcode, viruses, malware, or trojan horses.
Auditing: Auditing refers to detecting changes to sensitive data or configuration files by establishing a baseline of data in its desired state. Changes to the baseline are reported, enabling administrators to react quickly, and recover in the case of undesired changes.

Secure replacements of common utilities

Task/use case	Old insecure application	Recommended secure alternative
Remote access to command line	telnet rsh (remote shell)	ssh (Secure Shell)
Graphical access to remote system	X Window VNC	X Window over ssh VNC over ssh rdesktop
File transfer	ftp rcp (remote copy)	sftp scp (secure copy)
Mirroring/backup	rsync	rsync tunnelled over ssh

Using secure versions of utility programs

Today still, a lot of applications of the early days of the Internet exist and are in use. They were developed when security was not a big issue for the few Internet participants out there at the time. As the internet has evolved and grown rapidly over the last years, the lack of security makes those applications inappropriate for today's use. This is why replacements have been developed that are able to perform the same tasks –- tasks as important today as they were in the early days -– in a secure way. "Secure way" in this context basically means:

Encryption of the transferred data, which includes user credentials and other user-related data to prevent third parties from being able to understand the transmitted information.
Use of credentials such as username and password or digital certificates to identify users and systems.

Although these replacements are often referred to as "secure standard applications," they are not absolutely immune to attacks. This means that while you would be well advised to use the secure versions over the insecure ones, you still need to establish additional concepts and processes to secure your systems. The sidebar Secure replacements of common utilities lists applications suitable for selected common tasks. This list is not (and cannot be) complete, so you should always consider using secure applications even for those tasks not listed in the sidebar.

Partitioning

The chosen applications and the sources you are going to install from are not the only factor for security. To mitigate the effects of DoS attacks that try to fill the available disk space, make sure you plan dedicated partitions for at least these directories:

/home: Makes the user data independent of the system. This is very useful when you are performing backup and restore operations, upgrading or switching the operating system, or migrating users in a system landscape.
/var: Keeps the server's log and runtime data. By putting it on a separate file system, the data cannot fill up your entire free disk space if you are the target of a DoS attack.
/tmp: Like /var, this directory is writeable for user processes, making it a target for DoS attacks. An even better approach than using a separate file system is to use tmpfs, which speeds up file access and automatically clears the file system's contents upon reboot.
/boot: Contains the Linux kernel, initial drivers, and boot loader data. This partition does not need to be mounted in order for the boot process to function, because the boot loader loads the kernel as a list of sectors to read from the hard drive. If it is not mounted in normal operation, you cannot accidentally overwrite these files.

Acquiring the distribution

Linux distributions can be acquired in many different ways: shrink-wrapped CD/DVD distributions, copied from others, downloaded, and so on. Because a system that is compromised right at installation is worthless to begin with, you have to ensure that the installation is based on "clean" sources -- verified code without back doors. In practice, this burden is shifted to the distributor who compiles a set of CDs/DVDs containing the installation files. While you can probably trust the distributor, it is a good practice to verify the checksum of the installation media against the publicized checksums of the distributor to verify that the medium is genuine.

How to verify installation media

To verify MD5 checksums you can use

$ md5sum /path/to/iso/image.iso

$ md5sum /dev/cdrom

to check an ISO image or a CD, respectively. The calculated checksums have to match the ones publicized by the distributor. If you use the Web to find the published checksums, make sure to use https and view the certificate used in the connection to ensure that the publisher of the checksums is genuine.

Installation over a network or the internet -- while technically possible -- is not recommended. It is possible (e.g. via spoofing) for a site to disguise itself as a trustworthy installation source and offer modified software packages that include back doors, enabling an intruder to easily take over the system after installation. Of course, the installation can be made from an internal network server, for example, where the source is known and validated.

A newly installed operating system is usually not locked down right away and might not have the latest security patches installed. It is most vulnerable to attacks at this particular point in time (see Resources for a link to an article on the expected survival time of an unpatched system), and should be separated from the Internet or at least be located in a secured network segment throughout the installation process until the first configuration steps have been taken. These steps will be discussed in the next article of this series.

After the installation, the latest security patches and updates should be downloaded from the Internet via a second (appropriately secured) computer. Again, trustworthy installation sources must be chosen for the download of the patches. The integrity of downloaded installation files can be verified via checksums or hashes that are offered by serious providers.

Next in the series

With its open source philosophy, which allows users to customize and expand the system to suit specific needs, Linux is getting more and more popular. Therefore, Linux system administrators need to understand the security mechanisms for hardening Linux and securing it against possible attacks. The next installment in this series, " Securing Linux, Part 3: Hardening the system," shows you how to secure the boot process and local filesystems, lock up services and daemons, enforce quotas and limits, enable mandatory access control, and detect security vulnerabilities in new software versions.

Resources

Read the other installments in this Securing Linux series on developerWorks.
Develop a computer deployment plan that includes security issues is a practice from CERT's Security Improvement Modules.
Another CERT module you will want to read is Deploying Firewalls.
The BugTraq archive gives ongoing updates about a multitude of security risks.
Full Disclosure is a members-only security discussion list.
Smashing the stack for fun and profit provides a discussion of buffer overflows and how to exploit them.
The Securing Debian HOWTO provides a good configuration checklist that is useful for other distributions, too.
LinuxLinks' list of secure distributions is a list of hardened Linux distributions.
Tools to administer quotas can be found at the Linux DiskQuota project page on SourceForge.net.
Installation and build instructions for quotas are provided by the Quota mini-HOWTO Chapter "installation and configuration".
If you want an idea of how often attacks happen and how long you might expect a server to survive unpatched in the Internet, read Know Your Enemy: Statistics by the Honeynet Project.
The SANS Institute also has a short article showing collected survival time data, the average time it take until an IP address is targeted by a worm.
Best Practices for UNIX chroot() Operations discusses chroot() and shows how to use it to your best advantage.
For a general overview and resource guide for those working to provide a secure Linux environment, read Addressing security issues in Linux (developerWorks, June 2001).
Practical Linux security (developerWorks, October 2002) emphasizes that good security begins with good user management.
The Secure programmer column on developerWorks is an ongoing series dedicated to helping you write secure programs for Linux.
Find more resources for Linux developers in the developerWorks Linux zone.
Get involved in the developerWorks community by participating in developerWorks forums and blogs.
Browse for books on these and other technical topics.
Order the SEK for Linux, a two-DVD set containing the latest IBM trial software for Linux from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
Innovate your next Linux development project with IBM trial software, available for download directly from developerWorks.

About the authors

Comments (Undergoing maintenance)

Trademarks | My developerWorks terms and conditions

Close [x]

Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Close [x]

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

static.content.url=http://www.ibm.com/developerworks/js/artrating/

SITE_ID=1

Zone=Linux

ArticleID=31915

ArticleTitle=Securing Linux, Part 2: Planning the installation

publish-date=11112004

author1-email=m_eberlein@de.ibm.com

author1-email-cc=tomyoung@us.ibm.com

author2-email=rene.auberger@de.ibm.com

author2-email-cc=

author3-email=wrichter@de.ibm.com

author3-email-cc=tomyoung@us.ibm.com

Security plan
Detailed action plan
Acquiring the distribution
Next in the series
Resources
About the authors
Comments

Next steps from IBM

WebSphere Portal can help your small and midsize business achieve better website security, along with faster time to value with easily deployable and customizable example Web sites.