Xinetd: inetd with built-in TCP wrappers

XINETD has TCP Wrappers capabilities built-in.  Both RHEL and Suse uses Xinetd instead of classic inetd.   This allows XINETD to provide a slightly greater range of security options (see Security enhancements), but makes the software harder to deploy. 

Configuration is completely different from TCP Wrappers as xinetd serves dual function: inetd replacement and TCP_wrapper replacement.  In comparison with  inetd, there are the following differences:

• /usr/sbin/xinetd takes the place of inetd  daemon
• /etc/xinetd.d directory replaces /etc/inetd.conf.
• Instead of the  single one line per service format that  inetd uses,  xinetd uses one file per service approach. Inside each such file there is bracketed structure with keyword=value pairs. For example, an entry for SMTP is a file /etc/xinetd.d/smtp.  The file looks like:

service smtp 
	{ 
       socket_type = stream 
       protocol = tcp 
       wait = no 
       user = qmaild 
       id = smtp 
       server = /var/qmail/bin/tcp-env 
       server_args = /var/qmail/bin/qmail-smtpd 
       log_on_success -= DURATION USERID PID HOST EXIT 
       log_on_failure -= USERID HOST ATTEMPT RECORD 
	} 

XINETD provide the same ability of controlling access to TCP-based services as was (brilliantly) pioneered by TCP Wrappers .

XINETD can also protect UDP services (imitating firewall) and detect a some Denial of Service attacks

Rereading configuration and other signal-based operations

• SIGUSR1 : software re-configuration : the configuration file is re-read and the services parameters are changed accordingly
• SIGUSR2 : hardware re-configuration: as above, but furthermore, the outdated daemons are killed
• SIGTERM : ends xinetd and the daemons it generated

To restart xinetd, one must send the -USR1 signal instead of SIGHUP.  If xinetd receives a SIGHUP, it will exit prematurely hopefully killing whatever network connection was used to compromise the system security.

Service defaults

Most of these attributes (only_from, no_access, log_on_success, log_on_failure, ...) are inherited by all entries present in /etc/xinetd.conf, unless explicitly overwritten in individual entries/files for the corresponding service. 

Restricting access 

By default, denying access to a machine,  is the first step of a reliable security policy. Next, allowing access will be configured on a per-service basis. We've seen two attributes allowing to control access to a machine, based on IP addresses:

• only_from
• no_access.

no_access = 0.0.0.0/0

only_from = 0.0.0.0/0

Sep 17 15:11:12 charly xinetd[26686]: Service=echo-stream: only_from list and no_access list match equally 
	the address 192.168.1.1

only_from = 192.0.0.0/8

only_from =

Note: in case of no access rules at all (i.e. neither only_from, nor no_access) for a given service (allocated either directly or with the default) section, the access to the service is allowed!

Here is an example of defaults file:

defaults
{
  instances       = 15
  log_type        = FILE /var/log/servicelog
  log_on_success  = HOST PID USERID DURATION EXIT
  log_on_failure  = HOST USERID RECORD
  only_from       =
  per_source      = 5

  disabled = shell login exec comsat
  disabled = telnet ftp
  disabled = name uucp tftp
  disabled = finger systat netstat

  #INTERNAL
  disabled = time daytime chargen servers services xadmin

  #RPC
  disabled = rstatd rquotad rusersd sprayd walld
}

NEWS CONTENTS

• 20101114 : Weekend Project Replace Inetd with Xinetd for Better Network Administration Linux.com ( Weekend Project Replace Inetd with Xinetd for Better Network Administration Linux.com, Nov 14, 2010 )
• 20001119 : System Administration xinetd ( System Administration xinetd, Nov. 19, 2000 )
• 20001119 : Securing Linux, Part 3 Hardening the system ( Securing Linux, Part 3 Hardening the system, )
• 20001119 : Securing Linux, Part 3 Hardening the system ( Securing Linux, Part 3 Hardening the system, )
• 20001119 : Secure Cooking with Linux, Part 2 OReilly Media ( Secure Cooking with Linux, Part 2 O'Reilly Media, )

Old News ;-)

[Nov 14, 2010] Weekend Project Replace Inetd with Xinetd for Better Network Administration Linux.com

Xinetd is an alternative to the traditional super-server Internet daemon, inetd, the process that starts and stops all non-persistent network servers. Xinetd acts as a drop-in replacement for inetd, but it can do more than just start and stop services on your Linux machine in response to incoming TCP or UDP connections. The real advantage of Xinetd is that it allows more fine-grained control, including access control lists (ACLs), rate-limiting, time-based access, and stream redirection.

Xinetd is packaged by all major Linux distributions, so you can install it through the package management system. Barring that, you can download the latest release from xinetd.org and compile it with the usual ./configure; make; sudo make install process. There are no unusual dependencies to speak of. The only particular risk you undertake installing it if your distribution marks it as conflicting with the inetd package so that you cannot have both installed at the same time. Back up your /etc/inetd.conf file before you proceed.

Configuration Basics

Inetd's configuration file consists of a single line for each service, listing the service's name (as it is listed in the /etc/services file), the socket type (generally stream for TCP and dgram for UDP), the protocol, a "wait" or "nowait" directive that tells inetd whether or not to wait for the server to return before processing further connections, the user as whom the server should run, and the pathname of the server to launch, followed by any arguments. For instance,

imap stream tcp nowait root /usr/sbin/tcpd imapd
sane-port stream tcp nowait saned:saned /usr/sbin/saned saned

The first line launches an IMAP daemon whenever a request comes in on TCP port 220; the second is for network-sharing a SANE scanner, which uses the non-IETF-assigned TCP port 6566, and runs as the saned user.

Xinetd's configuration file /etc/xinetd.conf uses a different syntax, with braces-delimited stanzas holding the options for each service. Every entry begins with service servicename, followed on subsequent lines by individual attributes and their assigned values. For example,

service imap
{
  socket_type    = stream
  protocol       = tcp
  wait           = no
  user           = root
  only_from      = 192.168.2.102 localhost
  banner_fail    = /usr/local/etc/your_failure_banner
  server         = /usr/sbin/imapd
  log_on_failure += USERID
}

The first few lines specify the same settings as shown in the inetd example: TCP, stream, no waiting, run-as-root. The final few, however, indicate some of xinetd's additional options. The only_from attribute allows you to specify a space-separated list of allowable hosts and IP addresses. The banner_fail attribute allows you to specify a text file displayed to the remote host when a connection is denied (such as originating the connection from a disallowed IP address). You can also give a banner_success attribute to be displayed when a connection is established, and a banner attribute that is always displayed, regardless of success or failure.

The log_on_failure attribute lists what information is written to the log whenever a connection is disallowed. Note that the operator used is "+=" instead of "=" -- this has the effect of adding the userid of the connection to the information that is logged by default. As you might guess, log_on_success is also available, and there are several data values that Xinetd can log, including the remote host and total traffic count.

You can set up your entire Xinetd configuration entirely within /etc/xinetd.conf, or you separate out different services into their own configuration files. To do this, you end /etc/xinetd.conf with an includedir directive, giving as its argument a directory in which Xinetd should look for additional configuration files. Some distributions do this by default, usually with /etc/xinetd.d/ as the configuration directory. Every file in the specified directory will be parsed, unless its filename either begins with a dot (.) or ends with a tilde (~).

In this case, you should probably have a "defaults" stanza in your /etc/xinetd.conf file. This is a special stanza that assigns base attributes for every connection. Some attributes that apply to individual services (such as socket_type and server) do not apply in defaults; but you can save space by placing commonly-used attributes here rather than repeating them for each service. For example,

defaults
{
  log_type       = FILE /var/log/services.log
  log_on_success = PID
  log_on_failure = PID HOST
  instances      = 20
  banner_success = /usr/local/welcome_message
}

Access Control Measures

Beyond extra conveniences like banners and logging options are Xinetd's administrative functions, with which you can set and enforce network policy and respond to certain kinds of attacks.

The only_from attribute in the above example is the most basic form of access control; unlike using /etc/hosts_allow, however, you can configure only_from values for every service individually, or set a site-wide policy in your defaults stanza, and adjust it for specific services by using the += and -= operators in individual entries. The mirror image of only_from is no_access, which can disable access to a service based on IP or hostname. Both attributes can also accept an IP address range using ip/netmask formatting.

The access_times directive allows you to enable or disable connections based on the system time. You specify the time intervals when the service will accept connections, in hour:minute ranges. For example, access_times 05:00-11:30 13:00-16:30 keeps the service available from 5 AM to 11:30 AM, then closes it for a leisurely lunch break, and reopens it from 1:30 PM to 4:30PM. As the example shows, you can chain together multiple time intervals in one line. Conversely, you can use deny_time to dictate times when the service will be made unavailable to incoming connections.

These fixed-policy measures can be combined with adaptive settings that allow you to trigger service shutdown based on the machine's state or network traffic. The per_source attribute, for example, takes an integer as its argument, and limits the number of simultaneous connections that a single host may make using the service. This could be used to limit the number of SMTP connections made, which could be effective in catching machines infected with spam-bot viruses.

The cps attribute allows you to set a connection frequency threshold (in connections per second), above which the server will be shut down for a configurable amount of time. This allows you to prevent denial-of-service attacks based on flooding the service. Placing a setting of cps = 80 60 in a particular service's stanza says that Xinetd will respond to 80 connections per second, but if the rate of connections hits 81, it will stop the service, wait 60 seconds, then start processing new connections again.

You can also configure shutdown-threshold values for system load (using the max_load attribute), as well as address space (using rlimit_as), CPU-seconds (with rlimit_cpu), or even stack size (rlimit_stack).

Fun with Hosts and Interfaces

The redirect attribute allows you to forward a TCP (but not a UDP) connection to a different host entirely. The syntax is simple, redirect = ip-address port-number. When a connection on the matching service comes in, Xinetd starts a TCP connection to the listed IP address and port, and forwards all of the traffic to it.

This gives you a simple and effective way to redirect particular services (perhaps to machines not accessible to the outside network) without touching the firewall rules. That might be a useful feature for temporarily redirecting a service, or when combined with other access control measures, to redirect services based on their source and time of day.

Xinetd also has the ability to bind a particular service to a particular network adapter. This can be helpful when one service generates a large volume of traffic, or if you want to make a service available only over a wired connection (eth0) and not wireless (wlan0). You can use either the interface or bind attributes in the service's stanza, followed by the IP address of the interface.

Most of Xinetd's configuration tricks can be accomplished with a combination of other programs -- inetd, TCP Wrapper, hosts_allow and hosts_deny, iptables, etc. But what that smorgasbord of utilities does not do is provide a single, unified interface through which you can simply and easily compose your network service policy.

[Nov. 19, 2000] System Administration xinetd

xinetd - extended Internet services daemon - provides a good security against intrusion and reduces the risks of Deny of Services (DoS) attacks. Like the well known couple (inetd+tcpd), it allows to fix the access rights for a given machine, but it can do much more. In this article we will discover its many features.

You could now ask which daemon should I choose xinetd or inetd. As a matter of fact, xinetd requires a bit more administration, especially as long as it won't be included into distributions (it is in Red Hat 7.0). The most secure solution is to use xinetd on machines with public access (like Internet) since it offers a better defense. For machines within a local network inetd should be enough.

Securing Linux, Part 3 Hardening the system

The inetd/xinetd daemons

Securing Linux, Part 3 Hardening the system

Services can also be invoked on demand when requested by a client. These requests are given to the super daemon inetd or xinetd. The super daemon then decides which service to start and passes the request to the corresponding daemon. Typically services like telnet, ftp, rlogin, etc., are started using inetd or xinetd.

The inetd daemon is configured in /etc/inetd.conf, which contains entries for each service to be offered by the super daemon. An entry configuring an FTP server could look like this -- ftp stream tcp nowait root /usr/bin/ftpd in.ftpd -el -- and you can disable it by commenting it out using a hash sign.

For security reasons, the use of xinetd is recommended. In contrast to inetd, xinetd is able to start rpc-based services and provides access control. xinetd can limit the rate of incoming connections, number of incoming connections from specific hosts, or total number of connections for a service.

xinetd is configured by distinct configuration files for each subordinate daemon. These files are located in /etc/xinetd.d/. The example configuration file for the FTP server above would be called /etc/xinetd.d/ftp and would look like this:

Listing 1. Configuration file, /etc/xinetd.d/ftp

service ftp { socket_type = stream protocol = tcp wait = no user = root server = /usr/bin/ftpd server_args = -el disable = yes }

To disable the service, the parameter disable is set to yes as in the previous example.

For a more fine-grained control of access, xinetd supports these three additional parameters:

• only_from
• no_access
• access_time

To restrict the access but not completely disable the ftp daemon, you could modify the config file /etc/xinetd.d/ftp as follows:

Listing 2. Configuration file, /etc/xinetd.d/ftp, modified to restrict access

service ftp { socket_type = stream protocol = tcp wait = no user = root server = /usr/bin/ftpd server_args = -el disable = no only-from = 192.168.200.3 192.168.200.7 192.168.200.9 only-from += 192.168.200.10 192.168.200.12 172.16.0.0 no_access = 172.16.{1,2,3,10} access_times = 07:00-21:00 }

only-from and no_access accept numeric IP addresses (right-most zeros are treated as wild cards), IP addresses/netmask ranges, hostnames, and network names from /etc/networks. If a combination of only-from and no_access is used, xinetd finds the closest match for each host connecting.

For the previous code example, this means hosts with an IP address 172.16.x.x can connect except to hosts with addresses in 172.16.1.x, 172.16.2.x, 172.16.3.x, and 172.16.10.x. As you can see, there is no need to specify all four components of an address when you use the factorized notation as shown for no_access. The factorized part must be the right-most element of the address. See the Resources section below for an article on xinetd and its configuration.

Secure Cooking with Linux, Part 2 O'Reilly Media

Recipe 3.12. Restricting Access by Time of Day

Author's note: Most Linux systems control access to their network services using inetd or xinetd, two popular superdaemons. This recipe, excerpted from Chapter 3, "Network Access Control," demonstrates how to make inetd and xinet restrict access to those services depending on the time of day.

Problem

You want a service to be available only at certain times of day.

Solution

For xinetd, use its access_times attribute. For example, to make telnetd accessible from 8:00 a.m. until 5:00 p.m. (17:00) each day:

/etc/xinetd.conf or /etc/xinetd.d/telnet:
service telnet
{
        ...
        access_times = 8:00-17:00
}

For inetd, we'll implement this manually using the m4 macro processor and cron. First, invent some strings to represent times of day, such as "working" to mean 8:00 a.m. and "playing" to mean 5:00 p.m. Then create a script (say, inetd-services) that uses m4 to select lines in a template file, creates the inetd configuration file, and signals inetd to reread it:

/usr/local/sbin/inetd-services:
#!/bin/sh
m4 "$@" /etc/inetd.conf.m4 > /etc/inetd.conf.$$
mv /etc/inetd.conf.$$ /etc/inetd.conf
kill -HUP `pidof inetd`

Copy the original /etc/inetd.conf file to the template file, /etc/inetd.conf.m4. Edit the template to enable services conditionally according to the value of a parameter, say, TIMEOFDAY. For example, the telnet service line that originally looks like this:

telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd

might now look like:

ifelse(TIMEOFDAY,working,telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd)

which means "if TIMEOFDAY is working, include the telnet line, otherwise don't." Finally, set up crontab entries to enable or disable services at specific times of day, by setting the TIMEOFDAY parameter:

0  8 * * * /usr/local/sbin/inetd-services -DTIMEOFDAY=working
0 17 * * * /usr/local/sbin/inetd-services -DTIMEOFDAY=playing

Discussion

For xinetd, we can easily control each service using the access_times parameter. Times are specified on a 24-hour clock.

For inetd, we need to work a bit harder, rebuilding the configuration file at different times of day to enable and disable services. The recipe can be readily extended with additional parameters and values, like we do with TIMEOFDAY. Notice that the xinetd solution uses time ranges, while the inetd solution uses time instants (i.e., the minute that cron triggers inetd-services).

See Also

xinetd.conf(5), inetd.conf(5), m4(1), crontab(5).

Recommended Links

Softpanorama Recommended

Top articles

Sites

• xinetd
• http://synack.net/xinetd/ XINETD Home Page:
• Weekend Project Replace Inetd with Xinetd for Better Network Administration Linux.com

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019