歡迎您光臨本站 註冊首頁

利用Tripwire檢測系統完整性(1)
完整性是安全要求的基本要求之一,本文將向讀者詳細介紹如何利用開源完整性檢測工具Tripwire來檢查系統的完整性。

一、系統的完整性

我們知道,系統的正常運行要靠系統程序的正常運轉,而程序的運行又與其可執行文件休戚相關。所以,維護系統完整性是確保系統安全的一項基本工作。我們這裡的系統完整性是指系統中可執行文件的完整性,也就是說系統中的程序文件沒被非法修改。

如果可執行文件被惡意修改的話,如改變、插入或刪除等,將直接威脅到系統的安全性。大多數情況下,黑客滲入到系統後會立即修改某些系統文件以創建後門,如用準備好的替代物換掉系統中原有的/bin/login文件以便使其不用口令便能登陸系統;然後再修改某些文件,例如/bin/ls等,以便隱藏其行徑。如果我們沒能這些改變的話,那無異於身處險境卻還以為很安全,這就為黑客的長期入侵提供了非常有利的條件,同時也意味著我們的損失將更大!為了改變這種被動的局面,我們需要一種文件完整性檢查工具,使得當系統文件被惡意修改後能及時發現,從而為進一步處理創造條件。

二、Tripwire概述

Tripwire的運行機理

Tripwire是一款最為常用的開放源碼的完整性檢查工具,它生成目標文件的校驗和並周期性的檢查文件是否被更改。下面我們簡單介紹一下Tripwire的運行機理。與大多數完整性檢查程序相同,對於需要監視的文件,Tripwire會使用校驗和來為文件的某個狀態生成唯一的標識(又稱為"快照"),並將其存放起來以備後用。當Tripwire程序運行時,它先計算新的標識,並於存放的原標識加以比較,如果發現不匹配的話,它就報告系統管理人員文件已經被修改。接下來,系統管理員就可以利用這個不匹配來判斷系統是否遭到了入侵。例如,如果Tripwire已經為/bin/login和/bin/ls存放了快照,那麼對它們的尺寸、inode號、許可權以及其他屬性的任何修改,都逃不過Tripwire的火眼金睛。尤其是對於文件內容的修改,即使只改變了一個位元組,Tripwire也能察覺得到,因為校驗和是針對文件整體的。

通過對以上運行機制的了解我們不難發現,完整性檢查工具的安裝時機非常重要,最好是在交付用戶使用和連入網路之前的Linux系統初裝時進行。因為完整性檢查工具只有保留了系統文件的初始狀態(快照),才能確保系統文件的完整性;如果在系統使用一段時間后再取其快照的話,它很可能已經不再是原系統文件的映象(如已經遭到破壞),所以這時的完整性檢測的可靠性已經打了折扣。

Tripwire的組成

Tripwire主要由策略和資料庫組成。策略不僅指出Tripwire應檢測的對象即文件和目錄,而且還規定了用於鑒定違規行為的規則。一般情況下,對於/root、/bin和/lib目錄及其中文件的任何修改都應視為違規行為。資料庫則用來存放策略中規定的檢測對象的快照。只要建立了策略和資料庫,我們就可以隨時用快照來比較當前的文件系統,然後生成一個完整性檢測報告,從而判斷系統的完整性是否受到攻擊。除了策略和資料庫外,Tripwire還有一個配置文件,用以控制資料庫、策略文件和Tripwire可執行程序的位置等。

為了防止被篡改,Tripwire對其自身的一些重要文件進行了加密和簽名處理。這裡涉及到兩個密鑰:site密鑰和local密鑰。其中,前者用於保護策略文件和配置文件,如果多台機器具有相同的策略和配置的話,那麼它們就可以使用相同的site密鑰;後者用於保護資料庫和報告,因此不同的機器必須使用不同的local密鑰。

三、Tripwire的安裝和設置

Tipwire的安裝

Tripwire的下載地址為http://www.tripwire.org。如果您使用的是Red Hat Linux的話,可以下載該站點上的RPM格式的程序(當前最新版本為rpm4-tripwire-2.3-47.i386.tar.gz),假設將其下載到/A目錄的話,安裝過程如下所示:



rpm -ivh /A/rpm4-tripwire-2.3-47.i386.tar.gz


如果從源代碼中進行軟體安裝,先下載tar格式源程序並解包。接下來在相應目錄中執行如下操作:

./configure make make install


安裝后的設置

在安裝Tripwire之後,可以進行如下的設置:

# cd /etc/tripwire # ./twinstall.sh # tripwire --init # rm twcfg.txt twpol.txt


這裡,腳本twinstall.sh的作用在於執行下列任務:

1)創建site和local密鑰,這時會要求輸入口令;如果這兩個密鑰業已存在,則可以跳過此步驟。其中,site密鑰存放在site.key文件中,而local密鑰則存放在hostname-local.key(這裡的hostname是指該機器的主機名)文件之中。

2) 利用site密鑰對默認配置文件twcfg.txt進行簽名,並將簽名(而非被簽名的文件twcfg.txt)存放於文件tw.cfg之中。

3) 利用site密鑰對默認策略文件twcfg.txt進行簽名,並將簽名(而非被簽名的文件twcfg.txt)存放於文件tw.pol之中。

此外,您還可以手工方式來安裝,尤其是在由於某種原因,您的系統沒帶twinstall.sh文件等情況下則必須手工完成這項工作:

設置常見的變數:

DIR=/etc/tripwire SE_KEY=$DIR/site.key LOCAL_KEY=$DIR/`hostname`-local.key


創建site密鑰

# twadmin --generate-keys --site-keyfile $SITE_KEY


生成local密鑰

# twadmin --generate-keys --local-keyfile $LOCAL_KEY


為配置文件簽名

# twadmin --create-cfgfile --cfgfile $DIR/tw.cfg \ --site-keyfile $SITE_KEY $DIR/twcfg.txt


為策略文簽名

# twadmin --create-polfile --cfgfile $DIR/tw.cfg \ --site-keyfile $SITE_KEY $DIR/twpol.txt


設置許可權

# cd $DIR # chown root:root $SITE_KEY $LOCAL_KEY tw.cfg tw.pol # chmod 600 $SITE_KEY $LOCAL_KEY tw.cfg tw.pol


需要說明的是,上述配置是以您的默認配置和策略文件已經存在並分別為twcfg.txt 和twpol.txt為前提的。一般情況下,為了使這兩個文件能更好的滿足我們的系統要求,還必須對其進行相應的修改(見下文)。此外,策略和配置文件的名稱必須為twcfg.txt 和 twpol.txt,因為腳本代碼就是用的這兩個名稱。

然後,為tripwire建立資料庫並用local進行簽名,命令如下所示:

# tripwire -init


需要說明的是,完成此項操作,需要輸入local密鑰的口令;如果tripwire出現類似"Warning: File System Error"之類的錯誤消息的話,那麼可能是由於默認策略引用了並不存在的文件所引起的。

為了安全起見,我們還需要刪除明文形式的策略和配置文件,命令如下所示:

# rm twcfg.txt twpol.txt

利用Tripwire檢測系統完整性(2)
現在,Tripwire自身已經完全就緒,接下來我們要做的事就是用它來執行完整性檢查。

四、維護策略文件和配置文件

如何查看策略和配置

如果您想瀏覽一下Tripwire的策略和配置情況,但他們是以二進位的形式存放或當前缺失,請用下列命令:

生成有效配置文件

# cd /etc/tripwire

# twadmin --print-cfgfile > twcfg.txt


生成有效策略文件

# cd /etc/tripwire

# twadmin --print-polfile > twpol.txt


因為有效配置文件和策略文件已經加密和簽名,所以他們是以密文的形式存放。如果想瀏覽他們的話,需要先解密:將其轉換成明文的形式。為安全起見,一般建議在對他們重新進行簽名之後將明文形式的配置和策略文件刪除。

需要注意的是,儘管我們可以將twadmin的輸出重定向到任何文件當中,但安裝腳本twinstall.sh卻要求明文形式的策略和配置文件名為twcfg.txt和twpol.txt。

修改策略文件和配置文件

如果想改變Tripwire所檢查文件和目錄的話,或者想改變Tripwire的默認行為,那該怎麼辦呢?請按如下所示來進行:

首先,從明文文件中提取出策略和配置:

# cd /etc/tripwire

# twadmin --print-polfile > twpol.txt

# twadmin --print-cfgfile > twcfg.txt


策略文件twpol.txt和配置文件twcfg.txt的修改可以利用常見的文本編輯器來完成。對於修改過的策略文件twpol.txt和配置文件twcfg.txt文件,需要對他們進行再次簽名:

# twadmin --create-cfgfile --cfgfile /etc/tripwire/tw.cfg \

--site-keyfile site_key etc/tripwire/twcfg.txt

# twadmin --create-polfile --cfgfile /etc/tripwire/tw.cfg \

--site-keyfile site_key etc/tripwire/twpol.txt


然後,我們需要重新初始化資料庫:

# tripwire --init

# rm twcfg.txt twpol.txt


需要注意的是,我們只能對明文形式的策略和配置文件進行編輯,所以除非已有明文文件,否則必須先將加密簽名的策略和配置文件轉換成明文形式。另外,當在修改文件時,可能會遇到以下消息:

### Error: File could not be opened


這說明Tripwire沒有找到目標文件,如果是該文件的確不存在的話,我們就需要從策略和配置文件中去掉對該文件的引用(或將其註釋出來也可以),並對策略文件重新簽名。如果只是在完整性檢查之後簡單地更新一下資料庫的話,那完全沒必要嚴格按上述步驟來處理;但是對策略或配置文件作了修改後卻必須這樣處理。

五、配置完整性檢測

基本的完整性檢測配置

完整性檢驗的目的在於檢查一下自從上次Tripwire對文件作了快照以後,我們的文件是否發生了變動,我們可以簡單通過以下命令來達到此目的:

# tripwire -check


這是一條最基本的命令,它能告訴我們系統是否被修改了。它根據在策略文件中規定的規則,利用Tripwire資料庫跟文件系統當前狀態加以對比,之後將比較結果寫入標準輸出,並將其加蓋時間戳、簽名,然後作為一份Tripwire報告存放起來。另外,我們還可以針對資料庫中的單個或多個文件進行完整性檢查。若Tripwire的策略中包括以下規則:

(

rulename = "My funky files",

severity = 50

)

{

/sbin/e2fsck -> $(SEC_CRIT) ;

/bin/cp -> $(SEC_CRIT) ;

/usr/tmp -> $(SEC_INVARIANT) ;

/etc/csh.cshrc -> $(SEC_CONFIG) ;

}


那麼您就可以用以下命令來查看選中的文件和目錄:

# tripwire --check /bin/cp /usr/tmp


若要查看一條規則所對應的所有文件,用以下命令:

# tripwire --check --rule-name "My funky files"


也可以查看嚴重性大於等於特定值的所有規則,如下所示:

# tripwire --check --severity 40


關於策略文件的有關語法,請參閱有關手冊或查看聯機幫助:

$ tripwire --check --help




更高安全級別的完整性檢測

為了獲得更高的安全性,我們可以將Tripwire最關鍵的文件存放到諸如CD-ROM之類的只讀介質或有防寫的上磁碟上,這樣能防止它們被篡改。步驟如下:

1.把 site密鑰、local密鑰以及tripwire可執行文件本身複製到合適的磁碟上,打開防寫后再裝載,比如將其安裝在目錄/mnt/cdrom。

# mount /mnt/cdrom

# ls -l /mnt/cdrom

total 2564

-r--r----- 1 root root 931 Jan 21 10:20 site.key

-r--r----- 1 root root 931 Jan 21 10:20 myhost-local.key

-r-xr-xr-x 1 root root 2612200 Jan 21 10:19 tripwire


2.生成明文形式的配置文件

# DIR=/etc/tripwire

# cd $DIR

# twadmin --print-cfgfile > twcfg.txt


3.編輯配置文件以使之指向這些拷貝

/etc/tripwire/twcfg.txt:

ROOT=/mnt/cdrom

SITEKEYFILE=/mnt/cdrom/site.key

LOCALKEYFILE=/mnt/cdrom/myhost-local.key


4.對修改後的配置文件進行簽名

# SITE_KEY=/mnt/cdrom/site.key

# twadmin --create-cfgfile --cfgfile $DIR/tw.cfg \

--site-keyfile $SITE_KEY $DIR/twcfg.txt

5.更新資料庫並卸載CD-ROM

# /mnt/cdrom/tripwire --init

# umount /mnt/cdrom

現在,已經萬事具備,如果要進行完整性檢驗的話,只要插入光碟並輸入命令就可以了:

# mount /mnt/cdrom

# /mnt/cdrom/tripwire --check

# umount /mnt/cdrom


site密鑰、local密鑰以及tripwire可執行文件之所以要加以保護,是因為它們極為重要並且可能受到攻擊。Tripwire的其他文件,如資料庫、策略和配置等需要用這兩個密鑰和程序來簽名,如果site密鑰、local密鑰以及tripwire可執行文件是安全的,那麼用它們簽過名的文件發生的任何變化都能被發現。另外,將/usr/sbin/tripwire拷貝到光碟之前,一定要確保它是靜態鏈接的,也就是說該程序的執行不依賴任何動態共享庫,因為應用動態共享庫時,動態庫調用更容易被攻擊者所劫持。

$ ldd /usr/sbin/tripwire

not a dynamic executable


除了上面的方法外,我們還可以利用遠程進行完整性檢驗來提高安全強度。

為了提高檢驗的安全性,關鍵的Tripwire文件最好不要存放在被檢驗的機器上面。為此,我們在此引入兩台機器untrusty和trusty。前者是一台想要用Tripwire來檢查其完整性的"不可信"機器;後者是一台安全的機器,理想的情況下只能由它訪問網路,而其他機器這不能訪問它。此外,為了使其他機器不能訪問存放site密鑰、local密鑰以及tripwire可執行文件的遠程機器,通常使用rsync(SSH下的安全隧道技術)來驗證原件和拷貝的一致性從而觸發完整性檢驗。遠程機器trusty上的原始配置如下所示:

#!/bin/sh

REMOTE_MACHINE=untrusty

RSYNC='/usr/bin/rsync -a --progress --rsh=/usr/bin/ssh'

SAFE_DIR=/usr/local/tripwire/${REMOTE_MACHINE}

VITAL_FILES="/usr/sbin/tripwire

/etc/tripwire/site.key

/etc/tripwire/${REMOTE_MACHINE}-local.key"



mkdir $SAFE_DIR

for file in $VITAL_FILES

do

$RSYNC ${REMOTE_MACHINE}:$file $SAFE_DIR/

done


在檢驗本地機器之前,需要首先將site密鑰、local密鑰以及tripwire可執行文件與它們在遠程機器上的拷貝比較一番,以確定這三個文件的完整性。然後在trusty上運行下列代碼(需要注意,這裡的各個變數如REMOTE_MACHINE要與前面腳本中的保持一致):

#!/bin/sh

cd $SAFE_DIR

rm -f log

for file in $VITAL_FILES

do

base=`basename $file`

$RSYNC -n ${REMOTE_MACHINE}:$file . | fgrep -x "$base" >> log

done

if [ -s log ] ; then

echo 'Security alert!'

else

ssh ${REMOTE_MACHINE} -l root /usr/sbin/tripwire --check

fi


rsync是一個常用來同步兩台機器上的文件的實用程序。它實際上通過SSH建立了一條安全隧道,來為我們在兩台機器之間提供安全的鑒別功能,並為兩者之間的通信提供加密服務,但前提是您已經在兩台機器之間設置了SSH設施,否則,rsync就不能提供上述的安全功能。

這裡有幾個常用的選項需要介紹一下:-progress通知rsync只有當本地和遠程文件不同時才產生輸出;-n選項的作用在於讓rsync不拷貝文件。

對於fgrep命令,主要用於刪除所有輸出,但可疑的文件名除外。它的特點是用固定的字元串而非正則表達式進行匹配,而文件名中恰恰又包含常見於正則表達式的一些特殊字元,如"."等。fgrep-x對整行(即文件名)進行匹配,因此,當且僅當本地文件和遠程文件完全一致時,log文件才為空,從而觸發完整性檢驗。

那麼是否要遠程存儲資料庫呢?實際上是沒有必要的,因為資料庫是用local密鑰來簽名的,而該密鑰又是"離機的",因此如果資料庫發生意外變化的話,Tripwire就會發出警報。

Trusty不僅要檢查這些重要的Tripwire文件,同時還必須趕在untrusty進行完整性檢查之前將他們拷貝給untrusty:

# scp -p tripwire untrusty:/usr/sbin/tripwire

# scp -p site.key untrusty-local.key untrusty:/etc/tripwire/

# ssh untrusty -l root /usr/sbin/tripwire --check


高強度完整性檢測

上面介紹的是常規強度的完整性檢測,但我們還可以繼續提高檢驗強度,但天下沒有免費的午餐,這需要付出速度與方便性為代價的。

因此,我們可以創建一個可引導的CD-ROM,並在其中放上一個微型的Linux系統、Tripwire程序以及您的local和site密鑰。然後,將您的機器與所有網路斷開,從上面製作的可引導光碟引導系統,接著利用光碟上的(而不是硬碟上的)可執行程序來檢查機器磁碟的完整性。之後還要經常備份您的Tripwire的資料庫、配置和策略,以備萬一它們被攻擊者刪除時之用。

這種方法至少需要兩台機器,其中一個必須是安全可信的機器(稱為trusty),另一個是被檢測的機器(稱為untrusty)。我們的目的是為後者進行安全的Tripwire檢測。


第一步是安全創建可引導CD-ROM,這要求:



在trusty上創建CD-ROM,trusty必須是一個潔凈的Linux系統,它可以是由可信的源或二進位軟體包構建而成,從來沒有連入網路或被第三方訪問過,此外還要為其打上最新的安全補丁。


配置CD-ROM的啟動腳本使其禁用所有網路。


直接用可信的源或二進位軟體包來燒制光碟。


在trusty上建立site和local密鑰。

然後,從CD-ROM引導untrusty,裝上本地磁碟並利用CD-ROM上的程序和密鑰來創建untrusty的Tripwire資料庫。因為資料庫、策略和配置文件已經用CD-ROM的密鑰簽過了名,所以這些文件在untrusty上的安全性是可信的。接著,您就可以在執行完整性檢查之前從光碟上引導untrusty。另外,若只是從untrusty上載入光碟並從光碟上運行untrusty的話,則會出現以下情況:


如果untrusty是動態鏈接的話,很難保證共享庫的安全性;


難以保證系統內核的安全性;


難以保證untrusty上掛載點的正確性;

雖然這種方法提供了非常高的安全級別,但做起來非常麻煩,所以只有有特殊安全需求的情況下才採取該措施。為方便起見,我們可以安排一個cron任務,使其在每晚規定的時間從光碟上重引導untrusty,來進行Tripwire檢驗,之後再重引導untrusty。然而,不要讓untrusty本身來執行該任務,因為untrusty是不安全的,所以在其上運行的cron也是不可靠的;相反,應將其安排給trusty來執行,如利用SSH批處理任務來觸發重引導,因為這樣作更為合理一些.


利用Tripwire檢測系統完整性(3)
六、完整性檢測的自動化

如果您想讓Tripwire在特定的時刻或每隔一段時間就自動進行檢測的話,可以按照下列提示來完成。例如我們要他每天的下午2點進行一次檢測,那該如何做呢?我們可以利用cron來來協助我們完成此項任務。我們可以在root用戶的 crontab文件中添加以下一項:

0 2 * * * /usr/sbin/tripwire --check


需要注意的是,cron本身也可能受到攻擊,因而可能出現不執行等意外情況。所以我們最好在一個可信的遠程機器上來執行cron任務。在trusty上的crontab中添加如下一個遠程檢測項:

0 2 * * * ssh -n -l root untrusty /usr/sbin/tripwire --check


但是如果入侵者攻破了untrusty上的sshd的話,那麼覆巢之下,焉有完卵--您的安全性也必將受到威脅!此外,某些rootkits能夠顛覆對Tripwire的遠程exec調用。為了獲取最大的安全性,只是執行cron任務是遠遠不夠的,還得在可信機器上進行完整性檢驗。

Red Hat Linux預配置情況下,會在每晚通過cron任務/etc/cron.daily/tripwire-check來運行Tripwire程序。但是,Tripwire資料庫不是由操作系統來提供的,而是由用戶自己來提供一個原件,否則,cron只是定時向超級用戶發送一封Tripwire調用失敗的的電子郵件。

七、生成Tripwire報告

上面介紹了如何配置Tripwire來進行完整性檢測。但這並不是使用Tripwire的目的所在,我們需要的是完整性檢測的結果,換句話說還得要Tripwire將結果以報告的形式提交給管理人員,這樣我們才能以此判斷系統是否遭到破。具體操作如下所示:

#!/bin/sh

DIR=/var/lib/tripwire/report

HOST=`hostname -s`

LAST_REPORT=`ls -1t $DIR/$HOST-*.twr | head -1`

twprint --print-report --twrfile "$LAST_REPORT"


一般情況下,Tripwire報告存放在什麼地方是由Tripwire配置文件中的REPORTFILE變數來決定,其常見值為:

REPORTFILE = /var/lib/tripwire/report/$(HOSTNAME)-$(DATE).twr

變數HOSTNAME存放的是機器的主機名,變數DATE存放的是時間戳,如。所以,主機untrusty的報告文件名應當為:

/var/lib/tripwire/report/untrusty-20040130-030518.twr

雖然tripwire可以通過電子郵件發送報告,但不要太信賴電子郵件,因為它很可能被截獲並被篡改后重發。所以,最好由您直接檢查報告為上,要Twprin列印報告,可以按如下操作進行:

# twprint --print-dbfile --dbfile /var/lib/tripwire/`hostname -s`.twd

Tripwire(R) 4.0 Database

Database generated by: root

Database generated on: Mon Jan 1 22:33:55 2004

Database last updated on: Never

... contents follow ...


八、Tripwire資料庫的維護

對於Tripwire資料庫的維護工作,主要包括資料庫的更新、添加和刪除操作,下面我們將分別介紹。

更新資料庫

有時候,我們會對程序作一些正常的修改,這些改動也會反映在最新的Tripwire報告中,但問題是,我們使用Tripwire很大程度上只想讓它報告那些"非法的"修改。那麼,這時我們就需要利用最新的報告來更新一下我們的Tripwier資料庫,具體操作如下所示:

#!/bin/sh

DIR=/var/lib/tripwire/report

HOST=`hostname -s`

LAST_REPORT=`ls -1t $DIR/$HOST-*.twr | head -1`

tripwire --update --twrfile "$LAST_REPORT"


這裡有一點必須注意,那就是如果你已經修改了某些文件的話,您不能只是簡單的運行更新就算了事:您必須在此之前首先進行完整性檢驗。進行更新的好處是它比初始化資料庫要快得多!

向資料庫中添加文件

為了向Tripwire的資料庫中添加文件和目錄,請執行以下操作:

向有效策略文件中添加指定的文件,如/bin/ls:

/bin/ls $(SEC_BIN) ;


向有效策略文件中添加整個目錄樹,比如/etc:

/etc $(SEC_BIN) ;


向有效策略文件中添加目錄如/etc及其下的文件,但不包括其子目錄:

/etc $(SEC_BIN) (recurse=1) ;


向有效策略文件中添加目錄如/etc,但不包括其下的文件以及其子目錄:

/etc $(SEC_BIN) (recurse=0);


然後初始化資料庫。

策略實際上就是存放在策略文件中的規則表,規則的一般形式如下所示:

filename -> rule ;


它的基本含義就是,如果給定的規則被違反的話,那麼對應的文件或目錄就被認為是到了安全侵害。例如:

/bin/login -> +pisug ;


上面這條規則的含義是:如果自從上次快照之後,如果/bin/login的文件許可權(p)、inode號(i)、 尺寸 (s),、用戶(u)或組(g)發生了變化的話,那麼就應當引起我們的關注。如果想全面深入的了解Tripwire語法的話,請參閱Tripwire手冊。在這裡,我們使用了一個預定義的全局變數SEC_BIN來指出二進位文件不得修改。recurse=n的作用在於通知Tripwire在文件系統中的遞歸深度;當n為零時,其含義為只測試到目錄文件本身這一層次。

很多時候我們需要修改默認策略文件,因為它們所提供的策略未必完全適合我們的系統,所以我們需要針對不同的Linux類型和版本,對Tripwire所提供的默認策略進行適當的剪裁,從而滿足我們的要求。
從資料庫中刪減文件

我們不僅根據需要向資料庫中添加文件,有時我們還需要對資料庫中的文件加以刪減。具體操作如下所示:

例如首先向資料庫中添加一個目錄:

/etc -> rule


然後排除掉其中的一些文件:

!/etc/not.me

!/etc/not.me.either


如果我們想去掉一個子目錄的話:

!/etc/dirname


這裡,感嘆號!的作用在於將給定的文件或子目錄排除掉。

九、小結

Tripwire是現實中最為常見的一種開源完整性檢測工具,我們對實際工作中的一些常見操作進行了較為全面而不失側重的介紹,如果讀者要想更深入的了解本軟體的話,請參閱其使用手冊。

需要注意的是,Tripwire是進行周期性檢測的,因此在兩次檢測間隔內的修改對它來說就顯得有些鞭長莫及了,但我們還可以縮短其周期間隔,使其幾乎以實時的方式運行,但這時的開銷將明顯增加,所以我們要在安全性和系統開銷之間加以權衡,實際工作中可以視具體情況來加以定奪。

[火星人 ] gary168的《利用Tripwire檢測系統完整性》(3合一版,放一起多好)已經有686次圍觀

http://coctec.com/docs/linux/show-post-161950.html