name type protocol wait−status uid server arguments
The fields in the inetd.conf entry are:
Field Meaning
name The name of a service, as listed in the etcservices file.
type The type of data delivery service used, also called socket type:
stream The TCP byte stream delivery service. dgram The UDP packet datagram delivery service.
raw
The direct IP datagram service. protocol
The name of a protocol, as listed in the etcprotocols file. wait−status The value for this field:
wait
inetd waits for the daemon to release the socket, before it begins to listen for more requests
nowait inetd can immediately begin to listen for more requests on that socket Generally, datagram−type daemons require wait, and stream−type daemons require
nowait.
uid The user name under which the daemon runs usually root.
server
The full pathname of the daemon started by inetd. For some small services, the value of this field can be internal, because it is more efficient for inetd to perform such
services internally than to start an external daemon.
arguments These are any command−line arguments that should be passed to the daemon when it is started.
When an entry is added into the etcinetd.conf file, special attention should be paid that all entered data are well defined. Does the executable program of the added service reside in the specified
path? Is the service name listed appropriately in the etcservices file? inetd must know precisely the port number for where to listen for incoming requests for a new service. The protocol name must
also be listed appropriately in the etcprotocols file, etc.
Some of the entries in the presented etcinetd.conf file are commented; obviously, the corresponding services are disabled. There is no need to delete an entry, it is sufficient simply to
comment the entry out. It is common to disable services that carry any potential security risk, for example: tftp, or finger. On some systems, even very popular applications such as telnet and ftp
could be disabled.
15.5.2 Further Improvements and Development
The super−server inetd is fully utilized on every UNIX platform. However, many new network client server applications bypass the super−server and provide their own self−running daemons on the
server side. The main reasons are an unavoidable time−overhead in invoking the application through the inetd daemon and the possible overload of the super−server for very busy applications.
The side effect was that inetd did not grow as expected by grow it means the area of its responsibility, remaining more or less the same in size since it was introduced.
Another disadvantage with the original super−server is that inetd is supporting mostly old−fashioned applications maybe a more appropriate term is early UNIX applications that existed
at the time when UNIX merged with TCP IP network. Despite the fact that these applications are
362
However, often we need a specific discriminated application and we are ready to accept the security risk because of its usage. Modern UNIX flavors addressed this problem by introducing an
additional layer known as access control facility for Internet services between inetd and the application itself. Instead of invoking an application directly, inetd invokes another wrapper
program tcpd which provides additional checkup of received request, and then starts the application itself. The basic concept is quite simple — two files are assocoated with tcpd to
configure a flexible checkup of eligible requests for specific services. Files etchosts.allow and etchosts.deny enable a selective approach to each of the listed services regarding the eligible
hosts that requests are coming from. By default, everything is allowed as old good inetd has done, but by modifying these files, different scenarios are possible. Obviously by restricting an
access to the certain application only from certain hosts, the security risks could be dramatically reduced, while a needed service is provided.
This idea originates from Linux. However, the following example is from Solaris 2.8 also known as Solaris 8. Several new or better, modified inetd.conf entries are presented in bold:
cat etcinetd.conf
ident inetd.conf 1.44 SMI SVr4.0 1.5 Configuration file for inetd1M. See inetd.conf4.
..... .....
IPv6 and inetd.conf By specifying a proto value of tcp6 or udp6 for a service, ine td will
pass the given daemon an AF_INET6 socket. The following daemons have been modified to be able to accept AF_INET6 sockets
ftp telnet shell login exec tftp finger printer and service connection requests coming from either IPv4 or IPv6−based
transports. Such modified services do not normally require separate configuration lines for tcp or udp. For documentation on how to do this
for other services, see the Solaris System Administration Guide. You must verify that a service supports IPv6 before specifying proto as
tcp6 or udp6. Also, all inetd built−in commands time, echo, discard, daytime, chargen require the specification of proto as tcp6 or udp6
The remote shell server shell and the remote execution server exec must have an entry for both the tcp and tcp6 proto values.
Ftp and telnet are standard Internet services. ftp stream tcp6 nowait root usrsbin tcpd in.ftpd
telnet stream tcp6 nowait root usrsbintcpd in.telnetd Shell, login, exec, comsat and talk are BSD protocols.
363
..... .....
Besides the introduced usrsbintcpd program, some of the presented entries relay on IPv6 tcp6 protocol which will most probably replace tcp in the future. However, tcp6 is not in any way related
to our previous discussion. For better understanding of tcp6 protocol, please read the comments in the presented etcinetd.conf file.
The following two files are very pertinent to our discussion; files hosts.allow and hosts.deny live in the etc directory and specify hosts granted or denied for certain service.
cd etc ls −l |grep hosts.[ad]
−rw−r−−r−− 1 root other 90 Apr 6 20:00 hosts.allow −rw−r−−r−− 1 root other 9 Jan 25 23:44 hosts.deny
cat hosts.allow in.ftpd: 212.35.1.51
in.rshd: 212.35.71.97 in.rexecd: 212.35.71.97
in.rlogind: 212.35.71.97
cat hosts.deny ALL: ALL
In this example, all services are denied for all hosts, except: FTP for the host 212.35.1.51
• remote login, remote copy, and remsh for the host 212.35.71.97
• A host can be identified by its host name or IP address.
15.5.2.1 Extended Super Server xinetd Linux Red Hat 7.0 introduced a new, more versatile extended super−server named xinetd. The
extended super−server is a powerful replacement for inetd — xinetd performs the same functions as inetd, except it is doing that in a better way. Among many improvements, xinetd has access
control mechanisms, extensive logging capabilities, and the ability to make services available based on time and can place limits on the number of servers that can be started. Having all that in mind, it
is realistic to expect that other UNIX flavors would follow Linux, and that xinetd will become a common daemon on UNIX platform in the future.
The extended super−server is also more flexible in its implementation. While the basic concept of the super−server configuration remained preserved, everything is organized in a more efficient way,
making an overall configuration even easier. Individual configuration inetd entries are replaced with corresponding xinetd files that allow more detailed configuration specification. And on the top of the
configuration hierarchy is the master configuration file etcxinetd.conf. As the name xinetd resembles the old super−server, the same concept is in place for the configuration file. The new
configuration syntax is slightly different and is adapted to new requirements, but it is also self−explanatory and easy to learn. In other words it is very easy to switch from the old
super−server inetd and administer the extended super−server xinetd.
364
cat etcxinetd.conf
Simple configuration file for xinetd Some defaults, and include etcxinetd.d
defaults {
instances = 60 log_type = SYSLOG authpriv
log_on_success= HOST PID log_on_failure = HOST RECORD
} includedir etcxinetd.d
The etcxinetd.conf file defines global default values that could be overwritten in each individual configuration file if needed. However, the key directive is includedir which specifies the location of
configuration files for all implemented services. By commenting−out the directive, all services could be disabled, and then even the daemon xinetd will exit. By simple move−in move−out of the
specific configuration file toward the listed directory, the corresponding service will be enabled or disabled. And finally, each configuration file provides additional space for tuning.
Let us see the contents of the directory in this specific case:
ls −l etcxinetd.d
total 12 drwxr−xr−x 2 root root 1024 Jan 9 21:44 excludedir
−rw−r−−r−− 1 root root 289 Oct 17 17:13 echo −rw−r−−r−− 1 root root 303 Oct 17 17:13 echo−udp
−rw−r−−r−− 1 root root 361 Mar 22 23:29 rexec −rw−r−−r−− 1 root root 361 Jul 21 20:23 rlogin
−rw−r−−r−− 1 root root 414 Jul 21 20:08 rsh −rw−r−−r−− 1 root root 321 Oct 17 17:13 time
−rw−r−−r−− 1 root root 308 Oct 17 17:13 time−udp
Only listed services, i.e., services that have listed configuration files in this directory, are supported; and they are supported if they are explicitly enabled within the files themselves. Not−listed services
are definitely disabled. However, to disable or enable a certain listed service, it is easier to move the enabled configuration file into the subdirectory. excludedir this subdirectory was created later,
and its name is arbitrary, and back if we need the service again. In this example:
ls −l etcxinetd.dexcludedir
total 1 −rw−r−−r−− 1 root root 289 Jul 18 20:07 telnet
Obviously, telnet is the service that we can expect to activate later. Instead of deleting its configuration file, it is moved from the xinetd.d directory, and it remains ready for any future use.
Finally, here is an example of how the configuration files look:
cat telnet
default: on description: The telnet server serves telnet sessions; it uses \
unencrypted usernamepassword pairs for authentication. service telnet
{
365
}
The listed entries within the configuration file are very comprehensive, and they actually correspond to the already existing fields in the inetd entries, except for new functional extensions introduced by
the extended superserver xinetd.
366
Chapter 16: Domain Name System
16.1 Naming Concepts
Once a kernel is configured for TCPIP the current UNIX default setting, the network interface is set properly, and the routing table is established, the system is ready for a network communication.
A number of extremely useful network applications and services are available so that the system may benefit from the network configuration. In the past, UNIX considered networking an option;
today, networking is an integral part of any UNIX installation. Networking and network−based applications are booming today; however, it is not realistic to expect each network service to be a
default part of UNIX. The UNIX philosophy is to remain open to all newcomers, and, thanks to this concept and other related issues, UNIX is supporting networking very well. UNIX is actually the
main supporting platform for most network services.
The significance of different network applications and services varies; some network services are conditio sine qua non for other network services, while other services are optional, and are used
only by a very small segment of the UNIX community. Some network applications are important from an administration point of view, and we will refer to those network services as the core network
services.
Core network services are usually an integral part of each modern UNIX installation, and we will focus on them. Among all the core network services, perhaps the most important one is the name
service.
16.1.1 Host Names and Addresses
Each UNIX system on the network is uniquely identified by at least one IP address, and this is sufficient for systems. The machines understand these addresses very well, and they communicate
among themselves without any problem. In fact, they only understand the numerical IP addresses. However, it is not very convenient for users, who are human beings, to use numerical IP addresses
four not−logically related numbers, although there are no restrictions. For example, a user wishing to telnet to the host with IP address 128.124.128.14 can do that by entering the following command:
telnet 128.122.128.14
And it will work well. But when a user wishes to telnet to many different hosts, it would be quite hard to remember all of
the required IP addresses. Users are accustomed to using another identification mechanism, names, to identify someone or something. The name service, officially named Domain Name
Service DNS, also known as Domain Name System helps in implementing this mechanism in network communications. It is much easier for a user to establish the above telnet session using the
following command:
telnet acf4.nyu.edu
And it will also work well. DNS is basically a distributed database of host information, which, besides host names and IP
addresses, also includes some other useful information about hosts on the network. DNS makes this information available to all hosts, i.e., all users, on the network whenever they need it. By
367
