The first step to security is to plug the holes in your Linux distribution

I’ll start this article with a disclaimer—this is not meant to be a Security How To, or how to turn your Linux server into Fort Knox. If that’s what you want, there are extensive resources on the Net that’ll help you—with most of them telling you to use OpenBSD instead!

What I’ll attempt to do instead, is help you plug the obvious holes in a brand new, out-of-the-box Red Hat Linux installation. I’ve specified Red Hat here, but this should be true for any Linux distributions too. I’ll also examine some of the common security tools available on the Net that help in detecting and preventing intrusions into your server. Finally, we’ll look at online security resources that you should monitor to keep track of the latest holes and exploits.

Closing the holes

Red Hat by default comes with several services running. You may not need all of these, and there are some that you should definitely disable. To see which services are running by default, open up /etc/inetd.conf file. You’ll see several lines such as:

# These are standard services.

#

ftp stream tcp nowait root /usr/ sbin/tcpd in.ftpd -l -a

telnet stream tcp nowait root / usr/sbin/tcpd in.telnetd,

#

# Shell, login, exec, comsat and talk are BSD protocols.

It’s highly unlikely that you’ll need all of these, though it depends on what your server is configured for. Some services, such as the "r" suite (rlogin, etc) are known security holes and the most common source of exploits. You should definitely disable them unless you know what you’re doing, and have a good reason for doing so.

I’ll list out the services enabled by default, and what they’re used for.

ftp The commonly used file transfer protocol. It’s not considered too much of a security hole, though the version that ships with Red Hat 5.2 is vulnerable to a root exploit. If you feel you’re at risk from attackers using relatively advanced methods, such as packet sniffing, you may want to disable this option.

telnet It’s commonly used for logging into remote systems. However, like ftp, all data is communicated in clear text across the network, including logins and passwords. I strongly recommend that you disable telnet and use the freely available secure shell (SSH, included on this CD) instead.

shell, login Part of the "r" suite, should be disabled immediately.

talk, ntalk Unix talk. Disable the service unless you plan to use it.

finger As described in inetd.conf, finger can give out information about local users to potential crackers. Disable it unless you’re sure you need it.

auth Runs the identd daemon used for identifying remote hosts trying to connect to your machine. Though it’s easily fooled by an IP-spoofing attack, it can still serve as a valuable source of information against casual or careless attackers.

linuxconf It’s a Web-based remote administration tool, similar to webmin. It permits easy remote configuration of the server though a Web browser.

Red Hat comes with tcp_wrappers pre-installed, as do most modern distributions. Written by the famous Wietse Venema, tcp_wrappers acts as a form of gateway for incoming connections to your host. For example, the line ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l \a in inetd.conf, causes the tcpd daemon to listen for TCP traffic on the well-known FTP port 21, log all incoming traffic through syslog, and then forward it to the actual in.ftpd daemon. You really should be running tcp_wrappers, and if your distribution isn’t using it already, you can download and install it from ftp://ftp.porcupine.org/pub/security.

There are a few systems services that are turned on through the system startup scripts (/etc/rc.d//rcX.d) under Red Hat. The actual scripts are stored in the /etc/rc.d/init.d directory, with links being made to scripts under each runlevel. On a clean system, you can run the Red Hat "ntsysv" tool to see what services have been enabled. You’ll then want to disable those that you’re sure you won’t be using, such as NFS (which can be a huge security hole if not properly configured). Additionally, Samba and proxy services should be turned on only if required, and properly configured at once. If your system’s been online for a while, and there’s a possibility that it could’ve already been compromised, it’s a good idea to examine the rc.* startup scripts and the scripts in the init.d directory to see if they’ve been modified or contain any suspicious commands.

Restrict access to your host

It’s a good idea to restrict access to your host to your local domain and a few other domains you trust. While susceptible to IP-spoofing, it’s better than leaving things out in the open. tcp_wrappers examines the files /etc/hosts.allow and /etc/hosts.deny before allowing incoming hosts to connect. It’s a good policy to explicitly deny access to all connecting hosts by default, and then selectively allow access to those which you trust.

For example, your /etc/hosts.deny could have a single uncommented line that reads

ALL:ALL.

Now you can selectively turn on access to selected services in your /etc/hosts.allow file. For example, if you want to allow anyone to connect via SSH,

sshd : ALL

will allow all hosts access to the service.

Similarly, if your local network is 192.168.1.*, you may want access to the talk service from anywhere on your LAN. The line in.talkd : 192.168.1 will do this for you. You can then additionally grant access to different services from different networks or hosts.

Configuring common services

Proxy services

The most commonly used proxy on Linux is the fast, easily configurable, and powerful Squid. Squid supports access control lists to control access to specified domains and even workstations. The minimum that you should do is to enable access to only your cache within your local domain. Else it can be used as a "piggyback" by crackers to attack other hosts, and will also consume bandwidth. You can control access to the cache in the Squid configuration file (/etc/squid/squid.conf) in the Access Control List section. You could additionally set up Squid as a transparent proxy (See Setting Up a Transparent Proxy With Squid in this issue).

Sendmail has over the years built up a reputation as a bug-ridden, error-prone security hazard in some circles. The best solution would be to upgrade to qmail, which was designed with security in mind. However, if you choose to stay with sendmail, you should use the spam control features in the sendmail.cf file to prevent abuse. Also, follow the various sendmail bug reports, and upgrade/patch regularly. As sendmail runs as root, an exploit (such as those used by the BARC crackers) can give the users root access to your system.

File and print sharing services (Samba, NFS)

NFS, like sendmail, has a long history of exploits to its credit. Unless you’re in a mixed Unix environment and can’t do without it, turn it off. If you’re using it anyway, maintain your /etc/exports file meticulously. Always add the noexec parameter to any exported file systems, prevent root write access, and make readon-only if possible.

Samba should also be configured to prevent access from any but a list of acceptable hosts. Otherwise, your machine is susceptible to the Win 95 style bug where anyone over the Internet can have full access to shared files.

File system security

Your home directories should preferably be mounted on a separate partition, with "noexec", "nodev", and "nosuid" options in /etc/ fstab. Generally, there should never be a reason for you to have SUID/SGID programs in his home directory. The default umask for your home directories (set in /etc/profile) should be 022, or even more restrictive.

It’s also a good idea to impose memory and CPU quotas on local users. In Linux these are all configurable through PAM (Password Authentication Module). For example, the following lines in /etc/pam.d/limits.conf :

@pgp1 hard core 0

@pgp1 hard rss 5000

restricts the memory usage of your (belonging to the pgp1 group) programs to 5 MB and prevents the creation of core files. You can additionally enable quota support to restrict your disk space usage.

You should also keep track of all SUID/SGID programs on the server, as these are most likely to be left behind by a cracker who gains access to your system. The command

root# find / -type f \( -perm -04000 -o -perm -02000 \)

will list all SUID/SGID files on your system. Run it once at install time, and subsequently compare the output with the output of a daily cron job running the same command, and monitor for any unnecessary or new files.

TripWire (also on this month’s CD) is a good tool to use to monitor any modifications in system binaries. TripWire maintains a checksum of all important binaries on the system, and compares them against a checksum of previously taken "safe values", such as those taken on install. You can configure TripWire to run daily as a cron job and mail you any discrepancies.

When installing any new software on your system as root, download it from one of the official mirror sites if possible. In any case, before installing, check the file integrity using the MD 5 checksum against the author’s or distributor’s PGP key (which should also be available from the original site). There have been occasions in the past when files on public FTP sites have been compromised, and carry trojans (such as the utils package with a trojan login).

Monitoring suspicious activity on the server

You should continuously monitor all system logs on the server for any kind of suspicious activity. Probably the most informative is /var/log/messages, which keeps a track of failed login attempts and TCP connections from outside hosts. The utmp and wtmp files keep a track of logins, and are useful for tracking any unknown users accessing the system.

Keep informed!

Subscribe to or monitor security and bug-related mailing lists (see box above) to keep up-to-date with the latest exploits and patches. Sites like www.rootshell.com, which may be the playground for "script kiddiez", are also valuable resources in keeping one step ahead of them. Remember that in the computer world, things change by the minute and the hour, not just by the day. It’s important that you have access to information critical to the security of your machine at the earliest, and that you act on such information.

Remember that this article is not meant to be a comprehensive guide to security. You should carefully analyze your own requirements and the level of security required. (For example, whether you’d like users to have simple password-based security, or a fingerprint scanner, or smartcard). These are the minimum steps you should take in order to prevent your box from attacks by casual or not very well equipped crackers.