"Linux Gazette...making Linux just a little more fun!"


Securing Linux: The First Steps

By


Not too long ago, I sat patiently while the latest kernel version trickled down my slow, analog dial-up connection. Throughout the entire process, I longed for the day when high-speed Internet access would be available in the home. The arrival of xDSL and cable modems to the doorstep has made this dream a reality, but not without its price.

As I write this, somewhere in the world, someone is setting up a Linux distribution on their home computer for the first time. The new Linux administrator takes the system for a spin by firing up accounts for family and friends. Just a few short hours after the initial installation, this new Linux system is an Internet presence thanks to its high-speed DSL connection.

It Is Also a Sitting Duck

Nearly all Linux distributions available today are insecure right out of the box. Many of these security holes can be easily plugged, but tradition and habit have left them wide open. A typical Linux installation boots for the first time offering a variety of exploitable services like SHELL, IMAP and POP3. These services are often used as points of entry for rogue netizens who then use the machine for their needs, not yours. This isn't just limited to Linux--even the most sophisticated commercial UNIX flavors ship with these services and more running right out of the box.

Without assessing blame or pointing fingers, it is more important that these new machines become locked down (hardened, to pin a technical term to it). Believe it or not, it doesn't take an expert in system security to harden a Linux machine. In fact, you can protect yourself from 90 percent of intrusions in less than five minutes.

Getting Started

To begin the process of hardening your machine, ask yourself what role your machine will play and how comfortable you are with connecting it to the Internet. Carefully decide which services you want to make available to the rest of the world. If you are unsure, it's best not to run any. Most importantly, create a security policy for yourself. Decide what is and what is not acceptable use of your system.

For purposes of this article, the example machine is a workstation that will be used for typical Internet access such as mail and news reading, web browsing, etc.

Securing Network Services

First, gain superuser (root) access to the system and take an inventory of its current network state by using the netstat command (part of net-tools and standard on most Linux systems). An example of its ouput is shown here:

root@percy / ]# netstat -a
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address   Foreign Address         State
tcp        0      0 *:imap2                 *:*             LISTEN
tcp        0      0 *:pop-3                 *:*             LISTEN
tcp        0      0 *:linuxconf             *:*             LISTEN  
tcp        0      0 *:auth                  *:*             LISTEN  
tcp        0      0 *:finger                *:*             LISTEN  
tcp        0      0 *:login                 *:*             LISTEN  
tcp        0      0 *:shell                 *:*             LISTEN  
tcp        0      0 *:telnet                *:*             LISTEN  
tcp        0      0 *:ftp                   *:*             LISTEN  
tcp        0      0 *:6000                  *:*             LISTEN  
udp        0      0 *:ntalk                 *:*                     
udp        0      0 *:talk                  *:*                    
udp        0      0 *:xdmcp                 *:*                     
raw        0      0 *:icmp                  *:*             7       
raw        0      0 *:tcp                   *:*             7
As you can see from that output, a fresh installation left a number of services open to anyone within earshot. Most of these services are known troublemakers and can be disabled in the configuration file, /etc/inetd.conf.

Open the file with your favorite text editor and begin to comment out any services you do not want. To do this, simply add a ``#'' to the beginning of the line containing the service. In this example, the entire file would be commented out. Of course, should you decide at some point that you would like to offer some of these services, you are free to do so.

Now, restart inetd to reflect the changes. This can be done in a number of ways and can differ from system to system. A simple

killall -HUP inetd
should do the trick. Check the open sockets again with netstat and note the changes.

Next, take a look at what processes are running. In most cases, you'll see things like sendmail, lpd and snmpd waiting for connections. Because this machine will not be responsible for any of these services, they will all be turned off.

In most cases, these services are launched from the system initialization scripts. These can vary somewhat from distribution to distribution, but they are most commonly found in /etc/init.d or /etc/rc.d. Consult the documentation for your distribution if you are unsure. The goal is to prevent the scripts from starting these services at boot time.

If your Linux distribution uses a packaging system, take the time to remove the services you do not want or need. On this example machine, those would be sendmail, any of the ``r'' services (rwho, rwall, etc), lpd, ucd-snmp and Apache. This is a much easier approach and will ensure the services aren't activated accidentally.

Securing X

Most recent distributions enable machines to boot for the first time into an X Window System login manager like xdm. Unfortunately, that too is subject to exploits. By default, the machine will allow any host to request a login window. Since this machine has only one user that logs into the console directly, that feature will need to be disabled as well.

The configuration file for this varies depending on which version of the login manager you are using. This machine is running xdm, so the /usr/X11R6/lib/X11/Xaccess file will need to be edited. Again, add a ``#'' to prevent the services from starting. My Xaccess file looks like this:

#* #any host can get a login window
#* #any indirect host can get a chooser
The changes will take effect when xdm restarts.

Software Updates

Now that some of the basic hardening has been done, it is necessary to check with the vendor for updates and enhancements to the distribution. Poor maintenance or none at all is another large contributor to system compromises.

One of the blessings of open-source software is that it is constantly under development. Security vulnerabilities are often discovered by a number of people, and a fix is available within days, if not hours of its discovery. As a result, most vendors actively maintain their Linux distribution. Quite often, they post updates, bug fixes and security advisories on their web site. Make a daily or weekly visit to your vendor's site and apply any patches or updates they post.

The Next Step

By this point, the machine is far more secure than when it was first installed. It isn't invulnerable to attack, but at least it is no longer extending an invitation to attackers. The approach outlined here is similar to that of locking your home or car. The average thief will jiggle the handle, realize that it's locked and move on to one that isn't.

Should you decide these steps do not provide enough security, or you wish to provide some network services across the Internet, take the time to research some advanced security techniques before you do so.

Unfortunately, vendors of most Linux distributions assume their customers already know about these services and want to use them. This isn't always the case for newcomers. Of course, there is still a large amount of ground to cover before total Linux system security can be achieved, but these steps provide a basic foundation and awareness of system security.

To date, the majority of system and network compromises are relatively minor. As Linux increases in popularity and high-speed Internet access becomes more available, attacks on unprepared Linux systems will only become more severe and abundant.


Copyright © 1999, Peter Lukas
Published in Issue 47 of Linux Gazette, November 1999


[ TABLE OF CONTENTS ] [ FRONT PAGE ]  Back [ Linux Gazette FAQ ]  Next