After redhat7.0, inetd has been changed to Xinetd - it takes a lot. Let's take a look at /etc/xinetd.conf-instances maximum number of instances - if you use the wu-ftpd- the maximum number of people 60, change this. Note that the last INCLUDEDIR is actually included in this file - directly written here. Defaults {instances = 60 log_type = syslog authpriv log_on_success = host pid log_on_failure = host cps = 25 30} includeir /etc/xinetd.d This xinetd full guide is very complete - read it, you will be very familiar with Xinetd :) Many people started to find the North after loading redhat 7.x !!! (I am one of them) Because Redhat 7.x starts to pay attention to system security, the biggest feature is to replace the original inetd.conf with xinetd.conf And the default installation in 7.1 does not open FTP, Telnet, etc., but safer SSH! 7.1 is also added to FireWall and other services (thank Paradise to provide me to install redhat7.1) Everyone is the inetd called Super Server. It must be very familiar with it to control 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 known as TCP_Wrapper. Xinetd (Extended Internet Services daem) 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 supporting RPC support enough stable) * Based on the time period's access control * functional log function, you can record the connection success can also record the connection failed. Behavior * Can effectively prevent DOS attacks (DEnial of services) * can limit the number of servers of the same type of agreed, * can limit all servers available * Can limit log file size * Bind a service in a specific system interface On, it is possible to implement only a private network to access a service * can be implemented as other systems. If the IP camouflage combination can be implemented to the internal private network, its maximum disadvantage is the instability supported by RPC, but you can start ProtMap, coexist with XineTd to solve this problem compilation, you can download xinetd, The current latest version is XINETD 2.1.8.8p3. The default compilation and installation XINETD is very simple, follow the steps: #. / Configure; make; make install can be done. When Configure is performed: --with-libwrap: --with-libwrap: If you use this option xinetd, you will look at the TCPD profile (/etc/hosts. {directionow, deny}) to make access control, but If you want to use this feature, TCP_Wrapper and related libraries must be installed 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 it is using redhat7.0, it will be installed by default without the need to install it. Configuring 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. Each of /etc/xinetd.conf has the following form service service-name {.... } Where Service is a necessary keyword, 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 Properties Description and Allow Value Socket_Type TCP / IP Socket Type, Value may be Stream (TCP), DGRAM (UDP), RAW, and SEQPACKET (Reliable Ordered Datashera) Protocol Specify this service The protocol used, 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 specifying the parameters transmitted to the process, but does not include the server name Port defines the port number related to the service. If the service is listed in / etc / services, they must match the attribute of Wait 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 sets the UID of the service process, but if the effective UID of xinetd is not 0, the property is invalid for the GID of the Group setting process. If the effective UID of XineTd is not 0, this property invalid NICE specified process NICE value ID This property is used to uniquely 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 identifying two service Types, respectively, one or more values: RPC (for RPC services), INTERNAL, service provided by xinetd itself, such as echo), unlisted (no column) Services in standard system files such as / etc / rpc or / etc / service) Access_time Sets 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. You can use this service banner whether the connection is allowed, when establishing a connection, the file is displayed to Client 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 invalid RPC_Version specifies 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 its ENV separated VAR = Value table, 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's environment variable table in the XINETD environment separated by spaces, which is passed to the service program during activation. Set NO does not transfer any variables. This attribute supports all operator ONLY_FROMs to separate client tables that allow access services. 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 Delicate the client table that refuses to access the service with spaces. Table 2 gives the client syntax. This attribute supports all operator instances to accept an integer or unlimited that is 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 Specifies the service log recording mode, which can be: syslog facility [level]: Setting the tool for 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 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, ignore the Server property BIND to bind a service to a specific port. The syntax is bind = ipaddress. There is a host that has multiple interfaces (physical or logical) hosts to allow an interface but not specific service (or port) log_on_success on other interfaces to specify information registered when successful. Possible values is 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: The registration session duration is not registered when it is default any information. This property supports all the information log_on_failure to specify the information registered when 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 RFC1413. Can only be used for 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 can only be used for the Default item (see the defaults behind this section), specify the closing service list, is represented by a non-available service list separated by spaces. 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 a part 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 the /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 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 111111 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 Syntax Description HostName resolved host name. All IP addresses related to this hostname All IPAddress points and decimal forms of standard IP addresses, such as the network name X.x.0 x.x.0.0 x.0.0.0 0.0.0.0 0 as wildcards in 192.168.0.1 net_name / etc / networks. As item 88.3.92.0 matches all IP addresses from 88.3.92.0 to 88.3.92.255. Item 0.0.0.0 Match all addresses x.x.x. {a, b, ...} x.x {a, b, ...} x. {A, b, ...} specify the host table. If 172.19.32. {1,56,59} mean the IPAddress / NetMask-containing iPaddress / NetMask defines the network or subnet to match the IP address 172, 19.32.1, 172.19.32.56 and 172.19.32.59. As 172.19.16.0/20 matches all addresses from 172.19.16.0 to 172.19.31.255 After seeing these basic properties, then we carefully discuss those necessary attributes, 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 Property Grammatical Description Socket_type All Services WAIT All Services User Listed in / etc / Services or / ETC / RPC Server Non-internal Services PORT Not in / ETC / Services Non-RPC Services Protocol is not / etc / services All RPC services and all other services RPC_Version All RPC services RPC_Number are not listed in any RPC service in / etc / rpc to have 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 Properties 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 You can use = operator to rewrite the service, but disabled attribute Can be used for an exemplary example 2 of a service item is an instance of the default item. 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. In exemplary embodiment 2 /etc/xinetd.conf entry 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} Note: If the file /etcxinetd.conf There is no DEFAULTS item, and then decide to increase this, you must stop and restart 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 or if you use the startup script, just simply execute it. # / Etc / rc.d / init.d / xinetd Restart Servers Item Servers Special Services 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 Servers Item Sample Service Servers {type = INTERNAL UNLISTED SOCKET_TYPE = stream protocol = tcp port = 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, it is The server itself IP address. 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 Servers Service Output Example 1 $ Telnet Topcat 9997 2 TELNET TOPCAT 9997 2 TRYING 172.17.33.111 ... 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 17 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 $ Services Item Services Specific item The purpose 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 Sample Service Services {type = INTERNAL UNLISTED SOCKET_TYPE = stream protocol = tcp port = 8099 WAIT = no online = topcat} For Servers services, any user can perform Telnet Topcat 8099, And get the 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 output of the internal service query 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 way to get the information provided by Services specific services 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 INTERNALESTED SOCKET_TYPE = stream protocol = tcp port = 9967 WAIT = no online = 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, 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 In the example the rlogin service items /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 = root flags = 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} rlogin successful attempt to Example 11 [mary @ underdog] $ rlogin topcat Password: Last Login: WED APR 14 17:45:02 from roadrunner [Mary @ Topcat] $ Example 12 and Example 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 user ID 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 XINETD Registration Description 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 (iPadDress is logging): ipaddress is the client's IP address (only when Host is log_on_success) exit exit: service_id [type = s] [pid = pid] [duration = # (sec)] This is logged only if EXIT 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 (seconds) and requires Duration Options Fail Fail: Service_ID Reason [from = ipaddress] when the 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 is only recorded when Record is specified for log_on_failure. Service_ID is as before. The recorded DATA depends on the service, but typically records the remote username (if available) and status information userid userid: service_id text only when log_on_success or log_on_failure or specifying userid, record this accommodation. Service_ID is as before. Text includes the response of the client to RFC1413, especially remote username NOID NOID: Service_ID iPaddress Reason, appears when setting the iDonly value 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 of the failure of the unauthorized host Rlogin attempt 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: Connection Reset by peer sly.no.good.org $ Example 14 and Example 10-50 Related registration 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 to Rlogin to Topcat, the user will see the following error message RCMD: Topcat: address already in us, and Topcat is a registration item for this event record 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 the table 4, the FAIL key is the service name, then the explanation of the failed (at this time_limit), the last is 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 service is bound 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} of the results of 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 on the system. 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 TCP_Wrappers Defaults in the /etc/xinetd.conf {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 xinetd process accepts a number of process 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 PIDD's PID in a file, you can use XINETD -PID 2> /VAR/Run.xineTd.PID and XINETD processes to take specific actions based on the received signals. 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's marker syndrome Description -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. The default is /etc/xinetd.conf -PID writes the PID write standard error - Specifies the number of processes per second. The default is 10. For the faster machine, it may want to change its -reuse to set reusable TCP Socket, which means that other processes can be launched 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 by xinetd, the total number of RFC1413 requests simultaneous RFC1413 request is LIMIT -SHUTDOWNPROCS LIMIT when log_on_failure properties When the RECORD value is used, XINETD is bifurcated to the shutdown service to collect information when the service is terminated. This option restricts the total number of SHUTDOWN processes simultaneously run for Limit -CC Interval to make Xinetd consistently check every interval second. Table 18 XINETD Signal Serviced Sigusr1 soft reconfiguration with killall -iot xetd. 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.
