Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Xinetd
Xinetd is designed to be a secure replacement for the inetd program. It provides a more secure method for providing access to Internet services through a master daemon along with a number of other useful facilities. Xinetd was originally written by Panagiotis Tsirigotis. Currently, it is maintained by Rob Braun. It is supported by a Web page at http://www.xinetd.org and a mailing list hosted at synack.net.
Xinetd, like inetd, runs as a "super-server," or a switchboard. It listens on a number of ports and starts daemons as appropriate for incoming requests. Xinetd goes beyond the functionality of inetd in many ways. It takes advantage of its role as a switchboard operator to do a variety of things before it ever hands control off to the application daemon. Some of this functionality is used to create a more secure environment; other bits just make life better (or easier) for you, the administrator.
One of the most common tasks Xinetd performs is access control. Connections to a host can be allowed or disallowed based on the domain, name, or address of the remote host, and/or the time of access. If desired, Xinetd can be compiled with lib-wrap support to use the hosts.allow and hosts.deny files. Xinetd even allows you to bind specific services to specific IP addresses.
Xinetd is also used to prevent denial of services (DoS) attacks. Because it is looking at all the connections into a host instead of just one connection, Xinetd can limit the number of connections to given services. You can also set connection limits based on distinct client hosts.
One of the real strengths of Xinetd is its extensive logging capability. You can configure logging for each service individually. If you want to avoid syslog, you can write logs to log files directly. You can log information about failed connection attempts. You can even use Xinetd to log the connect and disconnect times of each connection.
Xinetd allows you to redirect TCP connections to a different host. These connections continue to run through the original host, so you could use this functionality to provide services from a privately addressed machine to the Internet.
Getting and Installing xinetd
Xinetd is now part of a stock Red Hat 7 system, but getting and building it is pretty straightforward as well. The sources are available from http://www.xinetd.org. There are currently two flavors: the stable release and the development release. Make sure that you grab the stable release.
Building Xinetd follows the normal configure, make, make install procedure. On a Red Hat 6.2 system it built and installed without any errors. If you do run into problems, please try the mailing list (see the section "What If I Have Problems" for information about subscribing).
The extra functionality provided by Xinetd means that it needs more information in its configuration file than inetd does. The two file formats are not interchangeable. A tool is provided to convert your existing /etc/inetd.conf, though, so things are relatively painless. To perform the conversion, do the following:
[root@cherry sbin]$ ./xconv.pl < inetd.conf > /etc/xinetd.conf
The resulting file is probably not exactly what you want, but it should work. The next section deals with making Xinetd do what you want it to.
Xinetd at Work
We'll take a small inetd.conf file and run it through xconv.pl to come up with a basic xinetd.conf. From there, we'll make incremental changes to our xinetd.conf to get it into shape for our own network.
A Basic Configuration
We'll start with a very short inetd.conf file, as shown in Listing 5.
Listing 5 A Basic inetd.conf
echo stream tcp nowait root internal echo dgram udp wait root internal ftp stream tcp nowait root /usr/sbin/in.ftpd in.ftpd -l -a telnet stream tcp nowait root /usr/sbin/in.telnetd in.telnetd imap stream tcp nowait root /usr/sbin/imapd imapd finger stream tcp nowait nobody [ccc] /usr/local/sbin/my_safe.fingerd in.fingerd
This config file only runs four external services on an internal service to the TCP protocol. After running xconv.pl on it, we get the xinetd.conf file shown in Listing 6.
Listing 6 The Converted xinetd.conf
# The file is merely a translation of your inetd.conf file into
# the equivalent in xinetd.conf syntax. xinetd has many
# features that may not be taken advantage of with this translation.
# The defaults section sets some information for all services
defaults
{
# The maximum number of requests a particular service may handle
# at once.
instances = 25
# The type of logging. This logs to a file that is specified.
# Another option is: SYSLOG syslog_facility [syslog_level]
log_type = FILE /var/log/servicelog
# What to log when the connection succeeds.
# PID logs the pid of the server processing the request.
# HOST logs the remote host's ip address.
# USERID logs the remote user (using RFC 1413)
# EXIT logs the exit status of the server.
# DURATION logs the duration of the session.
log_on_success = HOST PID
# What to log when the connection fails. Same options as above
log_on_failure = HOST RECORD
# The maximum number of connections a specific IP address can
# have to a specific service.
per_source = 5
}
service echo
{
flags = REUSE NAMEINARGS
socket_type = stream
protocol = tcp
wait = no
user = root
type = INTERNAL
id = echo-stream
}
service ftp
{
flags = REUSE NAMEINARGS
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/in.ftpd
server_args = in.ftpd -l -a
}
service telnet
{
flags = REUSE NAMEINARGS
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/in.telnetd
server_args = in.telnetd
}
service imap
{
flags = REUSE NAMEINARGS
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/imapd
server_args = imapd
}
service finger
{
flags = REUSE NAMEINARGS
socket_type = stream
protocol = tcp
wait = no
user = nobody
server = /usr/local/sbin/my_safe.fingerd
server_args = my_safe.fingerd
}
This config file really doesn't do everything we want it to, so we'll make some changes to it. First, we only want 1 ftp connection at a time. Second, we're only going to allow telnet sessions from internal hosts (they'll have 192.168.1.0/24 addresses).We'll log all finger connections and connect them to /usr/local/my_safe.fingerd. Because we're not running imap on this host, we'll redirect all imap sessions to our imap server at 192.168.1.10.
Throttling ftp connections is fairly straightforward. We'll modify the ftp section to look like that shown in Listing 7.
Listing 7 Defining ftp
service ftp
{
flags = REUSE NAMEINARGS
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/in.ftpd
server_args = in.ftpd -l -a
instances = 1
}
Controlling access is also straightforward. We'll modify the telnet session to match Listing 8.
Listing 8 Defining Access Control for telnet
service telnet
{
flags = REUSE NAMEINARGS
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/in.telnetd
server_args = in.telnetd
only_from = 192.168.1.0/24
}
What if we wanted to disallow connection from hosts within our local subnet during non-work hours? The following line could be added at the end of the section (after the only_from line):
access_time =08:00-18:00
Similarly, you could disallow certain connections all the time by adding the rule:
# this guy is trouble no_access =192.168.1.20
We're logging information by default, but we're going to try and capture extra information about finger users. Listing 9 shows how to do this.
Listing 9 Capturing finger Data
service finger
{
flags = REUSE NAMEINARGS
socket_type = stream
protocol = tcp
wait = no
user = nobody
server = /usr/local/sbin/my_safe.fingerd
server_args = my_safe.fingerd
log_on_success = PID HOST USERID
}
Finally, to redirect imap users to the right place, we'll make the changes shown in Listing 10.
Listing 10 Redirect imap Users
service imap
{
flags = REUSE NAMEINARGS
socket_type = stream
protocol = tcp
wait = no
user = root
redirect = 192.168.1.10 143
}
What If I Have Problems?
If you run into problems in installing, setting up, or using Xinetd, you should subscribe to the mailing list and ask for help.2 You can subscribe by sending mail to majordomo@synack.net with a body of "subscribe xinetd".
If You Subscribe
When there, please try to make a good bug report. Be specific, include all the pertinent information, and be polite! Remember that the folks who will be answering your questions are just folks volunteering their time. They will get annoyed, and might ignore you entirely if you can't be bothered to write a decent note describing your problem, what you've done, and indicating that you've at least tried to read the docs.