📄 00000000.htm
字号:
log_on_success = HOST PID <BR> # What to log when the connection fails. Same options as above <BR> log_on_failure = HOST RECORD <BR> # The maximum number of connections a specific IP address can <BR> # have to a specific service. <BR> per_source = 25 <BR> # Disabled nntp <BR> disabled = nntp <BR> #Whatever you do, don't let the evil bastards in <BR> no_access = .evilbastards.com <BR>} <BR>service ftp <BR>{ <BR> socket_type = stream <BR> wait = no <BR> user = root <BR> server = /usr/libexec/ftpd <BR> server_args = -l <BR> #Allow access from the local network (ie, 192.168.0.0/24) <BR> only_from = 192.168.0.0/24 <BR> #And from two remote locations <BR> only_from = 10.1.1.2 roadwarrior.sampleconfig.com <BR> #But not from the evil HR director's subnet <BR> no_access = 192.168.0.128/27 <BR> log_on_success = PID HOST EXIT DURATION <BR> log_on_failure = ATTEMPT HOST RECORD <BR>} <BR>service nntp <BR>{ <BR> socket_type = stream <BR> wait = no <BR> user = usenet <BR> server = /usr/libexec/nntpd <BR> server_args = <BR> #Allow access from the local network (ie, 192.168.0.0/24) <BR> only_from = 192.168.0.0/24 <BR> #And only during working hours <BR> access_times = 08:00-17:00 <BR> #And only 5 people at a time <BR> instances = 5 <BR> #And only 5 connections per second <BR> cps = 5 <BR> #And not under load <BR> max_load = 2.9 <BR> #And be low priority <BR> nice = 15 <BR>} <BR>service ssh <BR>{ <BR> socket_type = stream <BR> wait = no <BR> user = root <BR> server = /usr/libexec/sshd <BR> #It's not listed in my /etc/services <BR> port = 22 <BR> server_args = -i <BR> #Allow access from the local network (ie, 192.168.0.0/24) <BR> only_from = 192.168.0.0/24 <BR> #And from two remote locations <BR> only_from = 10.1.1.2 roadwarrior.sampleconfig.com <BR> log_on_failure = ATTEMPT HOST RECORD <BR>} <BR>---------------------------------------------------------------------------- <BR>---- <BR>Day to day use of xinetd (or updating the xinetd.conf) <BR>In the life of every service comes a day when it must be reconfigured for so <BR>me reason. Sometimes it's because you've installed another service, or wish <BR>to enable one that's been previously disabled, or may you've got an evil bas <BR>tard trying to beat your imap server to dust. Whatever the reason, it is gen <BR>erally disadvantageous to have to kill all the processes that xinetd has sta <BR>rted to bring up a new configuration, especially on a busy server. Fortunate <BR>ly, the xinetd coders gave us a way around this. To bring up a new configura <BR>tion, make your modifications to xinetd.conf (after making a backup copy of <BR>it, of course). Then find the PID for xinetd (ps -aux | grep xinetd). With t <BR>he xinetd PID in hand, use the kill command to send it a SIGUSR1 or SIGUSR2 <BR>signal (kill -USR1 <pid>). Sending it SIGUSR1 will cause a soft reconfigurat <BR>ion, meaning that it reads the new config and all new connections are applie <BR>d against it. If a SIGUSR2 is sent (kill -USR2 <pid>), a hard reconfiguratio <BR>n occurs. This means that not only will the new config be read in, it will b <BR>e applied immediately; any access controls are applied instantly, as well as <BR> any connection throttles. This allows you to immediately kick an evil basta <BR>rd off one of your servers, or disable a flagging service. One should note, <BR>however, if current connections are beyond the bounds of connection throttli <BR>ng settings in the new config when a SIGUSR2 is sent, random connections wil <BR>l be kicked to bring the rate/instances within acceptable parameters. <BR>---------------------------------------------------------------------------- <BR>---- <BR>Port redirection <BR>Amazingly enough, the folks that coded xinetd, have added the ability to red <BR>irect ports. That is, you can accept a connection on a port, and redirect th <BR>at connection to another port, even on another host. This is especially usef <BR>ul in a situation where the machine running xinetd is a firewall, or router. <BR> Usually this means the machine has multiple nics in it, each with it's own <BR>IP address and subnet. Using port redirection, an machine could accept a tel <BR>net session on port 23 of the router/firewall machine and redirect it to por <BR>t 23 of one of the internal hosts. The service definition to do this would l <BR>ook like the following: <BR>service telnet <BR>{ <BR> flags = REUSE <BR> socket_type = stream <BR> protocol = tcp <BR> wait = no <BR> user = root <BR> groups = yes <BR> bind = 10.1.1.1 <BR> redirect = 192.168.0.3 23 <BR>} <BR>There are a number of things to notice here. There are two new attributes: b <BR>ind, and redirect. The redirect attribute accepts an ip address (as it is he <BR>re), or a hostname, followed by a port number. The port number specified nee <BR>d not be the same as that of the service (in other words you could just as e <BR>asily accept connections via telnet and redirect them to port 80, being http <BR>, on some host). One can also redirect to a port on the same machine as that <BR> it is being redirected from. The other new attribute is bind. This tells xi <BR>netd that this service/rule is bound to the interface with the specified ip. <BR> In the above scenario, it is likely that there are two or more nics in the <BR>machine, one of which has a configured ip of 10.1.1.1, and the other with an <BR> address on the same network (or has some access to) as the host 192.168.0.3 <BR>. The bind attribute is by no means required; it is only shown here because <BR>this is a common configuration and use for the redirect attribute. <BR>---------------------------------------------------------------------------- <BR>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -