Securing Your Linux Server

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. 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. 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. Part of the
"r" suite, should be disabled immediately.

talk, ntalk

Unix talk. Disable the
service unless you plan to use it. 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. 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. 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. 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.