FreeBSD下也有“看門人”--淺談tcpw 曾幾何時，不知道你是否與筆者小神一樣，有在FreeBSD下實現與WIN2000中的IPSec安全策略實現訪問控制的一樣功能的想法呢？也許這對剛剛接觸FreeBSD的朋友來說是一種奢望，不僅是因為FreeBSD與WINDOWS系統的配置方式截然不同(特別是像小神這種喜歡跑shell的人)。不過不用失望，只要閣下用幾分鐘的時間專心看完下面的這篇文章的話，相信會有意外的收獲的:)。
首先我要為大家講解一下什麼是tcpwrapper。tcpwrapper是傳統Unix系統的主要安全組件之一，通過使用它我們能夠監控大多數的網絡服務進程，從而達到網絡服務訪問控制(形象點說它的功能就像一個看門人，當有請求進入時，它就會將請求內容分解，並與相應的設置規則進行配對，一旦找到相應的規則時就會自動調入相應的操作了)。在現在主流的FreeBSD4.x中它已經成為了內核中的基本“設施”，且使用的方法也有了一定的改變。今天我們就以telnetd為實驗對象來完成一次網絡服務訪問控制操作吧。
實驗環境:
一台普通的586，跑FreeBSD4.7，使用PPPoE並做成ADSL網關，開了telnetd服務進行客戶端管理(外網內網都可以訪問)。
實驗目的:
使用tcpwrapper監控telnetd服務，使外網無法登陸telnetd。
操作基本過程:
首先需要配置一下tcpwrapper的訪問控制規則文件hosts.allow(需要注意，以前的傳統的tcpwrapper都是用兩個配置文件的，hosts.allow與hosts.deny，通過使用它們進行交配式的規則管理。這樣非常煩瑣也不夠直觀，在FREEBSD3.2以後這個問題得到了新的改良，現在系統默認只需要使用hosts.allow一個文件就可以了，當然，hosts.deny你也可以自行建立，這是很自由的)。打開hosts.allow的配置來看看吧:
CODE:alex# cat /etc/hosts.allow看出規則的基本配置語法了嗎？最基本的語法就是: 服務對象 : 客戶端對象地址 : 行為
當然，除此之外還有多種的語法演變方式，大家可以在默認存在的/etc/hosts.allow的注釋文本中找到相關的資料。
現在我們要做的就是編寫自己的規則。在修改規則文件前還是先備份原來的規則文件吧。
CODE:alex# cp hosts.allow hosts.allow.bak用ee打開hosts.allow:
CODE:alex# ee /etc/hosts.allow在文檔的開始部分找到ALL : ALL : allow這句規則(這句規則是允許所有的服務與客戶端地址的)，在它的前面加上#符號，也就是改成:
CODE:#ALL : ALL : allow在hosts.allow中默認是沒有針對telnetd服務的配對規則的，所以這裡我們需要自行加上。找到下面的語句段:
CODE:# The rest of the daemons are protected.
ALL : ALL \
: twist /bin/echo "You are not welcome to use %d from %h."這個是整個規則群中最後的“保險”規則(當tcpwrapper在規則群中找不到相關的配對規則時就會根據這個規則進行處理了)。
---------------------------------------------------------------------------------------------
小提示:
也許有人會問:如果我把這個“保險”規則給停了(刪除了該規則語句或在前面加“#”號)，而tcpwrapper又找不到相應的規則，那tcpwrapper會如何處理呢？這樣的話inetd(超級網絡服務進程)會跳過tcpwrapper功能而直接把執行權交給相應的網絡服務進程的。
---------------------------------------------------------------------------------------------
在這個規則的上方加上下列的規則語句:
CODE:telnetd : 192.168.1.0/255.255.255.0 : allow #192.168.1.0/255.255.255.0是小神家中其他機器所
#使用的IP段
telnetd : ALL : deny #禁止其他所有的客戶端地址訪問本機的telnetd服務有一點是需要注意的:hosts.allow中的規則群使用的方法與我們通常所使用的防火牆規則群的原理都是一樣的，都是上下之分，越處於上方的規則它的優先執行權就越高。所以這裡我們必須把:
CODE:telnetd : 192.168.1.0/255.255.255.0 : allow這條規則放在
CODE:telnetd : ALL : deny規則之上，否則允許192.168.1.0/24訪問的這條規則就等於“空規則”了。
OK，保存退出。規則配置完成了。如何得知自己配置的規則群有無邏輯錯誤(如出現“空規則”等)或其他錯誤呢？關於這個問題tcpwrapper的作者也考慮到了，所以他另外寫了兩個附帶的工具:tcpdchk與tcpdmatch，默認這兩個程序都是在/usr/sbin/目錄下的。tcpdchk是一個檢查工具，直接運行它就可以查出配置文件中的多種錯誤問題了。其經常使用方法為:
CODE:alex# tcpdchk
或
alex# tcpdchk -v無參數運行tcpdchk可以直接得到該配置文件的錯誤提示(如果真的有錯誤存在的話)；加上參數-v可以立刻得到所有規則的參數配對列表(這裡無論規則是否有誤，都會一概顯示出來的)。如果我的規則群中有幾十、幾百、甚至幾千條規則呢？哪能知道哪條打哪條啊？嘿嘿，還有辦法，這裡就要用到第二個程序----tcpdmatch了，它是一個簡單的規則數據庫查詢工具。使用它進行查詢的基本格式是:
CODE:alex# tcpdmatch 服務名 訪問的客戶端地址或者機器名現在打個比方，我們想查看該服務器提供的telnetd服務是否允許IP地址為192.168.1.10的客戶端機器訪問呢？在SHELL中敲入:
CODE:alex# tcpdmatch telnetd 192.168.1.10
client: address 192.168.1.10 #提示你所查詢的客戶端機器地址為192.168.1.10
server: process telnetd #查詢的服務是telnetd
matched: /etc/hosts.allow line 2 #規則建立在/etc/hosts.allow的第2行
option: allow #管理者設置的行為是“允許”
access: granted #批准該規則大伙如果覺得規則群中某些規則的設置問題上是比較含糊的話，不妨使用一下這兩個工具，它們可以幫助你很快地整理並建立起屬於自己的規則群。
現在關於規則的設置問題就已經告一段落了。既然規則設置好了，如何能讓它們實施起來呢？大家應該知道，在FreeBSD中大多數INTERNET網絡服務都是通過inetd(超級網絡服務進程)來啟動與調節的，因此我們的tcpwrapper也應該從這裡下手。以前大多數的UNIX系統在使用tcpwrapper時都是通過使用tcpd守護進程來代替其他服務運行從而實現監控其他網絡進程的目的的，不過在現在的FreeBSD4.x中這個操作問題已經有了新的改良，現在我們只需要在啟動inetd時加入-w、-W這兩個參數就可以啟用tcpwrapper功能了。那關於日志的問題又如何解決呢？如何你經常使用inetd的話也應該清楚-l參數了吧？
CODE:alex# inetd -w -W -l加了-l後我們就可以直接在/var/log/auth.log中找到相關的日志記錄了。FreeBSD的日志比WINDOWS的更加直觀，大家已經自己找找:)...像這條:
CODE:xxx 24 xx:xx:xx alex inetd[255]: refused connection from 218.20.121.161, service telnetd (tcp) 一看就知道是IP為218.20.121.161的客戶端機器企圖訪問本機的telnetd服務，被本機拒絕了...
CODE:inetd_enable="YES"
inetd_flags="-w -W -l"保存退出，重新啟動機器試試:)。
是時候確認一下實驗後的“戰果”情況了，在服務器的SHELL中敲:
CODE:alex# sockstat -4
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
root inetd 77 4 tcp4 *:23 *:*
root syslogd 70 5 udp4 *:514 *:*PID為77的inetd進程證明telnetd是在提供正常服務的(如果想再進一步地確認telnetd是否在提供正常的服務的話，你可以直接用內網的機器登陸上去看一下)。現在使用規則“允許”范圍以外的其他地址的客戶端機器telnet上去，看看會如何，很快你就會看到:
遺失對主機的連接。
C:\>
不錯吧？其實這種操作是觸類旁通的，你可以把它的操作套在其他任何的網絡服務(無論是使用tcp的或是使用udp的，是external services還是internal services都是可以的)的進程上去。
最後談談最近針對tcpwrapper進行操作實驗後得到的一些個人觀點吧(有誤之處還請指出):
使用tcpwrapper的優點:屬於FreeBSD的“基本設施”程序，無需安裝，而且絕對綠色；輕量級，無須占用大量資源；支持所有inetd的網絡服務進程。
使用tcpwrapper的缺點:在進行登陸過程時inetd進程的運行速度會相對減慢(包括客戶端與服務端)；監控能力只局限於一些傳輸層的服務/協議(若是一些低層協議，如ICMP等的它就無能為力了)。rapper的基本使用方法。
