Linux Security – Is it Ready For The Average User?

There seems to be a new important security patch out for Linux every month, lots of “do not use this program” warnings, too many articles and books with too little useful information, high-priced consultants, and plenty of talk about compromised systems. It is almost enough to send someone back to Windows. Can the average Linux user or system administrator keep his or her system secure and still have time to do other things? I am happy to say yes and here is how to do it.

The Five Keys To Locking Your Linux System Down

Really, there are only five things needed to keeping a Linux system secure. This goes for both servers and client systems — desktops and laptops. The first is to keep up-to-date with patches. This is easy to do yet is critical. First, pick a distribution that provides timely security patches, which is most Linux distributions. Mandrake, SuSE, Slackware, Gentoo, and Red Hat all do this as do most other Distros. If your Distro and version of it does not provide prompt security patches (within 48 hours) upgrade or switch Distros.

Some vendors refuse to provide patches for any given release after a short time, forcing you to upgrade to new versions more frequently, sometimes at great cost but always at an inconvenience. Also, Red Hat now charges for security patches on a per-system basis. Factor this into your selection of vendors.

The only alternative if patches for your system are not available in a timely manner from the Distro is to download the sources yourself, e.g., from www.kernel.org/mirrors/, httpd.apache.org/download.cgi, etc. and build and install yourself. Red Hat’s Enterprise series does not always release timely patches. By the way, if you are not running the 2.6.11.6 or 2.4.30 kernels, it is time to upgrade (unless your vendor has back-patched a previous kernel that you are running).

Red Hat was the first to come out with a program that you can run to automatically check for new patches and install them, the up2date program. It works well so simply enable it if you use Red Hat. If you run a different Distro that has an equivalent program, use it. SuSE has yast2. Fedora has yum. Gentoo has emerge. The gentoo.org web site has great documentation to help beginners get started with emerge.

An alternative, used by some Distros such as Slackware is to invite you to subscribe to a mailing list alerting you to new patches. You then can decide which ones affect you and then download and install applicable patches. You can subscribe to Slackware’s by hitting:

www.slackware.com/lists/

Deciding which to install usually is obvious. If you do not use it and it does not run set-UID then it is not a risk. I generally will remove the program or set its permissions to 0 if I am not going to patch it to prevent a problem if someone “accidentally” tries to use it later.

You Call That A Password?

Pick good passwords. A password should be at least 10 characters long and should not consist solely of one or two words in any dictionary. It should not consist solely of lower-case letters or solely of digits. Do not get around the one- or two-word prohibition via the trivial changing of the letter ‘o’ to the digit ‘0’ or the letter ‘l’ to the digit ‘1’, etc. Hackers know that trick too.

Do not use obvious numbers such as 3.1416 or 42, words like secret, root, or wheel, a word repeated, names from science fiction, or names or other data from your current personal life, such as your girlfriend’s or pet’s names, automobile tag, or phone number. Use two or three unrelated words or names interspersed with two or three non-alphanumerics or something equally hard to guess or brute-force crack.

Don’t Blame Sendmail

The third key to good Linux security is not using programs in an insecure way and not using insecure programs. After a less than stellar security history, Sendmail now rarely suffers a security vulnerability being discovered. In defense of Sendmail, it predates the modern Internet and widespread hacking by about 20 years.

Sendmail now will check for obvious configuration errors when it starts up and will refuse to operate until the poor configuration is fixed or if you set the “dontblamesendmail” flag. This is a very clever solution to allow someone who really wants to – and presumable knows what he is doing or has a death wish – to disable Sendmail’s minimum security checks. Yet, one hardly could set this flag accidentally.

Most of the major subsystems that come with Linux, such as Sendmail, the Apache web server, and the Samba file server come with abundant documentation and default configuration files that usually need just a tiny bit of tweaking to help you configure the subsystem correctly.

Some programs cannot be made secure and must not be used, no way, no how. Heading this list is NFS and its cohorts, portmap, and the Sun Remote Procedure Call (RPC) library that still are turned on by default on some Linux Distros. Unless NFS and portmap are thoroughly protected with firewalling, they should not be used. Period. Number two on the list is PHP. I realize that many web sites have lots of time invested in PHP but I’m sorry, it continues to have security bugs discovered frequently and these affect even those using it “properly”. Find another solution or risk being hacked. I have dealt with such a likely hacked site as recently as last week.

These days, most systems other than mail servers do not receive email via SMTP (TCP/IP port 25). Thus, please do not allow Sendmail to listen on port 25. This is done by not including the “-bd” when invoking Sendmail. For Red Hat and Mandrake, edit the /etc/sysconfig/sendmail file and change:

DAEMON=yes

to

DAEMON=no

and restart sendmail with the command:

/etc/rc.d/rc3.d/*sendmail* restart

If you really do not want to have to blame Sendmail, use Postfix instead and turn off Sendmail’s set-UID bit and run it set-GID to a dedicated group instead to prevent someone else from taking advantage of its next vulnerability to be discovered. Note that Postfix is standard on SuSE now.

It Is Better To Ask Forgiveness Than Give Permission

The fourth key to keeping your Linux system secure is to use the most restrictive file permissions that you can that still allows it to operate normally. Number one here is to ensure that almost no files (including most directories and device files) have world write permission. Do not trust your Distro to have done this — most get it wrong. I do the following to check for world-writable files:

find / ! -fstype proc -perm -2 ! -type l -ls > find.log

Exceptions to the no world write access include the /tmp/., /var/tmp/., and /usr/tmp/. directories that have permissions of 1777 and tty devices. Do not even grant world read permission normally to files whose contents are confidential or group permissions unless it makes sense to do so.

It also is important to disable programs that have their set-UID or set-GID bits set if they are not needed. This is because if a hacker can get non-privileged access, say by cracking a user’s password by brute force guessing, he may be able to become root by taking advantage of a vulnerability in a program that is set-UID to root. This can be done by invoking the following commands:

find / ! -fstype proc -perm -4000 ! -type l -ls > find_uid.log
find / ! -fstype proc -perm -2000 ! -type l -ls > find_gid.log

Then, disable those that are not needed. They probably will include /usr/bin/rcp, /usr/bin/rsh, /usr/bin/rlogin, and /usr/bin/sperl5.6.1. The problem with simply removing them or even just doing a chmod on them is that you may want to undo your work later, even if you absolutely never will need them. I discovered this the hard way with sperl, a version of perl designed to support set-UID perl scripts. I was trying to install a security patch on the regular perl program. Unfortunately, Red Hat’s up2date program is not very smart and refused to install the new version of perl unless sperl also was present.

Fortunately, I could undo my work – just long enough to install the patch and to re-disable sperl. My technique is to create a directory called “off” in each directory that has a set-UID or set-GID program that I wish to disable. I create the “off” directory to be owned by root mode 700. Then, I just move the affected programs into their respective “off” directories. For example, one could do the following as root:

cd /usr/bin
mkdir off
chmod 700 off
mv rcp rsh rlogin sperl5.6.1 other stuff off/.

Forget about telnet and non-anonymous FTP too. Use ssh, scp, and sftp instead.

A Notable Exception

A notable exception is the list of programs that you will need but which should not be set-UID. The mount and umount programs constitute this list. They only need to be set-UID if you want to allow ordinary users to mount and unmount file systems. Not you? Good. Secure them by doing:

chmod 755 /bin/mount /bin/umount

Do Not Run Your Daemons As Root To Run Off Hackers

The only reason why most network daemons need to run as root is to open the well-known port for listening when the port number is less than 1024. Some daemons, such as Apache and named (DNS) can be configured so that once they open that port and do a little housekeeping, they will switch to run as a non-privileged user. Absolutely take advantage of this feature. Apache usually is set up to do this by default. Verify this by running the following command and verify that only one of the Apache daemons, the one whose PPID is 1, is running as root:

ps axl | grep httpd

The named program should be invoked with the -u flag to cause it to switch to run as an unprivileged user after opening its well-known port of 53 under both TCP and UDP. Even better would be to also use its -t flag to put it in a chroot jail. Many Distros now do this. Note that only an organization’s DNS servers need to run named. Desktop and laptop systems usually should not run named. Note too that chroot jails cannot contain root processes since they can chew through the bars.

Good Security Is Like Good Health

To improve your health, stop smoking, eat a balanced diet, and lose weight. Following that advice alone will greatly improve your health. Likewise, taking the advice in this article will improve your system’s security health substantially.

As with health, for those who want to improve their security more, there is no limit as to how far one can go. How far one should go depends on how important it is to not be broken into. For those that want to do more, please see my book:

“Real World Linux Security: Intrusion Detection, Prevention, and Recovery” 2nd Ed., Prentice Hall, (C) 2003, 848 pages, ISBN: 0130464562. Also available in Japanese, Chinese, Czech, and Polish.

Bob Toxen (interview) has 30 years of UNIX and 10 years of Linux experience, helped create Berkeley UNIX and ported UNIX to the Silicon Graphics workstation.