Taming the Daemons Within

Starters

Articles

Advanced

Resources

Interact

Corel & Linux

Linux Products

Linux Careers @ Corel

In the Press

Taming the Daemons Within
By Paul Hankes Drielsma

“When your daemon is in charge … wait, and obey.“ –Rudyard Kipling

In the traditional UNIX® world, the roles of the user and system administrator are rigidly defined and are separated by the simple fact that members of the former group lack the privileges needed to perform the tasks of the latter. Linux®, however, is bringing UNIX to the home workstation and, in so doing, is blurring this distinction. Many Linux users do their own system administration and must, therefore, do their own “taming” of the many Linux “daemons”.

To the ancient Greeks, a daemon was a protective spirit that presided over a person’s destiny. In UNIX circles, however, daemon stands for Disk And Execution MONitor. Daemons are server processes that are responsible for offering certain services. They run in the background and generally lie dormant until a process—either local or remote—calls upon them.

An important task for any Linux system administrator is the selection, installation and maintenance of daemons. This task can be simplified to some degree. For example, one could elect to routinely install all 40+ daemons, thus always enabling all system capabilities and avoiding the pesky challenge of anticipating which ones will actually be required. One cost of such a broadbrush approach of course, is the adverse effect it can have on system performance, as each running daemon requires a share of system resources. While this share will generally be small for a dormant daemon, it represents used memory and processor time nonetheless. If your ISP runs a domain name server for its users, why would you sacrifice resources to run named offering that same service?

Redundant daemons offering network services may also pose unnecessary security risks. If your machine is purely stand-alone, this will not be an issue. However, Linux is a dish best served networked and network protection is important.

One key to optimizing both the performance and the security of your Linux system, therefore, is knowing which daemons are really required. A quick look at a few common daemons will lead us to some useful techniques for optimizing your Linux system.

The syslog System Daemon
Perhaps the most important pair of system daemons, syslogd and klogd provide utilities for logging system and kernel messages respectively. Both local and remote logging are supported, and each message is classified by type and degree of urgency. This allows the sysadmin to specify the action to be taken for each type of message. For example, all mail-related messages could be redirected to a mail log, while kernel messages of a certain urgency might be displayed directly to the console. These definitions are in /etc/syslog.conf (see syslog.conf(5)). The logs produced by these utilities (usually found in /var/log) will often be your first resource for detecting security holes in your system, so they should be closely monitored.

Ironically, syslogd itself poses somewhat of a security risk, as it can be exploited to execute denial of service attacks by generating so many messages that the resulting log files fill up the hard disk. This is documented in syslogd(8), which also offers preventative strategies.

Network Service Daemons
Network daemons listen for incoming connections on a certain port (defined for each service in /etc/services). When one comes in, the server spawns a child process to handle it, while the parent process continues to listen for more connections. This, however, is inefficient. A daemon running for each port on which a service is offered would mean a great deal of system overhead. Instead, we run a single server which listens to all ports simultaneously and refers service requests to the appropriate server daemon.

inetd and its Services
Appropriately named the “Internet Super-Server”, inetd is the most important of the network daemons. Upon startup, it reads the /etc/inetd.conf (see inetd.conf(8)) configuration file, which describes the available network services and the server daemon that handles each one. Entries in this file have the following format:

Sample entries for the ftp and telnet services might look like this:

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

We can see that upon receiving an ftp request, inetd will refer it to the ftp daemon, whose path is /usr/bin/in.ftpd. It will pass ftpd the arguments in.ftpd - l -a.

This “super-server” itself cannot do anything except this simple referral of service requests. It neither logs them nor checks for any sort of authorization. The tcpd daemon, which is part of a package called tcp_wrappers, extends this functionality to make network services more secure. As described in tcpd(8) it works by “tricking” inetd into running tcpd rather than the usual server for the service requested. It logs the request, performs some access control checks, and only after it has been determined that the host requesting the service is authorized does it run the normal server to handle the request. So the lines from /etc/inetd.conf that we looked at above now become:

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

We can see in the <program> field, that tcpd is being called and passed the name of the normal server as a parameter.

Access control is performed by tcpd via the hosts.allow and hosts.deny files (in /etc), which allow the system administrator to specify which hosts are allowed to access which network services (see hosts_access(5)).

Non-inetd Services
Some network services do not fall under the purview of inetd. These are started at boot time by the startup scripts in /etc/rc.d and operate according to the “one daemon to listen to one port” scheme described previously. Here are a few of the better known non-inetd servers:

dhcpd: Dynamic Host Configuration Protocol server

httpd: The Web server daemon of which Apache is the most popular

named: The DNS server

sendmail: The most common mail transport agent, for receipt and delivery of e-mail

Security Tips
With all these (and indeed, many more) daemons available, how can one develop a viable security scheme? Here are some basic tips …

1. Disable insecure or unnecessary daemons
For inetd controlled daemons, simply comment out the line relating to that service in the /etc/inetd.conf file by placing a “#” at the beginning of the line. Then get inetd to reload its configuration by sending it the HUP signal. To do this, as root, execute:

# killall -HUP inetd

For other daemons, remove the symlink to the related startup/shutdown script from the /etc/rc.d/rcX.d directory (where X is your default run level). This will prevent the service from being loaded at boot time. If you do not reboot, the service will still be running, but can be easily stopped by first calling the script for it with the “stop” parameter. For example, in my /etc/rc.d/rc5.d directory I see the script S85httpd, which is responsible for starting and stopping Apache. If I wanted to disable Apache, I would simply execute the following:

# /etc/rc.d/rc5.d/S85httpd stop
# rm /etc/rc.d/rc5.d/S85httpd

So which daemons should be disabled? First, disable the ones you are not using. If you do not need these services, you are less likely to keep aware of updated versions of the daemons that may contain security fixes. Otherwise, disable any services that may pose security threats. Here are a few good candidates taken partly from Aeleen Frisch’s Essential System Administration:

finger, cfinger, systat, netstat: These can give out information about your system that can be useful to crackers.
tfp, bootps: The “trivial file transfer protocol” is used to transfer world-readable files between machines without any authentication. This is often used to boot diskless machines over a network, but it poses a serious security risk. It should be disabled unless absolutely needed (i.e. your machine will serve as a boot server). Similarly, bootps relates to remote booting of machines.
rexec: The rexec utility allows for remote program execution. It is a documented security risk and should generally be disabled.
uucp, pop-2, pop-3, imap: These services can usually be safely disabled. The latter three are seldom required, unless you are running a mail server.

2. Do not give daemons more permissions than they need
Some daemons need to run as the root user while others do not. Daemons such as ftp and news have their own UID under which the server program runs. Still others run as the user nobody. These tend to be the servers which may pose security risks such as finger, and httpd. If a given server does not need to be run as root, restrict its privileges to only what is absolutely necessary.

3. Secure remote access with ssh
ssh stands for secure shell. It provides secure remote access to machines over encrypted connections. The ssh package comes with both sshd (the daemon) and ssh (the client program). It is far more secure than tenet or rsh. In fact, if you choose to install it, you may want to disable these and enforce a “secure connections only” policy.

4. Monitor your logs
This cannot be stressed enough. Logs will generally be the first indication of a security problem.

Conclusion
A system can never be 100 per cent secure. Much like a burglar breaking into a house, if a cracker wants in badly enough, he or she will probably find a way. However, a good set of easy-to-follow practices is the first step towards a secure workstation and can thwart all but the most dedicated of crackers. After all, you lock the doors and windows of your house, so why not be just as careful with your system?

Paul Hankes Drielsma is a full-time student of computer science. He has been a user and advocate of Linux for five years and is particularly interested in system administration and security issues. He can be reached via e-mail at drielsma@home.com.

Disclaimer: The information provided on Linux.Corel.com is intended to be general information related to Linux issues. Articles reflect the opinion of the author and do not imply sponsorship, endorsement or approval by Corel Corporation.

Send e-mail to Webmaster