xinetd
 | This article needs additional citations for verification. (April 2011) |
| Developer(s) | Rob Braun |
|---|---|
| Stable release | 2.3.15
/ May 9, 2012 |
| Repository | |
| Written in | C |
| Operating system | Unix-like |
| Type | Daemon |
| License | Open source |
| Website | http://www.xinetd.org/ |
In computer networking, xinetd (extended Internet daemon) is an open-source super-server daemon which runs on many Unix-like systems and manages Internet-based connectivity. It offers a more secure extension to or version of inetd, the Internet daemon, thus most modern Linux distributions have switched to it.[1]
Description
xinetd listens for incoming requests over a network and launches the appropriate service for that request.[2]
Requests are made using port numbers as identifiers and xinetd usually launches another daemon to handle the request. It can be used to start services with both privileged and non-privileged port numbers.
xinetd features access control mechanisms such as TCP Wrapper ACLs, extensive logging capabilities, and the ability to make services available based on time. It can place limits on the number of servers that the system can start, and has deployable defense mechanisms to protect against port scanners, among other things.
On some implementations of Mac OS X, this daemon starts and maintains various Internet-related services, including FTP and telnet. As an extended form of inetd, it offers enhanced security. It replaced inetd in Mac OS X v10.3, and subsequently launchd replaced it in Mac OS X v10.4. However, Apple has retained inetd for compatibility purposes.
Configuration
Configuration of xinetd resides in the default configuration file /etc/xinetd.conf and configuration of the services it supports reside in configuration files stored in the /etc/xinetd.d directory. The configuration for each service usually includes a switch to control whether xinetd should enable or disable the service.
An example configuration file for the RFC 868 time server:
# default: off
# description: An RFC 868 time server. This protocol provides a
# site-independent, machine readable date and time. The Time service sends back
# to the originating source the time in seconds since midnight on January first
# 1900.
# This is the tcp version.
service time
{
disable = yes
type = INTERNAL
id = time-stream
socket_type = stream
protocol = tcp
user = root
wait = no
}
# This is the udp version.
service time
{
disable = yes
type = INTERNAL
id = time-dgram
socket_type = dgram
protocol = udp
user = root
wait = yes
}
The lines with the "#" character at the beginning are comments without any effect on the service. There are two service versions the first one is based on the Transmission Control Protocol (TCP), the second one is based on the User Datagram Protocol (UDP). The type and planned usage of a service determines the necessary core protocol. In a simple way, the UDP can not handle huge data transmissions, because it lacks the abilities to rearrange packages in a specified order or guarantee their integrity, but it is faster than TCP. TCP hast these functions, but it is slower. There are two column in each versions inside the Braces. The first is the type of option, the second is the applied variable.
The disable option is a switch to run a service or not. In most cases the default state is yes. To activate the service change it to no.
There are three types of services. The type is INTERNAL if the service is provided by xinetd, RPC when it based on Remote procedure call, they are commonly listed in the /etc/rpc file, or it can be UNLISTED when the service is neither in the /etc/services nor in the /etc/rpc files.
The id is the unique identifier of the service.
The socket_type determines the way of data transmission through the service. There are three types: stream, dgram and raw. This last one is useful, when we want to establish a service based on a non-standard protocol.
With the user option it is possible to choose a user to be the owner of the running service. It is highly recommended to choose a non-root user for security reasons.
When the wait is on yes the xinetd will not receive request for the service if it has a connection. So the number of connections is limited to one. It provide very good protection when we want to establish only one connection per time.
There are much more options available for xinetd, in most Linux distributions the full list of possible options and their description is accessible with the man xinetd.conf command.
To apply the new configurations a SIGHUP signal must be sent to the xinetd process to make it re-read the configuration files. It can be applied withe following command: kill -SIGHUP "PID". PID is the actual process identifier number of the xinetd, tt can be checked with the pgrep xinetd command.[3][4]
Warning: Not only with servers but with most Unix-like desktops it is possible to play around with super-server daemons, but it is dangerous to provide services to a public LAN. So it is recommended to use a private LAN for experimenting or use a server machine without any sensitivity data.[5]
References
- ^ Smith, Roderick W. (2001). "Networking". Linux Study Guide. Sybex Press. p. 365. ISBN 0-7821-2939-0.
- ^ Negus, C. (2002). "Running Network Services". Red hat Linux 8 Bible. Wiley Publishing Inc. p. 1007. ISBN 0-7645-4968-5.
- ^ Linux man page: xinetd.conf(5) http://linux.die.net/man/5/xinetd.conf
- ^ Pere, László (2005). "Hálozati szolgáltatások". GNU/Linux rendszerek üzemeltetése II. Kiskapu Kft. (Hungary). p. 107-136. ISBN 963-9301-98-1.
- ^ McClure, Stuart (2005). "Data-Driven Attacks". Hacking Exposed: Network Security Secrets & Solutions, Fifth Edition. McGraw-Hill/Osborne. p. 194. ISBN 9780072260816.
External links
 | This Unix-related article is a stub. You can help Wikipedia by expanding it. |