Securing Linux, Part 3: Hardening the system

ooike

Securing Linux, Part 3: Hardening the system


























Contents:

About hardening

Securing the boot process

Securing services and daemons

Securing local filesystems

Enforcing quotas and limits

Enabling Mandatory Access Control

Updating and adding security patches

Putting your security plan into action

Next in the series

Resources

About the authors

Rate this article


Related content:

Securing Linux, Part 1: Introduction

Securing Linux, Part 2: Planning the installation

Understanding Linux configuration files

Charming Python: Using the xinetd program for system administration

Addressing security issues in Linux

Practical Linux security



Subscriptions:

dW newsletters




How several configurations can keep your system safe from attack

Level: Introductory
Mario Eberlein
(
[email=m_eberlein@de.ibm.com?subject=Hardening the system]m_eberlein@de.ibm.com[/email]
), IT Architect, IBM Global Services
Rene Auberger
(
[email=rene.auberger@de.ibm.com?subject=Hardening the system]rene.auberger@de.ibm.com[/email]
), Software IT Architect, IBM Software Group
Wolfram Andreas Richter
(
[email=wrichter@de.ibm.com?subject=Hardening the system]wrichter@de.ibm.com[/email]
), IT Architect, IBM Software Group
14 Apr 2005
Learn techniques for making your Linux™ system more resistant to attacks, including securing the boot process and local filesystems, locking up services and daemons, enforcing quotas and limits, enabling mandatory access control, and recognizing security vulnerabilities that can be introduced when updating security with new software.
Part 1
in this series introduces security concepts and potential threats.
Part 2
lists the concerns to keep in mind when planning a secure installation.
In this series of articles, learn 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 with a general explanation of security concepts and potential threats.
Part 2
took you to the next stage by listing the concerns you need to keep in mind when planning a secure installation, including making a detailed security action plan.
In this part, we'll cover the steps involving in hardening Linux.
About hardening
For hardening activities to be most successful, you should:

Do hardening activities before the system is connected to the network to avoid attacks.

Base configuration on the least-privilege model: the system should grant access only to the degree necessary for proper functionality. Similarly, users should be allowed only the minimum set of access rights they need.
After completing the preliminary planning and preparation and performing the minimal installation (see Part 2), you need to consider several configuration steps. These steps are generally referred to as hardening Linux:

Securing the boot process

Securing services and daemons

Securing local filesystems

Enforcing quotas and limits

Enabling Mandatory Access Control

Updating and adding security patches
Securing the boot process
Configure the boot loader (LILO or Grub) so that it does not allow any user intervention at boot time; this prevents users from passing kernel parameters at boot prompt. Configured it to require a password unless you need to perform remote reboots (such as in a remote datacenter). This is an additional precaution against people who have physical access to the machine; it prevents casual hacks of such events as booting with the parameters single or init=/bin/sh to obtain a root shell, etc. Note, however, that with additional efforts (like removing the hard drive and mounting it on another system), this can be dodged easily unless you also encrypt your filesystems.
For LILO, replace the parameter prompt with password in the lilo.conf configuration file (usually in /etc). For Grub, the relevant parameters are hiddenmenu, default 0, and password in the Grub configuration file (usually in /boot/grub/grub/conf).
Ensure that the run-level configuration requires the root password when switching to single user mode by adding sp:S:respawn:/sbin/sulogin to /etc/inittab.
Prevent users from invoking a reboot using Ctrl-Alt-Del: disable the ctrlaltdel entry in /etc/inittab by commenting out the line with the ctrlaltdel. By adding a hash (#) sign similar to this -- #ca::ctrlaltdel:/sbin/shutdown -t5 -rf now -- you can prevent that key combination from ever triggering a reboot.
Securing services and daemons
The first step to a secure configuration of services is to disable all services that are not needed. Services that aren't offered can't be exploited by potential intruders, effectively reducing your risk.
To uncover all enabled services, check several locations. Also, disable insecure services and replace their functionality with more secure options. For instance, telnet is not encrypted, so use the encrypted ssh service instead of telnet (see Part 2).
Consider these elements when securing services:

/etc/inittab

Boot scripts in /etc/init.d

The inetd/xinetd daemons

TCP wrappers

Firewalls
/etc/inittab
During the boot process, the init process reads the entries in the file /etc/inittab. Each entry -- one per line -- defines which program is to be run in certain situations. Such programs are either services themselves or are used to start and stop services.
The init process distinguishes several states, so-called run levels, identified by a single character. When a run level is entered or certain events (such as power failure) occur, the entries are evaluated and the appropriate commands are executed.
The format of an entry in /etc/inittab is a label for the entry, followed by the run levels in which the entry is processed, followed by an action keyword and the command to be executed including command-line parameters. All these fields are separated by colons and a typical entry would look like this:
my_service:35:once:/usr/local/bin/my_service someparameter
(Find a complete list of action keywords in the man-pages of inittab.)
In this example, the entry's label is my_service. It will run the program /usr/local/bin/my_service with the parameter someparameter when run levels 3 or 5 are entered. Once the program terminates, it is not restarted (action keyword "once").
For a secure Linux system, you need to understand the functions of all entries in /etc/inittab and disable potentially unwanted services by deleting the entry or commenting it out using the hash sign at the beginning of the line.
Two types of entries are common in all Linux systems. The first is used to launch a program called /sbin/getty (or similar), which is used to allow logins on the Linux virtual consoles or serial lines. The second type launches a script usually named rc in the /etc/rc.d directory with the current run level as the parameter. This script controls the starting and stopping of services (and that's described next).
Boot scripts in /etc/init.d
Boot scripts located in /etc/init.d are used to start or stop system services. For each run level, there is a /etc/rcN.d directory (with "N" being the identifier of the run level) that contains soft links to the boot scripts that are to be invoked on run-level change.
If the link name starts with an "S" the script is executed when entering the run level to start the corresponding service; if it starts with "K" the script is executed when exiting the run level to stop the service.
Most of the time the name of the boot script reveals which service it controls. To prevent a service from being started in a specific run level, delete the links from the run-level subdirectory to the corresponding boot script or replace the original boot script in /etc/init.d by a dummy script doing nothing.
The inetd/xinetd daemons
Services can also be invoked on demand when requested by a client. These requests are given to the super daemon inetd or xinetd. The super daemon then decides which service to start and passes the request to the corresponding daemon. Typically services like telnet, ftp, rlogin, etc., are started using inetd or xinetd.
The inetd daemon is configured in /etc/inetd.conf, which contains entries for each service to be offered by the super daemon. An entry configuring an FTP server could look like this -- ftp stream tcp nowait root /usr/bin/ftpd in.ftpd -el -- and you can disable it by commenting it out using a hash sign.
For security reasons, the use of xinetd is recommended. In contrast to inetd, xinetd is able to start rpc-based services and provides access control. xinetd can limit the rate of incoming connections, number of incoming connections from specific hosts, or total number of connections for a service.
xinetd is configured by distinct configuration files for each subordinate daemon. These files are located in /etc/xinetd.d/. The example configuration file for the FTP server above would be called /etc/xinetd.d/ftp and would look like this:
Listing 1. Configuration file, /etc/xinetd.d/ftp
service ftp
        {
                socket_type       = stream
                   protocol          = tcp
                   wait              = no
                   user              = root
                   server            = /usr/bin/ftpd
                   server_args       = -el
                   disable           = yes
        }
To disable the service, the parameter disable is set to yes as in the previous example.
For a more fine-grained control of access, xinetd supports these three additional parameters:

only_from

no_access

access_time
To restrict the access but not completely disable the ftp daemon, you could modify the config file /etc/xinetd.d/ftp as follows:
Listing 2. Configuration file, /etc/xinetd.d/ftp, modified to restrict access
service ftp
        {
                socket_type       = stream
                   protocol          = tcp
                   wait              = no
                   user              = root
                   server            = /usr/bin/ftpd
                   server_args       = -el
                   disable           = no
                   only-from         = 192.168.200.3 192.168.200.7 192.168.200.9
                   only-from        += 192.168.200.10 192.168.200.12 172.16.0.0
                   no_access         = 172.16.{1,2,3,10}
                   access_times      = 07:00-21:00
        }
only-from and no_access accept numeric IP addresses (right-most zeros are treated as wild cards), IP addresses/netmask ranges, hostnames, and network names from /etc/networks. If a combination of only-from and no_access is used, xinetd finds the closest match for each host connecting.
For the previous code example, this means hosts with an IP address 172.16.x.x can connect except to hosts with addresses in 172.16.1.x, 172.16.2.x, 172.16.3.x, and 172.16.10.x. As you can see, there is no need to specify all four components of an address when you use the factorized notation as shown for no_access. The factorized part must be the right-most element of the address. See the
Resources
section below for an article on xinetd and its configuration.
TCP wrappers
If you decide to not use xinetd but to instead rely on inted, you can achieve logging of requests and specifically permitting/denying certain networks by using TCP wrappers. TCP wrappers evaluate /etc/hosts.allow and /etc/hosts.deny for authorization and logging purposes and wrap client requests without directly answering them. Once authorization is successful, the request is forwarded to the originally requested service.
Using TCP wrappers delivers two main advantages over using plain inetd:

The requesting client does not recognize the TCP wrapper; therefore, good guys do not realize any difference, and bad guys do not get any information on why their request failed.

A TCP wrapper works regardless of any wrapped services, enabling applications to share their configuration files and therefore easing up administration.
For a detailed documentation of TCP wrapper configuration files, see the Red Hat Linux Reference Guide listed in
Resources
.
How to find world-writable files
To find world-writable files, use this command:
find / -perm -002 \( -type f -o -type d \) -ls
Where:

/ is the starting point for searching.

-perm checks the permission.

002 means (octal notation) write bit set for "other."

- in front of the mode 002 means all permission bits are set (zero-bits in the mode are not considered).

-type f or -type d searches for regular files and directories.

-ls lists the files found in ls format.
Firewalls
To prevent unwanted communication to services that are not supposed to run or that are not supposed to be accessed from certain networks like the Internet, the installation of a firewall is recommended. A firewall provides controlled communication between networks based on trust levels and grants or denies access to certain services using a rule-based security policy leveraging the least-privilege principle.
The installation and configuration of a firewall is quite a complex topic and is beyond the scope of this article series.
Securing local filesystems
Securing the local filesystem deals with ownership of files and directories and access rights to them. To secure the filesystem, the protection bits of files and directories must set to grant minimum access only.
Take special care with respect to inappropriate permissions regarding world-writable files and system directories and so-called setuid or setgid commands. These commands are executed with higher user privileges than the user running the command actually has. This might be necessary to access files that only root has access to (such as /bin/passwd needs to access /etc/passwd). For each of these commands, make sure that it really needs the setuid/setgid bits set. If this is not the case, disable it.
When all files on a partition definitely do not need the setuid/setgid bits, the nosuid option in /etc/fstab disables it for each file on the corresponding filesystem (/dev/hdc1 in the following example):
#device                mountpoint        filesystemtype        options                dump        fsckorder
/dev/hda1        /                ext2                defaults        1        1
...
/dev/hdc1        /mnt/cdrom        iso9660            nosuid,user        1        2
Furthermore, for very sensitive data, it might make sense to encrypt that data and protect it with a passphrase. GnuPG provides a suitable package to accomplish this.
Enforcing quotas and limits
The Linux PAM (Pluggable Authentication Modules) can enforce some useful limits, which can be configured in the /etc/security/limits.conf file. Keep in mind that these limits apply to a single session. You can control the total limitation with the maxlogins option. Entries within limits.conf have the following structure: username|@groupname type resource limit.
Groupnames must be preceded by the @ to distinguish them from usernames. The type must be either soft or hard. Soft-limits can be exceeded and are usually warning marks, whereas hard-limits cannot be exceeded. A resource can be one of these keywords:

core - Limits the size of a core file (KB).

data - Maximum data size (KB).

fsize - Maximum file size (KB).

memlock - Maximum locked-in memory address space (KB).

nofile - Maximum number of open files.

rss - Maximum resident set size (KB).

stack - Maximum stack size (KB).

cpu - Maximum CPU time in minutes.

nproc - Maximum number of processes.

as - Address space limit.

maxlogins - Maximum number of logins allowed for this user.
In the following code example, all users are limited to 10 MB per session and are allowed a total of four simultaneous logins. The third line disables core dumps for everybody. The fourth line removes all limits for user bin. ftp is allowed to have 10 simultaneous sessions (which is especially useful for anonymous ftp accounts); members of the group managers are limited to 40 processes. developers have a memlock limit of 64 MB and all members of wwwusers cannot create files that are larger than 50 MB.
Listing 3. Setting quotas and limits
*           hard  rss        10000
*           hard  maxlogins      4
*           hard  core           0
bin         -
ftp         hard  maxlogins     10
@managers   hard  nproc         40
@developers hard  memlock    64000
@wwwusers   hard  fsize      50000
Quota best practices
You should enable quotas for every partition users are allowed to write to. Also take into account that your system has some user IDs that belong to applications instead of human users. Those IDs may have write access in directories where humans do not.
Add /sbin/quotacheck -avug to your cronjobs to automatically update quota files and the tables that are currently used by the kernel.
To activate these limits, you need to add the following line to the bottom of /etc/pam.d/login: session required /lib/security/pam_limits.so.
Quotas allow you to restrict the number of inodes and the consumable space for users and groups. Note that a quota is defined per mount point, so if users have write access on several partitions, make sure to define quotas for each of them.
Quotas are an administrator's way of minimizing the risk of DoS attacks that rely on filling up all the available space of a hard drive (which prevents other processes from creating temporary files and thus makes them fail). Depending on which distribution you are using, you can install the shipped quota tools or you can download, compile, and install them yourself (see
Resources
).
Quotas must be enabled in the kernel. Most distributions today come with quota support. If your distribution doesn't have quotas enabled, see the mini-howto in
Resources
for instructions on enabling them.
To enable quotas for a filesystem, you must add an option to the corresponding line in /etc/fstab. Use usrquota and grpquota to enable user quotas and group quotas as Listing 4 shows:
Listing 4. Enabling user quotas and group quotas
/dev/hda1    /           ext3    defaults                     1 1
/dev/hda2    /home       ext3    defaults,usrquota            1 1
/dev/hda3    /tmp        ext3    defaults,usrquota,grpquota   1 1
/dev/hda4    /shared     ext3    defaults,grpquota            1 1
/dev/hdc1    /mnt/cdrom  iso9660 nosuid,user                  1 2
Next, remount the corresponding filesystems to activate the newly added options with mount -a -o remount; then create a binary quota file using the command quotacheck -cugvm, which contains the quota configuration in a machine-readable format. This is what the quota subsystem operates on.
Assigning quotas is done using the tool edquota. To define the limits for user alice, invoke it with edquota -u alice. The editor defined in the environment variable EDITOR (default is vi) opens with similar content:
Quotas for user alice:
/dev/hda2: blocks in use: 3567, limits (soft = 5500, hard = 6500)
         inodes in use: 412, limits (soft = 1000, hard = 1500)
The "in use" values are for your information only and cannot be changed -- soft and hard limits are the only values you can modify. After saving and exiting the editor, edquota reads the temporary file you just edited and transfers the values into the binary quota file to reflect your changes. Editing group quotas works the same except that the option -g instead of -u has to be used.
Soft limits are a warning level that can be exceeded, whereas hard limits are strictly enforced. Soft limits have a grace period (sometimes also called soft time limits); this is the time span a user is allowed to exceed the soft limit until it is enforced by the system.
You can set the grace period with edquota -t. The available units are seconds, minutes, hours, days, weeks, and months. Other useful tools for managing quotas are repquota (summarizes quotas for a filesystem), quotaon, and quotaoff (switches quotas on and off).
Enabling Mandatory Access Control
You can achieve additional security with Mandatory Access Control, or MAC, by implementing SELinux. With MAC, permissions in the operating system are governed by the user/group ID under which a process runs and the user/group IDs of the objects (files) being accessed. Also, with MAC, policies for each individual process are enforced by the Linux kernel, and they control what a process may do.
That way, in a properly configured system with MAC, a service that has been hijacked or hacked into cannot take over the system. Even though the user or group ID under which the service processes run (worst case scenario: root) may match the file permissions of critical system files such as /etc/passwd, the policy in place disallows access to them.
The effectiveness of SELinux is illustrated by test systems on the Internet that allow anyone to log in; the control mechanisms prevent anything malicious from being done, even though users can log in as root!
Adding vendor GnuPG keys
The distribution vendor's GnuPG keys should already be part of the base configuration. You can add keys of third-party vendors you trust with this command: $ rpm -import .
You should ensure that you acquire the keyfile in a secure manner, for example, by downloading it from the vendor's Web site via HTTPS where you verified the connection's certificate.
There are some problems with SELinux, however. First, the configuration is fairly intrusive if the distribution is not MAC-enabled by the vendor. It may require patching and recompiling the kernel and replacing certain system-management tools (all of which may violate the distribution vendor's support policy). Second, it is a quite complex task to define a proper policy. If there is no policy definition available for your application of choice, you may have a hard time getting it to run in a MAC environment. This makes it difficult for use cases such as desktop workstations in which a wide variety of software packages are to be supported.
Updating and adding security patches
To keep your systems as secure as possible you need to stay informed of new fixes and patches for your software. There are several sources for this information, but naturally the software vendors and your Linux distributors should provide you with this information in a timely manner. You can also use the (nearly always free of charge) services from CERT (Computer Emergency Response Team). They often maintain mailing lists that carry information on the newest advisories, vulnerabilities, and so on.
When a new update becomes available, you should check to see if it applies to your system and your security requirements. Installing an update can itself be the cause of security issues. Also consider that each update may introduce new vulnerabilities, or if the update fails, your system may be left in an unusable state.
When you have to apply an update to a large range of systems, you often cannot update them all at the same time -- this may cause your systems to be mutually incompatible during the update phase.
As you can see, there are a lot of risks involved with updating a system. Here are some recommendations to mitigate these risks:

After the initial installation, do not connect your system to the network right away. Download all relevant updates on a separate machine and transfer them manually to make sure that the system is on a current state before it is exposed.

Always have a recent backup of your systems available.

For every system that is critical to your business, you should have an isolated test environment that is identical to your production environment in terms of hardware and software. Gain experience with the updates first in the test environment to prevent any surprises when administering your production systems.

In an ideal world, you'd have a suite of regression tests prepared to compare proper functionality and performance before and after the update for all programs that comprise your system. At the very least, make sure that there is a repeatable and documented quality control check that ensures that the main functions and services are not affected in the test environment before modifying the production systems.

Applying updates manually may work for a small network but will quickly become unmanageable in larger installations. This often results in updates not being installed. Ease the deployment of updates by using commercial or open source systems-management or software-distribution tools.

Did we mention that it's a good idea to have a backup at your fingertips? We'll just mention it again.

Develop a plan for applying updates and take into consideration:

• The order in which the systems should be updated
  
• The critical systems to your business
  
• How the systems depend on each other
  
• Which systems contain confidential data

When using integrity checking tools -- strongly recommended at least for servers -- remember to update the baseline of the fingerprint of your system taken at a known secure state to be able to identify unexpected changes.

Before applying any fixes, check the integrity and authenticity of the software (especially when downloaded from a Web site or ftp server) by using cryptographic checksum tools. In the Linux world, it is common to use MD5 and/or SHA-1 checksums. If the software is supplied using RPM packages, the vendor should have provided a GnuPG signature. You can check that by running the command $ rpm -v --checksig .rpm. A successful response would be ".rpm: md5 gpg OK"; an unsuccessful one would return ".rpm: md5 GPG NOT OK".
For verifying MD5 or SHA-1 checksums, you can use $ md5sum .rpm or $ sha1sum .rpm. If you have downloaded a file containing the checksums for more than one file (in most cases, it is called md5sum.asc or .md5), you can use $ md5sum -c md5sum.asc.

And last but not least, back up your systems. (Have we said that yet?)
Putting your security plan into action
As discussed in
Part 2
of this series, now match the installed system against the documented security plan. Get to know which processes are actually running on your system and disable the unnecessary ones. Do this on a regular basis to check for unusual activities; an unknown process could be offering unwanted services and indicate a system compromise.
This section shows you how to find and disable those unnecessary (and potentially dangerous) processes and prepare for a regular audit of the system.
Finding and disabling unnecessary processes
Ideally you should know every process running on your system. To get a list of all processes, you can issue the command ps -ef (POSIX style) or ps ax (BSD style). Processes with square brackets around their names are kernel-level processes that perform helper functions (such as flushing the caches to disk); all other processes are userland processes. You will notice that even on your newly installed (minimal) system, a lot of processes are running. Get familiar with them and include this in your documentation.
Network monitoring tools
These tools can help with network monitoring:

Nmap
(Network Mapper) is a free open source utility for network exploration or security auditing. Use it to check your system after you finish setting it up.

IPTraf
is a console-based network-statistics utility for Linux. It gathers a variety of figures such as TCP connection packet and byte counts, interface statistics and activity indicators, TCP/UDP traffic breakdowns, and LAN station packet and byte counts.

The
Multi Router Traffic Grapher
(MRTG) is a tool to monitor the traffic load on network links. MRTG generates HTML pages containing graphical images that provide a live visual representation of this traffic. See the
MRTG index page
for an example.
Now let's look at those processes that open network connections; they hold the largest potential for attacks. To get a list of all TCP or UDP connections, issue the command netstat -atu (with name resolution, easier to read) or netstat -atun (without name resolution, quicker). Within this list, pay special attention to TCP connections with status LISTEN and to all UDP connections because these are servers that accept incoming connections.
If the server listens to 127.0.0.1/localhost, it can only be reached by the system itself (loopback interface). It is therefore much less exposed than a server listening to an externally reachable interface or even 0.0.0.0 (= * with name-resolution turned on), which can be reached through any network interface.
If you have used netstat -atun, you need to translate the port numbers yourself. You can look them up in /etc/services. Use the additional parameter -p to display the corresponding process as shown in
Listing 5
.
In this example, you could conclude that the portmapper and the graphical user interface (X) is not needed for a particular server. Portmapper provides a standard endpoint for various RPC-based services such as NFS; the system does not provide NFS shares. An X window display is useful when the system is used as workstation, but has limited use on a server.
Identify how these processes were started (via /etc/inittab, via boot scripts, etc.) and disable them as described earlier. This task can become a bit more challenging if the program was launched by another program: The X server was most likely launched by a display manager such as xdm, kdm, or gdm, and does not turn up in the inittab or boot scripts directory itself.
Connections listed by netstat do not automatically have to be available to all computers on the net: A firewall based on Linux's built-in capabilities may further regulate the access before any packet reaches the open connection.
Audit preparation
Once a basic system is installed and securely configured, your ultimate goal is to keep the system secure. To identify unwanted changes to the system, use auditing tools that record a fingerprint of the system in a hopefully known and secure state and detect changes to it.
Next in the series
This installment has shown you how to harden your Linux system with a number of techniques to protect the secure heart of your Linux environment. The next installment in this series dives deeper into SELinux, giving you conceptual information as well as practical information on how to use it.


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/12757/showart_256921.html