Angels and Daemons


Because SLES multitasks, there are always some programs running in the background that take care of the system-related tasks, such as executing cron and at jobs and watching out for and servicing network requests. These background processes are referred to as daemons.

THE ORIGIN OF THE WORD DAEMON

Some references indicate daemon (pronounced dee-man or day-man) is an acronym for Disk And Execution Monitor. However, the word was actually first used by Professor Fernando J. Corbato and his Project MAC (http://en.wikipedia.org/wiki/MIT_Laboratory_for_Computer_Science) team back in 1963 to reference the background processes on the IBM 7094 mainframe. The reference was inspired by one of the "thought experiments" about thermodynamics conducted by the famous nineteenth century Scottish physicist James Clerk Maxwell (famous for Maxwell's equations of electrodynamics). In this experiment, Maxwell suggested that there exists an imaginary agent (a daemon) that helped sort molecules of different speeds and worked tirelessly in the backgroundan apt analogy to the various housekeeping tasks inside a multitasking computer operating system. (Visit http://ei.cs.vt.edu/~history/Daemon.html for more information.)

The Unix community adopted use of the word daemon, which in Greek mythology is a supernatural being that exists between gods and men, to describe the various background server processes that serve users (men) on behalf of the kernel (god). As a result, most of the server applications (such as the FTP server) have d appended to their filenamefor example, ftpd; this serves to separate them from the client applications (such as ftp for the FTP client).


Instead of having various server services (such as FTP) started at system initialization time (which would slow down the server boot process) and be dormant until a connection request arrives (taking up unnecessary resources), a special daemon process is started and listens on all service ports for the services listed in its configuration file. When a request comes in on a port for which there is an "active" server listed in the configuration file, this monitor daemon starts the appropriate server. Furthermore, this monitor daemon can provide additional security if the service does not. Because of the way this server operates, it is generally referred to as the super-server. The drawback of running a frequently accessed service under the super-server is the slight delay caused by the super-server in starting up the service every time it is required.

There are two implementations of this super-server: inetd (Internet services daemon; pronounced eye-net-d) and xinetd (Extended Internet services daemon; pronounced zy-net-d). inetd has been widely used since the early days of Unix. However, in recent years, xinetd is much more popular due to its extended functions such as access logging, enhanced access control, and IPv6 support. For example, although inetd allows control for TCP connections using Wietse Venema's TCP_Wrappers software (tcpd, which is included on your SLES 9 media), you cannot control UDP connections. Although you can control the rate of connections using inetd, you cannot control the maximum number of instances. This could lead to process table overflow attacksfor example, an effective denial of service (DoS). xinetd does not suffer from these shortcomings. By default, SLES 9 uses xinetd instead of inetd, so that is what we discuss here.

TIP

If you have been using inetd and want to convert over to xinetd, use either the itox utility or the xconv.pl Perl script (both supplied with xinetd, but xconv.pl is generally preferred over itox) to convert your inetd.conf style configuration files to xinetd.conf. Refer to man itox and man xconv.pl for more information.


Configuring xinetd

On startup, xinetd reads several files located in /etc. The main configuration files are /etc/xinetd.conf plus all the files in /etc/xinetd.d. These files specify which daemon should be started for which service. The other files it reads are shared with other daemons and system services and contain more general information about Internet services:

  • /etc/services This file maps port numbers to service names. Most of the port numbers below 1024 are assigned to special (so-called well-known) services (see http://www.iana.org/assignments/port-numbers) and are listed in this file. Every time you refer to a service by its name (as opposed to its port number), the name is looked up in /etc/services and the assigned port number is used to process the request.

  • /etc/protocols This file maps protocols to the numbers the kernel uses to distinguish between the different TCP/IP protocols. The list is based on http://www.iana.org/assignments/protocol-numbers.

  • /etc/rpc Similar to /etc/services, this file maps Remote Procedure Call (RPC) services to their ID numbers and common names.

Generally, you don't need to touch any of the files in the preceding list. When you do, the likely candidate for changes is /etc/services, where you'll add the port(s) used by some custom daemons not already listed in the file or if you need a specific service to run on a port other than its accepted default for some reason.

You can configure services supported by xinetd in two ways: using YaST or working directly with the configuration files. Although YaST provides a friendly user interface, you can modify certain options only by editing the configuration files directly. Therefore, we cover both procedures here.

To access the xinetd configuration module in YaST (see Figure 8.1), select Control Center, Network Services, Network Services (inetd). Alternatively, you can access this module directly by using yast2 inetd or yast inetd. Note that some of the menu text shows inetd even though you are using xinetd.

Figure 8.1. The xinetd configuration screen.


The top of the screen shows whether the super-server is running (Enabled) or not (Disabled). The list box on the screen shows the defined services and their current run status. Of particular interest are the columns labeled Ch, Status, and Server.

TIP

You can check to see whether xinetd is running by using the command /etc/init.d/xinetd status or the following:

 Athena:/home/admin # ps ax | grep xinetd 32369 ?        Ss     0:01 /usr/sbin/xinetd 20857 pts/8    R+     0:00 grep xinetd 

The first line shows xinetd is currently running as a detached system process (that is, no terminal attached) and its process ID (PID) is 32369. Similarly, you can use the same command to determine whether any of your service daemons are running by substituting xinetd with the name of the daemon, such as in.telnetd.


The Status column shows whether the daemon is running (On) or not (---); NI means YaST knows about the package, but the package is not installed and therefore cannot be configured. If you toggle the status of the daemon (from On to Off), an X is placed in the Ch column to indicate the status of this daemon has been changed; if the Ch column is blank, the service's status has not been altered. Remember to click Finish for the new status settings to take effect.

TIP

Instead of enabling or disabling one service at a time, you can click Status for All Services and then select to either enable or disable all services with a single click.


The Server column shows the name of the daemon and the path it is running from. Some of the network services do not have a server listed under this column because xinetd provides several simple services internally through the use of built-in routines. These services are

  • ECHO This service is mostly used as a debugging tool to send any datagrams received on TCP or UDP port 7 from a source back to that source. The risk with this service is that someone can overload the server via the ECHO service, amounting to a DoS attack. RFC 862 (http://www.ietf.org/rfc/rfc862.txt) describes the ECHO service.

  • DISCARD This service is also known as SINK or NULL. It is simply a data blackhole because it throws away any datagrams (TCP or UDP) it receives on port 9. RFC 863 (http://www.ietf.org/rfc/rfc863.txt) describes the DISCARD service.

  • SYSTAT Listening on TCP/UDP port 11, the SYSTAT (better known as ACTIVE USERS or just USERS) service simply sends a list of the currently active usersusers currently logged inon the host. All inputs are ignored. RFC 866 (http://www.ietf.org/rfc/rfc866.txt) describes the USERS service.

  • DAYTIME (human-readable time) In UDP, after the daemon receives a datagram on port 13 (which can contain any data), it sends back the current date and time in ASCII format. In TCP mode, on receipt of a datagram and after the connection is established, the service sends the date and time in ASCII format and closes the connection:

     Athena:/home/admin # telnet localhost 13 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 15 JAN 2005 07:08:42 EST Connection closed by foreign host. 

    RFC 867 (http://www.ietf.org/rfc/rfc867.txt) describes the DAYTIME service.

  • NETSTAT Also known as the Who Is Up protocol, NETSTAT listens on (TCP and UDP) port 15 and returns information about the server's network information, such as routing tables and connection data. This service reveals a wealth of information about the system's structure that can be used to later hack the system. As a result, this daemon is no longer listed in the /etc/services file in most Linux/Unix distributions available today, and the protocol is obsolete.

  • QOTD Listening on port 17, the Quote of the Day service (also known as the QUOTE protocol) simply sends a short message back to the client either via TCP or UDP without regard to the input. RFC 865 (http://www.ietf.org/rfc/rfc865.txt) describes the Quote of the Day service.

  • CHARGEN (character generator) In UDP mode, CHARGEN (also known as the TTYtst or Source protocol) generates random characters in one UDP packet containing a random number (between 0 and 512) of characters. In TCP mode, the daemon sends a continuous stream of TCP packets after a connection is made on port 19, until the session closes. Any data received (either in TCP or UDP mode) is discarded. A potential DoS attack is spoofing an IP address and causing two devices to send random traffic to each other. RFC 864 (http://www.ietf.org/rfc/rfc864.txt) describes the CHARGEN service.

  • TIME (also known as Unix Time; machine-readable time, in the form of the number of seconds since midnight, January 1, 1900the Epoch)This service works similarly to the DAYTIME protocol, but instead of returning the information in ASCII form, it sends the time back as a 32-bit binary number. It can also receive time data from another host; this was the standard way to set up time servers for a Unix network before the advent of the Network Time Protocol (NTP). Port 37 is used. RFC 868 (http://www.ietf.org/rfc/rfc868.txt) describes the TIME service.

  • FINGER Also known as the NAME protocol, the FINGER daemon listens on port 79 and returns a status report on either the system at the moment or about a particular person in depth. In recent years, this service has been mostly offered through its own daemon (fingerd) instead of the built-in support in inetd/xinetd. RFC 1288 (http://www.ietf.org/rfc/rfc1288.txt) describes the FINGER service.

When inetd is initially installed, all defined services are disabled by default. Enable only the services that you absolutely require so you minimize any security weaknesses that may be exposed by a given service.

Most of the network daemons offer you the option to set them to run either as standalone applications or to be invoked by xinetd on demand. Although the setup with xinetd saves resources in the time the service is not used, it creates a delay for the client. The daemon for this service has to be loaded and probably has to initialize itself before it's ready to serve the request. You should give considerable thought about which services you want to run as standalone applications and which ones you want to be called by xinetd.

For instance, you would likely want to run a web server such as Apache as a standalone service instead of having it invoked by xinetd whenever a client request comes in on port 80. Apache needs a relatively long load time, and you don't want your clients waiting too long while your website loads. Apache is highly optimized to run in standalone mode, so you probably don't want it to be spawned by xinetd. On the other hand, a service such as Telnet (whose daemon is in.telnetd) that enables logins from other machines doesn't need much time to load. That makes Telnet a good candidate for being invoked by xinetd.

Use the following procedure to add a new service to be managed by xinetd:

1.

In the Network Services Configuration dialog box, click Add.

2.

In the Add a New Service Entry dialog box (see Figure 8.2), fill in the service name and optionally the RPC Version (if the daemon is an RPC application). Then select the desired socket type, protocol, flags, and user and group the service will run under. Enter the complete path for the location of the daemon and specify any optional command-line arguments for the daemon. Optionally, enter identification comments about this new service.

Figure 8.2. Adding a new xinetd-managed service.


3.

If the new server is to be enabled right away, ensure the Service Is Active box is checked.

4.

Click Accept to save the entry.

5.

Click Finish to save the changes and signal xinetd to use the new configuration.

6.

If the new service uses a nonstandard port or one that is not already listed in /etc/services, you need to update the file to include the new service name, its port number, and the transport type.

CAUTION

Do not use any embedded whitespace in the service name (such as Password self service) because YaST stops parsing the name at the first whitespace.


WHAT IS RPC?

RPC (Remote Procedure Call; sometimes called Open Network Computing, or ONC) is a technique for constructing distributed, client/server-based applications initially developed by Sun Microsystems for its Network File System (NFS). It is based on extending the notion of conventional, or local, procedure calling so that the called procedure need not exist in the same address space as the calling procedure: The two processes may be on the same system, or they may be on different systems connected over a network. By using RPC, programmers of distributed applications avoid the details of the interface with the network. The transport independence of RPC isolates the application from the physical and logical elements of the data communications mechanism and allows the application to use a variety of transports.

RFC 1831 (http://www.ietf.org/rfc/rfc1831.txt) describes the Remote Procedure Call Protocol Specification Version 2.


The Wait and NoWait flag selection indicates if the service is single-threaded or multithreaded and whether xinetd accepts the connection or the daemon accepts the connection. Wait indicates the service is single-threaded and xinetd will start the server and then stop handling requests for the server as the service takes over in accepting the connection. After the service dies, xinetd will listen for requests on behalf of this server again. The NoWait flag indicates the service is multithreaded and xinetd will keep handling new service requests and accept the connection.

NOTE

Generally, UDP/datagram services use the Wait flag because UDP is not connection oriented. On the other hand, TCP/stream services use the NoWait flag.


Normally xinetd runs as root. This means any process it spawns also runs as root. However, from a security standpoint, this is generally not desirable because if the process is compromised, it can cause serious damage. The User and Group settings allow you to specify that the daemon will run as a lower-privileged user. You can use either the user/group names or their respective UIDs/GIDs; however, using the names is recommended. If a group name or GID is not specified, the user's primary group is used instead.

CAUTION

xinetd must be running as root for the User and Group settings to be effective. Otherwise, it would not have sufficient privileges to switch a service's UID/GID to that of a nonprivileged account/group.


Under the User column in the Network Services Configuration dialog box, you see, for instance, name.name for some services, whereas others have only name. Where name.name is shown, the first is the actual username, and the second is the group name. For example, the amanda service's User column shows amanda.disk. That means the service runs as user amanda and group disk. Similarly, the User column for the printer service is just root. So this service will run as root, and its primary group is specified in /etc/passwd (and YaST shows the Group as --default--; see Figure 8.2).

The /etc/xinetd.conf File

The main configuration file for xinetd is /etc/xinetd.conf. The xinetd.conf file, shown in Listing 8.1, contains only the default service settings plus a reference to the /etc/xinetd.d directory, where the other service configuration files are stored.

Listing 8.1. The Default /etc/xinetd.conf File
 # # xinetd.conf # # Copyright (c) 1998-2001 SuSE GmbH Nuernberg, Germany. # Copyright (c) 2002 SuSE LINUX AG, Nuernberg, Germany. # defaults {      log_type        = FILE /var/log/xinetd.log      log_on_success  = HOST EXIT DURATION      log_on_failure  = HOST ATTEMPT #     only_from       = localhost      instances       = 30      cps             = 50 10 # # The specification of an interface is interesting, # if we are on a firewall. For example, if you only want # to provide services from an internal network interface, # you may specify your internal interfaces IP-Address. # #       interface       = 127.0.0.1 } includedir /etc/xinetd.d 

Instead of cluttering xinetd.conf with entries for various services, this file simply refers to an include directory using the includedir directive, where each file in that directory corresponds to a defined service. However, instead of using additional files, you can put the service definitions in inetd.conf.

In general, the names of the files in /etc/xinetd.d match those of the services. This makes them easier to identify. However, having matching names is not a requirement. One example is the printer service: There is not a file called printer in /etc/xinetd.d. Instead, this service is defined in a file called cups-lpd. Therefore, if you are adding services to xinetd by manually creating files, you can call them anything you likebut having the filename match the service name is helpful.

NOTE

When you create a new service using YaST's Network Services Configuration dialog box, YaST creates a file corresponding to the service name in /etc/xinetd.d. This is another reason why you should not use embedded whitespace in service names because it makes accessing the files a little more cumbersome: You would need to put quotation marks (either single or double) around the name due to the embedded whitespaces.


Each service description is in the following format:

 #comment for the service #more comment lines service servicename {      directive = value      directive += value      directive -= value } 

Using =, the values on the right are assigned to the directive on the left. The += appends values to an already-defined directive. Without it (that is, using =), earlier directives are overwritten. This symbol can also be used to spread access lists, for example, over multiple lines. The -= removes an existing value from the directive.

The following is the basic minimum set of directives required for a service:

 service servicename {      disable         =      socket_type     =      protocol        =      wait            =      user            = #     group           =      server          = #     server_args     = } 

The disable directive indicates whether the service is active (disable = no) or not (disable = yes). If disable is not specified, its value defaults to no, meaning the service is active. The group directive allows you to specify the group (thus GID) under which the service will run as. If not specified, the service will run using the default group of the UID that the service runs as. Although the server_args directive is not required by xinetd, most daemons require at least one command-line switch to control behavior.

NOTE

Because the Network Services Configuration dialog box is designed to handle both xinetd and inetd, its interface does not provide any means to edit directive values other than those listed here as the minimum set. Therefore, if you want to include additional directives (such as access control, discussed in the next section), you need to edit the file containing the service definition to manually add the required directives.


Each service inherits the directives defined in the defaults section in xinetd.conf, unless specifically modified within that service's definition. Now let's consider the following sample service definition:

 #Example service service foobar {      disable         = yes      socket_type     = stream      protocol        = tcp      wait            = no      user            = dummy      group           = dumdum      server          = /var/sbin/foobard      server_args     = -log      log_type        = SYSLOG mail notice      log_on_success  += USERID      log_on_failure  += USERID      instances       = 15 } 

When you take into account the directives in the defaults section (see Listing 8.1), the effective directives values for the foobar service are as follows:

 disable         = yes socket_type     = stream protocol        = tcp wait            = no user            = dummy group           = dumdum server          = /var/sbin/foobard server_args     = -log log_type        = SYSLOG mail notice log_on_success  = HOST EXIT DURATION USERID log_on_failure  = HOST ATTEMPT USERID instances       = 15 cps             = 50 10 

Here, the values for log_type and instances are superceded by new values, and USERID is added to log_on_success and log_on_failure. Because cps (connection per second) is specified in defaults and is not in foobar's definition, defaults' cps value is used.

Sometimes it is much more convenient to start or stop a service from the command line instead of YaST. You just need to do the following:

1.

Using an editor, open the file containing the service's definition in /etc/xinetd.d and add the directive disable = yes to stop it. To enable the service, either comment out the disable = yes line or change it to disable = no.

2.

Use ps ax | grep xinetd to determine xinetd's process ID.

3.

Send the xinetd process the SIGHUP signal using the kill command: kill -SIGHUP pid. (You can also use killproc -SIGHUP /usr/sbin/xinetd instead.)

The SIGHUP (hang up) signal causes a hard reconfiguration for xinetd, which means xinetd rereads the configuration file, starts any new services, and terminates the daemons for services that are no longer available. Alternatively, you can use /etc/init.d/xinetd reload (or /etc/init.d/xinetd force-reload) instead of the kill command. You can also use /etc/init.d/xinetd to start and stop xinetdfor instance, /etc/init.d/xinetd start or /etc/init.d/xinetd stop.

YaST does not allow you to set advanced settings, such as log_type or instances, in a service configuration file. Therefore, you need to resort to using a text editor. After modifying the configuration file, you need to restart xinetd by sending it the SIGHUP signal so the new settings take effect. If changes were made using YaST, YaST will automatically restart xinetd after you click Finish.

TIP

Instead of /etc/init.d/xinetd, you can use /usr/sbin/rcxinetd instead because it is just a symbolic link to /etc/init.d/xinetd, a shell script. As a matter of fact, you will find rcxinetd referred to often in the documentation; using it instead is probably more convenient because /usr/sbin is in root's PATH setting, while /etc/init.d is not.


Applying Access Control

You need to realize that xinetd controls connections, not packets. As such, while it would break a TCP connect() attempt from a host that is prohibited from connecting to a service, it will not, and could not, break "stealth" scans such as a FIN scan. Therefore, don't rely on xinetd to be a firewall to prevent port scanning. A resourceful hacker will be able to use this information to gather access control lists for your various services. If you see your log file showing very short connection durations (zero or just a couple of seconds) made sequentially to your active services, chances are good that someone is doing a connect()-type port scan against your server.

NOTE

In a FIN scan, scanner software, such as nmap, utilizes TCP packets with the FIN flag set to scan for open ports on a host. nmap and other security assessment and intruder detection tools are discussed in Chapter 12, "Intrusion Detection."


Access control is fairly simple and easy to implement. You can use these three directives:

  • only_from lists the networks or hosts (separated by a space between each entry) from which the service will accept connections. You can use network numbers, such as 10.0.0.0 or 10, or network names (if defined in /etc/networks), including *.UniversalExport.ca or .UniversalExport.ca with this directive. Hostnames and IP addresses of hosts also can be used here. (Refer to man xinetd.conf for a list of supported addressing schemes, including subnet specifications.)

    WARNING

    If only_from is specified without any values, all access will be rejected.


  • access_times specifies the time intervals (separated by a space between each entry) when the service is available. An interval has the form hour:min-hour:min. Connections will be accepted between the listed time window. If access_times is not specified, there is no time restriction. The times are specified using the 24-hour clock format.

TIP

Unless you can use the host's security features to lock down its IP address or use DHCP to assign a static address to a given host, it is more secure to specify networks and subnets instead of individual host addresses when setting up the only_from and no_access directives. And if you are restricting access from outside your network, use domain names whenever possible because many ISPs use a range of subnets that may change from time to time.


By default (as specified in the defaults section of xinetd.conf), successful and failed connection attempts are logged to the /var/log/xinetd.log file. This file should be reviewed periodically for failed attempts from prohibited or unknown hosts and networks, as well as successful connections from unknown sites. The following is an excerpt from /var/log/xinetd.log showing both successful and failed attempts for a number of services:

 05/1/14@09:17:18: START: telnet from=10.4.4.4 05/1/14@09:17:31: EXIT: telnet status=1 duration=13(sec) 05/1/14@11:09:21: START: telnet from=10.4.4.4 05/1/14@12:15:16: EXIT: telnet status=1 duration=3955(sec) 05/1/14@16:28:05: FAIL: echo-stream address from=10.4.4.4 05/1/14@16:28:05: START: echo-stream from=10.4.4.4 05/1/14@16:28:05: EXIT: echo-stream status=0 duration=0(sec) 05/1/14@16:28:26: START: echo-stream from=10.3.3.4 05/1/14@16:28:43: EXIT: echo-stream status=0 duration=17(sec) 05/1/14@16:29:49: FAIL: echo-stream address from=10.4.4.4 05/1/14@16:29:49: START: echo-stream from=10.4.4.4 05/1/14@16:29:49: EXIT: echo-stream status=0 duration=0(sec) 05/1/14@17:06:18: START: chargen-stream from=10.4.4.4 05/1/14@17:06:23: EXIT: chargen-stream status=0 duration=5(sec) 05/1/14@17:15:08: START: telnet from=127.0.0.1 05/1/14@17:15:08: EXIT: telnet status=1 duration=0(sec) 05/1/15@04:43:46: FAIL: echo-stream address from=10.4.4.4 05/1/15@04:43:46: START: echo-stream from=10.4.4.4 05/1/15@04:43:46: EXIT: echo-stream status=0 duration=0(sec) 

TIP

If you're interested in just the failed attempts, you can easily display all related entries by using grep:

 Athena:/home/admin # grep -i fail /var/log/xinetd.log 05/1/14@16:28:05: FAIL: echo-stream address from=10.4.4.4 05/1/14@16:29:49: FAIL: echo-stream address from=10.4.4.4 05/1/15@04:43:46: FAIL: echo-stream address from=10.4.4.4 


Security Considerations

You should be sure that you need xinetd before you set it up. A client machine that primarily acts as a workstation has no need to run xinetd because the client machine is not meant to provide any services for the network. Similarly, if your SLES server runs a dedicated service, such as DNS, there is also no real need to run xinetd. Whether you use it is basically a question of security. Using xinetd on machines on which you really don't need it may reveal possible entry points for intruders. xinetd-enabled services such as telnet and rlogin can be used to exploit your machine. This doesn't mean that those services are generally insecure, but they may be a first source of information for potential hackers trying to enter your system.

When you are using xinetd, enable only the services that are absolutely required. Typical diagnostic services such as echo and chargen can become targets for DoS attacks because their use diverts CPU resources away from other processes that will cause problems for the connected networks and Internet services dependent on that server.



    SUSE LINUX Enterprise Server 9 Administrator's Handbook
    SUSE LINUX Enterprise Server 9 Administrators Handbook
    ISBN: 067232735X
    EAN: 2147483647
    Year: 2003
    Pages: 134

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net