Professional Documents
Culture Documents
he Linux operating system is a cornerstone of most modern enterprise computing environments. The power,
T flexibility, and stability of enterprise-focused Linux distributions such as Red Hat, SUSE, and Ubuntu are well
known and respected. Unfortunately, the flexibility and power of Linux has a downside -- the fact that Linux
systems can support most known network protocols and services can leave them open to attack unless correctly
configured and deployed.
The dependence of modern business on Web-based interaction and Internet-oriented applications and execution
environments puts increasing demands on networking infrastructure. High-volume data requirements and new net-
work services mean that more devices and data must always be available on the network, 24x7. This constant avail-
ability is a modern business fundamental that, unfortunately, isn't limited to authorized users. Those same systems
are now always available for attacks from online intruders and other malicious users.
Modern computer systems must export an increasingly wide network profile, but only that profile. Most enterprise
Linux distributions are delivered with most network ports and services disabled, so that services must be turned on
rather than off. Regardless, double-checking some standard aspects of the network and general security configura-
tion of your systems can substantially increase system security and will certainly increase your comfort level with the
safety and security of the systems on your network.
Note
One of the problems with providing general security suggestions that apply to multiple Linux distributions is that
different Linux distributions provide different administrative tools. This guide focuses on command-line tools that
can be found, or are at least available for, any Linux distribution.
The lsof (list open files) command lists all open files on a Linux system. Its -i option tells the command to list all IP
(Internet protocol) related files, while the -n option suppresses trying to map IP addresses to host names for any
established connection. (Avoiding these improves the speed with which results are returned.) We then pipe the out-
put of this command to the egrep command, only selecting results that contain COMMAND (which gives us the
headings for the various columns), TCP (a daemon listening using the TCP protocol), and UDP (a daemon that is lis-
tening using the UDP protocol). The following is sample output from the lsof command on a Red Hat Enterprise
Linux (RHEL) 4 system:
1 Securing Linux Systems for the Enterprise, a JupiterWeb Security eBook. Copyright 2006, Jupitermedia Corp.
Securing Linux Systems for the Enterprise
This output shows that the daemons running directly on this systems are portmap (RPC port mapper), rpc.statd
(RPC status monitoring), sshd (secure shell), ntpd (network time protocol), sendmail (mail server), and cupsd (CUPS
print daemon). In addition, the xinetd Internet services daemon is running the auth (remote identification daemon),
telnet (network terminal), and vnc (virtual network computing) servers.
The netstat (network statistics) command provides very similar output when run on the same system. The -t option
produces output for all TCP/IP ports, and the -u option produces output for all UDP ports. The -l option restricts the
output to ports that are actively listening for connections. The -p option shows the program and process ID that
owns the network connection. The following is sample output from the lsof command on a Red Hat Enterprise Linux
(RHEL) 4 system:
# netstat -tulp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Addr State PID/Program name
tcp 0 0 *:32769 *:* LISTEN 1891/rpc.statd
tcp 0 0 *:sunrpc *:* LISTEN 1871/portmap
tcp 0 0 *:auth *:* LISTEN 2097/xinetd
tcp 0 0 *:vnc *:* LISTEN 2097/xinetd
tcp 0 0 localhost.localdomain:ipp *:* LISTEN 3427/cupsd
tcp 0 0 *:telnet *:* LISTEN 2097/xinetd
tcp 0 0 localhost.localdomain:smtp *:* LISTEN 2132/sendmail: acce
tcp 0 0 *:ssh *:* LISTEN 2082/sshd
udp 0 0 *:32768 *:* 1891/rpc.statd
udp 0 0 *:795 *:* 1891/rpc.statd
udp 0 0 *:sunrpc *:* 1871/portmap
udp 0 0 *:ipp *:* 3427/cupsd
udp 0 0 rhel4.vonhagen.org:ntp *:* 2113/ntpd
udp 0 0 localhost.localdomain:ntp *:* 2113/ntpd
udp 0 0 *:ntp *:* 2113/ntpd
udp 0 0 *:ntp *:* 2113/ntpd
This list provides a bit more detail, but shows the same open ports and associated services as the lsof command.
A machine's internal view of the services that it provides should match those that an outside machine would see. To
verify this, you can use the nmap (network mapping) command from another system. The -sT option does a TCP
port scan, while the -sU option does a UDP port scan. Scanning the same machine from another system produces
output like the following:
2 Securing Linux Systems for the Enterprise, a JupiterWeb Security eBook. Copyright 2006, Jupitermedia Corp.
Securing Linux Systems for the Enterprise
Though the nmap command can't identify the services associ- Numerically, that pales compared to the 11,000
ated with ports 631 and 795, the local machine output from the Kaspersky found for Windows in the second half of 2005
lsof and nmap commands shown previously identifies these as alone. However, it could be more devastating because
a print daemon and the rpc.statd command, respectively. many non-Windows users assume malware is only a
Windows problem and don't take any precautions.
Kaspersky said Linux users are careful, but one security
Given that all of this output agrees, the next step is to analyze
expert disagrees.
the services that are available to determine whether they are all
necessary and, if not, what to do about them: "With Linux users, there's a very vigilant effort to make
sure the system is as secure as possible, mostly because
• First, the cupsd (print) and sendmail (mail server) daemons Linux people are very aware of security dangers and the
shown in the netstat and lsof output not visible in the nmap security that needs to be put in place," said Shane
output. The netstat and lsof output confirms that they are Coursen, senior technical consultant with Kaspersky's
only listening on the local loopback interface, and are there- U.S. office in Woburn, Mass.
fore not accessible from outside the machine and should not
"The other thing is that there are people who have transi-
pose a security problem. If performance is an issue for the
tioned from Windows to Linux, thinking Linux would pro-
machine you're analyzing, sendmail is useful for local mail vide them more security, and they make sure their new
delivery, but you may want to terminate the CUPS daemon if Linux system is secured," he added.
no one will be printing from this machine.
But Tom Ferris, researcher with Security Protocols, a
• The ssh (secure shell) daemon provides a secure mecha- computer security research firm in Mission Viejo, Calif.,
nism for remote logins and supports encrypted communica- said the opposite. "In people's minds, if it's non-Windows,
tion, so that's fine. it's secure, and that's not the case," he said. "They think
nobody writes malware for Linux or OS X. But that's not
necessarily true, as that report showed."
• The telnet daemon (network terminal) represents an older
protocol used to establish remote connections, and typically The growth in Linux malware is simply due to its increas-
uses unencrypted communications. Some newer versions of ing popularity, particularly as a desktop operating system,
telnet support secure authentication and communication said Coursen.
mechanisms such as Kerberos, but regardless, this is an
unnecessary service because SSH is also supported, and we "The use of an operating system is directly correlated to
should therefore shut this down. the interest by the malware writers to develop malware
for that OS," he added.
• The rpcbind (port mapper) and rpc.statd (port 795) dae-
The Kaspersky report said that the Unix picture mirrors
mons are only useful in NFS environments. If the machine
that on the Win32 front. The biggest problems are exploits
we're analyzing is not an NFS client, these should be shut and back doors designed to steal information. There are
down. also sniffers, flooders and other hack tools. While rootkits
get all the headlines, Coursen said the biggest problems
• The auth daemon can be useful in analyzing problems net- will still be exploits and Trojans.
work clients, but can also provide intruders with information
about the users of your systems. However, some FTP and --Andy Patrizio, InternetNews.com
other network clients essentially require it. It should either be
3 Securing Linux Systems for the Enterprise, a JupiterWeb Security eBook. Copyright 2006, Jupitermedia Corp.
Securing Linux Systems for the Enterprise
disabled or started with its -n option, which causes it to display numeric user IDs rather than user names.
• The ntp (network time) daemon is used to synchronize the clock across systems on a network, but has been
exploited in the past. We'll replace this daemon with running the ntp -q command once at boot time, which
queries and synchronizes with a time service once and then exits.
• The omad daemon on port 32768 is initially puzzling, but cross-checking against the lsof and netstat output
shows that port 32768 is actually being used for rpc.statd queries, and therefore should be eliminated by shutting
down the rpc.statd daemon. This daemon is being misidentified by nmap.
The next step in this process is to go to the machine that we're analyzing and determine where and when these
daemons are being started, so that we can terminate any we have identified as being extraneous (cupsd, portmap,
rpc.statd, telnet, vnc), and modify the behavior of any others (authd, ntpd) whose behavior we want to modify.
Note
Red Hat Enterprise Linux systems, such as the one being used as an example in this guide, provide a command
(chkconfig) that identifies the run levels at which various services are being started. This guide focuses on more
generic, distribution-independent mechanisms for deriving that information.
Most modern Linux systems use what is known as the SysVInit mechanism to start different systems at different run
levels. A central collection of scripts that start all available system services is stored in the directory /etc/init.d. The
services associated with different run levels, typically 0 through 6, are identified in each of the directories /etc/rc0.d
through /etc/rc6.d, and are actually started and stopped via symbolic links to the main scripts stored in the
/etc/init.d directory. The symbolic links for scripts that start services when a run level is entered begin with the letter
'S' (start), followed by a sequence number that reflects the order in which they are started (in ascending order). The
symbolic links for scripts that stop services when a run level is entered begin with the letter 'K' (kill), followed by a
sequence number that reflects the order in which they are stopped (in descending order). This mechanism is known
as "Sys V Init" because the ancestor of this system start-up approach was first introduced on AT&T System V Unix
machines.
To locate the scripts that are used to start various services, change to the directory /etc/init.d and list its contents.
You will see something like the following:
# ls
acpid FreeWnn mysqld rpcidmapd
amd functions named rpcsvcgssd
anacron gpm netdump rstatd
apmd haldaemon netdump-server rusersd
arptables_jf halt netfs rwhod
arpwatch hidd netplugd saslauthd
atd hpoj network sendmail
auditd httpd NetworkManager single
4 Securing Linux Systems for the Enterprise, a JupiterWeb Security eBook. Copyright 2006, Jupitermedia Corp.
Securing Linux Systems for the Enterprise
Looking through this list, it's easy to spot start-up scripts for services such as cups, ntpd, and portmap, since the
names of the start-up scripts are evocative of their associated services. However, it's unclear which script is associ-
ated with the rpc.statd daemon. We can use grep to determine this:
# grep rpc.statd *
nfslock:[ -x /sbin/rpc.statd ] || exit 0
nfslock: daemon rpc.statd "$STATDARG"
nfslock: killproc rpc.statd
nfslock: status rpc.statd
nfslock: /sbin/pidof rpc.statd >/dev/null 2>&1; STATD="$?"
We therefore need to disable the cups, nfslock, and portmap scripts so that they are not executed when we reboot
our system. We will also want to modify the ntpd script so that it executes ntpd differently.
A system's default run level, which is a way of referring to the specific collection of scripts and services that it starts
when it boots normally, is determined by the line containing the initdefault keyword in the file /etc/inittab. On a RHEL
system, this line looks like the following:
Different Linux distributions associate different logical meanings with the run levels 2 through 6, but the mechanism
is the same regardless of the services that are started at various run levels. For example, the default run level on a
Ubuntu Linux server is run level 2, as shown by the following:
Once you know your system's default run level, you can go to its associated directory and remove the symbolic
5 Securing Linux Systems for the Enterprise, a JupiterWeb Security eBook. Copyright 2006, Jupitermedia Corp.
Securing Linux Systems for the Enterprise
links that are associated with the services that you no longer want to start. In this example, this is the directory
/etc/rc5.d, because this sample RHEL system boots tom run level 5 by default.
Though these are only symbolic links, it's a good idea to keep track of which services you have manually disabled,
to make it easy for other system administrators to see the changes that you have made to a given machine from its
default configuration. To simplify this, create a directory called DISABLED and move the symbolic links to this direc-
tory, rather than just deleting them.
# mkdir DISABLED
# ls *nfslock *portmap *cups
S13portmap S14nfslock S55cups
# mv *nfslock *portmap *cups DISABLED
You should repeat this process for other run levels that may start these same services. Here's how you can find a
complete list:
# cd /etc
# find {init,rc}.d -name "*nfslock*"
rc.d/init.d/nfslock
rc.d/rc0.d/K86nfslock
rc.d/rc5.d/K86nfslock
rc.d/rc5.d/DISABLED/S14nfslock
rc.d/rc2.d/K86nfslock
rc.d/rc1.d/K86nfslock
rc.d/rc3.d/K86nfslock
rc.d/rc5.d/S14nfslock
rc.d/rc4.d/K86nfslock
rc.d/rc5.d/S14nfslock
rc.d/rc6.d/K86nfslock
This shows that the nfslock script is also being called at run levels 3 and 4, where you should disable it using the
same mechanism. You would then run this same command to identify other run levels at which the cups and
portmap scripts were called and disabled those using the same mechanism.
If you are using a system such as RHEL that provides a run level configuration tool, you will also want to use that
tool to disable the system's notion of what services are associated with various run levels. In this case, you would
execute that command to disable the specified service at all run, as in the following example:
Other Linux distributions, such as Ubuntu and Debian, provide similar tools such as the BootUp Manager (BUM).
6 Securing Linux Systems for the Enterprise, a JupiterWeb Security eBook. Copyright 2006, Jupitermedia Corp.
Securing Linux Systems for the Enterprise
As mentioned earlier, we want to modify the behavior of the network time protocol daemon, ntpd, so that it only
executes a single query when you boot the system rather than running the daemon continuously, and then synchro-
nizes daily thereafter. To do this, we'll either want to modify the /etc/init.d/ntpd script or any associated data files, or
change how the system invokes the ntpd daemon. We'll do the latter, which is a bit cleaner.
First follow the instructions in the previous section to remove the ntpd command from all run levels. Next, edit the file
/etc/rc.local, which is a start-up script that is executed as the last step of the boot process. Add the line
/usr/sbin/ntpd -q before the last line of the file so that it looks something like this (it will be different depending on
your distribution):
#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.
/usr/sbin/ntpd -q
touch /var/lock/subsys/local
Your system will now execute the /usr/sbin/ntpd -q command as essentially the last command in its start-up
process each time you reboot this system.
Next, we want to make sure that the system runs the same command once a day after it has been booted, so that
the system clock never gets too far from the real time. To do this, we'll use the cron command to schedule regular
execution of the ntpd -q command, in this example on a daily basis. To do this, execute the crontab -e command to
edit the table of command scheduled for regular execution and add the following line to the file:
Note: All of the quotes in this example are single back-quotes, which cause the command enclosed between
each pair of them to be executed.
This entry will execute the /usr/sbin/ntpd -q command at five minutes after midnight every day, and will append an
entry to the file /var/log/cron_ntpd.log that consists of a timestamp and the output of this command. We can then
monitor this log file to see how much readjustment was necessary and increase the frequency of this command, if
necessary. (You can consult the online reference page for the crontab command for more information about the for-
mat of a crontab file by executing the command man 5 crontab.)
One of the capabilities originally introduced with xinetd are known as TCP wrappers. This is a library that is transpar-
ent to the end user but provides system administrators with fine-grained control over the hosts that can (or cannot)
access a specific network service and associated daemon. The TCP wrappers library does this by checking the files
/etc/hosts.allow and /etc/hosts.deny for any restrictions on the hosts that can access a service before allowing a
connection to be established. The TCP wrappers concept has proven to be so useful that most modern Linux dis-
tributions compile all network daemons, including standalone daemons such as sshd and NFS daemons such as
portmap, with the TCP wrappers library.
7 Securing Linux Systems for the Enterprise, a JupiterWeb Security eBook. Copyright 2006, Jupitermedia Corp.
Securing Linux Systems for the Enterprise
The configuration files for all daemons that are managed by the xinetd daemon are located in the directory
/etc/xinetd.d. This directory contains the following files on a sample RHEL system:
# ls
amanda daytime gssftp rexec tftp
amandaidx daytime-udp klogin rlogin time
amidxtape dbskkd-cdb krb5-telnet rsh time-udp
auth echo krb5-telnet.rpmsave rsync vnc
chargen echo-udp kshell swat
chargen-udp eklogin ktalk talk
cups-lpd finger ntalk telnet
The files in this directory are text files that contain start-up instructions for each associated service. Each of these
files contains an entry that identifies whether the associated service is disabled on the target machine. To double-
check which of these services are actually enabled, you would execute commands like the following:
# cd /etc/xinetd.d
# grep disable * | grep no
auth: disable = no
krb5-telnet: disable = no
vnc: disable = no
The output will be different on your system, but should look fairly similar. This shows that the auth daemon, a
Kerberos-enhanced version of the telnet daemon, and the vnc server are all started in response to incoming
requests on the ports that they are associated with. As noted earlier, we want to disable the telnet and vnc servers,
and modify the behavior of the auth daemon. This section explains the former; modifying the behavior of the auth
daemon is explained in the next section.
To disable services so that they are not started by the xinetd, simply edit each file in a text editor and change "no" to
"yes" in each disable entry. After doing so, the control file for the auth daemon should be the only file in this directory
that will be managed by xinetd after a reboot.
The next section explains how to modify an xinetd control file so that the command is still executed on-demand, but
works differently.
service auth
{
disable = no
socket_type = stream
8 Securing Linux Systems for the Enterprise, a JupiterWeb Security eBook. Copyright 2006, Jupitermedia Corp.
Securing Linux Systems for the Enterprise
wait = no
user = ident
cps = 4096 10
instances = UNLIMITED
server = /usr/sbin/in.authd
server_args = -t60 --xerror --os -E
}
In this example, we simply want to add the -n option to the authd command line, which you would do using your
favorite text editor, so that the modified file would look something like the following:
service auth
{
disable = no
socket_type = stream
wait = no
user = ident
cps = 4096 10
instances = UNLIMITED
server = /usr/sbin/in.authd
server_args = -n -t60 --xerror --os -E
}
After saving this file, the next time that the xinetd is restarted, authd requests will no longer return and display user
names, but will return and display numeric user identifiers instead. The same functionality will still be present, but
less information about your system will be exposed over the network.
Now that's more like it: a lean, mean, networked machine. To verify how remote systems see this example host,
probing the system from another machine using nmap confirms that a much more limited set of services are now
available to other machines:
9 Securing Linux Systems for the Enterprise, a JupiterWeb Security eBook. Copyright 2006, Jupitermedia Corp.
Securing Linux Systems for the Enterprise
This verifies that the sample system is much less exposed to the network. Reducing the number of available servic-
es on a given system also has the fringe benefit of returning the amount of memory required by those services to
the pool that is available to the system itself.
Summary
The biggest step that you can make towards ensuring the security of a networked system is to reduce the number
of open ports and associated services that the system makes available over the network. This guide provided a
number of examples of how to eliminate extraneous services that are started as part of the system start-up process
and which are managed by other daemons on a machine, such as the xinetd.
This guide was written by Bill von Hagen. Copyright 2006, Jupitermedia Corp.
JupiterWeb eBooks bring together the best in technical information, ideas and coverage of important IT trends
that help technology professionals build their knowledge and shape the future of their IT organizations. For more
information and resources on IT security, visit any of our category-leading sites:
www.esecurityplanet.com
www.antionline.com
www.internetnews.com/security
www.earthwebnews.com/security
www.enterpriseitplanet.com/security
www.insideid.com
www.smallbusinesscomputing.com
www.linuxtoday.com/security/
For the latest live and on-demand Webcasts on IT security, visit: www.jupiterwebcasts.com/security
10 Securing Linux Systems for the Enterprise, a JupiterWeb Security eBook. Copyright 2006, Jupitermedia Corp.