[資安觀念] 談基準的重要性

不管你是不是常有機會跟女生閒話家常，一定都曾聽女生說過類似的話：「我在減肥，我太胖了。」奇怪的是，你可能以為說這話的女生颱風天肯定不能出門，否則就會因為體重過輕而被吹到某個無人島去…所以，太胖這件事對許多人(尤其是女生) 來說，並不是一個客觀的事實，而是主觀的意識。每個女生總喜歡跟自己最瘦的時候相比較，所以隨時都覺得自己很胖，簡直胖到無法見人。

回到資安方面，身為一個專業的管理人員，平時我最怕聽到使用者說出的一句話就是”最近系統好像怪怪的”。這句話有什麼好怕的？因為它代表了無限的可能性。最近？好像？怪怪的？每個字詞本身就是充滿了不確定性，組合在一起的威力就更加龐大了。身為管理者，聽到這句話時你有兩個選擇，一個就是虛應一句：「我知道了，我會查查看。」當然，使用者也都知道你說這句時只是希望結束這個不會有任何結果的對話。另外一個選擇，當然就是試著找出問題並解決之。但是，光憑這句話就要找出問題，你不但需要比福爾摩斯更敏銳的觀察力，還需要比豆豆先生更受老天爺疼愛的好運才有可能成事。

還好，身為一個專業的管理人員，你還是知道有哪些是必須追問的問題。「怪怪的？怎麼樣怪？」「就是系統乎快乎慢。」使用者認真地回答著。好了，使用者已經把問題描述出來了，但是…問題還是繼續藏身在五里霧當中。乎快乎慢？快是多快，慢又是多慢？什麼時候快，又什麼時候慢？當然，你可以繼續追問使用者這些問題，但是我相信這已經超出”正常”使用者能夠提供的資訊了。所以，這時候「我知道了，我會查查看。」這句 showstopper 又會被你搬上檯面，故事結束！

故事當然可以有不一樣的結局，只要你平日已經建立相關的機制並擁有所需資訊，你就可以判斷出是不是真有問題的存在，甚至精準地指出問題的所在。以上面的例子而言，如果我們平日就已經收集每個程序觸發的時間、動作、反應時間等資訊，我們就可以知道”最近”的反應時間跟之前相較而言是否有任何明顯的變化，有哪些動作受到影響，而影響的程度有多大。這些平日辛苦收集而來的資訊，就是我們用來判斷問題的基準值 (Baseline)。也就是說，我們要回答什麼是”怪怪的”這個棘手的問題之前，必須先知道什麼樣才是”不怪的”。我們可不能隨著使用者的心情，就決定系統是快、是慢，就像我們不能聽到女生說她因為過胖所以要減肥就認定她一定很胖一樣。

基準值，其實可以分為兩種類型，一種是人為強制產生的，另外一種則是根據實際的情況所自然產生。前者通常可看成是 (廣義) 政策的一部分，像是規定”所有使用者的螢幕保護程式必須在閒置五分鐘後自動啟動，並以密碼加以保護”就可以視為基準的一種。透過這類基準的建立，我們可以確保安全需求的基本滿足。這種類型的基準值因為屬於人工強制產生，所以在管理上並沒有太多的技術難處。 像是微軟還提供了 Microsoft Baseline Security Analyzer 這個免費工具，可以用來確保 Windows 系統滿足微軟所建議的基準值。

相較於人工強制產生的基準值，根據實際使用情況而自動產生的基準值，可就複雜許多了。以前述例子而言，你知道每個程序執行各項動作的平均/最慢/最快反應時間嗎？你知道這些反應時間與時段的關係嗎？你知道這些反應時間與日期 (幾月幾日/星期幾) 的關係嗎？甚至你知道這些反應時間跟各使用者之間的關係嗎？你可能會說，這麼多的東西我怎麼可能知道。沒錯，要知道的東西實在是很多，但是這並不是管理者用來偷懶的藉口。資安的事情，本來就沒有完善的一天，所以這些資訊的收集與分析，也不是三兩次就可以搞定的。好吧，你可能會說程序的反應時間跟資安有什麼關係(我個人認為是有很大的關係)，那我換幾個問題來問。你知道使用者通常什麼時候登入系統進行作業？每次大概登入多久？從哪邊登入？這些資訊的收集與利用，其實跟我之前談到的日誌管理有很大的關聯性，只是收集的內容更多，應用範圍更大而已。

唯有透過這些資訊的收集與分析，我們才能精準的回答”最近系統好像怪怪的”這類棘手的問題，甚至是主動發現隱而未發的問題，防範於未然。事實上，這個概念被廣泛應用在 IDS、防毒軟體、SIEM 等相關產品上，只是通常以”異常行為偵測”的名字出現。”異常行為偵測”立意雖好，但是在實務上同樣會面臨沒有收集到的資訊就沒辦法分析的根本問題。雖然目前因為儲存技術的進步以及儲存成本的下降，使得儲存大量資料變得可行，但是資訊數量的成長速度卻有可能遠大於成本下降的速度，導致總體成本並沒有隨之下降。此外，正常與異常之間的分際，通常也不如黑與白一般的清晰而無爭議，所以”高誤報率”與”高漏報率”是這類功能很難擺脫的陰影。

嚴格說來，類似的問題存在於各個領域當中。不管是金融投資、企業運作都有監控的機制與系統，而這些系統不但可以消極的指出問題之所在，更可以積極的指出成長的機會。商業智慧 (BI) ，正是這類系統運作於企業運作的當紅應用。相較於 BI 的火紅，在資安擁有類似訴求的 SIEM 顯然在受到企業主的重視程度上遠遠不及於 BI。這幾乎是所有資安產品的相同宿命，但是因為 SIEM 的技術難度較高，一般 opensource 產品不容易有所表現。而那些提供免費版本的商業軟體，卻有有使用上的限制。更甚者，導入這類系統其實並不會讓管理人員生活的更美好 (至少在可見的未來是如此)，因為有更多的資料需要判斷，而這需要一個清晰的腦袋與足夠的經驗。企業主不知道或不重視這類系統，再加上導入這些系統反而會增加管理者的負擔，也難怪這些就成為雙方不願意去揭開的祕密。畢竟，「我知道了，我會查查看。」在大部分的時候都還挺有用的。但是如果你是一個目標導向的管理人員，類似的機制與資訊，絕對會是你最為強大的助力。 而對於一個長期穩定運作的系統，了解並掌握這些隱藏於事實底下的基準值，更是絕對不可缺少。

最後，你可以也應該用證據向使用者證明為什麼系統沒有像他感覺的一樣有乎快乎慢的問題。但是，你千萬別跟她爭論她一點也不胖，尤其是絕對別拿 BMI 那套跟她說。

[從電影看資安] 密碼真的是”密”碼嗎？ - 非法入侵

許久不見的”從電影看資安”系列，今天要跟各位分享”非法入侵 (Entering and Breaking) ”這部電影。去年 (2011) 凱吉大叔也拍了一部叫做非法入侵 (Trespass) 的電影，但是我今天要介紹的這部是 2006 年出版，由 Jude Raw 所主演。

故事一開始，帶到了男主角與其好友所創立的公司遭到小偷入侵。因為工作性質的關係，公司使用了 Apple 的電腦設備，因此財務損失並不算小。除了財務上的損失，電腦內的工作資料與私人檔案也都隨之而去，而這才是更令人感到困擾之事。因為公司安裝了保全設施，所以對於小偷能夠不觸動警報而輕鬆得手，眾人都感到相當疑惑，甚至將懷疑的眼光放到了清潔女工身上。

然而 Apple 設備的吸引力果然驚人，小偷再次光臨男主角的公司，卻在倉促間與男主角好友的車子產生擦撞。因為保全設備一再失效，所以男主角兩人決定靠人不如靠己，每天晚上在公司附近守株待兔。就在追查的過程當中，男主角意外發現小偷的蹤影，並跟蹤到了他家，最後還跟小偷的媽媽來了一段婚外情…雖然男主角犯了全天下男人都會犯的錯，但是最後他還是發現老婆跟繼女才是他生活中最重要的親人，因此在幫小偷脫罪之後，毅然決然地選擇回到家人的身邊。

金衰，公司還沒賺到錢就先遭小偷

蘋果牌電腦跟錢都被拐跑了

明明已經花錢買了保全，但是警報器就是沒叫！

這算是階級的歧視還是警察辦案的經驗談？
好野人，又買了全系列的蘋果牌電腦。

女僕趕快自清一下，免得被趕回家吃自己。

男主角的好朋友因為用下半身思考本著人性本善，所以願意相信她。

開始挖洞

繼續挖

如果再出錯，我就把你把回家公事公辦。

小偷早就”傳變變”，連望遠鏡都拿出來。

喔，密碼不但被看到，連瞎子用聽的也聽到了。

結果當然是…免費的搬家工人又出現了。
抓到理由了，趕快把女僕把回家。

雖然密碼在技術上是一項極不安全的驗證機制，但是因為實在太過方便，所以至今依舊受到普遍的使用。以技術的角度而言，身分驗證的來源可以分成三種形式，你知道什麼 (What you know)、你擁有什麼 (What you have) 以及你是誰 (Who you are)，而密碼就是你知道什麼的一種。

以影片中的例子而言，是密碼最簡單的一種形式，也就是不需搭配其他”東西”。而常用來搭配密碼的”東西”，包含帳號、卡片(如提款卡)、乃至於指紋等。在這幾種用來搭配的”東西”當中，帳號其實並不會增加太多的安全性，不過對於使用者身分的稽核，卻是有相當程度的效益。而要達到身分稽核的有效性，一個很重要的前提就是千萬不可以共用帳號，否則將是前功盡棄。如果密碼搭配卡片，因為密碼與卡片分屬你知道什麼與你擁有什麼，所以又稱為雙因素 (Two-factory) 驗證，可以大幅提高驗證的安全性。當然，前提是你不會把擁有的東西與其他人分享，而且這樣東西是無法被複製的。所以，我們現在都改用安全性較高的晶片卡來進行 ATM 的交易，而不是容易遭受複製的磁卡。如果再把卡片換成指紋 (你是誰)，因為複製難度更高，再加上很難與人分享，所以在理論上可以擁有更高的安全性。

話說回來，使用何種方式進行驗證，通常不是由使用者決定，而是提供系統的一方。如果你恰巧使用到利用密碼來進行驗證的系統 (相信我，你一定會遇到)，有很多建議可以讓你選出一個好的密碼。但是再好的密碼，通常還是有可能落入壞人的手上，而這甚至並不需要很高的技術，常見的情況包含：

1. 偷窺密碼 (Shoulder Surfing)
   你在 ATM 提款的時候”應該”要用身體把打密碼的手檔住，以免其他人看到你的密碼。不過 ATM 提款只看到對方的密碼其實也沒多大用處，除非要把晶片卡一起 A 到手才有用。但是像影片中的女僕，設定密碼時卻不知道小偷正拿著望遠鏡偷窺著，而這就足以讓公司大門敞開了。
2. 寫下密碼 (Write It Down)
   你知道在辦公室電腦螢幕上貼最多的，除了廠商的聯絡電話跟待辦事項外，應該就屬密碼了。再好的密碼，只要寫下來都是一文不值啊。除了貼在螢幕上，寫在便條紙後直接丟到垃圾桶，更是壞人的最愛，而這招就叫做挖寶 (Dumpster Diving)。別笑，不少知名的駭客都挺喜歡用這招的。
3. 複誦 (Read Out)
   你曾聽過有人會邊打邊複誦密碼的嗎？老實說，還真不少。尤其是輸入一些不常使用或很複雜的密碼時，邊打邊念可以確定自己不會打錯。是的，下次壞人也不會打錯了。像影片中的女僕，不但選用自己的生日當密碼，還大聲複誦一遍，不出問題才是老天無眼。
4. 在 Email 或即時通傳送密碼
   在大部分的情況下，Email 與即時通的內容在傳送時是沒有經過加密的。所以只要是有心份子，就可以很容易地透過網路封包偷窺 (Packet Sniffing) 的方式取得你千辛萬苦所想到的密碼。除了有心份子，現在很多公司也都對員工的 Email 與即時通訊內容進行側錄。當然，公司保證這些側錄的資料不會拿來濫用，但是你確定所有經手的人員都剛正不阿嗎？ 除了網路，其實電話也是很容易遭到側聽或側錄的通訊方式。

如何選擇好的密碼確實很重要，但是唯有搭配合適的方式，這些好的密碼才能達到原有的預期功效，保護你不受到無謂的傷害。否則，一旦密碼不再機”密”，再複雜的密碼也是毫無用武之地。

[工具介紹] 利用 fail2ban 避免密碼遭受暴力破解法(錯誤嘗試)

在上一篇的文章中我談到有關封鎖的一些觀念，在這篇文章中我將用 fail2ban 這個套件來針對一些服務進行嘗試登入錯誤的封鎖。
前面提到有些應用程式本身就帶有封鎖的功能，但是因為每個應用程式的設定與管理方式不盡相同，甚至並不是所有的應用程式都具備這樣的功能，因此透過 fail2ban 這樣的套件可以讓封鎖的行為擁有一致性以方便管理。fail2ban 支援許多應用程式 (如 ssh, vsftpd, pop 等)，主要利用應用程式所留下的日誌找出可疑的行為，並進行封鎖的行為，封鎖的方式則包含 hosts.deny, iptables, ipfw 等。
fail2ban 屬於單機作業的套件，因此今天的測試環境相當單純，只要一台 Linux 主機即可，我今天準備的是一台 CentOS 6.x 的系統。接下來我們就一步一步地完成今天的目標：

1. 啟用 epel 這個 repository
   以 CentOS 6.x 而言，所需的指令為

   rpm –ivh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-5.noarch.rpm

2. 安裝 fail2ban 的 rpm 套件，指令為

   yum install fail2ban

3. 修改設定檔
   fail2ban 有兩個主要的設定檔，一個是 /etc/fail2ban/fail2ban.conf，用來指定一些基本的設定。在正常的情況下，這些設定並不需要進行修改。至於要指定哪些服務需要加以偵測並封鎖，則是必須透過另外一個設定檔 /etc/fail2ban/jail.conf 。在這次測試的環境中，我們要設定 fail2ban 支援 ssh 與 pure-ftpd 這兩個應用程式。
   1. fail2ban 預設就已經開啟對 ssh 的支援，但是我們仍然需要修改寄發通知的訊息，以提供更為清楚的標示。新增設定檔 /etc/fail2ban/jail.local，輸入下列設定(更新一)。

      [ssh-iptables]
      enabled  = true 
      filter   = sshd 
      action   = iptables[name=SSH, port=ssh, protocol=tcp]
                  sendmail-whois[name=通知信標題, dest=收件者信箱, sender=寄件者信箱] 
      logpath  = /var/log/secure 
      maxretry = 5

   2. 同樣在 /etc/fail2ban/jail.local 加上下列設定

      [pure-ftpd-iptables]
      enabled  = true 
      filter   = pure-ftpd 
      action   = iptables[name=PureFTPD, port=ftp, protocol=tcp]
                  sendmail-whois[name=通知信標題, dest=收信者信箱, sender=寄件者信箱] 
      logpath  = /var/log/messages 
      maxretry = 5

      其中 filter 與 logpath 分別用來指定比對的規則與日誌檔的位置，如果設定錯誤將造成功能的異常。至於 action 參數的 PureFTPD 字串則為 iptables 的規則名稱，可以依據自己的需求自行修改。
   3. 修改 pure-ftpd 的比對規則，也就是 /etc/fail2ban/filter.d/pure-ftpd.conf
      將

      failregex = pure-ftpd(?:\[\d+\])?: (.+?@<HOST>) \[WARNING\] %(__errmsg)s \[.+\]$

      改為

      failregex = pure-ftpd: \(\?@<HOST>\) \[WARNING\] %(__errmsg)s \[.+\]$

4. 設定 fail2ban 開機時自動啟動，指令為

   chkconfig fail2ban on

5. 啟動 fail2ban 的服務，指令為

   service fail2ban start

6. 確認 iptables 的狀態，指令為

   iptables –L –n

   如果看到下列的資訊，表示規則已經生效。

   Chain fail2ban-PureFTPD (1 references) 
   target     prot opt source               destination 
   RETURN     all  --  0.0.0.0/0            0.0.0.0/0
   Chain fail2ban-SSH (1 references) 
   target     prot opt source               destination 
   RETURN     all  --  0.0.0.0/0            0.0.0.0/0

7. 查看 fail2ban 的狀態，指令為
   

   fail2ban-client status

   可以看到類似下列的資訊

   Status 
   |- Number of jail:      2 
   `- Jail list:           pure-ftpd-iptables, ssh-iptables

8. 使用另外一台主機嘗試登入這台主機的 ssh，此時當然要故意打錯密碼。嘗試過後我們可以透過下列指令了解 fail2ban 是否已經偵測到這個錯誤的登入行為。
   

   fail2ban-client status ssh-iptables

   如果看到類似下列的資訊表示 fail2ban 已經正常運作。

   Status for the jail: ssh-iptables 
   |- filter 
   |  |- File list:        /var/log/secure 
   |  |- Currently failed: 1 
   |  `- Total failed:     2 
   `- action    |- Currently banned: 0    |  `- IP list:    `- Total banned:     0

   但是如果所有的數字都為0，表示 fail2ban 並沒有正確地判斷到這個錯誤的登入行為。
   
9. 繼續使用錯誤的密碼登入，直到被封鎖為止。恭喜你，你又完成了另外一個目標。

fail2ban 其實是一個相當容易操作的安全套件，不過如果測試時發現 fail2ban 無法偵測到錯誤的登入行為時，要找出原因還是需要一番功夫。建議可以從下列幾個地方查起：

1. 可以利用下列指令確認 jail.conf 內設定值與 filter 是否正確。
   

   fail2ban-regex /var/log/secure /etc/fail2ban/filter.d/sshd.conf

   或是

   fail2ban-regex /var/log/messages /etc/fail2ban/filter.d/pure-ftpd.conf

2. 將 /etc/fail2ban/jail.conf 內的 backend 參數由 auto 改為 polling，修改後重新啟動 fail2ban 的服務再行測試。
3. 將 /etc/fail2ban/fail2ban.conf 內的 loglevel 由 3 改為 4，修改後重新啟動 fail2ban 的服務再行測試。測試時請注意 /var/log/fail2ban.log 內的相關訊息。

前面提到 fail2ban 屬於單機的封鎖軟體，在管理大量的主機時可能會較為不便。幸好 fail2ban 在設定過後幾乎不太需要額外的管理，所以倒也不致於造成過多的管理負擔。如果還是有所擔心的話，使用集中管控的套件 (如 ossec) 可以簡化許多管理的複雜度。有關 ossec 的介紹，就留待以後再來分享了。

更新一 (2012/07/12)：原先建議各位修改 jail.conf，但是根據原始文件的建議，任何客製化的修改應該是放在 jail.local 這個檔案，而非 jail.conf。jail.local 內的設定檔將會蓋掉 jail.conf 內的預設值。

[資安觀念] 利用封鎖避免密碼遭受暴力破解法(錯誤嘗試)

密碼的選定，一向是一個很兩難的議題。太過簡單的密碼容易被猜到，而太過複雜的密碼也因為難以記憶而逼迫使用者利用各種秘技加以繞過(如自動記憶的功能，甚至是直接把密碼大剌剌地寫在螢幕前的便利貼上)。不過不管如何選擇，密碼本身都難以避免一種技術性很低的破解方式，那就是暴力破解法。只要給予足夠的時間，任何的密碼都可以在嘗試過所有可能組合之後被猜到。面對這類攻擊行為，我們能做的就是讓所有可能的組合範圍盡量龐大(所以要求在密碼當中使用更多的字元和特殊符號)，另外一個應對之策就是減緩嘗試的速度。以減緩嘗試速度來看，許多應用程式會在密碼輸入錯誤之後停頓一段時間(如一秒鐘)才允許下一次的登入嘗試。一秒鐘對於人類來說或許是一個很短的時間，但是對於自動化的攻擊程式來說可就算是天長地久了。至於要停頓多久，那就看應用程式開發人員自己的判斷了，有些可能是固定的時間，有些則可能讓停頓的時間隨著錯誤次數的增加而越來越長。

除了延緩可以再次嘗試登入的時間，更嚴謹的系統甚至會進行封鎖的動作，而封鎖的對象一般是針對帳號或 IP 位址。然而，不管是針對帳號或 IP 位址的封鎖，都無法避免駭客利用這些特點對系統進行阻斷服務攻擊 (Denial of Service, DoS)的可能性。舉例來說，如果應用程式會針對嘗試登入錯誤達三次的帳號進行封鎖，駭客只要故意利用此帳號故意登入錯誤三次，就可以讓這個帳號無法使用。雖然針對帳號或 IP 位址的封鎖，兩者之間並沒有矛盾之處，甚至也可以同時進行，但是在大多數的情況下應用程式僅會針對一個項目予以封鎖。

簡單來看，以帳號形式的封鎖比 IP 形式的封鎖更容易遭受阻斷服務的攻擊，原因在於駭客可以輕易地使用各個帳號進行嘗試登入的動作。相較於帳號，駭客要假冒合法使用者的 IP 位址而使得這些 IP 位址受到封鎖，在技術上的難度就顯得高了許多。封鎖 IP 位址比較大的風險在於如果這是一個經過 NAT 轉換過的 IP 位址，封鎖此一 IP 位址可能就代表了有一大群的電腦因此都同時遭受封鎖。

除了封鎖的對象，封鎖機制還有另外一個必須考量的重點就是封鎖的時間長短。封鎖的時間越長，對駭客而言在進行錯誤嘗試的攻擊時就須花費更多的時間，但是另外一方面也讓阻斷服務攻擊一旦成功時所造成的影響越嚴重。封鎖時間的極致，就是必須由管理者手動解除封鎖，而不是在固定的時間後自動解除。這類系統雖然安全性很高，但是卻會大幅增加管理者的負擔，因此使用上必須格外謹慎。

其次，阻擋的方式亦會決定阻擋的成效。阻擋可以分為本機與網路兩種形式，本機最常見的方式就是透過主機型的防火牆 (例如 iptables)，而在 Linux 下還有 /etc/hosts.deny 也可以用來當做阻擋的機制。至於網路的形式，包含網路型的防火牆以及路由器/交換器的 ACL，都是常見的阻擋方式。在主機上進行阻擋，可以同時應付來自外部與內部的攻擊。而如果利用網路進行封鎖，在應付來自內部的攻擊上可能就會力有未逮。然而對於一個異質環境而言，如何在不同的作業系統上統一管理封鎖的機制，是利用主機進行阻擋時所必須面對的嚴峻挑戰。

談完了封鎖的基本概念，我將在下一篇跟各位分享如何在 CentOS 下利用 fail2ban 這個套件達成封鎖的目的。

[工具介紹] 利用 nagios/icinga 監測 Windows 主機 (使用 winrpe)

Nagios/Icinga 是一套功能相當強大的監測套件，支援許多的監測機制可以用來監測遠端的系統，像是 TCP/UDP 服務、SNMP、甚至是利用 SSH 等方式從遠端進入系統中加以監測。在這些方式中，NRPE (Nagios Remote Plugin Executor) 提供了一個標準化的遠端監控協定。透過 NRPE，我們可以呼叫被監測主機上的程序，用以監測任何可供監測的項目。嚴格來說，透過 SSH 也可以達到相同的目的，但是 NRPE 不但在呼叫上較為方便，對於管控上也較為完整，所以 NRPE 可說是 Nagios/Icinga 用來監測遠端系統不可或缺的一環。因為 NRPE 是一種溝通的協定，所以使用上並沒有作業系統的限制。雖說如此，但是畢竟 Nagios/Icinga 原生在 Linux 的環境下，因此在其他作業系統下的支援當然還是顯得較為不足。
很不幸的是，除非是很特殊的環境，否則多種作業系統的混搭風 (專業的說法是異質環境) 絕對是不可避免的宿命。今天我要跟各位分享的就是如何透過 NRPE 監測 Windows 的作業系統。Windows 下的 NRPE 有幾個不同的套件，像是 NRPE-NT、NSClient++，以及今天我要示範的 winrpe。winrpe 運作於 cygwin，並透過 xinet 提供服務。廢話不多說，就讓我們看一下今天的測試環境並一步步完成目標吧。

測試環境

第一部分：設定被監測主機 (192.168.1.2)

1. 下載 winrpe。
   前往這裡下載 winrpe，我下載的是版本 4.0.0 。
2. 安裝 winpre。
   安裝 winrpe 再簡單不過了，一直按下一步就對了。
3. 設定 xinetd 服務。
   前面提到 winrpe 是透過 xinetd 提供服務，因此我們需要進行相關的設定：
   1. 開啟 "伺服器管理員" => "服務" => "XinetServer"，點選滑鼠右鍵的 "內容"。
      
   2. 將 "啟動類型" 改為 "自動"，設定完成後按下 "確定"。
      
   3. 手動啟動 XinetServer 服務。
      
4. 設定哪些主機 (IP) 可以透過 NRPE 可以對此進行進行 NRPE 的監測。
   有兩種方法可以限制有哪些主機 (IP) 可以對此系統進行 NRPE 的監控，一種方式是使用 Windows 內建的防火牆功能，另外一種方式則是透過 xinetd 的設定檔。這兩種方式並不會互相排斥，甚至我的建議是兩種方式都加以設定，以達到較為嚴格的管控。
1. 開啟 "服務器管理員" => "設定" => "具有進階安全性的 Windows 防火牆" => "輸入規則"。找到名為 Nrpe 的規則，點選滑鼠右鍵"內容"。
2. 開啟 "領域" => "遠端 IP 位址"，點選 "這些 IP 位址" 並加上監測主機的 IP 位址 (如192.168.1.1)。設定完畢後按下"確定"。
3. 修改 xinetd 的設定檔。
   在我的系統下，此設定檔的位置是 C:\Program Files (x86)\ICW\etc\xinetd.d\nrpe，請根據你的環境找出檔案的所在位置。
   將

   # only_from =     <ipaddress1> <ipaddress2>

   改為

   # only_from = 192.168.1.1

4. 在監測主機 (192.168.1.1) 使用下列指令測試 NRPE 的設定。

   /usr/lib64/nagios/plugins/check_nrpe –H 192.168.1.2 –c ‘pdm_disk_c’ –t 30

   如果設定無誤的話，可以看到類似下列訊息
   DISK OK – usage C: 31037.0 MB (1.82% of total 1706686.0 MB)|’disk in use’=31037.0MB; ‘disk usage’=1.82%;90;95; ‘disk total’=1706686.0MB
   但是如果看到下列的訊息，就表示監測主機 (192.168.1.1) 無法與被監測主機 (192.168.1.2) 進行溝通。
   CHECK_NRPE: Error – Could not complete SSL handshake.
5. 修改被監測主機 (192.168.1.2) 上的 nrpe 設定
   在我的系統下此檔案的位置是 C:\Program Files (x86)\ICW\nrpe.cfg，請根據你的環境找出檔案的所在位置。當你需要修改監測的參數或者是加上監測指令時，就必須修改這個檔案。這個檔案修改後，必須重新啟動 XinetServer 這個服務才會生效。

第二部分：設定監測主機 (192.168.1.1)

1. 修改監測主機上的 localhost.cfg
   在 localhost.cfg (/etc/icinga/objects/localhost.cfg) 加入下列設定
   
   
   1. 設定主機資訊

      define host { 
        use windows-server 
        host_name win2008 
        alias win2008 
        address 192.168.1.2 
      }

   2. 設定主機群組

      define hostgroup { 
        hostgroup_name windows-servers; 
        alias Windows Servers; 
        members win2008; 
      }

   3. 設定服務

      define service { 
        use local-service 
        hostgroup_name windows-servers; 
        service description Disk – C: 
        check_command nrpe!pdm_disk_c 
      }

      除了 pdm_disk_c 之外，也可以加上其他的監測項目，像是內建的 pdm_disk_d、pdm_cpuload、pdm_memload、event_all_errors 等。


2. 重新啟動監測主機上的 icinga 服務，指令為

   service icinga restart

進行至此，使用瀏覽器瀏覽 icinga 服務，應該可以就看到這些監測項目了。

嚴格來說，使用 winrpe 與使用 npre 並沒有多大的不同，設定檔 nrpe.cfg 的架構可說是完全一致。不過在使用 winrpe 時，仍有下列幾點須特別注意：

1. winrpe 並不支援 dont_blame_nrpe 這個設定值，所以無法透過監測指令指定相關的參數。也就是說，任何監測參數的指定，都必須透過修改被監測主機 (192.168.1.2) 上的 nrpe.cfg 檔案來達成。
2. winrpe 並不支援 allowed_hosts 這個設定值，取而代之是 xinetd 的存取控制 (請參考前面的步驟)。除此之外，也可以進一步使用 Windows 內建的防火牆限制存取權限。
3. 修改設定檔時 (nrpe.cfg 與 nrpe) 請使用可以辨識 Linux 換行字元的編輯器。如果使用會自動轉換換行字元的編輯器 (如 WordPad )，可能導致格式的錯誤而無法正常地啟動服務。