The difference between inetd and xinetd (ZT)

Http://hi.baidu.com/system_network/blog/item/fc3ab8133c5e1e5bf819b8fb.html

Every UNIX administrator is familiar with inetd,inetd is a daemon that manages most network connections through a centralized configuration file (inetd.conf). The xinetd daemon is an alternative to inetd, which provides many improvements or new features, as well as easier configuration. Ted explains the concept behind inetd and gives an example of setting up xinetd on your own site.
The classic inetd daemon has been around for a long time. There are several ways to replace inetd functionality, but the most flexible and easiest approach seems to be xinetd. inetd can do, xinetd can do, and xinetd can do more things. For example, TCP encapsulation, modular configuration, connection redirection, and inbound connection load limits, which only make xinetd a good choice for system administrators.

This article is intended for readers from beginners to mid-level system administrators, and the descriptions and examples in the article do not attempt to assume that you are already familiar with inetd. In this article, we'll look at some simple uses of xinetd, from installation to security policy implementation.

Before you start
For the purposes of this article, your system is best equipped with the most recent mainstream (2000 or later) UNIX (Linux, Solaris, BSD). These examples can also be run on earlier versions of Perl and UNIX (and other operating systems), but their functional barriers should be addressed by the reader as a practice. Given specific examples are used for Red Hat Linux, but they should also be run on other systems (except Chkconfig).

What the hell is inetd?
For UNIX system administrators, inetd is as basic as the CP/RM/MV command. It always exists and is prepared to handle inbound connections. But what it really is. What it is used to do.

First from TCP/IP (it also includes UDP, but we are not yet considering) to start answering. When you establish a connection to a host, you actually create a TCP/IP connection (usually a socket)-it's like making a phone call between you and the host. TCP/IP connections are uniquely defined by the originating host and the receiving host, but there are other identities. If we're all connected to a single server, how does it differentiate between webserver, Telnet, SSH, FTP, and other connections? Sockets are also defined by the ports that are used to establish the connection. For example, Port 21 is inbound FTP, Port 22 is SSH, Port 23 is TELNET (for most other ports, you can view/etc/services on UNIX systems).

Once the connection is established, someone picks up the phone at the other end. This can be an operator or a straight line. A line indicates that you are directly connected to the server, and that the operator is a method involving inetd. The operator actually processes a set of inbound lines (ports on the host) and personally hands them to the responsible program (server).

UDP is another way to connect. Like TCP, UDP is basically a conversation with someone, but it's not guaranteed to be reliable. UDP (continued use of the telephone metaphor) is like throwing a message on a conveyor belt and letting the receiver stand on the other end. You can get a lot of messages from the carousel, but if there are too many messages (high network traffic) or too long to read messages (the server is busy), the receiver may lose some messages.

If you use inetd, you are redirected to a specific server after performing some checks. Only one profile-inetd.conf to manage all inbound connections. This makes it easier to add, remove, change, or review services on your system. For example, use the TCP wrapper on the Solaris system to define FTP as follows:

The inetd.conf of the manifest 1,ftp service defines the FTP stream TCP nowait ROOT/USR/SBIN/TCPD in.ftpd




These are all the parameters required to create an FTP connection. Simply put, when we use TCP/IP (TCP) in a stream-oriented manner, we allow multiple FTP connections (nowait), run as root, and invoke FTP (next, the TCP wrapper will invoke the FTP daemon).

Is it difficult to parse it out in a morning? Absolutely difficult. Is it necessary to be so complicated. No. XINETD inherits the design of the inetd and modularity it, meaning that each service can exist in its own configuration file. XINETD also adds features like the TCP wrapper, making the configuration simpler.

XINETD maintains a central configuration (operator) approach that stores all profiles in a single location, typically/etc/xinetd.conf and/etc/xinetd.d/*, making it easier for system administrators to obtain them. Modular configuration means that you can distribute the service to multiple machines by copying the service to the XINETD.D directory, or you can remove it in a similar way. You can even specify an additional include directory.

Finally, the xinetd FAQ (see Resources later in this article) declares that RPC programs do not run very well under xinetd. But no problem, use inetd for RPC, and use xinetd for all other services. It's like hiring two operators, one speaking Spanish, the other speaking all the other languages.

XINETD Introduction
So what is xinetd. In a word, it is a program. There is nothing magical about handling inbound network connections. Can be handled using Perl, Python, or Java. XINETD is written in C, and it is as fast as its predecessor inetd, if not faster (for example, the TCP wrapper does not have to be executed for each inbound connection; they are starting fashion into memory).

XINETD is in the process of being developed. (your version may be out of date, so be sure to look for the latest version on the home page; see resources.) Because it is under development, XINETD security vulnerabilities can be quickly remedied, not as weak as inetd, which usually takes a long time to make up. Of course, XINETD is delivered with the source code, so you can review the source code and find out where it might be vulnerable.

How do I use xinetd to define a service? Writes a service file that specifies a specific configuration in addition to the generic parameters specified in/etc/xinetd.conf. So, if the/etc/xinetd.conf is like this:

Listing 2, sample xinetd.conf (Standard Red Hat 7.1) defaults
{
instances = 60
Log_type = SYSLOG Authpriv
log_on_success = HOST PID
Log_on_failure = HOST
CPS = 25 30
}

Service Telnet
{
Flags = Reuse
Socket_type = Stream
wait = no
user = root
Server =/usr/sbin/in.telnetd
Log_on_failure + + USERID
Disable = yes
}

Includedir/etc/xinetd.d




Each service file that you put into the/ETC/XINETD.D inherits these defaults and specifies its own parameters. Here, the Telnet service is defined at the top-level, not in the subdirectory. This is great, this modularity allows for complex configurations.

To enable XINETD to reread the configuration file, you do not have to restart it. Just send a USR2 signal to it.

What those parameters mean. Let's read through the entire list. You can also use man xinetd.conf at the command line to view the list (if the help page is properly installed), but this overview attempts to explain the parameters in simpler terms, without assuming that you already know all the information about sockets and services. Some parameters (Rpc_version, rpc_number) are skipped.

General parameters


Id
The unique name of the service. The service name is specified before the curly braces, but the ID makes the logically identical service likely to have multiple protocols. This is a restricted use for temporary users. For example, an NFS service can run on a UDP or TCP transport protocol. On Red Hat Linux 7.1, the TCP version (in/etc/xinetd.d/time) and the UDP version (in/ETC/XINETD.D/TIME-UDP) provide the internal time service for XINETD.


Type
This should actually be called a "special type" because it applies only to special services. It can be a combination of the following types: "RPC", for RPC services (remote procedure calls introduced by SUN, leading to many security issues, preferably avoided); "INTERNAL" for building services within XINETD, such as time services; "Unlisted", A nonstandard service that is not found in the system list (/etc/services or/ETC/RPC for RPC services).


Flags
All the extra flags are placed here. The list is long and highly technical; the flags we are interested in include reuse (for socket reuse, such as Telnet), Nameinargs/nolibwrap (if you want to invoke the TCP wrapper manually or avoid the wrapper entirely), nodelay/ KEEPALIVE (for adjusting TCP sockets), DISABLE (overriding the top-level "DISABLE" parameter), and SENSOR (for detecting and preventing certain types of denial of service (Denial-of-service) network attacks).


Disable
Unless you want to disable a service, always set it to "no". Red Hat Linux's chkconfig program turns the "disable" parameter on or off for you; on Red Hat, enabling and disabling specific services with Chkconfig may be simpler than manual methods. Please note that Chkconfig expects to find service files in/etc/xinetd.d/service. So for the example in Listing 2 above, Chkconfig will not turn telnet on or off at the request. You can think of it as an error or attribute, depending on your point of view.


Socket_type
Typically you want this parameter to be set to "stream" unless you use the UDP service, which is set to "Dgram". This parameter can also be set to "raw" and "Seqpacket", but very rare.


Protocol
This is the protocol used for the connection, usually "TCP" or "UDP," but theoretically you can use any value from the/etc/protocols.


Wait
If set to ' No ', xinetd will start a new handler for the service on each connection. If yes, XINETD expects the handler to handle all subsequent connections until it dies. In most cases, this parameter is "no".


Server, Server_args
The program name of the handler and the parameters it should get. The handler name should not appear in the parameter, as in the inetd environment.


Port
The port of the service. Usually not required because the port is mapped to the service through the/etc/services file.


redirect
Allows xinetd to send traffic to another host for all services. Therefore, a firewall-protected host can accept security traffic through a central xinetd forwarder without having to establish a connection to the external network. In some jobs, this feature can be used to perform failover services between two hosts.


Banner, Banner_success, Banner_fail
A custom text block from a file that will be printed on the "any/one success/one unsuccessful" connection.


Enabled
Complements the "disabled" parameter and the DISABLE flag at the global level.


Include, Includedir
Tell xinetd to include a file or directory.



Environment parameters


User, group, umask, groups
The UNIX attribute that xinetd should play when the service handler is started. This is primarily used for unsecured services.


Nice
Determine how important the service is to the UNIX priority level for the system. You can adjust it for your system, check out the man page of Nice.


Env
An environment variable for service handlers.


Passenv
An environment variable that should be passed down to the xinetd of the service handler.



Resource management parameters


Instances
Number of handlers that can be started at the same time. This parameter can be adjusted to prevent denial of service attacks. If you want the default (unrestricted) behavior, set it to "unlimited".


Max_load
I: If the system is overloaded, stop accepting the connection. The number of loads depends on the system, and you can adjust it only if you really know what you're doing.


Rlimit_as, Rlmist_cpu, Rlimit_data, Rlimit_rss, Rlimit_stack
The Rlimit parameter specifies the resource limits (memory, CPU, and specific memory regions) that are used for service handlers.



Security-specific parameters


Only_from, no_access
Supplemental to the TCP wrapper, this is one way to block the host from establishing a connection with us. Note that the default value is to allow access to anyone unless the TCP wrapper (whose rules are usually in/etc/hosts.allow) is otherwise specified.


Access_times
The time available for a service during the day. For example, "6:00-23:00" means that services are available from 6 o'clock in the morning to 11:01 in the evening.


Log_type, Log_on_success, log_on_failure
Various logging options. The USERID flag can be especially troublesome because it asks the connected host about the user we are connecting to, which slows the processing down. Avoid using USERID as much as possible.


Bind
Allow services to be interface-specific, usually for security reasons. For example, the FTP service within the network is FTP only, while an external FTP connection generates an intruder alert. The "id" parameter is useful here.


Per_source
Specifies the maximum number of instances of the service from the source IP. is useful for handling too many connections established by the Single-source denial of service (Single-source Denial-of-service) attack or an error program.


Cps
The maximum number of connections allowed per second, and the number of seconds before the service is re-enabled. "30 45" means "30 inbound connections per second, and wait 45 seconds if the limit is exceeded." Used primarily against denial of service attacks.


Deny_time
The time that the service was denied to the person who raised the SENSOR flag.





Replace the TCP Wrapper
The classic TCP wrapper package is a very useful tool. Allow or deny access to any host, as needed, with a centralized file (usually/etc/hosts.allow and/etc/hosts.deny) for each service. Unfortunately, the TCP wrapper library is less aware of the system load, resource constraints, multiple attacks, and so on. XINETD incorporates the TCP wrapper functionality (through the LibWrap library), so you can migrate to xinted and continue to use the same configuration files as before.

This is almost all the work that the migration has to do. Keep the old Hosts.deny and Hosts.allow files, XINETD will gladly follow them. However, keep in mind that XINETD has many improved connection control options based on the TCP wrapper. For example, limiting the number of connections per second or overloading can be a valuable Help for server management.

Make sure that you compile the xinetd using the libwrap option, otherwise it will not know the TCP wrapper. If xinetd comes from RPM on Red Hat Linux, make sure that you are testing the TCP wrapper file for proper operation before opening the machine "before".

Advanced Uses: Failover
Although there are several ways to use the Xinetd,redirect parameter, we provide the most interesting way to use it. It is well known that failover is difficult to implement and hardware failover is expensive. The method described here (through simple software) is both inexpensive and efficient. It has a single point of failure-a redirection point, so you should consider whether the method is acceptable. If it's not acceptable, then hardware failover is a good point.

First, identify a way to select an "active" machine from two or more machines. Let's say you do this through a script set_active.pl (we'll do that for the Telnet service, but it works for any other service, as long as it keeps the service from switching to another server without adversely affecting it). The script will take the name of the machine we used to set up the new failover, and the service name for the appropriate/etc/xinetd.d/service file for editing. Please feel free to customize the script to edit different files or use different parameters. You can perform this job with a single line of "Perl-p-i-e" script, but you can do a lot of extensions to this method in the future, and you can perform error checking on the parameters.

It's too easy. Now it's just a decision to call the script-either manually, through a cron job, or by another program. At this point, it becomes an architectural decision. Don't forget to send a USR2 signal to xinetd at this point, and if you want, you can restart it. On Red Hat Linux, you can automate the signal with the "PKILL-USR2 xinetd" and restart the xinetd simply by using "/etc/rc.d/init.d/xinetd restart" (on Linux) or other similar commands (in the large On most UNIX systems).

This failover will not take effect on database connectivity unless a lot of extra work is done on the database side. It is recommended that you use it for protocols such as rsync, SSH, FTP, and Telnet, where the failover machines are not interdependent.

Conclusion
It is clear that the many features offered by xinetd are a good reason to choose it. However, do not forget the other benefits of xinetd: errors are corrected once reported, source code is free and migration from existing inetd configurations (when you use the Itox helper program delivered with XINETD) is easy.

Why not use xinetd. Backward compatibility will be your best reason, as well as incompatibility with your particular platform. XINETD software is most popular on Solaris and Linux servers, so there may be unresolved issues on your particular platform.