Killing Daemons!

By Jay Beale (jay@bastille-linux.org) for SecurityPortal

September 26, 2000 - If you install most Linux distributions, including Red Hat 6.x in the "Server" configuration, you'll find a number of optional system "daemons" running. Given the normal path of discovery of security vulnerabilities , one or more of these (totally optional) programs might have a bug that attackers can exploit to get root access. The problem is this: most system administrators don't know what all those programs on their systems do ! This article attempts to clear up the confusion, by describing the purpose of each of the running daemons on a Red Hat 6.1/6.x "Server" box and often giving suggestions for deactivation. While this article is a "must-read" for every Red Hat/Mandrake system administrator, executives should find this article useful as well, to get a general understanding and to help set a security policy.

Why Should I Kill Daemons?

Most Linux distributions/Unices, by default, run a number of optional background system programs, regardless of whether you need them. These "daemons" might include an FTP server, printer daemon, or NFS system. The vendor does this as a matter of convenience and ease for users. The end user doesn't have to remember how to activate the FTP server, easing phone support costs on the vendor. Unfortunately, this provides convenience to another class of people: system crackers! It radically increases their chances of cracking your system! Why?

Well, each system daemon has a probability of possessing a security vulnerability, a bug that a cracker can exploit to get access. The more activated system daemons, the higher a chance that the box has a vulnerable one. Since almost all either run as superuser (root), these are all dangerous places to have a security bug. So, we very carefully try to reduce the total number and then take steps to configure the ones that we must leave running. We're applying computer security's Principle of Applied Minimalism: reduce the number of possible paths to system compromise by reducing the number of privileged programs. Let's get to the example that forms the basis for this article, Red Hat 6.1.

Cleaning up the Server Configuration on Red Hat 6.x

The primary daemons on a Linux/Unix box are run, by init , out of /etc/rc.d/rcX.d , where X is the runlevel. On a Red Hat server machine, the default runlevel (X) is 3, so we'll examine /etc/rc.d/rc3.d . Now, many of the smaller networking daemons (telnet, ftp,pop, imap) are run via inetd , but we won't talk about that here ¹ . We'll explore each of the start scripts in runlevel 3, deciding which can be deactivated.

The Red Hat 6.x Server setup runs the following scripts from /etc/rc.d/rc3.d ². I've written them in the order that init runs them:

kudzu

This is a hardware detection program, which checks on every boot to see if you've added/removed hardware. If you won't swap hardware on this server, turn this off. I strongly recommend turning it off now, reactivating it when you make a hardware changes ³ .

Now, suppose you do want to shut this off. Since we're on a Red Hat system, we use the chkconfig command to deactivate scripts that run from /etc/rc.d/rcX.d , by typing:

# chkconfig kudzu off

This deletes the links in the /etc/rc.d/rc*.d directories, without deleting the script itself (in /etc/rc.d/init.d ), thus non-destructively deactivating the daemon on the next boot. To kill the current instance of the daemon, type:

# /etc/rc.d/init.d/kudzu stop

This process is totally portable to the other daemons. Let's look at them.

network

This script doesn't activate any new daemons, but simply activates the network interface. You need to leave this turned on, if you're on a network.

portmap

This runs the portmap daemon, which is used to allocate ports for Remote Procedure Call (RPC) services. The notable RPC services are Network File System (NFS), used to share files over a LAN, and Network Information System (NIS), used mostly to share account information among many computers. Usually, you use NFS and NIS to share user home directories among many near-identical workstations, so a user can login with the same account at any one, with his same files and home directory.

If you're not using this kind of functionality, you should deactivate portmap , along with the other NFS/NIS daemons we'll see below. If you are using this technology, I strongly urge you to stop, or at least look into more secure alternatives. NFS and NIS have experienced a number of security problems over the years. They were both designed for LANS, not untrusted networks like the Internet. If you're not able to leave these protocols behind, investigate firewalling the requisite ports, including UDP/TCP ports 111 and 2049, and be careful.

nfslock

This starts the NFS file locking service, rpc.lockd , and its companion, rpc.statd . r pc.lockd tells client machines about file locks, so no two machines try to write to the same file simultaneously. rpc.statd tells client machines if the NFS server is rebooting, so they don't go crazy during a reboot. Normal NFS operation requires both, especially rpc.lockd . Unfortunately, both have had a recent history of security problems, especially under Linux. If you're not using NFS, turn these off. If you are, please heed the warnings above, under portmap .

apmd

This is the Advanced Power Management daemon, primarily used on laptops and other battery-backed devices. It might be possible to use this with PC power management systems (resume, standby mode and such), but most servers don't use those modes. You should, generally, turn this off on all non-laptops.

Remember, even if a daemon has no significant history of security vulnerabilities, it's possible that the vulnerabilities have either not yet been found, or that they haven't been widely published. They could be trouble later - you just don't know! It's best to simply turn off unnecessary daemons and reduce the number of components that could be attacked.

random

This script simply maintains the random seed for the system. It doesn't even run any programs, besides basic file operations, so it's Pretty Darn Safe™.

netfs

This shell script mounts all NFS, SAMBA, and Novell drives (exported filesystems). It doesn't run any additional programs, but if you're not using a network-based file system, you can deactivate this one.

syslog

This starts the syslogd and klogd system logging daemons, which are essential, as they create the system logs. Leave this on!

identd

This daemon is an old, informational daemon, used by other systems to identify TCP sessions originating from the host. For example, when an IRC server gets an incoming TCP connection from port 1049 on machine http://www.securityportal.com/ , it asks the identd process on http://www.securityportal.com/ for the identify of the client user. i dentd responds, as a courtesy. There's no guarantee that the answer is right, though, since an attacker could sabotage this daemon easily. You may want to leave this enabled anyway, as a courtesy to other sysadmins - this data can sometimes be useful in tracking network abuse.

atd

This scheduling daemon schedules "jobs" for later execution. You could use at to tell atd to run "ps -ef > /root/jay " in two hours, just to find out what processes are running then. Unfortunately, there's been a rich history of security problems in the at / atd program pair. Fortunately, the same basic functionality can be found in crond , which is a wholly necessary daemon. Disable atd , and its associated program /usr/bin/at, by running:

# chkconfig atd off

# chmod 000 /usr/bin/at

crond

crond is vital. It's used to schedule jobs for later execution and has a nice wildcard/list syntax that lets you schedule repeat execution easily. For example, I could set a job to run on the 1 ^st day of the January, April, July, and October, at 4am. Most systems use crond to run cleanup programs and other system maintenance scripts in the middle of the night, when usage is low.

While cron has some security history, we can't practically deactivate it. The best thing to do is limit its use to a small group of users. To learn more about this type: man crontab and look for a reference to cron.allow .

pcmcia

This is the script that inserts pcmcia kernel modules, for PCMCIA cards on laptops. It's so odd to me that this would be activated on a server system, or by default at all! Turn this off for non-laptops! The machine shouldn't even try to load modules that don't apply and it will clean up the /etc/rc.d/rc3.d directory.

inetd

The inetd Internet "super server" is responsible for starting many of the common, small networking daemons. It only runs a given daemon when a connection comes for said daemon. For example, when the machine receives a telnet request, inetd starts up the in.telnetd daemon to answer it. This daemon would take a whole separate article to explore, though, and there are many, many articles that do just that. (Either look for one, or wait for mine!) Please take the time to learn about inetd , if you're administering a Unix box, by typing man inetd .

If your machine is offering a single protocol offered by inetd , you must leave inetd activated. If you're not sure about this, take the time to find out! Go read up on inetd , starting with the man page and followed by a perusal of the /etc/inetd.conf configuration file.

lpd

This BSD-style printer daemon maintains the print spools. If you won't be printing from this machine, turn this off and disable the print spooling programs, like this:

# chkconfig lpd off

# chmod 000 /usr/bin/{lpq,lpr,lprm}

keytable

This script loads a keyboard map and system font, but leaves no programs running. Seems pretty safe...

sendmail

This daemon is often misunderstood by Linux users, along with most new sysadmins. Firstly, you don't need this program running constantly in order to send mail from a Unix client! Pine, mutt, elm and all these other mail user agents fire up their very own instance of sendmail every time they send a message. They don't use the daemon-mode instance! The primary purpose of the sendmail program running in the background is to receive mail from external systems. Most servers only need to send mail, but not receive mail from the outside, so we deactivate daemon mode. Now, just to be safe, we could set cron to have sendmail process the (failed sent messages) queue every hour. To turn sendmail off, run chkconfig , like this:

# chkconfig sendmail off

Then, edit root's crontab to process the mail queue hourly. First, type this:

# export EDITOR=emacs ; crontab -e root

Now, add the following line:

16 * * * * /usr/sbin/sendmail -q

sendmail has had a long history of security problems. Really, it has gotten a lot safer, though there was a recent root exploit in sendmail , though this was the Linux kernel's fault. Still, this interaction presents a strong argument for minimizing the number of daemons on one machine. Any daemon might turn out vulnerable, either by itself, or when interacting with another program. The most practical way to minimize the risk is to carefully remove daemons until you get the system down to its bare essentials.

gpm

gpm is the text-mode cut and paste daemon, used to duplicate X Window's similar cut-and-paste feature. This can be helpful, but gpm had security problems recently, one of which allowed the console user to get root access! Again, I recommend stripping out unnecessary functionality. For the few minutes per week that you work on your servers' consoles, this might be useful, but it elevates your risk. Consider either turning it off with chkconfig and only activating it when you're at the console.

httpd

This is the Apache web server. If this machine is running a webserver at this very moment, leave this on. Otherwise, turn it off. This actually is a case in point of an important security policy: even if you're going to use a daemon later, turn it off, unless you're using it right now . This reduces the window of vulnerability, if the daemon later has a security hole. Further, you might not ever get around to using that daemon - better to leave it off in the meantime. Finally, you should wait until you've had a chance to properly configure the daemon for your site - remember, a large bulk of security vulnerabilities are caused by sysadmins making mistakes in configuring daemons or leaving an insecure default configuration in place ⁴.

xfs

The X Font server shares fonts with other machines, to speed up font rendering and to support TrueType style fonts. Though Red Hat's configuration is as safe as they come ⁵, the man page has this to say:

If specified, xfs will attempt to run as user and group xfs. This has been implemented for security reasons, as xfs has not been thoroughly audited for buffer overflows and may not be entirely clean.

xfs is not necessary for X to function. Further, on a server, we shouldn't need X at all. It should be safe to chkconfig this one to off.

LinuxConf

This script doesn't start any daemons - it just provides a "hook to allow linuxconf to put into place any linuxconf -specific policies." It should be safe, though you can deactivate it if you don't use linuxconf .

What About the Rest?

The remaining scripts in /etc/rc.d/init.d aren't enabled by default. I've written a one-line below on each of them, to guide your decision should you decide to turn them on:

• anacron - an enhanced cron replacement

• arpwatch - used to construct and monitor an ARP table (an ethernet card -> IP address table)

• innd - the INternet News System (INN) news server - very, very few machines need this.

• ipchains - a non-configured packet filter - leave this off for now.

• irda - the Infrared TTY manager - most machines will never use this.

• kdcrotate - a Kerberos - specific script. If you're not using Kerb., you should leave it off.

• named - the BIND name server, used to administer a DNS server. If this machine isn't one, leave this off!

• postgresql - an SQL server - leave it off, unless you're building one.

• pulse - a component of clustering services - leave it off.

• Pvm - a Beowulf program - leave this off unless you're building a Beowolf machine!

• rstatd - used to allow any machine on the network to get performance statistics on this machine - leave it off, as there have been recent bad security problems

• rusersd - used to allow any machine on the network to get a list of logged-in users - leave it off - don't give attackers so much information.

• rwalld - allows any machine on the network to send a broadcast message to every user on this machine - leave it off!

• rwhod - similar to rusersd - leave this off, as it gives an attacker too much information about your usage patterns.

• smb - runs the smbd and nmbd SAMBA daemons, for sharing drives with Windows machines - turn this on, if you're exporting shares.

• Snmpd - runs the supporting daemon for the Simple Network Management Protocol - leave this off, because of past/present security issues, unless you absolutely need it.

Where Do I Go From Here?

OK, so we reduced the number of system daemons. The next step is to tune the configurations of the remaining ones. We'll spend most of that time on removing unneeded functionality, at a much more granular level. If you're still running a web server, we might deactivate CGI scripts or Server Side Includes (SSI's). If you're still running an FTP server, we might remove user or anonymous access. I'll spend an article on several major servers/daemons. Stay tuned!

Footnotes

1 There are two reasons for this. First, there are already lots of articles on that. Second, that would necessitate a discussion of TCP Wrappers and we only have so much space here.

2 Actually, there are soft links to /etc/rc.d/init.d scripts - most Linux distros/Unices use symbolic or hard links to do this.

3 Reactivate the kudzu script right before you power down, then deactivate it after the boot has completed and it has detected the new hardware.

4 Simple, default passwords, anyone?

5 xfs drops privileges to user xfs shortly after starting - further, it uses a local Unix domain socket instead of TCP.

About the Author

Jay Beale is the Lead Developer of the Bastille Linux Project (http://www.bastille-linux.org/ ). He is the author of a number of articles on Unix/Linux security, along with the upcoming book "Securing Linux the Bastille Way," to be published by Addison Wesley. At his day job, Jay is a security admin working on Solaris and Linux boxes. You can learn more about his articles, talks and favorite security links via http://www.bastille-linux.org/jay .