Jose 描述了如何著手配置調整xinetd。
~~~~~~~~~~~~~~~~~
xinetd 提供了訪問控制，改進的日志功能和資源管理，取代了inetd，已經成為了Red Hat 7
和Mandrake 7.2的Internet標准超級守護進程。對那些對它感興趣的人，這篇文章將引導你如何應
用一些它的特性，這些特性基於xinetd 2.1.8.8pre3版本。
********
導言
********
xinetd的最初的作者，Panagoitis Tsirigotis (
[email protected])。好像已經停止了這
個項目。 Rob Braun (
[email protected])繼續了這個工作，現在負責維護這個軟件包。為了能
使select( )在我的老的libc5系統上使用，我不得不給當前的包添加幾對頭文件，這是我注意到的
問題。或許你需要它們，如下：
xinetd/internals.c.orig
Fri Jun 16 19:00:15 2000
+++ xinetd/internals.c
Fri Jun 16 19:00:53 2000
@@ -12,6 +12,8 @@
#include
#include
#include
#include
#include
#include "sio.h"
*****************
關於 xinetd
*****************
xinetd 用同樣功能的，擴展了的語法取代了 inetd中的通用的行。 另外，還添加了日志功能和訪
問控制。 雖然 inetd 使用Venema的 tcp_wrappers 軟件(tcpd)控制TCP的連接, 但是你不能控
制UDP連接。而且，inetd對 RPC (portmapper)類型的服務也處理不好。 另外, 雖然使用inetd你
可以控制連接速度 ( 通過給wait或是 no wait 變量附加一個數, 例如nowait.1 每個 一秒鐘一個
實例)，你不能控制實例的最大數。這能導致進程表攻擊，例如，一個有效的拒絕服務攻擊。通過使
用 xinetd，我們可以防止這樣。
我啟動xinetd通常用下面的命令，把它放在我的Internet服務啟動腳本中：
/usr/sbin/xinetd -filelog /var/adm/xinetd.log -f /etc/xinetd.conf
這告訴 xinetd 對所有的服務都進行紀錄，日志保存到文件 /var/adm/xinetd.log 中，並且使用
配置文件 /etc/xinetd.conf.。這篇文章中的大量篇幅都將用在這個設置文件上。
*****************
編譯時選項
*****************
你應該注意的3個編譯時的選項提供了額外的訪問控制 libwrap， loadavg (用於監視負載均衡）
和 IPv6 支持。對於大多數libwrap“明白“的守護進程 (如 portmapper 和sendmail)，在設置
腳本中的``with-libwrap''選項 告訴 xinetd支持tcp_wrappers文件/etc/hosts.allow
和/etc/hosts.deny。xinetd 的這些選項就像對 inetd那樣支持所有的 xinetd控制的監視進
程。 注意如果你從頭開始做 xinetd的話，就可以做訪問控制，不再需要tcpd。不管怎樣對libwrap
的支持是有用的--如果你從inetd/tcpd遷移並且也不想改變你的訪問文件的話 。
第二個有趣的設置選項是支持負載均衡監視，在 ./configure腳本中使用with-loadavg選
項。sendmail 支持在高負載的時候去掉連接，假定它已經脫離了控制並且正在當掉機器。用這個選
項可以激活max_load 選項以限制任何連接或是基於負載均衡機器的所有服務。
最後，添加 IPv6支持 可以通過在 ./configure 腳本中使用 with-inet6 capability選項來
完成。這使xinetd 支持 IPv6地址和連接。注意要使這個生效的話你的核心（和網絡）必須支
持 IPv6。當然了，IPv4 仍然被支持。
**************
配置文件
**************
The xinetd 配置文件，通常可以手工或是自動從 inetd.conf文件生成。 前者費時間且容易出
錯；後者可以通過 itox軟件或者xconv.pl 腳本輕易完成。雖然 itox軟件正在被取消而傾向於使
用xconv.pl 腳本，它仍然很有用。但是,要注意重復的運行它會覆蓋原有的配置文件。itox
和xconv都以同樣的方式工作，我們用 itox來進行演示；
$ itox < /etc/inetd.conf > xinetd.conf
更新一些的軟件，xconv，可以理解注釋，並且比 itox對tcpd 用得更好，使用 itox，你不得不指
定守護進程的路徑 ，如 /usr/sbin。 你想要包含的第一段就是默認的段，就像名字的暗示的那
樣，默認的inetd服務。
defaults
{
instances = 25
log_type = FILE /var/adm/servicelog
log_on_sUCcess = PID HOST EXIT
flags = NORETRY
log_on_failure = HOST RECORD ATTEMPT
only_from = 129.22.0.0
no_Access = 129.22.210.61
disabled = nntp uucp tFTP bootps who
shell login exec
disabled += finger
}
馬上， 我們可以了解 xinetd 設置參數的語法：
<指示directive> <操作符operator> <值value>.
xinetd 指示符列在表一中，在這裡我們將忽略 flags，type，env 和 passenv指示符。 我對將
對only_from 和 no_access以及額外的日志選項加以更多的討論
表 1. xinetd的指示符
-----------------------------------------------------------------------
指示符 描述
socket_type 網絡套接字類型, 流或者數據包
protocol IP 協議, 通常是TCP或者 UDP
wait yes/no, 等同於inetd的wait/nowait
user 運行進程的用戶 ID
server 執行的完整路徑
server_args 傳遞給server的變量,或者是值
instances 可以啟動的實例的最大的值
start max_load 負載均衡
log_on_success 成功啟動的登記選項
log_on_failure 聯機失敗的時候的日志信息
only_from 接受的網絡或是主機
no_access 拒絕訪問的網絡或是主機
disabled 用在默認的 {} 中 禁止服務
log_type 日志的類型和路徑 FILE /SYSLOG
nice 運行服務的優先級
id 日志中使用的服務名
------------------------------------------------------------------------
操作符非常簡單， = 或者+=。用 =，右邊給定的值傳給左邊的指示符。 +=也是非常直接的，用於
給一個已經指定的指示符添加一個值。沒有它，原先的指示符就會被覆蓋，這樣可以用來展開訪問列
表，或者跨越多行。
用如下的格式描述服務：
----------------------------------
服務名
{
指示符 = 值
指示符 += 值
}
----------------------------------
服務名一定要在 /etc/services列出 ，並且要用使用合適的socket和協議。
*****************
關於訪問控制
*****************
關於訪問控制的有幾句話。 首先， xinetd控制連接，不是通過包，它只是個用戶方的守護進程,如
同inetd 一樣。 同樣的, 可以打斷一個被服務器禁止的主機的SYN或是connect()。但不能打斷
象FIN [端口掃描使用帶有FIN 標志位的TCP包， 通常是nmap這樣的工具運行產生的]這樣的“秘密
“ 掃描。 不要把 xinetd 當作一個 firewall 用以阻止端口掃描。一個有經驗的入侵者能夠用這
些信息收集你的不同服務的訪問列表。幸運的是, 這些可以被xinetd紀錄。當你看到你的日志的時
候你的疑慮會消失的。
第二， xinetd， 2.1.8.8pre3版本，當一個系統試圖連接的時候進行名字查找，以前，它在啟動的
時候進行查找， 但是現在已經改變了。
使用訪問控制真的很簡單。第一個指示符是 only_from, 列出了從哪一個網絡或是主機我們可以接
受連接。這個規則可以被 no_access覆蓋。 你可以使用網絡號，如 10.0.0.0 或者 10，或者是網
絡名，包括 *.my.com 或者 .my.com 。主機名或者主機的 IP地址也可以在這裡使用指示
符0.0.0.0 t匹配所有的主機，監聽所有的地址。通過使用 no_access一旦符合標准拒絕就會被解
析。 再說一遍，網絡和主機可以指定。
***********
服務配置
***********
讓我們看一些基本的應用.我們要看的第一個基本的服務是echo,它是inetd 和 xinetd固有的服務。
service echo
{
socket_type = stream
protocol = tcp
wait = no
user = root
type = INTERNAL
id = echo-stream
}
echo 作為root運行, 是一個tcp 流 並在內部處理。echo-stream指示符將出現在日志中。如果沒
在only_from或者是 no_access 指示符中,對這個服務的訪問不受限制。現在，讓我們看一個正規
的服務，daytime：
service daytime
{
socket_type = stream
protocol = tcp
wait = no
user = nobody
server = /usr/sbin/in.date
instances = 1
nice = 10
only_from = 0.0.0.0
}
再說一次，任何人都可以連接, 不過我們指明它以nobody的身份運行來返回信息。和前一個例子相
比，這個並沒有額外的什麼。現在我們看另一個服務 secure shell version 1。 下面的設置可以
防止sshd帶來的資源枯竭。
service ssh1
{
socket_type = stream
protocol = tcp
instances = 10
nice = 10
wait = no
user = root
server = /usr/local/sbin/sshd1
server_args = -i
log_on_failure += USERID
only_from = 192.168.0.0
no_access = 192.168.54.0
no_access += 192.168.33.0
}
在這裡，我們建立了前面我們所作的。當作為超級用戶inetd或者 xinetd重新調用 sshd 需要
用 -i 參數， 所以我們把它放在了 server_args 指示符後。 注意：把這個標記添加到server標
識符出會導致失敗。在任何時候只有十個人可以同時使用, 在這個服務器上這不是問題，這個例子我
們從日志得到。另外作為默認信息, 如果不能連接的話，連接方的用戶 ID在RFC 1413種描述。最
後，我們有兩個網絡列表不能訪問這個服務器。
***************
日志和 xinetd
***************
日志中有幾個值可以用於得到你的服務器的信息
表2 不同的日志指示值
__________________________________________________________________________
值 成功/失敗 描述
PID success 當一個連接成功時登記產生的進程的 pid
HOST both 登記遠程主機地址
USERID both 登記遠程用戶的RFC 1413 ID
EXIT success 登記產生的進程的完成
DURATION success 登記任務持續的時間
ATTEMPT failure 登記連接失敗的原因
RECORD failure 關於連接失敗的額外的信息
__________________________________________________________________________
這樣，可以添加一些標准的行指明日志，就像下面的樣子。對一個成功連接的服務, 我們通常想登記
服務產生的進程id, 連接的主機和退出的時間：
log_on_success = PID HOST EXIT
這可以給我們有用的信息用來排錯， 並明白服務器連接. 針對失敗, 我們可以記錄我們想要的：
log_on_failure = HOST RECORD ATTEMPT
Here we log the host that connected, 拒絕連接的原因和關於連接主機的額外的信息(由的時
候是那些試圖連接的用戶的 ID)。推薦你這樣做，可以對你的服務器有一個好的把握。 還看上面，
在我們的默認段中，我們的日志寫在 /var/adm/servicelog中。我們指定所有信息，成功和失敗的
都要被 xinetd記錄。我們的大多數信息看起來像這樣：
00/9/13@16:05:07: START: pop3 pid=25679 from=192.168.152.133
00/9/13@16:05:09: EXIT: pop3 status=0 pid=25679
00/10/3@19:28:18: USERID: telnet OTHER :www
使用這個信息, 可以輕易對 xinetd 排錯和進行和正常操作。也可以容易發現安全問題 ，如你試圖
阻止的連接企圖， 在日志中簡單的用 grep 作 ``FAIL'' 過濾， 這些項顯示如下：
00/10/4@17:04:58: FAIL: telnet address from=216.237.57.154
00/10/8@22:25:09: FAIL: pop2 address from=202.112.14.184
真正的安全問題需要另外的文章，但是，這足以說明，既然地址可以偽造，不要把地址報告看作固定
的信息。 xinetd.log文件，包含了從 xinetd得到的信息. 連接出錯的時候作為排錯信息很有用。
00/10/25@21:10:48 xinetd[50]: ERROR: service echo-stream,
accept:
Connection reset by peer
**********************
重新配置 xinetd
**********************
在xinetd.conf運行的時候，你可以編輯 xinetd.conf 文件。 要重新配置，發送一個信號l
SIGUSR1 給 xinetd 進程：
# ps -ax grep xinetd
50 ? S 5:47 /usr/sbin/xinetd -filelog /var/adm/xinetd.log -f /etc/xinetd.conf
# kill -SIGUSR1 50
察看日志文件的尾部確保你的配置和改動已經生效。如果你是個遠程用戶的話要確保你退出後還可以
重新登陸進來。
注意使用-HUP，對xinetd重新配置，會實際導致 xinetd 停止操作。 從設計的角度看，這可以阻止
黑客重新配置你的 xinetd並且無需理解文檔就可以重新載入它。
*********************
何時使用 xinetd
*********************
以我個人而言，對所有的服務我都使用 xinetd； 唯一一個對性能有影響的服務是我的web 守護進
程 Apache。不得不啟動太多的進程，太快了時間的效率是個問題。DNS 服務也不應該用 xinetd；
性能消耗太大。
sendmail 服務我也使用了 xinetd，對於允許連接的客戶，我能夠進行完美的控制。針對
sendmail我的設置如下：
service smtp
{
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/sendmail
server_args = -bs
instances = 20
nice = 10
only_from += 0.0.0.0
no_access += 129.22.122.84 204.0.224.254
}
即使是在一個高流量的郵件服務器上，對性能的影響也是可以忽略不計的。 我還把sshd 載入
到xinetd 以便阻止對它的進程表攻擊。
********
結論
********
我希望這篇文章對你配置或者是根據需要調整inetd很有幫助。正如你所看到的，它提供的特性要
比inetd甚至tcp_wrappers強大的多。Solar Designer http://www.openwall.com/) 有一個補丁
是針對稍舊一點的xinetd的版本的，2.2.1版本，允許基於IP 的實例控制，這有助於阻止簡單的進
程表攻擊。注意，不管怎樣，簡單的偽造可以繞過它。我不知道是否這個包對以後的 xinetd是否也
適用。
程表攻擊。注意，不管怎樣，簡單的偽造可以繞過它。我不知道是否這個包對以後的 xinetd是否也
適用。
到xinetd 以便阻止對它的進程表攻擊。
********
結論
********
我希望這篇文章對你配置或者是根據需要調整inetd很有幫助。正如你所看到的，它提供的特性要
比inetd甚至tcp_wrappers強大的多。Solar Designer http://www.openwall.com/) 有一個補丁
是針對稍舊一點的xinetd的版本的，2.2.1版本，允許基於IP 的實例控制，這有助於阻止簡單的進
程表攻擊。注意，不管怎樣，簡單的偽造可以繞過它。我不知道是否這個包對以後的 xinetd是否也
適用。
