Using inetd

Using inetd

Normally, a server runs and ties itself to a specific port (a resource identified by protocol type and a number between 1 and 65,535). Incoming requests are directed to specific ports associated with particular server types. For instance, Simple Mail Transfer Protocol (SMTP) mail servers conventionally use TCP port 25, and Hypertext Transfer Protocol (HTTP) servers (Web servers) normally use TCP port 80.

The inetd program is one of two common super servers for Linux. These are servers that function as intermediaries; instead of running the target server itself, the computer runs the super server, which links itself to the ports used by all of the servers it needs to handle. Then, when a connection is made to one of those ports, the super server launches the target server and lets it handle the data transfer. This has two advantages over running a server directly. First, the memory load is reduced; a super server consumes little RAM compared to the servers it handles, particularly if it handles many servers. Second, the super server can filter incoming requests based on various criteria, which can improve your system's security. The drawback is that it takes time for the super server to launch the target server, so the time to connect to a server may be increased, although usually only by a second or two. As a general rule, it's good to use super servers for small or seldom-used servers, whereas big and frequently used servers should be run directly.

The /etc/inetd.conf File Format

You can configure inetd through the /etc/inetd.conf file. Aside from comments (lines that begin with a pound sign, # , that inetd ignores), inetd.conf consists of a series of lines, each of which defines a single server. A sample line resembles the following:

 telnet  stream  tcp  nowait  root  /usr/sbin/tcpd  in.telnetd 

Each line consists of a series of fields, which are separated by spaces or tabs. The meaning of each field is as follows :

• Server name ” The first field is the name of the server protocol, as recorded in /etc/services . In the case of the preceding example, the server protocol name is telnet , and if you check /etc/services , you'll see that this name is associated with 23/tcp ”in other words, TCP port 23. There must be an entry in /etc/services in order for inetd to handle a server. For this reason, you may need to edit /etc/services if you want inetd to handle some unusual server. In most cases, though, /etc/services has the appropriate entries already.

• Socket type ” The second field relates the network socket type used by the protocol. Possible values are stream , dgram , raw , rdm , and seqpacket .

• Protocol type ” The third field is the name of the protocol type, which in this context means a low-level network stack protocol such as TCP or UDP. Possible protocol values appear in /etc/protocols , but the most common values are tcp and udp .

• Wait/Nowait ” The fourth field takes just one of two values, wait or nowait , and is meaningful only for datagram ( dgram ) socket types (other socket types conventionally use a nowait value). Most datagram servers connect to a socket and free up inetd to handle subsequent connection attempts. These servers are called multi-threaded, and they require a nowait entry. Servers that connect to a socket, process all input, and then time out are said to be single-threaded, and they require wait entries. You may optionally add a number to these values, separated by a period, as in wait.60 . This specifies the maximum number of servers of the given type that inetd may launch in one minute. The default value is 40 .

• Username ” You can tell inetd to launch a server with a specific user 's privileges. This can be an important security feature, because restricting privileges for servers that don't require extensive access to the system can prevent a bug from causing a security breach. For instance, the Apache Web server usually doesn't need unusual privileges, so you could launch it as nobody or as some special account intended only for Apache. The preceding example shows the username as root because root privileges are needed to launch the login processes required by a Telnet server. If you add a period and a group name, the specified group name is used for the server's group privileges. For instance, nobody.nogroup launches a server with the username nobody and the group nogroup .

• Server program ” The sixth field specifies the name of the server program that inetd launches when it detects an incoming connection. The preceding example gives /usr/sbin/tcpd as this program name. In reality, tcpd is not a server; it's the program file for the TCP Wrappers program, which is described shortly. Most Linux distributions that use inetd also use TCP Wrappers, and so launch most inetd -mediated servers through tcpd . You can bypass TCP Wrappers for any server you like, although it's generally best to use TCP Wrappers for reasons that are described shortly.

• Server program arguments ” The final field is optional. When present, it contains any arguments that are to be passed to the server program. These arguments might modify the server's behavior, tell it where its configuration files are, and so on. In the case of servers launched through TCP Wrappers, the argument is the name of the ultimate target server, such as in.telnetd in the preceding example. (You may add the ultimate server's arguments to this list, if it needs any.)

You can edit /etc/inetd.conf using any text editor you like. Be sure that any new entries you create, or existing ones you modify, span a single line. (Long filenames, server arguments, and the like sometimes produce lines long enough that some editors will try to wrap the line onto two lines, which will cause problems.) If you need to add an entry for a server you've installed, consult the server's documentation to learn what its inetd.conf entry should look like. In some cases, you can model an entry after an existing one, but without knowing what values to enter for the server name, socket type, and so on, such an entry might not work.

Most distributions that use inetd ship with an /etc/inetd.conf file that contains entries for many different servers. Many of these entries are commented out, so they're inactive. You can activate a server by uncommenting such a line, if the matching server is installed. Some inetd.conf files include multiple entries for any given service; for instance, a file might have two or three different entries for different FTP servers. If yours is like this, be sure you uncomment only the line corresponding to the specific server you've installed, such as ProFTPd or WU-FTPD.

TIP

One of the first things you should do after installing Linux is to go through /etc/inetd.conf (or the xinetd configuration files, as described shortly) and comment out entries related to servers you don't need. A good rule of thumb is to eliminate any entries you don't understand; Linux doesn't need any of the servers listed in inetd.conf to boot, although it may need some to accept network logins. Eliminating unnecessary servers improves your security by limiting avenues of attack available to undesirable outsiders. Unfortunately, you can't do the same thing with SysV startup scripts, because many of these start vital nonnetwork services upon which Linux relies to do useful things.

Using TCP Wrappers

As mentioned earlier, TCP Wrappers functions as an intermediary between inetd and the ultimate target server. The reason for doing this is security: TCP Wrappers can apply rules to determine whether or not a given connection should be allowed, thus protecting the server from unwanted accesses. For instance, suppose you want to allow only people on your own local network to access your computer's Telnet server. If you were running the Telnet server directly, it would have to be programmed to reject unwanted accesses , but not all servers include such code. Placing the responsibility for limiting access in TCP Wrappers extends the flexibility of the system without requiring extensive rewriting of all your server programs.

TCP Wrappers is controlled through two files: /etc/ hosts .allow and /etc/hosts.deny . These files have identical formats, but they have opposite actions ” hosts.allow specifies computers that are to be allowed access to the computer, with all others denied access; hosts.deny specifies computers that are to be denied access, with all others allowed access. When a server is listed in both files, hosts.allow takes precedence. This allows you to set a restrictive policy in hosts.deny but override it to grant access to specific computers. For instance, you could disallow access to all computers in hosts.deny , then loosen that restriction in hosts.allow . If a server isn't specified in either file (either explicitly or through a wildcard, as discussed shortly), TCP Wrappers grants access to that server to all systems.

NOTE

In some ways, TCP Wrappers is similar to a local firewall, as discussed in Chapter 25, Configuring iptables. A firewall provides broader-based protection, but TCP Wrappers can provide both redundancy in case of a firewall failure and a few features that iptables can't provide, such as the ability to filter based on an NIS netgroup name.

As with many other configuration files, a pound sign ( # ) at the start of a line indicates a comment. Other lines take the following form:

  daemon-list  :  client-list  

The daemon-list is a list of one or more servers to which the rule applies. If the list contains more than one server, commas or spaces may separate the server names. The names are those listed in /etc/services . The ALL wildcard is also accepted; if the daemon-list is ALL , then the rule applies to all servers controlled by TCP Wrappers.

WARNING

Remember that not all servers are run through TCP Wrappers. Thus, an ALL wildcard for the daemon-list may not apply to all servers run on the computer. Similarly, listing a server in daemon-list won't protect it unless the server is run through inetd and TCP Wrappers or uses TCP Wrappers directly.

The client-list is a list of computers that are to be allowed or denied. As with the daemon-list , the client-list can consist of just one entry or a list separated by commas or spaces. You can specify computers in any of several ways:

• IP addresses ” You can list complete IP addresses, such as 10.102.201.23 . Such an entry will match that IP address and that IP address only.

• IP address range ” There are several ways to specify ranges of IP addresses. The simplest is to provide fewer than four complete bytes followed by a period. For instance, 10.102.201 . matches the 10.102.201.0/24 network. You can also use an IP address/ netmask pair, such as 10.102.201.0/24 . IPv6 addresses are also supported, by a specification of the form [ n : n : n : n : n : n : n : n ]/ len , where the n values are the IPv6 address and len is the length in bits of the range to be matched.

• Hostname ” You can provide a complete hostname for the computer, such as badcracker.threeroomco.com . This will match that computer only. Because this method relies upon a hostname lookup, though, it's subject to problems if your DNS servers go down or if the person who controls the domain modifies its entries.

• Domain ” You can match an entire domain or subdomain much as you can match a single hostname. The difference is that you must precede the domain name with a period, as in .threeroomco.com ”this example matches all the computers in the threeroomco.com domain.

• NIS netgroup name ” If a string is preceded by an at symbol ( @ ), the string is treated as a Network Information Services (NIS) netgroup name. This method relies upon your network having a functioning NIS configuration.

In addition, the client-list specification supports more wildcards than does the daemon-list specification. Specific wildcards you may use include the following:

• ALL ” This wildcard matches all computers.

• LOCAL ” This wildcard is intended to match all local computers, based on hostname. If the computer's hostname lacks a period, it's considered local.

• UNKNOWN ” This wildcard matches computers whose hostnames aren't known by your name resolution system.

• KNOWN ” This wildcard matches computers whose hostname and IP addresses are both known to the system.

• PARANOID ” This wildcard matches computers whose names and IP addresses don't match.

These last three options should be used with care, since they usually depend upon proper functioning of DNS, and DNS can be unreliable because of transient network problems. For instance, if a client's own DNS system is down or inaccessible, you might be unable to verify its hostname. As an example of a short but complete /etc/hosts.allow file, consider the following:

 telnet,ftp : 192.168.34. dino.pangaea.edu ssh : LOCAL .pangaea.edu 

The first line specifies identical restrictions for the Telnet and FTP servers, allowing access only to the 192.168.34.0/24 network and the host called dino.pangaea.edu . The second line applies to SSH and restricts access to local computers and all those in the pangaea.edu domain. Because no other servers are listed in the daemon-list fields, TCP Wrappers doesn't block access to any other server. For instance, if you were to run Apache through inetd and TCP Wrappers, everybody would be granted access to Apache with this configuration.

In addition to matching entire computers, you can use the user @ computer form to match individual users of the remote system. This form, however, requires that the client computer run an ident (aka auth ) server, which returns the name of the user who is using a given network port. Your own server can query the client's ident server about the connection attempt, thus getting the username associated with that attempt. This may cause additional delays, however, and the information often isn't particularly trustworthy, especially from random hosts on the Internet. (You're more likely to want to use this feature to control access from specific users of systems that you control.)

The EXCEPT operator is another special keyword; it specifies exceptions to the rules just laid out. For instance, consider the following /etc/hosts.deny entry:

 www : badcracker.org EXCEPT [e-mail] 

This example denies access to the Web server to all the computers in the badcracker.org domain, unless the connection is coming from [e-mail] . (Because /etc/hosts.allow takes precedence over /etc/hosts.deny , entries in the former can also override those in the latter.)

If your goal is to run a very secure system, you may want to begin with the following /etc/hosts.deny file:

 ALL : ALL 

This blocks access to all computers for all servers handled by TCP Wrappers. You must then explicitly open access to other servers in /etc/hosts.allow . You should open access as little as possible. For instance, you might only give access to computers in a specific network block or domain for sensitive servers like Telnet. (Telnet passes all data in an unencrypted form, so it's a poor choice for logins over the Internet as a whole. See Chapter 13, Maintaining Remote Login Servers, for a discussion of this issue.)