Daemon Process:

Daemon Process is a system process that once started leave the terminal i.e runs
in background independently of any user who is logged on.

Generally it sits behind the scene and waits for when it is to step in e.g ftp daemon
may be in the background and occupying RAM but is waiting for request to run it.

Super daemon the daemon that control other daemons. Example of super daemon
is inetd and xinetd. Internet service daemon and extended internet service daemon.

Whenever you learn about controlling access to a Linux box, one "creature" you
usually encounter is the "superdaemon." A superdaemon is a daemon that controls
other daemons--and daemons are typically network service control programs that
run long-term behind the scenes, waiting for when they need to step into action.

Introduction to inetd and xinetd

In the Linux realm, "the superdaemon" has typically referred inetd, which handles
requests for a number of daemons that either aren't used often enough to justify
running in the background all of the time, or have such a simple job that a
standalone daemon simply isn't needed. The problem with inetd is that this
superdaemon makes little attempt to be secure. It allows you to disable various
services if you don't want to use them, but there is no fine control available.

Enter xinetd (http://www.xinetd.org). This program is a "secure" replacement for

inetd, meaning in this case that it offers many features that allow you to control who
accesses which services, and from where. I always keep the Titanic in mind when I
talk about security or safety, meaning that nothing is fully secure, but any level of
native access control in the superdaemon certainly helps us to protect our systems.

Some distributions (such as Mandrake and Red Hat) currently come with xinetd
installed and enabled by default. Yours might include xinetd but not by default, or
you can download the tool from the project site.

Diference between inetd and xintedD

Let's take a look at the real differences between xinetd and inetd before we get into
using xinetd. Anyone who's dealt with the inetd superdaemon is likely familiar with
its configuration file, inetd.conf. This file contains a list of all of the services the
daemon controls, along with commented out items that it could control if you wanted
to activate those services.

That's pretty much all there is to inetd. You can control these services using
additional features of Linux itself, such as hosts.allow, hosts.deny, traffic filtering,
and so on. But for many people that's not enoughmost of the files discussed in this
article are in the /etc directory on most Linux distributions, but sometimes
distributions like to utilize a different setup, so you might have to dig for them.
xinetd has a collection of configuration files. The base file is xinetd.conf, which allows
for general configuration. Along with the main configuration file is the subdirectory
xinetd.d, which contains a series of individual files pertaining to various applications.
Each of these files is loaded by the xinetd.conf when xinetd loads its configuration
data into memory.

Within each of the xinetd configuration files you have a wide range of choices to
control where people can access a service from, what local accounts they can use to
access the service, what remote accounts they can use, and much more.

Installing xinetd (not a package rather uncomiled code)

Since there are so many distributions that don't come with xinetd already installed
by default, I'll go through the process of getting and installing xinetd from its web
site. Those who have access to this tool already or through their distribution's
package management system might prefer to install from there insteadlook for the
distribution version first, that will make your life much easier since it will ensure your
distribution knows the program is installed.

Point your browser to the xinetd site, and download the source file. You'll find that
it's remarkably small, and that the installation is a pretty standard process. To
compile and install this software, do the following:

1. Uncompress and unpackage it by typing tar xzvf xinetd-version*. You

might find as I did that, oddly, the file came through with an extra .tar on the
end. You'll need to rename the file so that it ends in .tar.gz, not .tar.gz.tar, if
that happens to you.
2. Change to the directory created during this process.
3. Type ./configure to run the autoconfiguration routine. You might be told
that you need to add particular software packages. If so, do that now, and
start Step 3 again.
4. Type make to compile the program. The speed of your machine, its RAM, and
what else you're doing all are factors in how long this process will take.
However, even on my PIII 450 it took less than five minutes.
5. Type make install to put the package and its files into place. This process
finishes quite fast.
6. If you want to base your xinetd configuration on your current inetd
configuration, then make sure you have Perl installed, and then type the
following as suggested by the xinetd team:
7. xinetd/xconv.pl < /etc/inetd.conf > /tmp/xinetd.conf

That's the first stage. Notice that your new configuration file was copied into /tmp.
Do not try to use the default file. It likely won't work.

The xinetd program has two major configuration setups. First, there's the default
configuration, which is in the file /etc/xinetd.confthough your distribution might put
this file in a different place. Then there's a group of files typically in the /etc/xinetd.d
directory that each corresponds to a different service.

We'll start with xinetd.conf. A default setup for this file might look like:
# Simple configuration file for xinetd

defaults
{
only_from = localhost
instances = 60
log_type = SYSLOG authpriv
log_on_success = HOST PID
log_on_failure = HOST
cps = 25 30
}

includedir /etc/xinetd.d

If you've only seen the inetd configuration file before, it should already be obvious
just how different xinetd setup is. Contained in xinetd.conf are your global
defaultsthough you can do individual configurations here as well. The globals are
assigned in the defaults statement, and its contents are marked off with the braces
({}). Let's take a look at the options from top to bottom:

only_from Restricts access to a service to only the specified external

machines.
instances Restricts how many simultaneous accesses to this service will be
accepted.
log_type Sets logging rules for this particular service. The options here are
SYSLOG and FILE. SYSLOG tells xinetd to utilize syslogd, the "standard" Linux
system logging daemon, and the term that follows it tells syslogd which
facility and level (see man syslogd) to utilize.
log_on_success Sets logging rules for a successfully started server instance.
The value(s) allowed are DURATION, EXIT, HOST, PID, and USERID (see man
xinetd.conf for more details).
log_on_failure Sets logging rules for when a requested server instance
cannot start, either due to bugs or the request not matching the set rules.
Value(s) allowed are ATTEMPT, HOST, and USERID (again, see man
xinetd.conf for more information).
cps Restricts the rate of incoming connections that xinetd will bother with.
The first argument is how many requests per second the server will put up
with before it disables the requested service completely. The second
argument tells xinetd how many seconds to wait before opening the port
again.

If you see the following as the last line then your xinetd is set up to look in
/etc/xinetd.d (or whatever directory is specified) for specific configurations:

includedir /etc/xinetd.d

You can add such a line as well, if needed.

When we turn our attention to the broader range of elements you might configure for
specific services, we discover that there is a long list of options. Rather than
spending the time and space covering every option in detail, I'll cover one specific
example so that we can get on to more tutorial. You can get more information about
any option, and of course the whole list of available options, in the xinetd.conf man
page.

Let's use the vsftpd xinetd configuration file:

# default: off
# description: The vsftpd FTP server serves FTP connections. It uses \
# normal, unencrypted usernames and passwords for authentication.
service ftp
{
disable = no
socket_type = stream
wait = no
user = root
server = /usr/sbin/vsftpd
nice = 10
}

Notice that this file, like all of its cousins in /etc/xinetd.conf, starts with a line in the
form service <servicename>. <servicename> is one of the items in /etc/services or
one of the other files listed in this tutorial, and refers to the basic functionality
provided by this particular tool. In the case of vsftpd, it's not hard to guess that the
service is ftp.

Inside the braces are the options for this specific service. Here I'm only going to
define what these particular settings mean. We'll get into the specifics of these
options in the tutorial. The vsftpd setup is, from top to bottom:

The port is open and the service is available.

FTP uses TCP so that it can ensure that all of the data has arrived, and so is a
streaming socket type.
Streaming sockets are typically set to no wait.
This FTP server runs as root.
This FTP server is located at /usr/bin/vsftpd.
This command runs at an average priority level.

All of these settings are in addition to what was set in xinetd.conf.

Configuring xinetd.conf or xinted.d directories

When it comes to configuring your own superdaemon, you might be much more
fussy than just accepting the defaults. The first thing you need to do is determine
which services you want to configure, because what the service is and does will tell
you what statements you must include, and what statements won't work at all.

Once you've got a list of what you want to custom configure, decide if you want to
alter xinetd.conf itself, or to create a separate file in the xinetd.d directory. I typically
recommend that if it's not global, to use the separate files. It just keeps things
neater.
Now you have to choose what you want to set for this particular service. There are
forty-four available parameters, but only two that must be set for any service. These
two are:

socket_type This entry is determined by whether the underlying protocol

used is TCP (which yields a socket type of stream) or UDP (which yields a
socket type of "dgram").
wait This entry is also determined by whether you're using TCP (not) or UDP
(yes).

The other required parameters depend on the type of service you're setting up. For
the services that xinetd does not handle for you, such as incoming FTP and web
requests, you must also have:

server The path to the program that xinetd needs to start.

server_args Only required if you need to pass flags, options, or values to the
server when it's started.
user The user that this program should run as. More often than not, this user
is root, but never just blindly use root if you can help it.

Another pair of services are referred to as RPC services, and unlisted services. An
RPC (Remote Procedure Call) service is a C programming library that supports
client/server architecture, allowing a machine to send a command to another
machine, which executes the command and then sends back the results. An unlisted
service is one that isn't included in /etc/services or /etc/rpcthe file that contains the
list of all RPC services.

Keeping the RPC and unlisted services in mind, the remaining required statements (if
appropriate for the service you're setting up) are:

port The port to accept communications for this service on. Only required for
unlisted services that don't use RPC.
protocol The protocol from /etc/protocols that this service requires. Only
absolutely necessary for RPC and unlisted services.
rpc_number The number from /etc/rpc for this services. Only absolutely
necessary for RPC and unlisted services.
rpc_version The version number of RPC that this service requires, either a
single number or a range separated by dashes. Only required for RPC
services.

From here, everything is optional. Rather than putting you to sleep covering all of the
items in the xinetd.conf man page, here are the ones you are most likely to want to
use or to run into when editing existing filessee the xinetd.conf man page for in
depth specifics on exact syntax and options:

banner_fail A banner to print for the user who tries to access this service
but isn't allowed.
banner_success A banner to print for the user who successfully accesses this
service.
bind Only accept accesses for this service through a particular network
device.
 cps The threshold of connections per second that push xinetd to temporarily
disable the service.
disable A no if you want xinetd to pick up the phone when someone tries to
access this service, and a yes if you don't. Often distributions that utilize
xinetd will install software such as FTP servers with disable = yes so that
they will not be available until you've fully configured the server and then
enable it.
env Ensures that the specified environment variables are in this service's
environment.
group The group that this program should run as.
instances The number of simultaneous accesses xinetd should allow for this
service. UNLIMITED is the default.
log_on_success What information to log when the service starts and when it
stops.
log_on_failure What information to log when a service can't start due to an
error or someone trying to get in who shouldn't.
log_type Whether to use the syslog daemon or log to a file.
max_load The threshold of the one minute load average that causes xinetd to
refuse connections for this service.
nice The priority this particular service should have in taking up CPU cycles.
See the nice man page for details.
no_access Expressly forbids access from the specified location to this service.
Uses the same formats as only_from.
only_from Which hosts outside of this server are allowed to access this
service.
per_source Limits how many times someone can access this service from the
same location at the same time.
redirect Whenever someone tries to access this service, point the request to
another location and forward it along.

Most of these entries are used in the format:

statement = item1 item2 ...

So, once you know what service you want to configure, where you want to configure
it (what file), and what portions you want to configure, you create an entry that
looks like this whether you're doing it in the main file or in one of the separate files:

servicename

statement1 = item1 item2 ...

statement2 = item1 item2 ...
...
}

Once you're finished making these configuration changes, be sure to restart xinetd
so it can load the new setup. It's typically a good idea to use the control scripts if
your distribution supports them. For example, in Red Hat Linux you would type:

/etc/rc.d/init.d/xinetd restart
Hopefully you've found here that xinetd deserves further investigation. If you're used
to inetd then this more secure superdaemon can give you a few headaches at first,
but the better control over who's accessing your system, and when, makes up for it.