Securing a New Linux Installation

Introduction

From a security professional's perspective, a number of common Linux distributions are insecure "out of the box", and many of the supplied packages are already out of date by the time they reach the shelves. As the security of one's computer and more importantly its data is a priority concern, there are a number of steps that should be taken at the time of installation to secure one's operating system as well as to help identify attempted or successful attacks.

These steps are listed below and each is expanded on in detail in the sections that follow.

Installation and configuration of an effective firewall
The (automatic) updating of all installed packages
Stopping and disabling of all unnecessary services
Locating and removing/altering unnecessary SUID/SGID's
Logwatch and Tripwire

1. Installing and Configuring a Firewall

A properly configured and effective firewall policy is not only your first line of defense but it is also your most important. Any potential (remote) attacker that cannot breach your firewall will not be able to exploit any of the possible vulnerabilities of the underlying services that are protected by it.

The firewall should be set-up before you connect you new Linux installation to the internet for the first-time. Configure it to deny all incoming packets except those that are ESTABLISHED or RELATED. This will provide maximum protection while you carry out the rest of the steps to secure your installation. Once you have completed all of the steps you can then configure your firewall policy as you require.

I introduced the basic concepts of iptables, the built-in firewall of the Linux kernel, and gave a number of example configurations for various scenarios in "Firewalling with netfilter/iptables" from issue #103 of the Gazette. I strongly recommend you read through this article and use it to complete this step.

2. Update All Installed Packages

A standard Linux distribution can come bundled with well over 1,000 packages and many of these will have had newer versions released by the time you install them. Most of these updates will be feature enhancements and bug fixes, but some will also be security fixes, and some of these security fixes may be serious. Ensuring that all of the installed packages are at their newest versions is not just a job at installation but rather one that must be continued throughout the lifetime the new installation. This can be a very time consuming job and luckily there are a number of utilities that can do this for us automatically. The two most common utilities used are APT (Advanced Package Tool) and Yum (Yellowdog Updater, Modified).

Some distributions may provide their own utilities and in those cases you may find it easiest to just install them and use them as pre-configured. For example RedHat and Fedora distributions come with up2date and the Debian distribution uses APT by default.

If you have or want to install one yourself I would recommend APT which can be used with any RPM-based Linux distribution. You will also need to locate a repository containing the new/updated packages for you distribution from where APT can download and install them. A quick internet search with the name of your distribution and 'apt' or 'apt-get' should locate an APT binary RPM and a repository for you. See the links following this article for some useful sites and repositories.

Once you have APT installed and the repositories set-up (usually /etc/apt/sources.list or similar), its use is trivial and involves only two commands (run as root):

$ apt-get update
$ apt-get upgrade

The first command downloads the latest package information from the repository and the second uses this information to download and install newer versions of already installed packages if available. These commands should be performed regularly to ensure your system is always up-to-date.

If you wish to ensure maximum security you should always try to use official repositories containing signed packages; this is best accomplished by using the default auto-updater supplied by the more popular distributions. When downloading individual packages and files from the internet, always try and use md5sum (c.f. man md5sum). An MD5SUM is a hash/checksum of a file and most download sites publish the MD5SUMs of the files they have available for download; comparing these with the ones you generate from the downloaded file will help ensure that you have an not downloaded a trojaned version of the package/file.

Finally, you should strongly consider subscribing to your distribution's security mailing list. These are usually low-volume lists and you will be informed by e-mail whenever a new package is released that fixes a vulnerability.

3. Stop and Disable All Unnecessary Services

A new installation of many Linux distributions will have many services/daemons configured to start each time you boot your machine. Some of these might include the HTTP (web server), POP3/IMAP (e-mail) daemons, a database server, etc. Many of these will be unnecessary for many users and can offer a potential attacker many routes to infiltrate your new operating system. You should go through each of them and stop and disable all of those you don't need.

The bigger and more common distributions will probably have a GUI application for configuring these services; try looking in the Settings or System menus of your desktop's application menu for this.

On RedHat systems, the command line utility for configuring services is called chkconfig. To list the current status of all installed services, execute (as root):

$ chkconfig --list

which will generate something similar to:

iptables        0:off   1:off   2:on    3:on    4:on    5:on    6:off
sshd            0:off   1:off   2:on    3:on    4:on    5:on    6:off
sendmail        0:off   1:off   2:on    3:on    4:on    5:on    6:off
httpd           0:off   1:off   2:on    3:on    4:on    5:on    6:off
 ...             ...     ...     ...     ...     ...     ...     ...
 ...             ...     ...     ...     ...     ...     ...     ...
smb             0:off   1:off   2:off   3:off   4:off   5:off   6:off
squid           0:off   1:off   2:off   3:off   4:off   5:off   6:off
xinetd based services:
        chargen-udp:    off
        rsync:          off
        chargen:        off
          ...           ...
          ...           ...
        sgi_fam:        on

The numbers (0 through 6) preceding the colons represent the system "run-levels" where the two of usual concern are 3 and 5; if your system boots to a console (no GUI) then it runs in level 3 whereas if it boots to a GUI it runs in level 5.

To enable a service (say squid) in run-levels 2,3,4 and 5 we would execute (as root):

$ chkconfig --level 2345 squid on

and to disable a service (say sshd) in levels 3 and 5 we would execute (as root);

$ chkconfig --level 35 sshd off

If you do not know what a particular service that is enabled is or does then try an internet search or try using the man command with the service name as a keyword (man -k). Some of the GUIs may offer an explanation of what the services are.

The chkconfig command will enable/disable services the next time you boot your computer but it won't have any effect on whether or not a service is currently running. Under RedHat, we use the service command as follows:

$ service service_name start
$ service service_name stop
$ service service_name restart
$ service service_name status

where service_name is the same as those reported by chkconfig --list.

You can run netstat -l after disabling all unnecessary services to ensure you got them all (it checks what sockets are listening for connections). For the services which you do keep running, ensure that they are correctly (and restrictively) firewalled and configured.

4. Locate and Remove/Alter Unnecessary SUID/SGID's

A SUID (set user ID) or a SGID (set group ID) program is one that allows an ordinary user to execute it with elevated privileges. A common example is the passwd binary which, among other functions, allows an ordinary user to change their login password. However, these passwords are stored in a file that can only be altered (and sometimes read) by the root user and, as such, non-root users should be unable to change their passwords. The access privileges for this binary are:

-r-s--x--x  1 root root 18992 Jun  6  2003 /usr/bin/passwd

As you can see, the owner execute bit is set to 's' instead of the usual 'x', making the binary SUID; i.e. when an ordinary user executes passwd, it will run with the privileges of the file's owner - in this case the root user.

Many SUID/SGID executables are necessarily so, such as passwd above. However many others are not. SUID/SGID programs can be exploited by malicious local users to gain elevated privileges on your system. Run the following command as root to find all of these executables:

find / \( -perm -4000 -o -perm -2000 \)

or for a more detailed list use:

find / \( -perm -4000 -o -perm -2000 \) -exec ls -ldb {} \;

We must now go through this list and try to reduce these files that are owned by root or in the root group to the bare minimum by either removing unnecessary SUID/SGID binaries and/or removing the SUID/SGID bit.

Packages containing SUID/SGID executables that you are unlikely to use can be removed by first finding the package with, say, rpm -q --whatprovides /usr/sbin/kppp and then removing it with rpm -e package-name.

The SUID/SGID bit can be removed with, for example, chmod -s /usr/sbin/kppp. The executable can then be run by the root user when needed.

5. Logwatch and Tripwire

Although we may do our best to secure our system, the reality of the situation is that no matter how much effort we make we will never be completely secure. Rather than burying our heads in the sand and hoping for the best, there are a few other things we can do to ensure that we know if and when our system is compromised.

One intrusion detection program that is often underestimated and under used is Tripwire (http://www.tripwire.org/). This program checks your system's files periodically to see if they have been changed. If any have that should not have, Tripwire will generate a report for you to act on. Tripwire takes a little time to configure and set up properly but it is well worth the effort; Tripwire helped me to identify an intrusion on a server I was administering a couple of years back. I will cover the proper installation and configuration of Tripwire in next month's article.

An invaluable source of information on what is going on in the background of your computer are the log files (usually in /var/log). All logging on a Linux system is handled by the syslogd daemon and its configuration file /etc/syslog.conf. The configuration file specifies what facilities or subsystems to record messages from (e.g. cron, daemon, mail, etc), what level of messages to log (e.g. debug, info, warn, etc) and what to do with these messages (append to log file, send to printer, etc). If you wish to change the default configuration you will find a lot of information in the various man pages (syslogd(8), syslog.conf(5), syslog(2), syslog(3) and more).

Syslog also allows remote logging; placing your log files on another networked system. The advantage of this is that if your system is compromised by someone they will be unable to remove their steps from your logs making the tracing of their origin and their actions all the easier.

Unfortunately there is far too much information in the various log files for the average user to assimilate each day and for this reason we turn to Logwatch. Logwatch (http://www.logwatch.org/), as described by its authors, "parses through your system's logs for a given period of time and creates a report analysing areas that you specify, in as much detail as you require."

Logwatch is installed with most common distributions as standard and by default it will usually generate daily reports and e-mail them to the root user. As these reports are usually short they should be read every day. They will highlight, depending on its configuration, such information as invalid login attempts, network connections to various daemons such as SSHD, possible port scans, etc. Its configuration file is usually located in /etc/log.d/conf/logwatch.conf and it is well documented with comments to help you out.

There are a number of other intrusion detection systems you might like to consider, such as Snort - http://www.snort.org/, and you can easily find them with a quick internet search.

Closing Remarks

Security is not something that you consider at installation and then put on the back burner; rather it must be something that is always on your mind in everything you do; whether it be ensuring your system is up-to-date, ensuring proper password policies, governing whom you grant access to your system to and what level of access, reading your daily logs, checking the tripwire reports, reading the security mailing list of you Linux distribution, etc. There is an old saying that is hugely relevant to computer security: "A chain is only as strong as the weakest link". It can just take one lapse of effort or concentration on your part to open one security hole and all your effort will be wasted.

This article covers the basics - the important procedures that every user should do. There is always more that can be done but each person will have to weigh up the potential advantage against the cost in terms of the time and the effort involved.

Some final nuggets of advice:

Never ever use telnet, ftp or any other plain-text remote sessions that involve typing a user name or a password. You should always and only use ssh, sftp and similar utilities.
Have different user names/passwords for logging into unencrypted (http) and encrypted (https) web pages and never ever use the same user names and passwords that you use for logging into your computers.
Always use a restrictive firewall policy; DROP all connections be default and only open those you need in an as restrictive manner as possible. For example if you need to ssh into your computer from work and no where else then only allow your work-based IPs through.

A Note on Last Month's Article

Thomas Adam pointed out a potential conflict in my article last month (" Automatic Backups with rsync and Anacron", Linux Gazette #104). In the article I had crontabs such as:

00 02 * * * rsync -r -e ssh --delete /home/username/mail
[email protected]:/backups/mail
...

Thomas rightfully informed me that "this could cause a few issues if one is already running some kind of "ntp" check, since the task running at precisely 02:00 could clock skew. This would cause the scheduled rsync process above to get reloaded by cron multiple times or even not at all. Therefore, it is best to offset the time to either a few minutes before the hour, or a few minutes afterwards."

Thanks for pointing that out. And, as always, I welcome all feedback, compliments and criticism. You'll find my e-mail by clicking on my name at the top of this article.

Next month:

The ins and outs of Tripwire.

[BIO] Barry O'Donovan graduated from the National University of Ireland, Galway with a B.Sc. (Hons) in computer science and mathematics. He is currently completing a Ph.D. in computer science with the Information Hiding Laboratory, University College Dublin, Ireland in the area of audio watermarking.

Barry has been using Linux since 1997 and his current flavor of choice is Fedora Core. He is a member of the Irish Linux Users Group. Whenever he's not doing his Ph.D. he can usually be found supporting his finances by doing some work for Open Hosting, in the pub with friends or running in the local park.

Copyright © 2004, Barry O'Donovan. Released under the Open Publication license unless otherwise noted in the body of the article. Linux Gazette is not produced, sponsored, or endorsed by its prior host, SSC, Inc.

Published in Issue 105 of Linux Gazette, August 2004

<-- prev | next -->