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.
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 xinetdOn 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:
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
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:
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.
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 FileThe 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:
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 ControlYou 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:
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 ConsiderationsYou 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. |