Xinetd Complete Guide
Author: ideal
What is xinetd?
Everyone must be familiar with the inetd called the super server, and its actual control is connected to the host network. When a request arrives at the service port managed by inetd, inetd forwards the request to a program named TCPD. TCPD determines whether the request is allowed to serve the request according to the configuration file hosts. {Allow, deny}. If the request is allowed to be allowed, the corresponding server program (such as: ftpd, telnetd) will be started. This mechanism is also called TCP_Wrapper.
Xinetd (Extended Internet Services Daemon) provides a function similar to inetd tcp_wrapper, but more powerful and secure. It provides the following features:
* Support TCP, UCP, RPC services (but currently support for RPC is not stable)
* Based on time period access control
* Full log function, you can record the connection success or behavior of the connection failed
* Effectively prevent DOS attacks (DEnial of services)
* Number of servers that can limit the simultaneous operation
* Significant number of servers that can be limited
* Limit the log file size
* Bind a service on a specific system interface, so that only allows private networks to access a service
* Enable agents as other systems. If combined with IP camouflage, access to internal private networks can be implemented
Its biggest disadvantage is the instability supported by RPC, but you can start ProtMap, coexist with Xinetd to solve this problem.
Compilation and installation
You can download Xinetd from www.xinetd.org, the current latest version is XINETD 2.1.8.8P3. By default compiling and installing xinetd is very simple, followed by the following steps:
#. / configure; make; make install
Okey completion.
When Configure is performing configure, you can support the following options:
--with-libwrap: If you use this option XINETD, you will look at the TCPD profile (/etc/hosts. {directionow, deny}) to perform access control, but if you want to use this feature, you must have TCP_Wrapper and related libraries on the system. .
--with-loadavg: Use this option, XINETD will process the max-load configuration option. Thus, some service processes are turned off at the system load over time, and some DOS attacks are implemented.
--with-inet6: Using this option xinetd will support IPv6.
Configure
The default configuration file for xinetd is /etc/xinetd.conf. Its syntax and /etc/inetd.conf are completely different and is not compatible. It is essentially a combination of /etc/inetd.conf and /etc/hosts.allow ketc/hosts.deny function. Every item in /etc/xinetd.conf has the following form
Service service-name
{
}
Where service is the necessary keywords, and the property table must be enclosed in braces. Each item defines the service defined by the service-name.
Service-name is arbitrary, but it is usually a standard network service name, and other non-standard services can also be increased as long as they can be activated over the network, including the network request issued by LocalHost itself. There are a lot of Attribute that can be used, in detail in the table below. The necessary properties and properties will be described later.
The operator can be =, =, or - =. All attributes can use =, their function is assigned one or more values, some attributes can be used in the form of = or - =, and their roles are added to an existing value table, or to respectively Remove from the existing value table. Table 10.10 illustrates the properties of the latter form. Value is a parameter set for a given property.
Table 1 Extended LNERNET Service Process Properties
Attributes
Description and allow value
Socket_type
TCP / IP Socket type, value may be Stream (TCP), DGRAM (UDP), RAW, and SEQPACKET (reliable orderly)
Protocol
Specify the protocol used by the service, its value must be defined in / etc / protocols. If you do not specify, use the default protocol of the service.
Server
The process to be activated must specify a full path
Server_args
Specifies the parameters transmitted to the process, but does not include the service program name
Port
Define the port number related to this service. If the service is listed in / etc / services, they must match
Wait
This attribute has two possible values. If Yes, XINETD will start the requested process and stop the request for the service until the process is terminated. This is a single-threaded service. If it is NO, the XINETD will start a process that is started for each request, regardless of the state of the previously started process. This is a multi-thread service
User
Set the UID of the service process, but if the effective UID of xinetd is not 0, the property is invalid
Group
Set the GID of the process. If the effective UID of xinetd is not 0, this property is invalid
Nice
Specifies the NICE value of the process
Id
This property is used uniquely specified a service. Because some services are only in use of different protocols, it is necessary to use this attribute to distinguish. The service ID and service name are the same by default. For example, Echo supports DGRAM and STREAMA services. Set id = echo_dgram and id = echo_streams to uniquely identify two services, respectively
Type
Can be one or more values: RPC (for RPC), INTERNAL (served by xinetd itself, such as echo), unlisted (not listed in standard system files such as / etc / rpc or / etc / service) service)
Access_time
Set the time interval when the service is available. The format is hh: mm_hh: mm; such as 08: 00-18: 00 means from 8 A.M to 6p.m. This service can be used
Banner
Whether the connection is allowed, the file is displayed to the client when the connection is established.
Flags
Can be any combination of one or more options:
Reuse: Setting TCP / IP socket reuse. That is to set the SO_REUSEADDR flag in this service socket. When breaking and restarting xinetd
Intercept: Intercept Dente Denomes Perform access checks to determine that it comes from the location where the connection is allowed. You cannot use this property value with the INTERNAL service and multithreaded service.
NORETRY: If the Fork fails, do not try
IDonly: The connection is only accepted only when the remote user is recognized (that is, the remote system must run the Ident server), which is only available for connection-oriented services. If the UserID record option is not used, the tag invalid log_on_success and / or log_on_failure property sets the UserID value to make this value take effect. Slow service only for multi-threaded
Nameinargs: Allows the first parameter in the Server_args property to be the fully qualified path of the process to allow TCP_WrapPers
Nodelay: If the service is a TCP service, and the Nodelay tag is set, the TCP_NodeLay tag will be set. If the service is not a TCP service, the tag is invalid RPC_Version
Specify the RPC version number or service number. The version number can be a single value or a range such as 2-3
RPC_Number
If the RPC program number is not in / etc / rpc, specify it
ENV
Separated VAR = Value table with spaces, where var is a shell environment variable and value is its set value. These values and XINETD environments are activated to the service program. This property supports = and = operator
Passenv
The table is passed to the service program when activated with a space-separated XINETD environment. Set NO does not transfer any variables. This property supports all operators
ONLY_FROM
Use a space to allow access to a client to access the service. Table 2 gives the client syntax. If you do not specify a value for this property, you refuse to access this service. This property supports all operators.
NO_ACCESS
Refuse to access service with spaces. Table 2 gives the client syntax. This property supports all operators
Instances
Accept an integer or unlimited greater than or equal to 1. Set the maximum number of processes that can run simultaneously. Unlimited means that XINETD does not limit the number.
LOG_TYPE
Specify the service log recording mode, you can:
Syslog facility [level]: Set this tool to Daemon, Auth, User or Loca10-7. Setting Level is optional, available for Emerg, Alert, crit, Err, Warning, Notice, Info, Debug, default is INFO
FILE [Soft [Hard]]: Specifies the file to record the log instead of syslog. Limit Soft and HARD specify (optional) with KB (optional). Once the SOFT limit is reached, XINETD registers a message. Once the Hard limit is reached, XINETD stops registering all services to use the file. If you do not specify a Hard limit, it becomes Soft plus 1%, but the default does not exceed 20MB. The default SOFT limit is 5MB
REDIRECT
This attribute syntax is redirect = ipaddress port. It reliesTCP services to another system. If you use this property, you ignore the Server property.
Bind
Bind a service to a specific port. The syntax is bind = ipaddress. This has multiple interfaces (physical or logical) hosts allow an interface but not specific services (or ports) on other interfaces.
LOG_ON_SUCCESS
Specifies the information registered when successful. May value
PID: PID of the process. If a new process is not bifurcated, the PID is set to 0.
Host: Client Host IP Address
UserID: High Use the UID that captures the client user via RFC1413. Can only be used for multi-threaded flow services.
EXIT: Registration process termination and state
Duration: Registration Session Continction
No information is not registered by default. This property supports all operators
LOG_ON_FAILURE
The information registered when it fails. Always register the message indicating the nature of the error. Possible values are Attempt: Record a failure attempt. All other values are implied to this value.
Host: Client Host IP Address
Userid: Call the UID of the capture client user via the RFC 1413. only
Can be used in multi-threaded flow services.
Record: Record additional client information such as local users, remote users
And the type of terminal.
No information is not registered by default. This property supports all operators.
Disabled
You can only use the default item (see the defaults behind this section), specify the closing service list, is represented by a non-available service list separated by a space. It and the service item has the same effect in the /etc/xinetd.conf file. We first look at a simple example. Example 1 is an example of the configuration file /etc/xinetd.conf. The definition of these two services seems to be based on /etc/inetd.conf because they are converted from /etc/inetd.conf with the iTox tool, only the /etc/inetd.conf item is converted into appropriate xinetd grammar. Thus, these attributes (the left side of the = number in the braces) is very straightforward, and the correlation value (the right side of the = number in the braces) is also.
Example 1 file /etc/xinetd.conf
SERICE FTP {
Socket_type = stream protocol = tcp wait = no user = root server = root Server_args = - 1 - a} Service telnet {Socket_type = stream protocol = tcp wait = tcp user = root server = / usr / sbin / in.telnetd
The easiest way to create /etc/xinetd.conf file is to use iTox tools (this example assumes that the current work directory is the compilation directory of Xinetd:
# Xinetd / ketox -daemon_dir / usr / sbin /etc/xinetd.conf. ITOX parameters -Daemon_dir / usr / sbin Specifies the directory location of the service program, if you implement TCP_WrapPers, from /etc/inetd.conf, it cannot be determined, after the conversion is complete, start adding attributes and values to restrict access and Increase registration, finally modify /etc/xinetd.conf to take advantage of the features of Xinetd; otherwise, if only /etc/inetd.conf converts to /etc/xinetd.conf, Xinetd's behavior is the same as inetd.
Table 1 details some of the most commonly used properties and values that are most common in /etc/xinetd.conf. Of course, there are many other properties, and the detailed configuration options can be obtained through Man XineTd.conf after installing xinetd. In the Configuration Instances behind this section, many of the properties will be clarified by some examples.
Table 2 gives the syntax of the ONLY_FROM and NO_ACCESS tables to define the syntax of the specified hostname, IP address, and network. Note that the last NetMask's syntax in Table 2 is different from the previously seen. It does not use traditional decimal or hexadecimal Netmask's representation, but uses an integer representing the number of digits from NetMask (with binary representation). Therefore, the NetMask value of a given example is set to 20, meaning that the leftmost 20 bits are set to 1, and the remaining 12 bits are set to 0, or
11111111 11111111 11110000 00000000
It is a binary representation of the decimal Netmask255.255.240.0.
Table 2 /etc/xinetd.conf's Access Control Table Syntax
Phonetic
Describe
Hostname
Analytical host name. All IP addresses related to this hostname
IPaddress
Standard IP addresses in points and decimal forms, such as 192.168.0.1Net_name
Network name in / etc / networks
X.x.x.0 x.x.0.0
X.0.0.0 0.0.0.0
0 is viewed as a wildcard. As item 88.3.92.0 matches all IP addresses from 88.3.92.0 to 88.3.92.255. Item 0.0.0 Match all addresses
X.x.x. {a, b, ...}
X.x {a, b, ...}
x. {a, b, ...}
Specifies the host table. Such as 172.19.32. {1,56,59} Means Table of IP Address 172, 19.32.1, 172.19.32.56 and 172.19.32.59
Ipaddress / Netmask
Define the network or subnet to match. As 172.19.16.0/20 matches all addresses from 172.19.16.0 to 172.19.31.255
After reading these basic properties, let's take a closer discuss those required properties, specific services, and some configuration instances.
Required properties must specify certain properties for each service. Some services require more properties than other services because they are not defined by default (ie, not in / etc / services or / etc / rpc). Table 3 lists the necessary properties.
Table 3 required attributes
Language SD_type All Service WAIT All Services User Listed in / etc / Services or / etc / RPC Server Non-internal Services in / etc / Services Non-RPC Services Protocol is not in / etc / services All RPC services and all other service RPC_Version All RPC services RPC_Number is not listed in any RPC service in / etc / rpc
There are 4 special items in a specific xinetd service /etc/xinetd.conf file. They are Defaults, Servers, Services, and XADMIN. The DEFAULTS item is not a service, and does not need a pre-service keyword (otherwise it will be treated as a service called Defaults). These special items are described in the following 4 segments.
The default item in the default item /etc/xinetd.conf file is the default value that implements all the services in the file specifying certain properties. These default values can be canceled or modified by each service item. Table 4 lists the properties that can be specified in the Defaults item. This table also indicates which properties can be modified in the specific service item.
Table 4 Defaults available attributes
Property Service Modify Log_on_suCcess Log-on_Failure Only_FROM NO_ACCESS Passenv You can use = operator to rewrite or with = or - = operator modification instances log_type can use = operator to rewrite the service, but the Disabled property can be used for a service item Inside
Example 2 is an example of a default. As seen from it, the registration message will be sent to the syslogd process via Loca14.info. For successful service connections, register PID, client IP address, abort status, and connection time. For unsuccessful connection attempt, the client IP address will be registered. The maximum number of instances per service is set to 8. Ban two services: in.tftpd and in.rexecd.
The Default item is essentially a default value for establishing certain properties throughout the file, which is applied to all services that do not set these properties.
Example 2 /etc/xinetd.conf Example of Defaults
Defaults {log_type = syslog loca14 info log_on_success = pid Host exit duration log_on_failure = host instances = 8 disabled = in.tftpd in.rexecd} comment
If there is no DEFAULTS item in the /etcxinetd.conf file, and then decide to add this, you must stop and restart the xinetd to make the defaults take effect. This is also true for any new service to increase to /etc/xinetd.conf. It can be done as follows.
# Kill-Term xinetd
# / usr / sbin / xinetd
Or if you use a startup script, just simply execute.
# / Etc / rc.d / init.d / xinetd restart
Servers Item Servers Special Services is to implement process tables currently run on the server, and exact information about these processes. In other words, it provides a list of active connections. This is a useful mechanism for exclusion failures and checking the xinetd status. Example 3 shows an instance servers item in the /etc/xinetd.conf file. Note The type of this service is Internal, Unlisted, which means it is the internal function of Xinetd, and is not listed in / etc / services. The port used is completely arbitrary.
Example 3 of the 3 Servers item
Service Servers
{
TYPE = INTERNAL UNLISTED
Socket_type = stream
Protocol = TCP
Port = 9997
Wait = NO
ONLY_FROM = 172.17.33.111
Wait = NO
}
Note that this service is only used for a specific IP address 172.17.33.111, which is the IP address of the server itself. This means that any other host is not allowed to get a list of processes currently running on the server from this server. The reason for this is obvious: if this information can be obtained by the host on other systems, based on the understanding of the currently running process. In addition to being commissioned, it is generally not to run because any user on 172.17.33.111 can obtain this information through Telnet 172.17.33.111 9997 in Executive Example 4. Note that xinetd only provides this information and does not provide an interactive connection. The output in Example 4 tells us that there are two running Telnet processes (line 5 and 31), one process PID is 5931, and the other is 5961 (6 lines and 32), there is an FTP Process (line 18), which runs PID to 5960 (line 19).
Example 4 Sample of Servers Services
1 2 $ TELNET TOPCAT 9997
Trying 172.17.33.111 ......
(Continued)
3 connection to topcat
4 Escape Character is '^]'
5 Telnet Server
6 pid = 5931
7 start_time = sat apr 17 10:32:15 1999
8 Connection Info:
9 state = closed
10 service = telnet
11 DESCRIPTOR = 20
12 Flags = 9
13 Remote_address = 10.48.3.2, 39958
14 Alternative Services = 15 log_remote_user = YES
16 WRITES_TO_LOG = YES
In one
18 FTP Server
19 pid = 5960
20 start_time = sat apr 17 10:49:06 1999
21 Connection Info:
22 State = Closed
23 Service = FTP
24 DESCRIPTOR = 20
25 Flags = 9
26 Remote_address = 172.17.55.124,2320
27 Alternative Services =
28 log_remote_user = YES
29 WRITES_TO_LOG = YES
30
31 Telnet Server
32 pid = 5961
33 Start_Time = Sat Apr 17 10:49:20 1999
34 Connection Info:
35 State = Closed
36 Service = Telnet
37 descriptor = 20
38 Flags = 9
39 Remote_address = 172.17.1.3, 35461
40 Alternative Services =
41 log_remote_user = yes
42 WRITES_TO_LOG = YES
43
44 Connection Closed by Foreign Host
45 $
The purpose of the Services item Services specific item is to provide a list of available services. For Services specific items, this is a useful exclusion fault tool, but for the same security factor above, it may not be used. Despite this, you still have to look at how it works.
Example 5 is an example of the Services item. The choice of port numbers is also arbitrary. It should also be noted that access is limited to Topcat, which is the host name of the server itself.
Example 5 /etc/xinetd.conf SERVICES item example
Service Services
{
TYPE = INTERNAL UNLISTED
Socket_type = stream
Protocol = TCP
Port = 8099
Wait = NO
ONLY_ from = Topcat
}
For Servers services, any user can perform Telnet Topcat 8099 and obtain an output from the Services service. Example 6 gives an instance information information of the connection 8099 port. Note XINETD only provides this information and does not provide any interaction connection.
Example 6 Query the output of SERVICES internal services
$ Telnet topcat 8099 Trying 172.17.33.111 ...... Connected to topcat. Escape character is '^]' Servers tcp 9997 Services tcp 8099 ftp tcp 21 telnet tcp 23 Shell tcp 514 Login tcp 513 Talk udp 517 Ntalk udp 518 Pop-2 tcp 109 POP-3 TCP 110 IMAP TCP 143 Linuxconf TCP 98 Connection Closed by Foreign Host. $
XADMIN item This particular service item provides a method of obtaining information provided by a Services specific service in an interactive manner. Example 7 is an example of /etc/xinetd.conf item (the selection of port numbers is also arbitrary), similar to Services and Servers services, this service has no password or other protection, so be careful to set the service, Enhance security. Example 7 XADMIN
Service xadmin {type = internal unlisted socket_type = stream protocol = tcp port = 9967 wait = no = = topcat}
For the first two specific service types, you only need Telnet to the column port, namely Telnet Topcat 9967. Unlike the first two services, XADMIN provides an interactive environment. Once connected to the XADMIN server, 5 commands can be executed. They are Help, Show, Run, BYE and EXIT. Help Command Displays other commands and a short usage message. Bye and exit commands are turned off. The Show Run and Show Avail commands provide information provided by Servers and Services, respectively.
caveat
As pointed out in the first 3 paragraphs, these specific services Servers, Services, and xadmin generated information can be used to attack the system. You may not need to run these services, perhaps only when you debug it. At any time, if these services are indeed, the access control is configured to configure Access_FROM and / or NO_ACCESS. You can also use the bind property to use the BIND attribute to further restrict access.
Configuration Instance This section will see some different examples, related behaviors, and their registration messages thereof.
Access control starts from a simple access control example. In Example 10, the server TOPCAT's Login service item allows IP addresses to access at 172 but not any system starting at 172.19. This example includes a defaults section. Assuming this uses for the Login service and activates the Rlogin command from the client, allowing us to check the successful and unsuccessful attempts, and their registration.
Assume that the host underdog and IP address are 172.18.5.9. Then when Mary performs rlogin registration topcat, give her access. This successful login is shown in Example 11. Although Example 11 illustrates the log content generated by Mary. As shown in Example 12, the last item in this example reflects the exit when MARY is removed. You can use PID to trace an exit of a session, as long as you indicate that this PID will be registered in /etc/xinetd.conf. The registration is as follows: Each xinetd registry record date and timestamp, then the server hostname, then XINETD, then in parentheses is the pid of Xinetd. The first record in Example 12 starts at the start keyword, indicating the beginning of this session, and then identifies the activation process (login), then activates the PID of the process, and finally the client address.
Example 10 Example of the rlogin service item in /etc/xinetd.conf
DEFAULTS
{
LOG_TYPE = SYSLOG LOCA14 INFO
LOG_ON_SUCCESS = PID HOST EXIT DURATION
LOG_ON_FAILURE = Host
INSTANCES = 8
}
Service login
{
Socket_type = stream
Protocol = TCP
Wait = NO
User = rootflags = reuse
ONLY_FROM = 172.0.0.0
NO_ACCESS = 172.19.0.0
OLG_ON_SUCCESS = UserID
OLG_ON_FAILURE = UserID
Server = / usr / sbin / in.ftpd
Server_args = -1 -a
}
Example 11 successful Rlogin attempt
[Mary @ Underdog] $ rlogin Topcat
PASSWORD:
Last login: Wed Apr 14 17:45:02 from roadrunner
[MARY @ Topcat] $
Example 12 and Example 11 Related registration
APR 15 11:01:46 Topcat Xinetd [1402]: start: login pid = 1439
From = 172.18.5.9
Apr 15 11:01:46 Topcat Xinetd [1439]: Userid: Login other: Mary
...
...
Apr 15 11:39:31 Topcat Xinetd [1402]: EXIT: Login Status: 1 PID = 1439 DURA-
Tion = 2265 (SEC)
The second item starts with the userid keyword, indicating that the RFC1413 call is successfully issued. After the service name (login), the remote system responds to RFC1413 (at this time), the last remote username (MARY).
The meaning of these LOG items is clear, but Table 4 provides the explanation of these keywords (such as Start, UserID and EXIT) and its meaning.
Now, Joe wants to use Rlogin on the host SLy.No.good.org (IP address 19.152.1.5). Example 13 shows this result. It seems that the Joe connection is rejected, or maybe he wants to be strong. Let us see the registries generated by this three attempts in Example 14. Note that the registration item does not include the remote username, although we use the log_on_failure attribute in Example 10 special requests that information. This is because the remote host sly.no.good.org does not run the IdentD or similar process. Because the host sly.no.good.org is not in the ONLY_FROM table in Example 10, although the FLAGS = IDonly is added in the Login service item, it will not record the fact that sly.no.good.org does not run identd. Such a registration record will appear only when the host is licensed.
Table 4 Description of XINETD registration
Registration keyword
Format and description
Start
START: Service_ID [PID = PID] [from = ipaddress]
Record the item when a service is started. Service_id is the service name, like the ID property specified (if this property is not set, it uses the value of the service parameter: see Table 10.10); PID is the identifier of the activation process, or if there is no process is activated, 0 (only not a spirit log_on_
SUCCESS is specified when the PID is recorded): ipaddress is the client's IP address (record only when Host is log_on_success))
Exit
EXIT: Service_ID [Type = S] [PID = PID] [DURATION = # (sec)]
This is recorded if the process is terminated only when the process is specified for log_on_success. Service_id and PID items are the same as before. The TYPE item records the exit state or generates a termination signal. Duration captures session time (number of seconds) and needs to explain Duration Options Fail in log_on_success
Fail: Service_id REASON [from = ipaddress]
This item is generated when a failed request occurs and at least the log_on_success property specifies a value. Service_ID is as before. Reason is a simple word or phrase that explains the cause of failure. IPadDress is a client address and needs to set up a host value for log_on_success properties.
Data
Data: Service_id Data
Record only when RECORD is specified for log_on_failure. Service_ID is as before. The recorded DATA depends on the service, but usually includes a remote username (if available) and status information.
UserID
Userid: service_id text
This place is logged only if log_on_success or log_on_failure or when you specify UserID. Service_ID is as before. Text includes the response of the client to RFC1413, especially remote username
NOID
NOID: Service_ID ipaddress Reason
This item appears only when the IDONLY value is set for the Flags property and at least log_on_success or log_on_on_failure sets the userID value. Service_ID is as before. The ipaddress given is the host address. Reason is a failure
Example 13 failed Rlogin attempts from unauthorized hosts
Sly.no.good.org $ rlogin Topcat
Topcat: Connection Reset by Peer
Sly.no.good.org $ rlogin -1 paul topcat
Topcat: Connection Reset by Peer
Sly.no.good.org $ rlogin -1 mary topcat
Topcat: Connection Reset by Peer
Sly.no.good.org $
Example 14 and Example 10-50 related registration items
Apr 15 12:08:40 Topcat Xinetd [1402]: Fail: Login Address from 19.152.1.5
APR 15 12:08:52 Topcat Xinetd [1402]: Fail: Login Address from-19.152.1.5
Apr 15 12:08:49 Topcat Xinetd [1402]: Fail: Login Address from 19.152.1.5
There is a final registration to check. Note The instances attribute in Example 10 is set to 8. What happens to the 9th login session? When the 9th user tries rlogin to Topcat, the user will see the following error message
RCMD: Topcat: Address Already in Uses
And the registration item recorded for this event in Topcat is
Apr 15 13:37:33 Topcat Xinetd (1402): Fail: Login Service_Limit from-172.17.55.124
Relative to this record and the description of Table 4, the FAIL key is the service name, then the explanation of the failed (at this time is Service_Limit), and finally the client address.
Use the BIND attribute BIND attribute to allow the IP address of a particular interface to associate with a specific service. It is assumed that there is an internal FTP server that provides read-only resources to the company staff via anonymous FTP. Suppose this FTP server has two interfaces, one connection in the corporate environment, and the other is connected to a private internal network, usually only the staff working in that particular group can access it. This example only considers the need to provide two different FTP services based on the interface. Example 15 illustrated two FTP service items in /etc/xinetd.conf. It can achieve desired features. DEFAULTS section is again provided for integrity. Note that each FTP service item has a unique ID attribute. There is no restriction on the number of services with the same name, as long as each unique identifier is available. In this example, the ID attribute is set for the internal FTP server as FTP, and the ID attribute is set to the external anonymous server as ftp_chroot. Note that in the latter case, the activated process is /usr/sbin/anon/in.Aftpd (TWIST for TCP_WrapPers), which is different from previous services.
Example 15 Bind the service to a specific address
DEFAULTS
{
LOG_TYPE = SYSLOG LOCA14 INFO
LOG_ON_SUCCESS = PID HOST EXIT DURATION
INSTANCES = 8
}
Service ftp
{
ID = ftp
Socket_type = stream
Protocol = TCP
Wait = NO
User = root
ONLY_FROM = 172.17.0.0 172.19.0.0/20
Bind = 172.17.1.1
LOG_ON_SUCCESS = UserID
LOG_ON_FAILURE = UserID
Server = / usr / sbin / in.ftpd
Server_args = -1 -a
}
Service ftp
{
ID = ftp_chroot
Socket_type = stream
}
Service telnet
{
Socket_type = stream
Wait = NO
Flags = Reuse
User = root
Bind = 172.17.33.111
Server = usr / sbin / in.telnetd
LOG_ON_SUCCESS = Pid Host Exit Duration UserID
LOG_ON_FAILURE = Record Host
}
Service telnet
{
Socket_type = stream
Protocol = TCP
Wait = NO
Flags = Reuse
User = root
Bind = 201.171.99.99
REDIRECT = 172.17.1.1 23
LOG_ON_SUCCESS = Pid Host Exit Duration UserID
LOG_ON_FAILURE = Record Host
}
Example 16 REDIRECT
$ telnet 201.171.99.99
Trying 201.171.99.99
Connected to 201.171.99.99
Escape Character is '^]'
UNIX (r) System V Release 4.0 (Foghorn)
Login:
Because Linux supports up to 256 logical interfaces for each physical port, it is theoretically 256 different addresses for each physical address.
Although the Redirect mechanism may be very useful, be careful when implementing it. Be sure to register on the proxy server and the terminal system. However, in a highly controlled internal network, this implementation may be convenient.
Contains TCP_WrapPers /etc/xinetd.conf Contains TCP_WrapPers function so simple, all features of TCP_WrapPers can be entered through xinetd, just like inetd. Example 17 is an instance of the /etc/xinetd.conf file that uses TCP_WrapPers for many services. When the property server is set to / usr / sbin / tcpd, that service will be wrapped. Note that such an item always sets the Server_args property to the process (full path) to be activated. To discuss the compile of XINETD, use the libwrap configuration option, but whether the configuration file in Example 17 can play regardless of whether LibWrap compiled. The role compiled with LibWrap is to include access restrictions in /etc/hosts.allow and /etc/hosts.deny. Example 7 provides a set of complete features of TCP_WrapPers, Banners, SpaWn, Twist, etc. Example 17 Using TCP_WrapPers in /etc/xinetd.conf
DEFAULTS
{
LOG_TYPE = SYSLOG LOCA14 INFO
LOG_ON_SUCCESS = PID HOST EXIT DURATION
LOG_ON_FAILURE = Host
INSTANCES = 8
}
Service ftp
{
ID = ftp
Socket_type = stream
Protocol = TCP
Wait = NO
User = root
ONLY_FROM = 172.17.0.0
LOG_ON_SUCCESS = UserID
LOG_ON_FAILURE = UserID
Access_times = 8: 00-16: 30
Server = / usr / sbin / tcpd
Server_args = /usr/sbin/in.ftpd -1 -a
}
Service telnet
{
Socket_type = stream
Wait = NO
Flags = nameinargs reuse
User = root
Bind = 172.17.33.111
Server = / usr / sbin / tcpd
Server_args = /usr/sbin/in.telnetd
LOG_ON_SUCCESS = Pid Host Exit Duration UserID
LOG_ON_FAILURE = Record Host
}
Service telnet
{
Socket_type = stream
Protocol = TCP
Wait = NO
Flags = Reuse
User = root
Bind = 201.171.99.99
REDIRECT = 172.17.1.1 23
LOG_ON_SUCCESS = Pid Host Exit Duration UserID
LOG_ON_FAILURE = Record Host
}
...
...
xinetd process
The xinetd process accepts several parameters. These parameters can be rewritten by attributes in the specific service default, or to write in a single attribute item of one or more services. However, all parameters given here or their default values are used to control the behavior of xinetd itself. For example, if the FILELOG tag is specified as xinetd, all status conversion messages will be registered there, although the /etc/xinetd.conf file specifies other registration locations for the service related messages. The available parameters are listed in Table 5.
Attention should be aware of all status information of the Xinetd report, always appear in the registration file specified in the -syslog or -filelog tag, whether the setting is set, or in /etc/xinetd.conf. If you want to capture the PID of xinetd in a file, you can use xinetd-pid 2> /var/run.xinetd.pid
The available signal XINETD process used with Xinetd is also based on the received signals to take specific actions. Table 16 describes the functions of each signal it accepts. Note Whenever a new service or default is added, or whenever any service is changed: Protocol, Socket_Type, Type or Wait, you must use the Sigterm (or easier TERM) signal to stop x atd. Write the registration item shown in Example 19 whenever a soft or hard repeat signal is issued to the XINETD. This particular example is the result of hard repeat. Note that the result of this hard repeating is to abort a service (identified with Dropped = 1).
Table 5 xinetd
Mark
Describe
-d debug mode. The output can be used to specify the syslogd tool with the debugger such as GDB. It is Daemon, Auth, User, and Loca10-7 -filelog file specifying registration to file instead of syslog. Must be a full path name -fconfig_file specified configuration file. Must be a full path name. By default, /etc/xinetd.conf-pid write PID write standard errors
-loop rate Specifies the number of processes per second. By default, 10. Must be able to change it for faster machines
-reuse Sets reusable TCP Socket, which means that other processes can be started when the previous instance is run. When used with the Flags property, there is a more special service control (see Table 10.10) -Limit Numproc Limit the total number of processes running simultaneously from XineTd to Numproc -
Limit the simultaneous RFC1413 request number limited to limit -shutdownprocs limit
When the RECORD value is used in the log_on_failure property, the XINETD is called Shutdown's service to collect information when the service is terminated. This option limit the total number of SHUTDOWN processes at the same time as Limit -CC Interval
Make Xinetd to consistency on its internal state every interval second. Manual implementation with killall -iot xetd
Table 18 xinetd signal
The signal is softly configured for SIGUSR1. Reread /etc/xinetd.conf and adjust the SIGUSR2 hard repeat configuration accordingly. Rereading /etc/xinetd.conf and kills all the processes that are no longer matched in the establishment criteria in the configuration file. For example, if a client is connected to the server and adds to the no_access table, then this signal terminates all the pro-forked forks of the client's session SIGQUIT termination XINETD but does not terminate it; then Termination XINETD SIGHUP Write XINETD Status Information to /TMP/xinetd.dump SIGIOT Checking Internal Database Destruction and Report Results
Example 19 XINETD Ruking Record
APR 15 14:42:31 Topcat Xinetd [1402]: Starting Hard Reconfiguration Apr 15 14:42:31 Topcat Xinetd [1402]: Readjusting Service Servers Apr 15 14:42:31 Topcat Xinetd [1402]: Readjusting Service Servces Apr 15 14:42:31 Topcat Xinetd [1402]: Readjusting Service Telnet Apr 15 14:42:31 Topcat Xinetd [1402]: Readjusting Service Shell Apr 15 14:42:31 Topcat Xinetd [1402]: Readjusting Service login Apr 15 14: 42:31 Topcat Xinetd [1402]: Readjusting Service NTalk Apr 15 14:42:31 Topcat xinetd [1402]: Readjusting Service POP-2 APR 15 14: 42:31 Topcat Xinetd [1402]: Readjusting Service POP-3 APR 15 14:42:31 Topcat Xinetd [1402]: Readjusting Service IMAP APR 15 14:42:31 Topcat Xinetd [1402]: Readjusting Service LinuxConf Apr 15 14: 42:31 Topcat Xinetd [1402]: Readjusting Service FTP Apr 15 14:42:31 Topcat Xinetd [1402]: Reconfigured: New = 1 OLD = 12 Dropped = 1 (Services) Note
Determine a modified /etc/xinetd.conf file is read by the most reliable way to stop and restart the xinetd process. It is best to use the Sigterm signal to stop xinetd. As described in this section, send XzineTd a sigterm to abort (with SIGKILL or signal number 9) to control each process under control. Sometimes there is a delay before the sub-process of Xinetd, which means if killing and immediately restarting xinetd, it is impossible to bind all ports (for this XINETD registration file --- instead of this service specified) Register file --- contains an error message). This is why the sleep3 command appears in the script between the STOP and START commands in the example. This issue is completely eliminated with the TCP service such as Telnet and FTP with Flags = Reuse property and its value or specifying the -reuse option to completely eliminate this issue.
