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.