Two daemon processes in Linux stand alone and xinetd

Two daemon processes in Linux stand alone and xinetd

--http://www.cnblogs.com/itech/archive/2010/12/27/1914846.html#top

General use Stand alone/etc/init.d/

Very little use of xinetd/etc/xinetd.d/

How the Linux daemon works

1. Independent run (stand-alone) daemon

The standalone daemon is managed by the Init script, and the scripts for all the independently running daemons are in the/etc/rc.d/init.d/directory. System services are self-running daemons, including SYSLOGD and Cron. The standalone daemon works as stand-alone, which is a UNIX-traditional access pattern for the C/s mode. The stand-alone mode works as shown in 4-4.

Work in stand-alone mode network services have xinetd, route, gated, in addition to the Web server Apache and mail server sendmail, domain name server bind. Services initiated through stand-alone mode on Linux systems are started by symbolic links in the corresponding runlevel below/etc/rc.d/.

2. XINETD mode runs an independent daemon

From the daemon concept, it can be seen that for each service that the system is going through, it must run a daemon that listens to a port connection, which usually means a waste of resources. To solve this problem, Linux introduces the concept of "Network Daemon Service Program". The network daemon used by Red Hat Linux 9.0 is xinted (eXtended Internet daemon). XINETD can listen to multiple specified ports at the same time, when accepting user requests, it can initiate different network service processes to handle these user requests depending on the port the user requests. You can think of xinetd as a Management server that manages the startup service, decides which program to hand a client request to, and then initiates the appropriate daemon. XINETD does not run and listens for services on all ports it manages. When a request arrives for a service to which it manages, XINETD initiates the appropriate server for the service. The XINETD mode works as shown in 4-5.

3. xinetd and stand-alone mode of operation, the system does not want each network service process to listen to its service port, running a single xinetd can simultaneously listen to all service ports, thus reducing the system overhead and protecting system resources. However, in the case of large access and frequent concurrent access, XINETD will frequently start the corresponding network service process, which can result in degraded system performance. To see what mode of operation the system provides for Linux services, you can use the Pstree command on the Linux command line to see two different mode-initiated network services. In general, some of the high-load services in the system, Sendmail, Apache services are started separately, and other service types can be managed using XINETD Super server.

Five Xinetd

1. What is xinetd

XINETD is extended Internet daemon,xinetd is a new generation of Network Daemon service program, also known as Super Internet server. Often used to manage a variety of lightweight Internet services. XINETD provides functionality similar to Inetd+tcp_wrapper, but is more powerful and secure.

2. Features of XINETD

1) Powerful access control function
-built-in differential treatment settings for malicious and bona fide users.
-With libwrap support, it is more effective than TCPD.
-You can limit the level of connections, the number of host-based connections, and the number of service-based connections.
-Set a specific connection time.
-Set a service to a specific host to provide the service.

2) effectively prevent Dos attacks
-You can limit the level of connections.
-You can limit the maximum number of connections for a host to prevent a host from monopolizing a service.
-You can limit the size of the log file to prevent disk space from being filled.

3) Powerful log function
-Log levels can be set for each service on the syslog.
-If you do not use syslog, you can also create a log file for each service.
-You can record the start and end times of the request to determine the access time for each other.
-You can log requests that you attempted to access illegally.

4) Steering function
The client's request can be forwarded to another host for processing.

5) Support IPV6
XINETD from xinetd 2.1.8.8pre* support IPV6, can be done by using the/configure with-inet6 option in the. Capability script. Note that in order for this to take effect, the core and network must support IPV6. Of course IPv4 is still supported.

6) Interactive functions with the client
Regardless of whether the client request is successful, xinetd will be prompted to inform the connection status.

3. Disadvantages of XINETD
At present, its biggest disadvantage is the instability of RPC support, but it is possible to start protmap so that it can coexist with xinetd to solve this problem.

4 starting the daemon with xinetd
In principle, any system service can use XINETD, but the most suitable should be those commonly used network services, at the same time, the number of requests and the frequency of the service is not too high. Like DNS and Apache is not suitable for this way, and like FTP, Telnet, SSH and so on for the use of XINETD mode, the system default use of XINETD services can be divided into the following categories.
① standard Internet service: Telnet, ftp.
② Information Service: Finger, netstat, systat.
③ Mail Service: IMAP, IMAPS, POP2, POP3, pops.
④RPC services: Rquotad, RSTATD, RUSERSD, Sprayd, Walld.
⑤BSD services: Comsat, exec, login, ntalk, Shell, talk.
⑥ Internal services: Chargen, Daytime, ECHO, servers, services, time.
⑦ Security services: IRC.
⑧ Other services: Name, TFTP, UUCP.

5. Interpreting xinet configuration Files/etc/services,/etc/xinetd.conf and/etc/xinetd.d/*

0)/etc/services

The port under XINETD is set in/etc/services, for example:

$ cat/etc/services | grep rsync
rsync 873/tcp # rsync
rsync 873/UDP # rsync

The configuration file for

1)/etc/xinetd.conf
xinetd is/etc/xinetd.conf, but it includes only a few default values and a configuration file in the/etc/xinetd.d directory. If you want to enable or disable an xinetd service, edit the configuration file that is located in the/etc/xinetd.d directory. For example, the Disable property is set to Yes to indicate that the service is disabled, and the Disable property is set to No, indicating that the service is enabled. /etc/xinetd.conf has many options, the following is the/etc/xinetd.conf of Rhel 4.0.
# Simple configuration file for xinetd
# Some defaults, and include/etc/xinetd.d/
defaults
{
 & nbsp;  instances             =
     log_type               = SYSLOG authpriv
    log_on_success       = HOST PID
     log_on_failure       = HOST
    cps                    = +
}
Includedir/ ETC/XINETD.D

-instances = 60: Indicates the maximum number of connection processes is 60.
-log_type = Syslog Authpriv: Indicates a service enlistment using a syslog.
-log_on_success= HOST PID: Indicates the process ID that records the IP address of the client after it has been successfully set.
-log_on_failure = HOST: Indicates that the client's IP address is logged when the setting fails.
-cps = 25 30: Represents 25 inbound connections per second, and waits 30 seconds if the limit is exceeded. Mainly used to deal with denial of service attacks.
-INCLUDEDIR/ETC/XINETD.D: Indicates that the file or directory to which XINETD is to be included is/ETC/XINETD.D.

2)/etc/xinetd.d/*
The following is an example of a file (rsync) in/etc/xinetd.d/.
Service rsync
{
Disable = yes
Socket_type = Stream
wait = no
user = root
Server =/usr/bin/rsync
Log_on_failure + = USERID
}

The meanings of each line option are described below.
-disable = yes: Indicates that the service is disabled.
-socket_type = stream: The packet type that represents the service is stream.
-wait = No: Indicates that no wait is required, i.e. the service will run in a multithreaded manner.
-user = root: Indicates that the user executing this service process is root.
-server =/usr/bin/rsync: The location of the startup script.
-log_on_failure + = USERID: Indicates that the UID is added to the system registration form when the setting fails.

5 Configuring XINETD
1) format
Each entry in/etc/xinetd.conf has the following form:
Service Service-name
{
......
}

Where service is a required keyword, and the attribute table must be enclosed in curly braces. Each item defines a service defined by Service-name.
Service-name is arbitrary, but is typically a standard network service name and can also be added to other nonstandard services as long as they can be activated over a network request, including a network request from localhost itself. There are many properties that you can use, and you will later describe the usage rules for the required properties and properties.

The operator can be =, + =, or-=. All properties can use =, which is to assign one or more values, and some properties can use + = or-=, with the effect of increasing their values to an existing value table or removing their values from the existing value table.

2) configuration file
The relevant configuration files are as follows:
/etc/xinetd.conf
/etc/xinetd.d/*//All files in this directory
/etc/hosts.allow
/etc/hosts.deny

3) disabled and enabled in/etc/xinetd.conf
The parameter of the former is a list of disabled services, and the latter parameter is the list of services that are enabled. What they have in common is the same format (attribute names, service names, and services are separated by spaces, such as disabled = IN.TFTPD IN.REXECD), and they all work globally. If it is specified in the disabled list, it is disabled regardless of whether the service included in the list has a profile and how it is set, and if the enabled list is specified, only the services in the list can be started, and if enabled is not specified, All services other than the specified service disabled can be started.

4) Attention Issues
① when reconfiguring, the following properties cannot be changed: Socket_type, wait, protocol, type;
② if the Only_from and No_access properties are not specified (either directly or by default in the service item), there is no limit to the access IP for the service;
The ③ address check is for an IP address and not for a domain name address.

6 xinetd reasons for preventing denial of service attacks (denial of services)
XINETD can effectively prevent denial of service attacks (denial of services) for the following reasons.

1) Limit the number of processes running concurrently
Set the instances option to set the number of concurrent processes running concurrently:
Instances=20
When the number of processes that the server is requested to connect to is 20, XINETD will stop accepting more than one part of the connection request. Until the number of request connections is below the set value.

2) Limit the maximum number of connections to an IP address
Prevents a host from monopolizing a service by limiting the maximum number of connections to a host.
Per_source=5
Here the number of connections per IP address is 5.

3) Limit log file size to prevent disk space from being filled
Many attackers know that most services need to be written to the log. Intruders can construct a large number of error messages and send them out, and the server logs these errors, potentially causing the log files to be very large or even stuffed with hard disks. At the same time, the administrator will face a large number of logs, but not to discover the intruder's true intrusion path. Therefore, limiting the log file size is one way to protect against denial of service attacks.
Log_type File.1/var/log/myservice.log 8388608 15728640
The log file set here File.1 a critical value of 8MB, when this value is reached, the Syslog file will be alerted to reach 15MB, the system will stop all services using this log system.

4) Limit Load

XINETD can also protect against denial of service attacks using a method that restricts the load. With a floating-point number as the load factor, the service suspends processing of subsequent connections when the load reaches that amount.
Max_load = 2.8
The above setting indicates that when a system load reaches 2.8, all services are temporarily aborted until the system load drops below the set value.
Note that to use this option, compile with "--with-loadavg", XINETD will handle max-load configuration options to shut down certain service processes when the system is overloaded, to protect against certain denial of service attacks.

5) Limit the number of servers (connection rate)
XINETD can use the CPS option to set the connection rate, the following example:
CPS = 25 60
The above setting indicates that the server initiates a maximum of 25 connections, and if this number is reached, it will stop starting the new service for 60 seconds. No requests are accepted during this period.

6) Restricting the use of hardware resources
With the Rlimit_as and rlimit_cpu two options, you can effectively limit the resource usage of a service to memory and CPU:
Rlimit_as = 8M
Rlimit_cpu=20
The above setting represents a limit on server hardware resource usage, with up to 20 processes per second for 8MB,CPU memory.

An important feature of XINETD is its ability to control the amount of resources that a dependent service can utilize, which can be achieved through the above settings, helping to prevent a xinetd service from taking up a significant amount of resources, leading to a "denial of service" situation.

Six service commands

The service command for Linux is to view and control all of the independent boot daemon processes. This command is not available in all Linux distributions. Mainly in the Redhat system Linux. Service This command is located in/sbin/service, and viewing this command with the file command finds it to be a script command. The analysis script shows that the purpose of this command is to go to the/ETC/INIT.D directory to find the appropriate service, to open and close operations. For example, service mysqld stop is equivalent to/etc/init.d/mysqld stop.

The seven xinetd itself is also an independent daemon, in/etc/init.d/xinetd.

Two daemon processes in Linux stand alone and xinetd