1. 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.
extended Internet Services Daemon provides a function similar to inetd TCP_Wrapper, but more powerful and secure. It provides the following features:
Support for TCP, UCP, RPC services (but currently not stable enough to stabilize the RPC) Based on the log functionality of the access control function of the time period, you can record the connection success or the behavior of the connection failure can effectively prevent DOS attacks (Denial Of Services) Can limit the number of servers at the same time that the number of servers that can limit the start-up server can limit the log file size to a particular system interface, so that only private network access to a service can be implemented. Implement a proxy for other systems. If combined with IP camouflage, access to internal private networks can be implemented
It is the biggest disadvantage that it is the instability supported by RPC, but it can start ProtMap, coexisting with XineTD to solve this problem.
2. Compilation and installation
You can download xinetd from www.xinetd.org, the current latest version is XINETD 2.1.8.8p3. The default compilation and installation XINETD is very simple, followed by the following steps: #. / Configure; make; Make Install
Okey completion.
When Configure is performed, 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.
If you use redhat7.0, it will be installed by default without installing itself.
3. Configuration
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. Each of /etc/xinetd.conf has the following form inline service-name
{{
.......
}
in which service is a necessary keyword, and the property table must be enclosed in braces. Each item defines the service defined by the service-name.
The Services-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 activate the network, including the network request issued by LocalHost. 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 parameter set for a given property.
Table 1 Extended LNERNET Service Process Attribute Socket_type
used TCP / IP Socket type, value may be Stream (TCP), DGRAM (UDP), RAW and SEQPACKET (reliable orderly)
Protocol
Specify the protocol used by this service, its value must be defined in / etc / protocols. If you do not specify, use the default protocol of the service.
Server
To activate the process, you must specify the full path
Server_Args
Specify the parameters transmitted to the process, but does not include the service program name
Pot
Define the port number related to the 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
Set the UID of the service process, but if the effective UID of xinetd is not 0, this property is invalid
Group
Set the GID of the process. If the effective UID of xinetd is not 0, this property is invalid
Nice
NICE value of the process
ID
This property is used to specify 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 (RPC service), INTERNAL (serve 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
No matter if 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 the interrupts and restart XINETD Intercept: Intercept Denomes Perform access checks to determine that it comes from the location where the connection is allowed. You cannot use this attribute value NoreTry: If the Fork fails, you don't want to re-try IDonly: accept this connection only when you recognize the remote user (that is, the remote system must run the Ident server), which only Suitable 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 service 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 specified 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
The VAR = Value table separately 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 the space is separated by a space-separated environment variable table. Set NO does not transfer any variables. This property supports all operators
Only_from
Use a spacemap that allows access to the service with spaces. 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
Use spaces to separate access to the client table. 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 an optional, the Level value is Emerg, Alert, crit, Err, Warning, Notice, Info, Debug, default value for info file [Soft [hard]]: Specify file to record 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 is no more than 20MB. The default SOFT limit is 5MB
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
The information registered at the time of success. 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 of the capture client user via RFC1413. Can only be used for multi-threaded flow services. EXIT: Registration Process Termination and Status Duration: Registration Session Duration No information is registered by default. This attribute supports all operatorslog_on_failure
The information registered when it fails. Always register the message indicating the nature of the error.
Attempt: Record attempts to fail. All other values are implied to this value. Host: Client Host IP Address UserID: Call the UID of the capture client user via RFC1413. Can be used in multi-threaded flow services. Record: Records attached client information such as local users, remote users, and terminals. No information is not registered by default. This property supports all operators. Disabled
You can only use the default item (see the Defaults item 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 Document / TEC/xinetd.conf part SERICE FTP
{{
Socket_type = stream
Protocol = TCP
Wait = NO
Server = root
Server_Args = - 1 - a
}
SERVICE TELNET
{{
Socket_type = stream
Protocol = TCP
Wait = TCP
Server = / usr / sbin / in.telnetd
}
The easiest way to create /etc/xinetd.conf file is to use the ITOX tool (this example assumes 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 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, which means that the leftmost 20 digits are set to 1, and the remaining 12 digits are set to 0, or 11111111 11111111 111111111 11111111 11110000 million it is a decimal Netmask255.255.240.0 Binary representation.
Table 2 /etc/xinetd.conf's Access Control Table Syntax Hostname
Analytical host name. All IP addresses related to this hostname
IPaddress
ip address in the decimal form, such as 192.168.0.1
NET_NAME
/ ETC / NetWorks Network name
x.x.x.0 x.x.0.0
x.0.0 0.0.0.0
0 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. {A, b, ...}
{a, b, ...}
{a, b, ...}
Specify 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 necessary attributes, specific services, and some configuration instances.
3.1 Required properties
Each service must specify some attributes. 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 Socket_Type
All services
Wait
All services
Services listed in / etc / services or / etc / rpc
Server
Internal service
Pot
non-RPC service in / etc / services
Protocol
All RPC services in / etc / services and all other services
RPC_Version
All RPC services
RPC_Number
Not listed in any RPC service in / ETC / RPC
There are 4 special items in a particular 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.
3.2 Defaults
The default item in the / etc / xinetd.conf file is the default value that implements some attributes to all services in the file. 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 Log_on_suCcess
Log-ON_FAILURE
Only_from
NO_ACCESS
Passenv
can be rewritten with = operator or use = or - = operator modification Tances
Log_Type
can be rewritten with = operator
Disabled
The service that can be released, but the Disabled property can be used in a service item.
Example 2 is an example of the 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.
DEFAULTS entries provide a default value for establishing certain properties throughout the file, which is applied to all services that do not set these properties.
Example 2 of the DEFAULTS item in /etc/xinetd.conf DEFAULTS
{{
Log_Type = Syslog Loca14 Info
LOG_ON_SUCCESS = PID HOST EXIT DURATION
Log_on_failure = Host
stances = 8
Disabled = in.tftpd in.rexecd
}
Note: If there is no DEFAULTS item in the /etcxinetd.conf file, and then decide to increase this, you must stop and restart the xinetd to make 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
If you use the startup script, just simply execute it. # / Etc / rc.d / init.d / xinetd restart
Servers Item Servers special service is to implement process tables currently running 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 Sample of Servers itemsService Servers
{{
Type = INTERNAL UNLISTED
Socket_type = stream
Protocol = TCP
Pord = 9997
Wait = NO
only_from = 172.17.33.111
Wait = NO
}
Note This service is only used for specific IP addresses 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 the Servers Service Example $ TELNET TOPCAT 9997
2 Trying 172.17.33.111 ......
3 connect 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
17
18 FTP Server
19 pid = 5960
20 start_time = sat apr 17 10:49:06 1999
21 Connection Info:
22 state = closed
Text3 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 $
3.3 SERVICES items
The purpose of Services specific items 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
Pord = 8099
Wait = NO
}
For the Servers service, 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.
^] '^]'
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.
$
3.4 xadmin item
This particular service item provides a method of obtaining the information provided by the Services specific service in a 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
Poport = 9967
Wait = NO
Only_from = 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.
WARNING: As pointed out in the first 3 paragraphs, the information generated by these specific services Servers, Services, and XADMIN 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. 4. Configuration instance
This section will see some different examples, related behaviors and registration messages they produce.
4.1 Access Control
Starting 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
Enstances = 8
}
SERVICE LOGIN
{{
Socket_type = stream
Protocol = TCP
Wait = NO
Flags = Reuse
Only_from = 172.0.0.0
no_access = 172.19.0.0
Olg_on_success = userid
= UserId
Server = / usr / sbin / in.ftpd
Server_Args = -1 -a
}
Example 11 Successful Rlogin attempts [Mary @ Underdog] $ RLOGIN TOPCAT
Password:
Llast 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) Starting with the USERID keyword, it is shown 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, it is assumed that 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
Start and description start
Start: Service_ID [PID = PID] [from = ipaddress]
This item is recorded 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 specifies the PID record): 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 the DURATION option in log_on_success
FAIL
FAIL: Service_ID Reason [from = ipaddress]
This item is generated when a value that has occurred 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.
service_id text
This accommodation is recorded only when log_on_success or log_on_failure or specified UserID. Service_ID is as before. Text includes the response of the client to RFC1413 calls and, especially remote user name 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_failure sets the userID value. Service_ID is as before. The ipaddress given is the host address. Reason is a failure
Example 13 failure Rlogin attempted from unauthorized hosts
Si.No.Good.org $ rlogin Topcat
Topcat: Connection Reset by Peer
Si.No.Good.org $ rlogin -1 paul topcat
Topcat: Connection Reset by Peer
Si.No.Good.org $ rlogin -1 mary Topcat
Topcat: Connection Reset by Peer
Si.No.Good.org $
Example 14 and Example 10-50 Related registration entries 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 rmmd: Topcat: Address Already in Use
And the registration item recorded in this event in Topcat is theApr 15 13:37:33 Topcat Xinetd (1402): Fail: login service_limit from -172.17.55.124
This record and the description of this record are relative, the FAIL keyword is the service name, then the explanation of the failed (which is service_limit), and finally the client address.
4.2 use bind properties
The Bind property allows the IP address of a particular interface and 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 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
Enstances = 8}
SERVICE FTP
{{
ID = FTP
Socket_type = stream
Protocol = TCP
Wait = NO
On-ly_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
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
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 results $ telnet 201.171.99.99
Trying 201.171.99.99
Connected to 201.171.99.99
^] '^]'
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 proxy.
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.
4.3 Contains TCP_WrapPers
The / etc / xinetd.conf contains the 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_WrappersDefaults in /etc/xinetd.conf
{{
LOG_TYPE = SYSLOG LOCA14 INFO
Log_on_suCcess = Pid Host Exit Duration
LOG_ON_FAILURE = Host
Enstances = 8
}
SERVICE FTP
{{
ID = FTP
Socket_type = stream
Protocol = TCP
Wait = NO
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
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
Bind = 201.171.99.99
Redirect = 172.17.1.1 23
Log_on_success = Pid Host Exit Duration UserID
Log_on_failure = record host
}
...
...
5.xinetd process
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 to 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 tags - D
Debug mode. Output can be used with debuggers such as GDB
-Sysllog Facility
Specify Syslogd Tools. Is one of Daemon, Auth, User and Loca10-7
-Filelog file
Specify registration to write to File instead of syslog. Must be a full path name
-Fconfig_file
Specify the configuration file. Must be a full path name. By default, /etc/xinetd.conf
-PID
Write the PID Write standard error - LOOP RATE
Specify the number of processes per second. By default, 10. Must be able to change it for faster machines
-Reuse
Setup 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
Numproc
Limit the simultaneous RFC1413 request number of LIMIT
-ShutdownProcs Limit
When the RECORD value is used in the log_on_failure property, the XINETD is bifurcated as Shutdown's service to collect information when the service is terminated. This option limits the total number of SHUTDOWN processes at the same time as Limit
-Cc interval
Make Xinetd to run consistency checks for its internal state every interval second. Manual implementation with killall -iot xetd
Table 18 xinetd signal Sigusr1
Soft reconfiguration. Reread /etc/xinetd.conf and adjust accordingly
Sigusr2
Hard researcher. 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 this server and add it to the no_access table, then this signal will terminate the session of the client.
Sigquit
Terminate XINETD but not terminate any process it bifurcated
Sigterm
Terminate all processes for spears for spears; then terminate Xinetd
Sighup
Write xinetd status information in /tmp/xinetd.dump
check the internal database destruction and report results
Example 19 XINETD Ruristic Registration 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 Talk
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: Determines a modified /etc/xinetd.conf file to be read by stopping and restarting 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.
