14 DAY TRIAL // xinetd is a secure replacement for inetd that should be installed on most computers that use some of the services which will be mentioned later. Basically, xientd performs the same functions as inetd, but it?s a lot better in terms of security because it provides access control, can prevent denial-of-access attacks, has better logging abilities and has also some other interesting features. Because of this, many additions in xinetd over inetd the configuration files are not compatible.
First of all, let me tell you how xinetd works. It uses a configuration file where services are listed. xinetd listens on all service ports for the services listed in the configuration file and when a request comes in, xinetd starts the appropriate daemon (server). The same principle is also behind inetd. Actually, inetd came up with this great idea.
The default configuration file can be found in /etc directory and it?s called xinetd.conf. This default config file will store the default configurations because most of the distributions store their configuration files in a directory called /etc/xinetd.d/. Here, you have files which describe each service individually and usually, it has the name of that service. This is possible because in xinetd.conf, there is a includedir statement that includes, as configuration files, everything that exists in the directory specified there. Allowing us to maintain separate configuration files for each service is a great feature of xinetd that is not present in inetd. Even though it might sound a bit complicated, it's actually very easy in practice. Take a sneak peak and you'll see what I'm talking about!
This configuration files use attribute and value pairs. The attribute identifies the purpose of each parameter and the value configures that attribute. Below, you can see my configured file:
In my xinetd.conf config file, cps(connections per second) tells xinetd to accept a maximum of 10 connections in a single second and if there are more than 10 connection attempts, the service will wait 30 seconds. This stops the denial-of-access attacks. The instances attribute defines the maximum number of deamons xinetd will start for only a type of service. The default is 60 but if you know that it will never require this many, you should use a smaller value. log_type defines where messages will be logged. There are two possible values for this attribute: FILE pathname which tells xinetd to store the log in a file defined by the pathname. The default one is SYSLOG and tells xinetd to use syslogd lo log the activity. authpriv is one of the facilities defined in syslog.conf and should not be changed if you don't know what are you doing. The log_on_success attribute defines the information that is logged when an attempt to connect to the listed service is successful. By default, you can see that it is logged to the host and the process ID. The log_on_failure attribute defines the information that is logged when an attempt to connect to the listed service is unsuccessful.
In the /etc/xinetd.d directory, you have only a few files by default. These are the services that can be started by xinetd on your system at this point. Most probably, if you want to start a new server, you'll have to create your own configuration file. I'll create a config file in /etc/xinetd.d to start wu-ftpd. This is the Washington University FTP Daemon.
My file looks like this:
As you can see, this file begins with the statement of the service name. It should match an entry in the /etc/services file. Here, we have ftp and you can see its port 21 mapped in the services file. Between the Brackets, we have the attribute list that will be used for this service: socket_type is used to specify the type of socket used for this service. The most common are dgram for a service provided by UDP, or stream for a service provided by TCP. The other possible values are raw and seqpacket but it's very unlikely you'll have to use either of them. wait tells xinetd whether it should wait for the service to release the port before listening for more connections to that service or not. Possible values are yes and no. Most often, UDP requires xinetd to wait, and TCP permits xinetd to proceed without waiting. user sets the username that is used to run the service. If you want security, the username should be carefully chosen. server defines the path to the program that xinetd should start when it detects activity on the port. server_args are the command line arguments that are passed to the server program when it is started. log_on_success this has already been discussed earlier, but I would like to add that the += syntax used with the attribute, adds the values defined here to the values previously defined in the xinetd.conf file. If you want to overwrite the defaults, you should only use = because, in this case, the default values are disregarded. For log_on_failure it is exactly the same. nice defines the nice value that xinetd uses when it launches the server program. The nice command sets the scheduling priority for server program. disable tells xinetd whether or not this service has been disabled by the system administrator. If you don't want to disable a service, just don't add the disable attribute.
Those attributes will be found on most servers that can be used with xinetd and, usually, they should be enough for the average user. xinetd has a lot more to offer but currently I don't think that I am able to explain some of the advanced features.
I hope you understood how good is this super daemon and that in less that 150KB, it packs a lot of power. It consumes very little system resources, even on legacy systems, so this would be probably one of the best additions for your server.
