Linux xinetd Super Server daemon
The Linux xinetd (Extended Internet Services) daemon, also known as the super server, controls many network services.
The xinetd service listens on all ports used by the daemons it controls. When a connection is requested, xinetd determines if the client is allowed access. If the client is allowed access, xinetd starts up the desired service and allows the client to connect.
The xinetd service listens for connection requests for all of the active servers with scripts in the /etc/xinetd.d directory. There's a generic configuration file for xinetd services, /etc/xinetd.conf. The scripts in the /etc/xinetd.d directory function as service-specific configuration files.
The xinetd rpm package should be installed to to use the xinetd super server.
The following command will install the xinetd super server.
The following command will install the xinetd super server.
[root@RHEL03 Server]# rpm -ivh xinetd-2.3.14-10.el5.i386.rpm
warning: xinetd-2.3.14-10.el5.i386.rpm: Header V3 DSA signature: NOKEY, key ID 37017186
Preparing...########################################### [100%]
1:xinetd… ########################################### [100%]
warning: xinetd-2.3.14-10.el5.i386.rpm: Header V3 DSA signature: NOKEY, key ID 37017186
Preparing...########################################### [100%]
1:xinetd… ########################################### [100%]
To install telnet server, you should install the telnet-server rpm package after the installation of xinetd rpm package. The telnet-server rpm package can be installed by running the following command.
inetd Configuration files in /etc/xinetd.d folder
The files in the /etc/xinetd.d directory specify a particular service you want to allow xinetd to manage.The following configuration (/etc/xinetd.d/telnet) file is related to the telnet server we have just installed.
# default: on
# description: The telnet server serves telnet sessions; it uses \
# unencrypted username/password pairs for authentication.
service telnet
{
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.telnetd
log_on_failure += USERID
disable = yes
}
The following table is the description of different parameters used in xinetd file. Note that the "disable" parameter is set to yes, which disables the telnet server. If you want to enable the telnet server, this value should be "no".# description: The telnet server serves telnet sessions; it uses \
# unencrypted username/password pairs for authentication.
service telnet
{
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.telnetd
log_on_failure += USERID
disable = yes
}
| Parameter | Description |
| flags | Supports different parameters for the service; REUSE is a default that supports continuous use of the service. |
| Options | include IPv6 to set this as a service for those types of networks. |
| socket_type | Specifies the communication stream. |
| wait | Set to yes for single-threaded applications or no for multithreaded applications. |
| User | Account under which the server should run. |
| Group | Group under which the server should run. |
| server | The server program. |
| only_from | Host name or IP address allowed to use the server. |
| no_access | Host name or IP address not allowed to use the server. |
| log_on_failure | Whether a failure should be logged |
| disable | By default, set to yes, which disables the service. |
xinetd FAQ
Q. What is xinetd ?
A. xinetd is a replacement for inetd, the internet services daemon.
Q: I am not a system administrator; what do I care about an inetd replacement ?
A: xinetd is not just an inetd replacement. Anybody can use it to start servers that don't require privileged ports because xinetd does not require that the services in its configuration file be listed in /etc/services.
Q. Is it compatible with inetd ?
A. No, its configuration file has a different format than inetd's one and it understands different signals. However the signal-to-action assignment can be changed and a program has been included to convert inetd.conf to xinetd.conf.
Q. Why should I use it ?
A. Because it is a lot better (IMHO) than inetd. Here are the reasons:
A. xinetd is a replacement for inetd, the internet services daemon.
Q: I am not a system administrator; what do I care about an inetd replacement ?
A: xinetd is not just an inetd replacement. Anybody can use it to start servers that don't require privileged ports because xinetd does not require that the services in its configuration file be listed in /etc/services.
Q. Is it compatible with inetd ?
A. No, its configuration file has a different format than inetd's one and it understands different signals. However the signal-to-action assignment can be changed and a program has been included to convert inetd.conf to xinetd.conf.
Q. Why should I use it ?
A. Because it is a lot better (IMHO) than inetd. Here are the reasons:
1) It can do access control on all services based on:
a. address of remote host
b. time of access
c. name of remote host
d. domain name of remote host
2) Access control works on all services, whether multi-threaded or single-threaded and for both the TCP and UDP protocols. All UDP packets can be checked as well as all TCP connections.
3) It provides hard reconfiguration:
a. kills servers for services that are no longer in the configuration file
b. kills servers that no longer meet the access control criteria
4) It can prevent denial-of-access attacks by
a. placing limits on the number of servers for each service (avoids process table overflows)
b. placing an upper bound on the number of processes it will fork
c. placing limits on the size of log files it creates
d. placing limits on the number of connection a single host can initiate
e. place limits on the rate of incoming connections
f. discontinue services if the load exceeds specified limit
5) Extensive logging abilities:
a. for every server started it can log:
i) the time when the server was started
ii) the remote host address
iii) who was the remote user (if the other end runs a RFC-931/RFC-1413 server)
iv) how long the server was running
(i, ii and iii can be logged for failed attempts too).
b. for some services, if the access control fails, it can log information about the attempted access (for example, it can log the user name and command for the rsh service)
6) No limit on number of server arguments
7) You can bind specifc services to specific IP's on your host machine
Q. Whom should I thank/blame for this program ?
A. panos@cs.colorado.edu originally wrote this program, but I am fielding bug reports at this time.
Q. What's up with 2.2.1 version of xinetd?
A. The most recent original version of xinetd was 2.1.1 with patches bringing it up to 2.1.8. Nick Hilliard created xinetd 2.2.1, based off an unreleased xinetd 2.2.0 by Panos. The copyright included with xinetd specified the required versioning to be the official release of xinetd (2.1.8 in this case) and a fourth version number tacked on to indicate the modification level. This is the versioning I have adopted. xinetd 2.1.8.X, which is available here, is not based off xinetd 2.2.0 or higher. It was created from the codebase of xinetd 2.1.8, although I have re-implemented some of the features introduced in xinetd-2.2.1.
Q. Where can I find the latest-and-greatest version ?
A. The xinetd source can be obtained from http://www.synack.net/xinetd
Q. Has anyone been able to get qmail working with xinetd?
A. yes, here is the entry info
service smtp
{flags = REUSE NAMEINARGS
socket_type = stream
protocol = tcp
wait = no
user = qmaild
server = /usr/sbin/tcpd
server_args = /var/qmail/bin/tcp-env -R /var/qmail/bin/qmail-smtpd
}
Contributed by: Anthony Abby
This method will allow you to set environment variables and whatnot in /etc/hosts.allow. Although xinetd can be compiled with libwrap support, this doesn't mean it can completly replace tcpd's functionality. xinetd calls host_access(), which performs the access control documented in host_access(5) man page. This is a subset of the features offered by tcpd.
Q. What platforms is xinetd know to work on?
A. I have run it on Solaris 2.6 (sparc and x86), Linux, BSDi, and IRIX 5.3 and 6.2. The original package ran on SunOS 4 and Ultrix.
Q. How to do setup a chrooted environment for a service?
A. Here is the config file entry:
This method will allow you to set environment variables and whatnot in /etc/hosts.allow. Although xinetd can be compiled with libwrap support, this doesn't mean it can completly replace tcpd's functionality. xinetd calls host_access(), which performs the access control documented in host_access(5) man page. This is a subset of the features offered by tcpd.
Q. What platforms is xinetd know to work on?
A. I have run it on Solaris 2.6 (sparc and x86), Linux, BSDi, and IRIX 5.3 and 6.2. The original package ran on SunOS 4 and Ultrix.
Q. How to do setup a chrooted environment for a service?
A. Here is the config file entry:
service telnet_chroot
{log_on_success = HOST PID DURATION USERID
log_on_failure = HOST RECORD USERID
no_access = 152.30.11.93
socket_type = stream
protocol = tcp
port = 8000
wait = no
user = root
server = /usr/sbin/chroot
server_args = /var/public/servers /usr/libexec/telnetd
}
Contributed by: lburns@sasquatch.com
Q. How do I use itox?
A. itox reads in a regular inetd.conf file from stdin and writes an xinetd.conf file to stdout. In general, you use the command:
itox < /etc/inetd.conf > /etc/xinetd.conf
If your inetd.conf does not have explicit paths to each of the daemons, you must use the -daemon_dir option. Suppose all your daemons live in /usr/sbin, use the following command:
itox -daemon_dir=/usr/sbin < /etc/inetd.conf > /etc/xinetd.conf
itox is rather old and hasn't been updated for a while. xconv.pl is a perl script that is a little better about converting modern inetd.conf files. It's usage is similar to itox's.
Q. Does xinetd support libwrap (tcpwrappers)?
A. Yes. xinetd can be compiled with libwrap support by passing --with-libwrap as an option to the configure script. When xinetd is compiled with libwrap support, all services can use the /etc/hosts.allow and /etc/hosts.deny access control. xinetd can also be configured to use tcpd in the traditional inetd style. This requires the use of the NAMEINARGS flag, and the name of the real daemon be passed in as server_args. Here is an example for using telnet with tcpd:
Q. How do I use itox?
A. itox reads in a regular inetd.conf file from stdin and writes an xinetd.conf file to stdout. In general, you use the command:
itox < /etc/inetd.conf > /etc/xinetd.conf
If your inetd.conf does not have explicit paths to each of the daemons, you must use the -daemon_dir option. Suppose all your daemons live in /usr/sbin, use the following command:
itox -daemon_dir=/usr/sbin < /etc/inetd.conf > /etc/xinetd.conf
itox is rather old and hasn't been updated for a while. xconv.pl is a perl script that is a little better about converting modern inetd.conf files. It's usage is similar to itox's.
Q. Does xinetd support libwrap (tcpwrappers)?
A. Yes. xinetd can be compiled with libwrap support by passing --with-libwrap as an option to the configure script. When xinetd is compiled with libwrap support, all services can use the /etc/hosts.allow and /etc/hosts.deny access control. xinetd can also be configured to use tcpd in the traditional inetd style. This requires the use of the NAMEINARGS flag, and the name of the real daemon be passed in as server_args. Here is an example for using telnet with tcpd:
service telnet
{flags = REUSE NAMEINARGS
protocol = tcp
socket_type = streamwait = no
user = telnetd
server = /usr/sbin/tcpd
server_args = /usr/sbin/in.telnetd}
Q. Does xinetd support IPv6?
A. Yes. xinetd can be compiled with IPv6 support by adding the --with-inet6 option to the configure script. Access control is functional with IPv6. You can use ipv4 mapped addresses, or give normal dotted quad ipv4 addresses for access control, and xinetd will map them to ipv6 addresses.
Q. No services start with IPv6! What's the deal?
A. When you compile IPv6 support in, all sockets are IPv6 sockets. If your kernel doesn't understand what an IPv6 socket is, all attempts to create sockets will fail, and no services will start. Only compile xinetd with IPv6 support if your kernel supports IPv6.
Q. What's this setgroups(0, NULL) error?
A. By default, xinetd does not allow group permissions to the server processes, and it does this by setting the groups of the child process to nothing. Some BSD's have a problem with this. To avoid this error, put the directive groups = yes into your services. This says to allow the server process to have all the group privleges entitled to the user the server process is running as.
Q. Why can't telnetd start normally on Linux?
A. On some Linux distributions, the telnet daemon starts as a nonprivleged user, but the user belongs to groups that allow it to open new tty's, and to update utmp. By default, xinetd does not allow group permissions to the server process, so telnetd can fail to start properly. To get the server process to posess the proper groups, use the groups = yes directive for the telnet service. This will tell xinetd that it is OK for the server process to start with all the groups the user has access to.
Q. How do I use xinetd to wrap SSL around services
A. Use the program stunnel to wrap SSL around services. This can actually be used by an inetd.
Q. How do I setup a cvs server with xinetd?
A. A user wrote in with this suggestion:
A. Yes. xinetd can be compiled with IPv6 support by adding the --with-inet6 option to the configure script. Access control is functional with IPv6. You can use ipv4 mapped addresses, or give normal dotted quad ipv4 addresses for access control, and xinetd will map them to ipv6 addresses.
Q. No services start with IPv6! What's the deal?
A. When you compile IPv6 support in, all sockets are IPv6 sockets. If your kernel doesn't understand what an IPv6 socket is, all attempts to create sockets will fail, and no services will start. Only compile xinetd with IPv6 support if your kernel supports IPv6.
Q. What's this setgroups(0, NULL) error?
A. By default, xinetd does not allow group permissions to the server processes, and it does this by setting the groups of the child process to nothing. Some BSD's have a problem with this. To avoid this error, put the directive groups = yes into your services. This says to allow the server process to have all the group privleges entitled to the user the server process is running as.
Q. Why can't telnetd start normally on Linux?
A. On some Linux distributions, the telnet daemon starts as a nonprivleged user, but the user belongs to groups that allow it to open new tty's, and to update utmp. By default, xinetd does not allow group permissions to the server process, so telnetd can fail to start properly. To get the server process to posess the proper groups, use the groups = yes directive for the telnet service. This will tell xinetd that it is OK for the server process to start with all the groups the user has access to.
Q. How do I use xinetd to wrap SSL around services
A. Use the program stunnel to wrap SSL around services. This can actually be used by an inetd.
Q. How do I setup a cvs server with xinetd?
A. A user wrote in with this suggestion:
cvspserver stream tcp nowait root /usr/bin/cvs cvs --allow-root=/home/pauljohn/cvsroot --allow-root=/home/pauljohn/cvsmisc pserver
If you want to make the same work under xinetd, you save a config file in /etc/xinetd.d called cvspserver, (where the last line tells it the names of your repositories):
service cvspserver
{socket_type = stream
protocol = tcp
wait = no
user = root
passenv =
server = /usr/bin/cvs
server_args = --allow-root=/home/pauljohn/cvsroot --allow-root=/home/pauljohn/cvsmisc pserver -f
}
All the other cvs setup stuff is the same. This seems to work, afaik.
No comments:
Post a Comment