English Author: Jose Nazario Chinese translator: Fenng Fdh@163.net translation history: 2001/11/27 Version 0.01 2003/05/23 Version 1.00
JOSE describes how to connect to configure adjustment Xinetd.
XINETD replaces inetd and provides access control, enhanced log and resource management capabilities, has become the Internet standard super daemon of Red Hat 7 and Mandrake 7.2. This article will guide you how to apply some of its features, which are based on the XINETD 2.1.8.8Pre3 version.
Introduction XINETD's original author (Panagootis Tsirigotis Panos@cs.colorado.edu) seems to have stopped this project. Rob Braun (bbraun@synack.net) continues the project and is now responsible for maintaining this package. In order to make SELECT () can also be used on my old libc5 system, I have to add a few pairs of headers to the current package, this is what I noticed. Maybe you need them, as follows:
XINETD / INTERNALS.C.ORIGFRI JUN 16 19:00:15 2000 Xinetd / Internals.cfri Jun 16 19:00:53 2000 @@ #include
The extended syntax has replaced the universal line in inetd with parentheses. In addition, logs and access control functions have been added. Although inetd can use Venema's TCP_WrapPERS software (TCPD) to control TCP connections, you can't use it to control UDP connections. In addition, inetd's services for RPC (portmapper) are also handled well. In addition, although you can control the connection speed (by adding a value by giving WAIT or NO WAIT variables, such as NOWAIT.1 means an instance of every one second), you cannot control the maximum number of instances. This can lead to process table attacks (eg, an effective denial of service attack). By using Xinetd, we can prevent DOS.
I usually start xinetd using the following command, put it in my Internet service startup script:
/ usr / sbin / xinetd -filelog /var/adm/xinetd.log -f /etc/xinetd.conf
This tells xinetd to record all services, logs to file /var/adm/xinetd.log and use the configuration file /etc/xinetd.conf. The large number of spaces in this article will be used on this configuration file.
Compile time options You should pay attention to 3 compile time: libwrap, loadavg (for monitoring load balancing) and IPv6 Support, which provide additional access control. For most libwrap "understand" daemons (such as portmapper and sendmail), the '' WITH-LIBWRAP 'option in the configuration script tells xinetd to support TCP_WrapPers files /etc/hosts.allow and /etc/hosts.deny. These options are just like they are in inetd, and support all XINETD control daemon. Note If you do XINETD from zero, you can do access control, no longer need TCPD. one way or another. Support for libwrap is useful - if you migrate from inetd / tcpd and don't want to change your access files. The second interesting setting option is to support load balancing, which can be achieved by using the with-loadavg option in ./configure scripts. Sendmail supports stopping connections at high loads - assumes that it has been separated from control and is off the machine. Use this option to activate the MAX_LOAD option to limit any connection or all services based on load balancing machines. Finally, add IPv6 support can be done by using the with-inet6 capability option in ./configure scripts. This allows xinetd to support IPv6 addresses and connections. Note that your core (and network) must support IPv6 if you want to take effect. Of course IPv4 is still supported. Profile XINETD profiles can usually be generated from inetd.conf files manually or automatically. The former fee is time and is easy to go wrong; the latter can easily complete it through the ITOX software or XCONV.PL script. Although ITOX software is being canceled and tends to use Xconv.pl scripts, it is still useful. However, pay attention to repeated running it will overwrite the original profile. Both ITOX and XCONV work in the same way, we use iTox to demonstrate:
$ itox xinetd.conf
New tools (XCONV) can understand annotations and do better than iTox in the use of TCPD, you have to specify the path to the daemon (such as / usr / sbin). The first paragraph you want to include is the default segment, just like the name suggests, the default xinetd service.
defaults {instances = 25 log_type = FILE / var / adm / servicelog log_on_success = PID HOST EXIT flags = NORETRY log_on_failure = HOST RECORD ATTEMPT only_from = 129.22.0.0 no_access = 129.22.210.61 disabled = nntp uucp tftp bootps who shell login exec disabled = Finger}
Immediately, we can understand the syntax of the XINETD setting parameters:
The operator is very simple, = or =. Use = to pass to the indicator on the left. = Is also very straightforward, used to add a value to a specified indicator. Without it, the original indicator will be overwritten, which can be used to expand the access list, or cross multi line.
Describe the service with the following format:
Service name {indicator = value indicator = value}
The service name must be listed in / etc / services and use the appropriate Socket and protocol.
There are a few words about access control on access control. First, the XineTD controls the connection rather than the control data packet, it is just a user's daemon, just like inetd. Similarly, you can interrupt SYN or Connect () of the host that is prohibited by the server. However, it is impossible to use the FIN [port scan using the TCP package with the FIN flag, which is usually the "secret" scan for the tool running this NMAP. Don't use XINETD as a firewall to block port scans. An experienced intruder can collect the access control list of your different services with this information. Fortunately, these can be recorded by the xinetd. Your doubts will be eliminated when you see the log. Second, Xinetd (2.1.8.8pre3 version), when a system is trying to connect, the name is found. Previously, it was found when started, but now it has changed. Use access control is really simple. The first indicator is ONLY_FROM, which lists which network or the host is connected. This rule can be covered by NO_ACCESS. You can use the network number, such as 10.0.0.0 or 10 or a network name (including .my.com or .my.com). The IP address of the host name or host can also match all hosts and listen to all the addresses using the indicator 0.0.0.0 here. Once the NO_ACCESS is used, once the standard rejection will be parsed. Again, the network and the host can be specified. Service configuration let us see some basic applications. Let's take a first basic service Echo, which is an inherent service in inetd and xinetd.
Service echo {socket_type = stream protocol = tcp wait = no user = root type = internal id = echo-stream}
Echo runs with root privileges, is a TCP stream and internally. The Echo-Stream indicator will appear in the log. If there is no ONLY_FROM or NO_ACCESS in the indicator, the configuration of this service will be unrestricted. Now let's take a regular service, daytime:
Service daytime {socket_type = stream protocol = tcp Wait = no user = nobody server = /usr/sbin/in.date instances = 1 nice = 10 only_from = 0.0.0.0}
Again, anyone can connect, but we indicate that it returns information as Nobody's identity. This is not an extra one more than the previous example. Now let's see another service second shell version 1. The following settings prevent the resource from the resources from SSHD from being exhausted.
service ssh1 {socket_type = stream protocol = tcp instances = 10 nice = 10 wait = no user = root server = / usr / local / sbin / sshd1 server_args = -i log_on_failure = USERID only_from = 192.168.0.0 no_access = 192.168.54.0 no_access = 192.168.33.0} Here, we have established our previous. When the SSHD is reused as a super user inetd or XINETD, we need to use the -i parameter, so we put it behind the Server_args indicator. Note: Adding this tag to the Server identifier will result in failure. Only ten people can be used at all times, this is not a problem on this server, this example we get from the log. In addition, as the default information, if it is not connected, the user ID of the connection is described in RFC 1413. Finally, we list two networks that cannot be accessed.
There are several values in the Log and the xinetd log to get the information table 2 of your server. Different log indication Values Successful value. Both registration Remote User's RFC 1413 ID EXIT SUCCESS registration process Duration Duration Success Registration Task Continuous Time Attempt Failure Registration Connection Reason Record Fail Recontinence About Connection Failure
In this way, some standard rows of lines can be added, just like the following. For a successful connection, we usually want to register the process ID generated by the service, the connected host and exit time:
LOG_ON_SUCCESS = PID HOST EXIT
This gives us useful information and normal server fierce information. For failure, we can record what we want:
LOG_ON_FAILURE = HOST RECORD ATTEMPT
We record the reasons for connecting hosts, reject connections and additional information about hosts in the connection (sometimes those who try to connect). It is recommended that you do this, you can have a good grasp of your server. Also looking above, in our default segment, our log is written in / var / adm / serviceelog. We specify all information, success, and failure to be recorded by xinetd. Most of our information look like this:
00/9/13 @ 16: 05: 07: Start: pop3 pid = 25679 from=192.168.152.13300/9/13@16: 05: 09: exit: pop3 status = 0 pid = 2567900/10/3 @ 19: 28:18: Userid: Telnet Other: WWW Use this information to easily troubleshoot and perform and normal operations. It can also be easily discovered (if you try to block the connection attempt), simply use GREP to use GREP in the log, these items are shown below: 00/10/4 @ 17: 04: 58: Fail: Telnet Address from=216.237.57.15400/10/8@22: 25: 09: fail: pop2 address from = 202.12.14.184
Real security issues require additional articles, but this is enough to explain that since the address can be forged, do not treat the address report as a fixed information. The xinetd.log file (including information obtained from xinetd) is useful as a tired information when connecting an error.
00/10/25 @ 21: 10: 48 xinetd [50]: Error: Service Echo-Stream, Accept: Connection Reset by Peer
Heavy configuration xinetd is running in xinetd.conf, you can edit the xinetd.conf file. To reconfigure, send a signal SIGUSR1 to the xinetd process:
# ps -ax | GREP XINETD50? S 5:47 / usr / sbin / xinetd -filelog /var/adm/xinetd.log -f /etc/xinetd.conf# kill -sigusr1 50
Look at the tail of the log file (with a tail command) to ensure that your configuration and change have taken effect. If you are a remote user, make sure you can re-log in after you quit. Note Using -HUP to reconfigure the xinetd, it will actually cause the xinetd to stop operation. From a design perspective, this can prevent hackers from reconfiguring your xinetd and reload it if you do not need to understand documents.
When using Xinetd, I personally, I have made xinetd; the only service that has an impact on performance is my Apache Web daemon. Too many processes have to be started, which is too fast for it to time efficiency. DNS services should not use Xinetd, performance consumption too much. I also used Xinetd to sendMail service. This allows for a customer to be connected to perfect control. My settings for Sendmail are as follows:
service smtp {socket_type = stream protocol = tcp wait = no user = root server = / usr / sbin / sendmail server_args = -bs instances = 20 nice = 10 only_from = 0.0.0.0 no_access = 129.22.122.84 204.0.224.254}
Even on a high-flow mail server, the impact of performance can be ignored. I also load SSHD into Xinetd to block the process table attack on it. Conclusion I hope this article is helpful to you or adjust the inetd as needed. As you can see, it provides a much larger than inetd, and even contains TCP_WrapPers. Solar Designer (http://www.openwall.com/) provides a patch for a slightly a bit of xinetd (2.2.1 version), allowing IP-based instance control, which helps to block simple process tables attack. Note, in any case, simple forgery can bypass it. I don't know if this package is also applicable to the future XINETD.
Attachment: Xinetd Represents Extended Internet Services Daemon A reference settings on a xinetd.conf man page below: # # Sample configuration file for xinetd #
defaults {log_type = FILE / var / log / servicelog log_on_success = PID log_on_failure = HOST RECORD only_from = 128.138.193.0 128.138.204.0 only_from = 128.138.252.1 instances = 10 disabled = rstatd}
# # Note 1: the protocol attribute is not required # Note 2: the instances attribute overrides the default # service login {socket_type = stream protocol = tcp wait = no user = root server = /usr/etc/in.rlogind instances = UNLIMITED }
# # Note 1: the instances attribute overrides the default # Note 2: the log_on_success flags are augmented # service shell {socket_type = stream wait = no user = root instances = UNLIMITED server = /usr/etc/in.rshd log_on_success = HOST RECORD}
Service ftp {socket_type = stream wait = no nice = 10 user = root server = /usr/etc/in.ftpd server_args = -l instances = 4 log_on_success = DURATION HOST userid access_times = 2: 00-9: 00 12:00 -24: 00} # litTes of memory and a Total # 20 CPU Seconds for Child Processes. Service telnet {socket_type = stream wait = no nice = 10 user = root server = /usr/etc/in.telnetd RLIMIT_AS = 8m rlimit_cpu = 20}
# # This entry and the next one specify internal services. Since # this is the same service using a different socket type, the # id attribute is used to uniquely identify each entry # service echo {id = echo-stream type = INTERNAL socket_type = Stream User = root wait = no}
Service echo {id = echo-dgram type = internal socket_type = DGRAM user = root wait = no}
Service Servers {type = internal unlisted protocol = tcp port = 9099 Socket_type = stream wait = no}
# # Sample RPC service # service rstatd {type = RPC socket_type = dgram protocol = udp server = /usr/etc/rpc.rstatd wait = yes user = root rpc_version = 2-4 env = LD_LIBRARY_PATH = / etc / securelib}
# # Sample unlisted service # service unlisted {type = unlished socket_type = stream protocol = tcp wait = no server = / home / user / some_server port = 20020} end.
Postscript: On the Internet, I saw this translation document 2 years ago, read it, I found a lot of fallacy, I found the original text, and I did something wrong. I have no enthusiasm for Linux. There is no high 2 years ago, and the tracking of Linux hasn't been so enthusiastic. It is not so strict enough for this article. It is definitely still existed. Welcome to point out! Thank you!
