哪個更安全？白名單還是黑名單？Agent端對監控指標黑白名單的支持

“實際上，agent端指標的白名單和黑名單也是Zabbix培訓中的一個重要主題?！?/p>

——Kaspars Mednis ,?全球培訓師負責人，Zabbix SIA

本文整理自Kaspars 在2020Zabbix中國峰會的演講，ppt獲取鏈接見文末。更多演講視頻可關注官方Bilibili賬號主頁（ID：Zabbix中國）。

目錄

一?為什么需要agent端指標的白名單和黑名單

二 如何保障安全性

三 關于通配符

四 關于功能注釋

五 哪個更安全？白名單還是黑名單？

為什么需要agent端指標的白名單和黑名單

首先，第一個問題是為什么？我們為什么需要agent端指標的白名單和黑名單？

實際上，我們都知道，Zabbix agent主要的功能就是采集監控，但也可以從配置文件、日志文件、密碼文件或任何其他敏感數據源收集到一些敏感信息。正如大家現在所看到的一個簡單示例，通過Zabbix get功能，我們可以對密碼文件的內容實現讀取。我想現在大家心中都會認為這也太不安全了，對吧？這屬于敏感信息。

除此之外，另一個問題是system run[*]命令，system run[*]命令是非常有用、非常強大的命令，它實際上允許你直接在被監視的主機上從Zabbix前端執行任何命令，這也意味著你可以收集很多有用的信息，但這里的關鍵詞是“任何命令”。實際上，有些人可能會使用這些命令執行一些有害代碼。正如大家現在所看到的，在第一個示例中，用戶將嘗試從Web下載一些惡意代碼，然后將嘗試執行，以期獲得根權限或其他權限?；蛘?，在另外一個示例中，用戶想要刪除一些活動痕跡，試圖刪除一些日志文件。這些只是幾個例子，都可以從前端執行。

我是從命令行使用Zabbix get，因為這樣可以更容易的測試。但需要指出的是，如果從前端執行也可以實現同樣的效果。當然，通常Zabbix agent是以非特權帳戶運行的，這就意味著并不是所有這些命令都會成功。但是如果在windows上運行Zabbix，那么Zabbix的運行位置是windows的本地系統。實際上，在這里，幾乎可以運行所有的命令。

如何保障安全性

這就引出了下一個問題，我們如何防止這種情況發生？

1.?Enable Remote Commands參數

在Zabbix5.0發布之前，我們在Zabbix agent配置文件中設置了一個選項，稱為Enable Remote Commands。如果您將此參數設置為零，則遠程命令就會被禁用。因此，有兩個選擇，要么啟用遠程命令，要么完全禁用它們。但是，我們并不能完全阻止任何其他項的Key，這些也有潛在的危險，比如文件內容或其他一些Key。

2.?參數“Allow key”和“Deny key”

而Zabbix 5.0的發布，則給了我們更多的選擇，我們在Zabbix5中添加了兩個新的agent參數“Allow key”和“Deny key”。通過這些agent參數，您可以指定模式，而這些模式實際上是一個通配符表達式。這個模式指定可以在Key名稱和參數中。通過使用“Allow key”和“Deny key”，借助通配符，實際上可以創建白名單或黑名單。并且Zabbix agent能夠支持無限數量的這樣的規則。

注：在這里規則是按照指定的順序自上而下的執行。一旦監控項的Key與任何Allow或Deny規則匹配，則該項將被允許或拒絕。在此之后，規則檢查將停止。

因此，如果您對監控項的Key有兩個規則(如一個允許規則和一個拒絕規則)，則先出現的規則將生效。另一個將會被忽略。通過這張PPT，我們可以清楚地看到其工作流程。

假設你為某個Deny key定義了一些拒絕規則，而Zabbix只是檢查所有規則。所以第一個Allow key與您的模式不匹配，所以Zabbix將轉到下一個。

接下來是將會匹配的Deny key。這意味著您的關鍵字被拒絕，處理停止，反之亦然。如果您設置有Allow key，第一個規則不匹配，但是下一個規則匹配這個Allow key，那么這個項關鍵字就會被允許。即使下面有一些拒絕規則，這些規則也會被忽略。因此，在創建順序時一定要非常小心。

例如，假設我們有一個監控項Key，試圖執行一個命令[cat /proc/stat]，這實際上是一個安全命令，只是從系統中收集一些統計數據，并且你允許它執行。所以你已經定義了，比方說，你定義了三個規則，一個允許規則system run[free] 一個允許規則system run[cat /proc/stat]， 以及拒絕規則system run[*]，將如何處理？

首先，Zabbix將檢查第一個模式，很明顯，[cat /proc/stat]不會匹配[free]。如果模式不匹配，則Zabbix將檢查第二個模式，該參數實際上是匹配的，Key將被允許。

是的，該Deny Key將被完全忽略。但是作為示例，如果你有任何其他命令，在Allow key中沒有指定。那么這些命令將被拒絕。是的，正如我說的那樣，這是由于順序問題產生的一個典型錯誤。在綠色框中您可以看到正確的順序，您已經允許了一些操作，可能是使用/var/log/myapp/*或/var/log/mydb/*文件指定了一些通配符，這是可以的。

而在底部，您已經拒絕了對任何其他文件的任何其他操作，是的，所以這意味著agent只能訪問位于/var/log/myapp/或/var/log/mydb/中的文件。而底部您可以看到錯誤的順序，因此您正在嘗試允許一些運行命令，如ipcs -l或free。但是在一開始，您有一個拒絕Deny Key system run[*]運行，通配符被拒絕，實際上這會拒絕任何system run[*]命令，您所有的Allow key規則都不會有任何效果。所以一定要記住，它們從上到下處理和執行的。

關于通配符

讓我們來討論一下通配符，我將向大家介紹一些一般通配符規則，Zabbix使用的是通配符，它能夠匹配特定位置上的任意數量的字符，既可以在關鍵字名稱中使用，也可以在參數中使用。稍后我會提到這個。

首先，如果參數在ALLOW KEY或DENY KEY中指定，則必須用方括號括起來。如system.run[*只帶左方括號，或vfs.file*.txt]只帶右括號，這都是不完整的，都會被認為是錯誤的句法規則。如果您的Zabbix agent有這樣的參數，它就會崩潰，也不會啟動。像vfs.file后跟圓點，后跟任意選項，后跟任意參數是正確的句法規則。

模式示例，這里要特別注意，盡管很簡單，因為這些只是通配符，但它們確實有點棘手，因為所有vfs.file通配符和參數中的通配符將匹配以vfs.file開頭的任何Key和任何參數。大家可以看到，它們將匹配vfs.file.contents[/etc/passwd]，但它不會匹配vfs.file.contents。大家可能覺得這沒必要大驚小怪，因為沒有任何參數的vfs.file內容Key是沒用的，是這樣嗎？但是看看最后一個，看看system.*，它將匹配任何不帶參數的system開頭的key。因此它將匹配system.cpu.load，因此使用這種語法，您可以允許或拒絕system.cpu.load，但它不會與system.run.[*]命令匹配

system.run[*]命令需要使用語法system.*[*]，只有這樣system.run[*]命令才會被拒絕。

因此，我強烈建議，當您在創建這樣的規則時，查看文檔和監控項Key，它們可能有參數，也可能沒有參數，創建您的規則，最好進行一定的測試。否則，您可能會得到一些不愿看到的結果，比如您會認為system.通配符是安全的，但實際上這與任何system.run[*]的通配符都不匹配。

下面是一個小示例，您正在拒絕vfs.file.*，如果您試圖獲取vfs.file內容，就不會起作用。但是，如果您指定一些內容，如您所見，您將獲得這些內容。所以這個例子實際上是一個很糟糕的例子。是的，這是配置錯誤。你認為你拒絕了vfs.file.*監控項Key，但實際上您只是拒絕了沒有參數的vfs.file監控項Key，這是無用的。要使其按預期工作，您需要指定方括號和另一個通配符作為參數，只有這樣，這些內容才不會被其他人查看。

再舉一個例子，比方說你在拒絕system.cpu.load[*]，比方說你的組織系統的system.cpu.load是秘密。并且您已經拒絕了system.cpu.load，并且您已經測試了system.cpu.load，平均數據不會被報告。但是如果有人在沒有任何參數的情況下執行命令，這實際上是允許的。那么這個人就會拿到結果。是的，因此在此場景中，您還需要阻止帶參數和不帶參數的命令，您需要指定兩行。其中，一行就是上面所說的，另一行是system.cpu.load。否則將授予訪問權限。

關于功能注釋

我來向大家介紹一些關于這個功能注釋的內容。

首先，關于配置，您可能知道，對于自動注冊，我們擁有特定的參數，如主機名項、主機元數據項或主機接口項，您還可以在其中指定項關鍵字。因此，那些Allow或Deny key不會影響這些參數。您可以拒絕某些系統運行命令，但您仍然可以在主機名項中使用它，它依舊可以起作用。接下來，如果客戶端配置中不允許使用特定的監控項關鍵字，則會發生以下情況。

首先，該項將被報告為不受支持的，因此Zabbix不會告訴您該項被拒絕，而只是像任何其他不受支持的監控項一樣不受支持。這樣就不會給攻擊者任何線索。是的，也許有人會攻擊你的系統，但他到頭來依舊會毫無頭緒。它被拒絕了或者只是文件不見了什么的?？蛻舳巳罩局胁粫i定任何內容。是的，所以被拒絕的命令只是靜默地刪除，沒有任何日志條目。即使您將日志級別提高到級別5，我們也可以說仍然沒有條目。

正如大家所看到的這樣，Zabbix agent支持包含文件。是的，您可以包含在include參數中指定的多個配置文件，不過要非常小心。因為不應該假定包含文件的特定順序，這意味著包含文件只是以隨機順序包含。

如果您有Allow key或Deny key列表，那么重要的一件事就是記住它們的順序。如果您不知道包含規則的包含文件的順序，那么您實際上就無法控制這些規則的執行。所以記住順序十分重要。

命令行實用程序，所以您當然可以嘗試項關鍵字，也可以從命令行嘗試，但是如果它們被拒絕，您實際上都會得到相同的結果。Zabbix agent將只報告不支持的關鍵字，Zabbix get將顯示不支持的未知指標。

如果您嘗試使用Zabbix agent打印所有命令，使用-p選項打印(-print (-p))，但是，它也不會顯示這些命令，因此它們完全隱藏起來，就像從未存在過一樣。

“哪個更安全？白名單還是黑名單？”

最后，我需要向大家提問以下問題，那就是“哪個更安全？白名單還是黑名單？”

假設您有Deny Key，它拒絕了vsf.file.contents[/etc/passwd]，您看不到通配符，在這里，所有內容都是以純文本指定，只需阻止對/etc/passwd 的訪問，您就可以從前端從Zabbix get測試此項關鍵字。是的，大家可以看到，它確實被屏蔽了。所以沒有辦法獲取/etc/passwd ，但真的完全沒有辦法獲取到/etc/passwd 嗎？如果您足夠聰明，你可以寫這個。假設使用Unix 路徑并在目錄中來回移動，您可以指定這實際上是某個文件，這是/tmp，然后返回，然后轉到/etc/zabbix，然后返回，然后轉到passwd，然后您將獲得文件內容。

因此，這意味著即使您指定了一些拒絕規則，它們也可能不會被破壞，但是可能有一些解決方法可以繞過它們。因此，在這種情況下，白名單會更安全。是的，你可以阻止任何文件內容，只允許幾個文件的內容，這當然會更安全。不過我個人不知道如何繞過這個問題，但對于大家而言，任何皆有可能，不是嗎？

最后感謝大家的參與和傾聽。這是一個簡短的關于Zabbix5.0的白名單黑名單的演示。謝謝大家！

PPT網盤鏈接: https://pan.baidu.com/s/1ZgQjzDc4sEUBKiAKSnmFSg 提取碼: 97ys

“實際上，agent端指標的白名單和黑名單也是Zabbix培訓中的一個重要主題?！?/p>

——Kaspars Mednis ,?全球培訓師負責人，Zabbix SIA

本文整理自Kaspars 在2020Zabbix中國峰會的演講，ppt獲取鏈接見文末。更多演講視頻可關注官方Bilibili賬號主頁（ID：Zabbix中國）。

目錄

一?為什么需要agent端指標的白名單和黑名單

二 如何保障安全性

三 關于通配符

四 關于功能注釋

五 哪個更安全？白名單還是黑名單？

為什么需要agent端指標的白名單和黑名單

首先，第一個問題是為什么？我們為什么需要agent端指標的白名單和黑名單？

實際上，我們都知道，Zabbix agent主要的功能就是采集監控，但也可以從配置文件、日志文件、密碼文件或任何其他敏感數據源收集到一些敏感信息。正如大家現在所看到的一個簡單示例，通過Zabbix get功能，我們可以對密碼文件的內容實現讀取。我想現在大家心中都會認為這也太不安全了，對吧？這屬于敏感信息。

除此之外，另一個問題是system run[*]命令，system run[*]命令是非常有用、非常強大的命令，它實際上允許你直接在被監視的主機上從Zabbix前端執行任何命令，這也意味著你可以收集很多有用的信息，但這里的關鍵詞是“任何命令”。實際上，有些人可能會使用這些命令執行一些有害代碼。正如大家現在所看到的，在第一個示例中，用戶將嘗試從Web下載一些惡意代碼，然后將嘗試執行，以期獲得根權限或其他權限?；蛘?，在另外一個示例中，用戶想要刪除一些活動痕跡，試圖刪除一些日志文件。這些只是幾個例子，都可以從前端執行。

我是從命令行使用Zabbix get，因為這樣可以更容易的測試。但需要指出的是，如果從前端執行也可以實現同樣的效果。當然，通常Zabbix agent是以非特權帳戶運行的，這就意味著并不是所有這些命令都會成功。但是如果在windows上運行Zabbix，那么Zabbix的運行位置是windows的本地系統。實際上，在這里，幾乎可以運行所有的命令。

如何保障安全性

這就引出了下一個問題，我們如何防止這種情況發生？

1.?Enable Remote Commands參數

在Zabbix5.0發布之前，我們在Zabbix agent配置文件中設置了一個選項，稱為Enable Remote Commands。如果您將此參數設置為零，則遠程命令就會被禁用。因此，有兩個選擇，要么啟用遠程命令，要么完全禁用它們。但是，我們并不能完全阻止任何其他項的Key，這些也有潛在的危險，比如文件內容或其他一些Key。

2.?參數“Allow key”和“Deny key”

而Zabbix 5.0的發布，則給了我們更多的選擇，我們在Zabbix5中添加了兩個新的agent參數“Allow key”和“Deny key”。通過這些agent參數，您可以指定模式，而這些模式實際上是一個通配符表達式。這個模式指定可以在Key名稱和參數中。通過使用“Allow key”和“Deny key”，借助通配符，實際上可以創建白名單或黑名單。并且Zabbix agent能夠支持無限數量的這樣的規則。

注：在這里規則是按照指定的順序自上而下的執行。一旦監控項的Key與任何Allow或Deny規則匹配，則該項將被允許或拒絕。在此之后，規則檢查將停止。

因此，如果您對監控項的Key有兩個規則(如一個允許規則和一個拒絕規則)，則先出現的規則將生效。另一個將會被忽略。通過這張PPT，我們可以清楚地看到其工作流程。

假設你為某個Deny key定義了一些拒絕規則，而Zabbix只是檢查所有規則。所以第一個Allow key與您的模式不匹配，所以Zabbix將轉到下一個。

接下來是將會匹配的Deny key。這意味著您的關鍵字被拒絕，處理停止，反之亦然。如果您設置有Allow key，第一個規則不匹配，但是下一個規則匹配這個Allow key，那么這個項關鍵字就會被允許。即使下面有一些拒絕規則，這些規則也會被忽略。因此，在創建順序時一定要非常小心。

例如，假設我們有一個監控項Key，試圖執行一個命令[cat /proc/stat]，這實際上是一個安全命令，只是從系統中收集一些統計數據，并且你允許它執行。所以你已經定義了，比方說，你定義了三個規則，一個允許規則system run[free] 一個允許規則system run[cat /proc/stat]， 以及拒絕規則system run[*]，將如何處理？

首先，Zabbix將檢查第一個模式，很明顯，[cat /proc/stat]不會匹配[free]。如果模式不匹配，則Zabbix將檢查第二個模式，該參數實際上是匹配的，Key將被允許。

是的，該Deny Key將被完全忽略。但是作為示例，如果你有任何其他命令，在Allow key中沒有指定。那么這些命令將被拒絕。是的，正如我說的那樣，這是由于順序問題產生的一個典型錯誤。在綠色框中您可以看到正確的順序，您已經允許了一些操作，可能是使用/var/log/myapp/*或/var/log/mydb/*文件指定了一些通配符，這是可以的。

而在底部，您已經拒絕了對任何其他文件的任何其他操作，是的，所以這意味著agent只能訪問位于/var/log/myapp/或/var/log/mydb/中的文件。而底部您可以看到錯誤的順序，因此您正在嘗試允許一些運行命令，如ipcs -l或free。但是在一開始，您有一個拒絕Deny Key system run[*]運行，通配符被拒絕，實際上這會拒絕任何system run[*]命令，您所有的Allow key規則都不會有任何效果。所以一定要記住，它們從上到下處理和執行的。

關于通配符

讓我們來討論一下通配符，我將向大家介紹一些一般通配符規則，Zabbix使用的是通配符，它能夠匹配特定位置上的任意數量的字符，既可以在關鍵字名稱中使用，也可以在參數中使用。稍后我會提到這個。

首先，如果參數在ALLOW KEY或DENY KEY中指定，則必須用方括號括起來。如system.run[*只帶左方括號，或vfs.file*.txt]只帶右括號，這都是不完整的，都會被認為是錯誤的句法規則。如果您的Zabbix agent有這樣的參數，它就會崩潰，也不會啟動。像vfs.file后跟圓點，后跟任意選項，后跟任意參數是正確的句法規則。

模式示例，這里要特別注意，盡管很簡單，因為這些只是通配符，但它們確實有點棘手，因為所有vfs.file通配符和參數中的通配符將匹配以vfs.file開頭的任何Key和任何參數。大家可以看到，它們將匹配vfs.file.contents[/etc/passwd]，但它不會匹配vfs.file.contents。大家可能覺得這沒必要大驚小怪，因為沒有任何參數的vfs.file內容Key是沒用的，是這樣嗎？但是看看最后一個，看看system.*，它將匹配任何不帶參數的system開頭的key。因此它將匹配system.cpu.load，因此使用這種語法，您可以允許或拒絕system.cpu.load，但它不會與system.run.[*]命令匹配

system.run[*]命令需要使用語法system.*[*]，只有這樣system.run[*]命令才會被拒絕。

因此，我強烈建議，當您在創建這樣的規則時，查看文檔和監控項Key，它們可能有參數，也可能沒有參數，創建您的規則，最好進行一定的測試。否則，您可能會得到一些不愿看到的結果，比如您會認為system.通配符是安全的，但實際上這與任何system.run[*]的通配符都不匹配。

下面是一個小示例，您正在拒絕vfs.file.*，如果您試圖獲取vfs.file內容，就不會起作用。但是，如果您指定一些內容，如您所見，您將獲得這些內容。所以這個例子實際上是一個很糟糕的例子。是的，這是配置錯誤。你認為你拒絕了vfs.file.*監控項Key，但實際上您只是拒絕了沒有參數的vfs.file監控項Key，這是無用的。要使其按預期工作，您需要指定方括號和另一個通配符作為參數，只有這樣，這些內容才不會被其他人查看。

再舉一個例子，比方說你在拒絕system.cpu.load[*]，比方說你的組織系統的system.cpu.load是秘密。并且您已經拒絕了system.cpu.load，并且您已經測試了system.cpu.load，平均數據不會被報告。但是如果有人在沒有任何參數的情況下執行命令，這實際上是允許的。那么這個人就會拿到結果。是的，因此在此場景中，您還需要阻止帶參數和不帶參數的命令，您需要指定兩行。其中，一行就是上面所說的，另一行是system.cpu.load。否則將授予訪問權限。

關于功能注釋

我來向大家介紹一些關于這個功能注釋的內容。

首先，關于配置，您可能知道，對于自動注冊，我們擁有特定的參數，如主機名項、主機元數據項或主機接口項，您還可以在其中指定項關鍵字。因此，那些Allow或Deny key不會影響這些參數。您可以拒絕某些系統運行命令，但您仍然可以在主機名項中使用它，它依舊可以起作用。接下來，如果客戶端配置中不允許使用特定的監控項關鍵字，則會發生以下情況。

首先，該項將被報告為不受支持的，因此Zabbix不會告訴您該項被拒絕，而只是像任何其他不受支持的監控項一樣不受支持。這樣就不會給攻擊者任何線索。是的，也許有人會攻擊你的系統，但他到頭來依舊會毫無頭緒。它被拒絕了或者只是文件不見了什么的?？蛻舳巳罩局胁粫i定任何內容。是的，所以被拒絕的命令只是靜默地刪除，沒有任何日志條目。即使您將日志級別提高到級別5，我們也可以說仍然沒有條目。

正如大家所看到的這樣，Zabbix agent支持包含文件。是的，您可以包含在include參數中指定的多個配置文件，不過要非常小心。因為不應該假定包含文件的特定順序，這意味著包含文件只是以隨機順序包含。

如果您有Allow key或Deny key列表，那么重要的一件事就是記住它們的順序。如果您不知道包含規則的包含文件的順序，那么您實際上就無法控制這些規則的執行。所以記住順序十分重要。

命令行實用程序，所以您當然可以嘗試項關鍵字，也可以從命令行嘗試，但是如果它們被拒絕，您實際上都會得到相同的結果。Zabbix agent將只報告不支持的關鍵字，Zabbix get將顯示不支持的未知指標。

如果您嘗試使用Zabbix agent打印所有命令，使用-p選項打印(-print (-p))，但是，它也不會顯示這些命令，因此它們完全隱藏起來，就像從未存在過一樣。

“哪個更安全？白名單還是黑名單？”

最后，我需要向大家提問以下問題，那就是“哪個更安全？白名單還是黑名單？”

假設您有Deny Key，它拒絕了vsf.file.contents[/etc/passwd]，您看不到通配符，在這里，所有內容都是以純文本指定，只需阻止對/etc/passwd 的訪問，您就可以從前端從Zabbix get測試此項關鍵字。是的，大家可以看到，它確實被屏蔽了。所以沒有辦法獲取/etc/passwd ，但真的完全沒有辦法獲取到/etc/passwd 嗎？如果您足夠聰明，你可以寫這個。假設使用Unix 路徑并在目錄中來回移動，您可以指定這實際上是某個文件，這是/tmp，然后返回，然后轉到/etc/zabbix，然后返回，然后轉到passwd，然后您將獲得文件內容。

因此，這意味著即使您指定了一些拒絕規則，它們也可能不會被破壞，但是可能有一些解決方法可以繞過它們。因此，在這種情況下，白名單會更安全。是的，你可以阻止任何文件內容，只允許幾個文件的內容，這當然會更安全。不過我個人不知道如何繞過這個問題，但對于大家而言，任何皆有可能，不是嗎？

最后感謝大家的參與和傾聽。這是一個簡短的關于Zabbix5.0的白名單黑名單的演示。謝謝大家！

PPT網盤鏈接: https://pan.baidu.com/s/1ZgQjzDc4sEUBKiAKSnmFSg 提取碼: 97ys

云安全

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。