深入淺出Zabbix 3.0 -- 第十九章 數(shù)據(jù)加密通信

第十九章 數(shù)據(jù)加密通信

Zabbix 3.0中非常重要的一個特性就是支持對Zabbixserver、Zabbix proxy、Zabbix agent、zabbix_sender和zabbix_get之間的通信進行加密，支持Certificate-based（基于證書）和pre-shared key-based（基于預(yù)共享秘鑰）的加密，不再像早期版本那樣需要額外的解決方案。

Zabbix 3.0中加密是獨立組件，作為配置選項進行配置時非常靈活，可以針對不同的hosts設(shè)置不同的加密方式。例如有些proxy 和agents配置使用Certificate-based加密和server之間的通信，有些使用pre-sharedkey-based加密，而另外一些沒有配置加密。如下圖19-1所示。

?

? ? ? ? ? ? ? ? ? ? ? ? ? ??

圖 19-1

?

19.1編譯Zabbix支持加密

Zabbix使用Transport LayerSecurity (TLS) protocol v1.2進行加密，為了讓Zabbix支持加密功能，在源碼編譯安裝時必須要鏈接到下面三個加密庫中的其中一個。

• mbed TLS：早期也叫PolarSSL，目前僅支持1.3.x版本。注意不支持2.x版本。

• GnuTLS：支持v3.1.18及更高的版本。

• OpenSSL：支持v1.0.1及更高的版本。

根據(jù)你的選擇，configure腳本可以使用下面的某個選項：

• --with-mbedtls[=DIR]

• --with-gnutls[=DIR]

• --with-openssl[=DIR]

例如：

# ./configure--enable-server --enable-agent --with-mysql --enable-ipv6 --with-net-snmp--with-libcurl --with-libxml2 --with-openssl

在編譯安裝Zabbix的不同組件時可以使用不同的加密庫，例如server使用OpenSSL，agent使用GnuTLS。建議使用OpenSSL，在實際測試中OpenSSL是最快的，接下來是GnuTLS。

如果你使用安裝包安裝Zabbix組件時，默認已經(jīng)支持加密功能。你可以通過查看日志文件確定Zabbix安裝的功能特性。例如下面是Zabbixserver啟動時顯示的特性列表。

# vi/var/log/zabbix/zabbix_server.log

? 1065:20150817:103017.520****** Enabled features ******

? 1065:20150817:103017.520SNMP monitoring:?????? ????YES

? 1065:20150817:103017.520IPMI monitoring:?????????? YES

? 1065:20150817:103017.520 Webmonitoring:?????????? YES

? 1065:20150817:103017.520VMware monitoring:??????? YES

? 1065:20150817:103017.520SMTP authentication:??????? YES

? 1065:20150817:103017.520Jabber notifications:???????? YES

? 1065:20150817:103017.520 EzTexting notifications:?????? YES

? 1065:20150817:103017.520ODBC:???????????????????? YES

? 1065:20150817:103017.520SSH2 support:?????????????? YES

? 1065:20150817:103017.520IPv6 support:?????????????? YES

? 1065:20150817:103017.520 TLSsupport:??????????????? YES

? 1065:20150817:103017.520******************************

?

近日完成《深入淺出?zabbix 4.0》視頻教程的錄制并正式發(fā)布，該教程基于 zabbix 4.2 ，對Zabbix進行全面講解。歡迎大家圍觀。課程鏈接：https://edu.51cto.com/sd/ce000?

19.2 pre-shared keys加密

Zabbix中使用PSK（pre-shared key）加密時，需要提供標識符（PSKidentity）和加密字符串（PSK string）。PSK identity是一個非空的UTF-8字符串，例如PSK ID 001 zabbix agent，在這里僅僅作為一個特定PSK的名稱，方便Zabbix中各組件的引用。由于PSK identity在網(wǎng)絡(luò)中是明文傳輸，因此在名稱中不要涉及到敏感信息。PSK string是由十六進制組成的字符串，例如e560cb0d918d26d31b4f642181f5f570ad89a390931102e5391d08327ba434e9。

19.2.1 長度限制

在Zabbix中使用PSK加密時，對PSK identity和PSK string長度是有限制的。在Zabbix前端頁面中配置PSK identity的長度可以達到128個字符，PSK string的長度可以達到2048個bit，但也要看使用的加密庫的限制。如果配置的字符串長度超過限制會導致Zabbix各組件之間通信失敗。

例如Zabbix server使用PSK連接到agent之前，server會在數(shù)據(jù)庫中查找agent配置的PSK identity和PSK string，當收到agent配置的PSK identity和PSK string后進行比較，如果雙方具有相同的PSK identity和PSK string時將成功連接。

長度限制的參數(shù)如下表19-1所示。

表 19-1

19.2.2 PSK生成

在CentOS中可以使用不同的工具生成PSK，下面就以生成一個256-bit（32字節(jié)）PSK為例來看一下。

• 使用OpenSSL

# openssl rand -hex 32

3e2b2ef85c2ad0af3410c9a495fe77d0a8741c2f1243c2af73a2e17623f70098

• 使用GnuTLS

# yum install gnutls-utils

# psktool -u psk_identity -p mypsk.psk -s 32

Generating arandom key for user 'psk_identity'

Key stored to mypsk.psk

# cat mypsk.psk ??psk_identity:9b8eafedfaae00cece62e85d5f4792c7d9c9bcc851b23216a1d300311cc4f7cb

使用psktool工具時會生成一個文件，格式為pskidentity:psk string，在Zabbix中使用該文件時需要把psk identity:刪除，只保留psk string。

19.2.3 配置實例

19.2.3.1 配置server和agent之間使用PSK

配置步驟：

1、? 在agnet主機中，將PSK string保存到一個文件中。例如 /etc/zabbix/zabbix_agentd.psk。

# vi /etc/zabbix/zabbix_agentd.psk

3e2b2ef85c2ad0af3410c9a495fe77d0a8741c2f1243c2af73a2e17623f70098

2、? 設(shè)置zabbix_agentd.psk文件的訪問權(quán)限。

# chown zabbix:zabbix /etc/zabbix/zabbix_agentd.psk

# chmod 644 /etc/zabbix/zabbix_agentd.psk

3、? 編輯zabbix_agentd.conf配置文件。

# vi /etc/zabbix/zabbix_agentd.conf

TLSConnect=psk

TLSAccept=psk

TLSPSKFile=/etc/zabbix/zabbix_agentd.psk

TLSPSKIdentity=PSKAgent

如果agnet類型為active（主動式）agent，那么agent將連接到server并接收來自server和zabbix_get使用PSK加密的連接，PSK identity為PSK Agent。

4、? 重啟agent，使用zabbix_get進行測試。

# zabbix_get -s 127.0.0.1 -k"system.cpu.load[all,avg1]" --tls-connect=psk? \

??????????? --tls-psk-identity="PSK Agent" --tls-psk-file=/etc/zabbix/zabbix_agentd.psk

5、? 在Zabbix前端頁面中配置加密，在Configuration--> Hosts頁面中點擊需要配置的主機名稱，進入主機配置頁面的Encryption標簽中進行設(shè)置。如下圖19-2所示。

?

圖 19-2

在主機列表中AGENT ENCRYPTION列中可以很清楚的看到當前使用的加密方式，如下圖19-3所示。

圖 19-3

19.2.3.2 配置server和active proxy之間使用PSK

配置步驟：

1、? 在proxy主機中，將PSK string保存到一個文件中。例如 /etc/zabbix/zabbix_proxy.psk。

# vi /etc/zabbix/zabbix_proxy.psk

3e2b2ef85c2ad0af3410c9a495fe77d0a8741c2f1243c2af73a2e17623f70098

2、? 設(shè)置zabbix_proxy.psk文件的訪問權(quán)限。

# chown zabbix:zabbix /etc/zabbix/zabbix_proxy.psk

# chmod 644 /etc/zabbix/zabbix_proxy.psk

3、? 編輯zabbix_proxy.conf配置文件。

# vi /etc/zabbix/zabbix_proxy.conf

TLSConnect=psk

TLSPSKFile=/etc/zabbix/zabbix_proxy.psk

TLSPSKIdentity=PSKProxy

4、? 重啟proxy，Proxy將使用PSK加密連接到server，PSK identity為PSK Proxy。

5、? 在Zabbix前端頁面中配置加密，在Administration--> Proxies頁面中點擊需要配置的proxy名稱，進入proxy配置頁面的Encryption標簽中進行設(shè)置。如下圖19-4所示。

圖 19-4

檢查Zabbix server和proxy的日志文件，出現(xiàn)下面類似的信息說明配置有問題。

# tail -f /var/log/zabbix/zabbix_server.log

2124:20160823:122631.486cannot parse host availability data from active proxy at"192.168.10.116": connection of type "unencrypted" is notallowed for proxy "Zabbix proxy"

# tail -f /var/log/zabbix/zabbix_proxy.log

2558:20160823:122630.484cannot send history data to server at "192.168.10.107": connection oftype "unencrypted" is not allowed for proxy "Zabbix proxy"

?

Passive（被動式）proxy的設(shè)置過程和主動式proxy的類似，唯一不同的是在proxy的配置文件中設(shè)置了TLSAccept=psk，并在Zabbix前端頁面中設(shè)置Connections to proxy。

19.3 Certificate-based 加密

Zabbix可以使用一個公共的或內(nèi)部證書頒發(fā)機構(gòu)簽名的PEM格式的RSA證書，證書的驗證依賴一個預(yù)先配置的CA證書。Zabbix不支持自簽名的證書，必須是CA頒發(fā)的證書。每個Zabbix組件只能配置一個證書。

利用OpenSSL強大的命令行工具，我們可以生成和創(chuàng)建Zabbix中配置證書加密需要的文件，包括頂級自簽名的根CA證書文件、Zabbix組件私鑰（private key）文件及簽署的Zabbix組件證書或證書鏈（certificatechain）文件。

證書的內(nèi)容包括：CA的信息、公鑰用戶的信息、公鑰、CA的簽字和有效期等等。證書的格式和驗證方法普遍遵循X.509國際標準。

CA也擁有一個證書（內(nèi)含公鑰）和私鑰。用戶通過驗證CA的簽字從而信任證書，任何人都可以得到CA的證書（內(nèi)含公鑰），用以驗證它所簽發(fā)的證書。因此Zabbixserver必須能夠訪問到頂級自簽名的根CA證書文件。如果你使用多個來自不同根CAs的證書時，可以將它們放在同一個文件中，例如下面的文件/etc/zabbix/zabbix_root_ca.cert所示。

# cat /etc/zabbix/zabbix_root_ca.cert

Certificate:

???Data:

???????Version: 3 (0x2)

???????Serial Number: 1 (0x1)

???Signature Algorithm: sha1WithRSAEncryption

???????Issuer: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Root1CA

???????????...

???????Subject: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Root1CA

???????Subject Public Key Info:

???????????Public Key Algorithm: rsaEncryption

??????????????? Public-Key: (2048 bit)

???????????...

???????X509v3 extensions:

???????????X509v3 Key Usage: critical

??????????????? Certificate Sign, CRL Sign

???????????X509v3 Basic Constraints: critical

??????????????? CA:TRUE

???????????...

-----BEGIN CERTIFICATE-----

MIID2jCCAsKgAwIBAgIBATANBgkqhkiG9w0BAQUFADB+MRMwEQYKCZImiZPyLGQB

....

9wEzdN8uTrqoyU78gi12npLj08LegRKjb5hFTVmO

-----END CERTIFICATE-----

Certificate:

???Data:

???????Version: 3 (0x2)

???????Serial Number: 1 (0x1)

???Signature Algorithm: sha1WithRSAEncryption

???????Issuer: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Root2CA

???????????...

???????Subject: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Root2CA

???????Subject Public Key Info:

???????????Public Key Algorithm: rsaEncryption

??????????????? Public-Key: (2048 bit)

???????????....

???????X509v3 extensions:

???????????X509v3 Key Usage: critical

??????????????? Certificate Sign, CRL Sign

???????????X509v3 Basic Constraints: critical

??????????????? CA:TRUE

???????????....??????

-----BEGIN CERTIFICATE-----

MIID3DCCAsSgAwIBAgIBATANBgkqhkiG9w0BAQUFADB/MRMwEQYKCZImiZPyLGQB

...

vdGNYoSfvu41GQAR5Vj5FnRJRzv5XQOZ3B6894GY1zY=

-----END CERTIFICATE-----

CA的嚴格層次結(jié)構(gòu)可以描繪為一棵倒置的樹，在這棵倒置的樹上，根代表一個對整個PKI域內(nèi)的所有實體都具有特別意義的CA，通常被稱作根CA，把它作為信任的根或稱“信任錨”。在根CA的下面是零層或多層的中間CA，因為是屬于根的，也稱作子CA，子CA可作為中間節(jié)點，再伸出分支，最后是樹的葉子，被稱作終端實體或稱為終端用戶。

證書鏈由兩個環(huán)節(jié)組成：信任錨環(huán)節(jié)（CA證書）和已簽名證書環(huán)節(jié)。自我簽名的證書僅有一個環(huán)節(jié)的長度，信任錨環(huán)節(jié)就是已簽名證書本身。

證書鏈可以擁有任意環(huán)節(jié)的長度。所以在三節(jié)的證書鏈中，信任錨證書CA環(huán)節(jié)可以對中間證書簽名，中間證書的擁有者可以用自己的私鑰對另一個證書簽名。 證書鏈是CA證書發(fā)出的證書序列，最終以根CA證書結(jié)束。證書最初生成時是一個自簽名證書，自簽名證書是簽發(fā)機構(gòu)名（Issuer）和證書用戶名（Subjet）相同的證書。自簽名證書是證書鏈中的最后一個證書。證書鏈中的每個證書都需要使用鏈中的前一個證書的公鑰進行驗證，直到自簽名的根證書。

證書鏈文件如下面的例子所示。

# cat /etc/zabbix/zabbix_server.cert

Certificate:

???Data:

???????Version: 3 (0x2)

???????Serial Number: 1 (0x1)

???Signature Algorithm: sha1WithRSAEncryption

???????Issuer: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group,CN=Signing CA

???????...

???????Subject: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group,CN=Zabbix server

???????Subject Public Key Info:

???????????Public Key Algorithm: rsaEncryption

??????????????? Public-Key: (2048 bit)

??????????????? ...

???????X509v3 extensions:

???????????X509v3 Key Usage: critical

??????????????? Digital Signature, KeyEncipherment

???????????X509v3 Basic Constraints:

??????????????? CA:FALSE

???????????...

-----BEGIN CERTIFICATE-----

MIIECDCCAvCgAwIBAgIBATANBgkqhkiG9w0BAQUFADCBgTETMBEGCgmSJomT8ixk

...

h02u1GHiy46GI+xfR3LsPwFKlkTaaLaL/6aaoQ==

-----END CERTIFICATE-----

Certificate:

???Data:

???????Version: 3 (0x2)

???????Serial Number: 2 (0x2)

???Signature Algorithm: sha1WithRSAEncryption

???????Issuer: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Root1CA

?? ?????...

???????Subject: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group,CN=Signing CA

???????Subject Public Key Info:

???????????Public Key Algorithm: rsaEncryption

??????????????? Public-Key: (2048 bit)

???????????...

???????X509v3 extensions:

???????????X509v3 Key Usage: critical

??????????????? Certificate Sign, CRL Sign

???????????X509v3 Basic Constraints: critical

??????????????? CA:TRUE, pathlen:0

???????...

-----BEGIN CERTIFICATE-----

MIID4TCCAsmgAwIBAgIBAjANBgkqhkiG9w0BAQUFADB+MRMwEQYKCZImiZPyLGQB

...

dyCeWnvL7u5sd6ffo8iRny0QzbHKmQt/wUtcVIvWXdMIFJM0Hw==

-----END CERTIFICATE-----

Zabbix組件私鑰（private key）應(yīng)單獨保存到一個文件，例如下面的文件所示。

# cat /etc/zabbix/ zabbix_server.key

-----BEGIN PRIVATE KEY-----

MIIEwAIBADANBgkqhkiG9w0BAQEFAASCBKowggSmAgEAAoIBAQC9tIXIJoVnNXDl

...

IJLkhbybBYEf47MLhffWa7XvZTY=

-----END PRIVATE KEY-----

19.3.5 證書加密的一些限制

當Zabbix server、proxy或agent之間建立TLS連接時，相互之間會對證書進行檢查，如果雙方證書都是由同一個信任的CA頒發(fā)的，就會認為是有效合法的，對證書的有效期和其他一些參數(shù)檢查通過后，建立連接開始通信。在最簡單的場景中不檢查證書的Issuer和Subject，但這樣做會有風險，持有同一個信任的CA頒發(fā)的證書的人可以冒充別人。為了提高安全性，我們可以在Zabbix proxy或agent中配置特定證書的Issuer和Subject，只允許匹配的證書。

例如，在proxy配置文件中指定Issuer和Subject：

TLSServerCertIssuer=CN=zabbix ca root,OU=IT Dept,O=MyCompany,ST=Beijing,C=CN

TLSServerCertSubject=CN=zabbix server,OU=IT Dept,O=MyCompany,ST=Beijing,C=CN

當完成上面的配置后，active（主動式）proxy不會和證書中Issuer或Subject不同的Zabbix server建立連接。Passive（被動式）proxy不會響應(yīng)來自server的請求。

zabbix_get和zabbix_sender工具也可以在命令行中使用Issuer和Subject。

Zabbix中進行Issuer和Subject字符串匹配時需要注意：

• Issuer和Subject字符串時單獨檢查的，兩者都是可選的。

• 允許使用UTF-8字符。

• 未指定字符串時意味著可以接受任意的字符串。

• 字符串比較時必須完全相同才認為匹配成功。

• 不支持通配符和正則表達式的匹配。

• 只實現(xiàn)了RFC 4514Lightweight Directory Access Protocol (LDAP): String Representation ofistinguished Names中只有部分要求。

• 可以使用轉(zhuǎn)義字符'“'(U+0022), '+' U+002B, ',' U+002C, ';' U+003B, '<' U+003C, '>' U+003E, '\'U+005C。

• 轉(zhuǎn)義字符空格（' 'U+0020）和數(shù)組符號（'#' U+0023）只能在字符串的開頭使用。

• 如果遇到null字符（U+0000）將匹配失敗。

• 不支持RFC 4517Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules 和 RFC 4518 Lightweight Directory Access Protocol (LDAP):Internationalized String Preparation中的要求。

另外，Zabbix中對Issuer和Subject字符串的格式也有要求，Zabbix遵循RFC 4514的推薦使用逆序的方式。OpenSSL默認顯示證書的Issuer和Subject用正常的順序，例如：

# openssl x509 -noout -in/etc/zabbix/zabbix_proxy.cert -issuer -subject

issuer= /C=CN/ST=Beijing/O=My Company/OU=IT Dept/CN=zabbix ca root

subject= /C=CN/ST=Beijing/O=My Company/OU=IT Dept/CN=zabbix proxy

利用OpenSSL命令行的特殊參數(shù)可以獲得Issuer和Subject的逆序顯示，例如：

# openssl x509 -noout-issuer -subject -nameopt esc_2253,esc_ctrl,utf8,dump_nostr, \ dump_unknown,dump_der,sep_comma_plus,dn_rev,sname-in /etc/zabbix/zabbix_proxy.cert

issuer= CN=zabbix ca root,OU=IT Dept,O=My Company,ST=Beijing,C=CN

subject= CN=zabbix proxy,OU=IT Dept,O=My Company,ST=Beijing,C=CN

現(xiàn)在你看到的是Issuer和Subject的逆序顯示，每個字段之間用逗號分隔，這個字符串可以在Zabbix proxy配置文件中使用，也可以在Zabbix前端頁面中使用。

在生成證書時，使用X.509 v3證書擴展項也有一些限制：

• Subject Alternative Name(subjectAltName) extension：在subjectAltName擴展中定義的Alternative subject names（像IP address、e-mail address等）在Zabbix中不支持。在Zabbix中只檢查Subject字段的值。

• Extended Key Usage extension：如果使用該擴展項，clientAuth （TLS WWW clientauthentication）和serverAuth（TLS WWW server authentication）是必須的。例如，在被動式檢查中，Zabbix agent就像是一個TLS server，所以在agent證書中必須設(shè)置serverAuth。在主動式檢查中agent證書中需要設(shè)置clientAuth。在GnuTLS中會報錯但允許建立連接進行通信。

• Name Constraints extension：該擴展項并不是所有的加密工具都支持它，這個擴展可以防止Zabbix加載CA證書中標記為關(guān)鍵的部分（依賴特定的加密工具包）。

• 利用OpenSSL創(chuàng)建證書

本書中只講解通過OpenSSL創(chuàng)建CA證書的過程，更多的PKI、CA方面的知識，請讀者自行參考相關(guān)資料。

用OpenSSL實現(xiàn)私有CA的具體步驟如下：

1、? 生成CA私鑰（公鑰自動提取不用生成）并生成自簽名證書及相關(guān)文件。

2、? 生成用戶秘鑰及證書頒發(fā)請求

3、? 由CA簽署用戶證書。

CentOS 7中OpenSSL的配置文件位于/etc/pki/tls/openssl.cnf，默認證書保存的目錄為/etc/pki/CA，該目錄中保存創(chuàng)建的證書等相關(guān)文件。利用OpenSSL的命令行工具開始創(chuàng)建證書之前，需要在 /etc/pki/CA目錄中創(chuàng)建幾個生成證書必要的文件。

# cd/etc/pki/CA

創(chuàng)建已簽發(fā)證書的文本數(shù)據(jù)庫文件，文件初始化為空。

#touch index.txt

創(chuàng)建簽發(fā)證書時使用的序列號文件，該文件中保存16進制格式的序列號，文件創(chuàng)建時必須包含一個有效的序列號。

#echo 00 > serial

創(chuàng)建證書吊銷列表序列號文件，該文件在創(chuàng)建證書吊銷列表時使用，保存16進制格式的序列號。

#echo 00 > crlnumber

目錄結(jié)構(gòu)如下所示。

#tree .

.

├── certs???????????????????? ???????? # 保存已頒發(fā)的證書

├── crl?????????????????????????????????? # 保存已吊銷的證書

├── crlnumbe????????????????????? # 證書吊銷列表序列號

├── index.txt?????????????????????? # 數(shù)據(jù)庫文件

├── newcerts????????????????????? # 保存CA生成的新證書

├── private????????????????????????? # 保存私鑰文件

└── serial???????????????????????????? # 證書序列號文件

?

現(xiàn)在我們使用OpenSSL命令行創(chuàng)建CA及Zabbix各組件的證書，創(chuàng)建過程如下：

# cd /etc/pki/CA

生成CA私鑰及證書頒發(fā)請求。

#openssl req -new -keyout private/zabbix_root_ca.key -outprivate/zabbix_root_ca.csr \

-subj"/C=CN/ST=Beijing/L=Beijing/O=My Company/OU=IT Dept/CN=Zabbix RootCA"

Generating a 2048 bit RSA private key

.......+++

..............................................................+++

writing new private key to'private/zabbix_root_ca.key'

Enter PEM pass phrase:

Verifying - Enter PEM pass phrase:

-----

?

生成自簽名CA證書。

#openssl ca -out certs/zabbix_root_ca.cert -batch -keyfile private/zabbix_root_ca.key\

-selfsign-extensions v3_ca -infiles private/zabbix_root_ca.csr

Using configuration from/etc/pki/tls/openssl.cnf

Enter pass phrase forprivate/zabbix_root_ca.key:

Check that the request matches thesignature

Signature ok

Certificate Details:

???????Serial Number: 0 (0x0)

???????Validity

???????????Not Before: Aug 31 04:03:37 2016 GMT

???????????Not After : Aug 31 04:03:37 2017 GMT

???????Subject:

???????????countryName?????????????? = CN

???????????stateOrProvinceName???? ???=Beijing

???????????organizationName??????? ???= MyCompany

???????????organizationalUnitName?? ???= ITDept

???????????commonName????????????? = ZabbixRoot CA

???????X509v3 extensions:

???????????X509v3 Subject Key Identifier:

???????????????47:95:AF:32:4E:F1:53:DF:30:DE:02:19:CD:15:14:C3:04:73:5F:B4

???????????X509v3 Authority Key Identifier:

???????????????keyid:47:95:AF:32:4E:F1:53:DF:30:DE:02:19:CD:15:14:C3:04:73:5F:B4

?

???????????X509v3 Basic Constraints:

??????????????? CA:TRUE

Certificate is to be certified until Aug 3104:03:37 2017 GMT (365 days)

?

Write out database with 1 new entries

Data Base Updated

?

生成Zabbix server私鑰及證書頒發(fā)請求。

#openssl req -new -nodes -keyout private/zabbix_server.key -outprivate/zabbix_server.csr \ -subj "/C=CN/ST=Beijing/L=Beijing/O=MyCompany/OU=IT Dept/CN=Zabbix Server" -days 3650

Generating a 2048 bit RSA private key

.....+++

............................................................................................................................................................................+++

writing new private key to'private/zabbix_server.key'

-----

?

由CA簽署Zabbix server證書。

#openssl ca -cert certs/zabbix_root_ca.cert -keyfile private/zabbix_root_ca.key-out \ certs/zabbix_server.cert -infiles private/zabbix_server.csr

Using configuration from /etc/pki/tls/openssl.cnf

Enter pass phrase forprivate/zabbix_root_ca.key:

Check that the request matches thesignature

Signature ok

Certificate Details:

???????Serial Number: 1 (0x1)

???????Validity

???????????Not Before: Aug 31 04:04:24 2016 GMT

???????????Not After : Aug 31 04:04:24 2017 GMT

???????Subject:

???????????countryName?????????????? = CN

???????????stateOrProvinceName??? ????=Beijing

???????????organizationName?????? ????= MyCompany

???????????organizationalUnitName?? ???= ITDept

???????????commonName????????????? = ZabbixServer

???????X509v3 extensions:

???????????X509v3 Basic Constraints:

??????????????? CA:FALSE

???????????Netscape Comment:

??????????????? OpenSSL Generated Certificate

???????????X509v3 Subject Key Identifier:

???????????????92:57:C9:58:8B:78:DE:4B:83:0E:B1:F4:61:B2:DC:3D:AB:0E:76:44

???????????X509v3 Authority Key Identifier:

???????????????keyid:47:95:AF:32:4E:F1:53:DF:30:DE:02:19:CD:15:14:C3:04:73:5F:B4

?

Certificate is to be certified until Aug 3104:04:24 2017 GMT (365 days)

Sign the certificate? [y/n]:y

?

1 out of 1 certificate requests certified,commit? [y/n]y

Write out database with 1 new entries

Data Base Updated

?

用同一CA分別簽署頒發(fā)Zabbix proxy和agent證書。

#openssl req -new -nodes -keyout private/zabbix_proxy.key -outprivate/zabbix_proxy.csr \ -subj "/C=CN/ST=Beijing/L=Beijing/O=MyCompany/OU=IT Dept/CN=Zabbix Proxy" -days 3650

?

#openssl ca -cert certs/zabbix_root_ca.cert -keyfile private/zabbix_root_ca.key-out \ certs/zabbix_proxy.cert -infiles private/zabbix_proxy.csr

?

#openssl req -new -nodes -keyout private/zabbix_agent.key -outprivate/zabbix_agent.csr \

-subj"/C=CN/ST=Beijing/L=Beijing/O=My Company/OU=IT Dept/CN=Zabbix Agent"-days 3650

?

#openssl ca -cert certs/zabbix_root_ca.cert -keyfile private/zabbix_root_ca.key-out \ certs/zabbix_agent.cert -infiles private/zabbix_agent.csr

?

19.3.2 配置參數(shù)

Zabbix中使用證書加密時需要配置以下幾個參數(shù)：

• TLSCAFile：包含完整路徑名的頂層根CA證書文件，文件中首先是低級的CA證書，然后是高一級的CA。來自多個CA的證書可以包含在同一個文件中。該參數(shù)必須配置。

• TLSCRLFile：包含完整路徑名的證書吊銷列表文件。該參數(shù)為可選配置。

• TLSCertFile：包含完整路徑名的證書（證書鏈）文件，在文件中首先是Zabbix server、proxy或agent證書，然后是上一級的CA證書，直到頂層CA。該參數(shù)必須配置。

• TLSKeyFile：包含完整路徑名的私鑰文件，該文件的訪問權(quán)限必須設(shè)置成只有zabbix用戶可讀。該參數(shù)必須配置。

• TLSServerCertIssuer：允許的服務(wù)器證書頒發(fā)者。該參數(shù)為可選配置。

• TLSServerCertSubject：允許的服務(wù)器證書擁有者。該參數(shù)為可選配置。

• 配置證書加密

前面提到的配置參數(shù)在Zabbix server中只需要配置TLSCAFile、TLSCertFile和TLSKeyFile，如果需要也可以使用TLSCRLFile參數(shù)配置吊銷證書列表。例如：

# vi /etc/zabbix/zabbix_server.conf

TLSCAFile=/etc/zabbix/zabbix_root_ca.cert

TLSCertFile=/etc/zabbix/zabbix_server.cert

TLSKeyFile=/etc/zabbix/zabbix_server.key

配置完成后需要重新啟動server證書相關(guān)的配置才能夠生效。

19.3.4 Proxy配置證書加密

Proxy配置證書加密需要配置TLSCAFile、TLSCertFile和TLSKeyFile，分別對應(yīng)頂級CA證書文件、proxy證書（證書鏈）文件和proxy私鑰文件。如果需要也可以使用TLSCRLFile參數(shù)配置吊銷證書列表。

如果proxy設(shè)置為active（主動）模式，必須配置TLSConnect為cert，passive（被動）模式中需要配置TLSAccept為cert。

例如：

# vi/etc/zabbix/zabbix_proxy.conf

TLSConnect=cert

TLSAccept=cert

TLSCAFile=/etc/zabbix/zabbix_root_ca.cert

TLSCertFile=/etc/zabbix/zabbix_proxy.cert

TLSKeyFile=/etc/zabbix/zabbix_proxy.key

通過上面的配置，你已經(jīng)完成了proxy最基本的證書加密。注意需要重啟proxy配置才能夠生效。

為了提高proxy的安全性，在配置文件中可以配置TLSServerCertIssuer和 TLSServerCertSubject參數(shù)，例如：

TLSServerCertIssuer=CN=zabbix ca root,OU=IT Dept,O=MyCompany,ST=Beijing,C=CN

TLSServerCertSubject=CN=zabbix server,OU=IT Dept,O=MyCompany,ST=Beijing,C=CN

然后到Zabbix前端頁面配置proxy加密，進入Administration --> Proxies頁面中，點擊proxy名稱進入proxy配置頁面，在Encryption標簽中，選擇Certificate加密方式，填寫Issuer和Subject字段。

Active （主動式）proxy配置如下圖19-5所示。

圖 19-5

?

Passive（被動式）proxy配置如下圖19-6所示。

圖 19-6

?

19.3.5 Agent配置證書加密

Agent配置證書加密需要配置TLSCAFile、TLSCertFile和TLSKeyFile，分別對應(yīng)頂級CA證書文件、agent證書（證書鏈）文件和agent私鑰文件。如果需要也可以使用TLSCRLFile參數(shù)配置吊銷證書列表。

如果agnet設(shè)置為active（主動）模式，必須配置TLSConnect為cert，passive（被動）模式中需要配置TLSAccept為cert。

例如：

# vi/etc/zabbix/zabbix_proxy.conf

TLSConnect=cert

TLSAccept=cert

TLSCAFile=/etc/zabbix/zabbix_root_ca.cert

TLSCertFile=/etc/zabbix/zabbix_agent.cert

TLSKeyFile=/etc/zabbix/zabbix_agent.key

通過上面的配置，你已經(jīng)完成了agent最基本的證書加密。注意需要重啟proxy配置才能夠生效。

為了提高agent的安全性，在配置文件中可以配置TLSServerCertIssuer和 TLSServerCertSubject參數(shù)，例如：

TLSServerCertIssuer=CN=zabbix ca root,OU=IT Dept,O=MyCompany,ST=Beijing,C=CN

TLSServerCertSubject=CN=zabbix server,OU=IT Dept,O=MyCompany,ST=Beijing,C=CN

然后到Zabbix前端頁面配置agent加密，進入Configuration --> Hosts頁面中，點擊主機名稱進入主機配置頁面，在Encryption標簽中，選擇Certificate加密方式，填寫Issuer和Subject字段。如下圖19-7所示。

圖 19-7

19.3.5 配置證書吊銷列表

證書可能因為泄露秘鑰、泄露CA、從屬關(guān)系改變或業(yè)務(wù)終止而指定為吊銷證書，CA發(fā)布一個證書吊銷列表（CRL），列出被認為不能再使用的證書的序列號。證書吊銷列表可以在Zabbix server、proxy或agent配置文件中使用TLSCRLFile參數(shù)進行配置。例如：TLSCRLFile=/etc/zabbix/zabbix_crl_file。

在zabbix_crl_file中可能會包含來自多個CA的CRLs，例如：

-----BEGIN X509 CRL-----

MIIB/DCB5QIBATANBgkqhkiG9w0BAQUFADCBgTETMBEGCgmSJomT8ixkARkWA2Nv

...

treZeUPjb7LSmZ3K2hpbZN7SoOZcAoHQ3GWd9npuctg=

-----END X509 CRL-----

-----BEGIN X509 CRL-----

MIIB+TCB4gIBATANBgkqhkiG9w0BAQUFADB/MRMwEQYKCZImiZPyLGQBGRYDY29t

...

CAEebS2CND3ShBedZ8YSil59O6JvaDP61lR5lNs=

-----END X509 CRL-----

CRL文件只在Zabbix組件啟動時加載，更新CRL文件更新后必須重啟Zabbix 組件。

19.3.5 常見問題

Zabbix中各組件之間建立加密通信時扮演的角色是一端為TLS客戶端，另一端為TLS服務(wù)器端，無論是Zabbix server、proxy還是agent，都能以TLS 服務(wù)器和客戶端的角色運行。例如Zabbix server連接到被動式agent時，server就是一個TLS 客戶端，而agent是一個TLS 服務(wù)器。主動式agent連接到proxy時，agent就是一個TLS客戶端，proxy就是一個TLS服務(wù)器。但是zabbix_get和zabbix_sender工具始終都是TLS客戶端。

Zabbix使用相互身份驗證，每一方都會驗證對端的身份，如果對端的證書無效時會立即關(guān)閉連接并記錄到日志文件中。因此，當遇到拒絕連接時應(yīng)當檢查服務(wù)器端的日志文件確定連接被拒絕的原因，客戶端的日志中記錄的錯誤信息比較籠統(tǒng)，例如Connection closed by peer或者connection was non-properly terminated等。

有時候配置錯誤也會產(chǎn)生令人困惑的錯誤信息，不能明確指出產(chǎn)生錯誤的真正原因。下面我們會列舉出一些常見的錯誤信息以及可能發(fā)生問題的原因。但要注意不同的加密工具包對相同的問題會產(chǎn)生不同的錯誤信息。

1、連接類型和權(quán)限問題

• server配置PSK連接到agent，但agent只接受未加密的連接。

• 使用mbed TLSv1.3.11加密工具包時在server或proxy的日志文件中記錄的錯誤信息為：Get valuefrom agent failed: ssl_handshake(): SSL - The connection indicated an EOF。

• 使用GnuTLS v3.3.16加密工具包時在server或proxy的日志文件中記錄的錯誤信息為：Get value from agent failed: zbx_tls_connect(): gnutls_handshake()failed: -110 The TLS connection was non-properly terminated。

• 使用OpenSSLv1.0.2c加密工具包時在server或proxy的日志文件中記錄的錯誤信息為：Get valuefrom agent failed: TCP connection successful, cannot establish TLS to[[127.0.0.1]:10050]: Connection closed by peer. Check allowed connection typesand access rights

• 一端使用證書連接但另一端只接受PSK，反之亦然。

• 使用mbed TLS 加密工具包時在日志文件中記錄的錯誤信息為：failed to accept an incoming connection: from 127.0.0.1:ssl_handshake():SSL - The server has no ciphersuites in common with the client。

• 使用GnuTLS加密工具包時在日志文件中記錄的錯誤信息為：failed to accept an incoming connection: from 127.0.0.1:zbx_tls_accept(): gnutls_handshake() failed: -21 Could not negotiate asupported cipher suite。

• 使用OpenSSL v1.0.2c加密工具包時在日志文件中記錄的錯誤信息為：failed to accept an incoming connection: from 127.0.0.1: TLShandshake returned error code 1: file .\ssl\s3_srvr.c line 1411:error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher: TLS writefatal alert "handshake failure"

2、證書問題

• OpenSSL在證書鏈中使用了一些CA的CRL，沒有配置TLSCRLFile參數(shù)包括這些CRL。

• 使用mbed TLS和OpenSSL的情況下在TLS 服務(wù)器日志中記錄的錯誤信息為：failed to accept an incoming connection: from 127.0.0.1: TLShandshake with 127.0.0.1 returned error code 1: file s3_srvr.c line 3251:error:14089086: SSL outines:ssl3_get_client_certificate:certificate verifyfailed: TLS write fatal alert "unknown CA"。

• 使用GnuTLS的情況下在TLS服務(wù)器日志中記錄的錯誤信息為：failed toaccept an incoming connection: from 127.0.0.1: TLS handshake with 127.0.0.1returned error code 1: file rsa_pk1.c line 103: error:0407006A: rsaroutines:RSA_padding_check_PKCS1_type_1: block type is not 01 file rsa_eay.cline 705: error:04067072: rsa outines:RSA_EAY_PUBLIC_DECRYPT:paddin

• CRL 過期或在服務(wù)器操作期間過期

• 使用OpenSSL時在服務(wù)器日志中記錄的錯誤信息為：

過期之前：cannot connect to proxy "proxy-openssl-1.0.1e": TCPsuccessful, cannot establish TLS to [[127.0.0.1]:20004]: SSL_connect() returnedSSL_ERROR_SSL: file s3_clnt.c line 1253: error:14090086: SSLroutines:ssl3_get_server_certificate:certificate verify failed: TLS write fatalalert "certificate revoked"。

過期之后：cannot connect to proxy "proxy-openssl-1.0.1e": TCPsuccessful, cannot establish TLS to [[127.0.0.1]:20004]: SSL_connect() returnedSSL_ERROR_SSL: file s3_clnt.c line 1253: error:14090086: SSLroutines:ssl3_get_server_certificate:certificate verify failed: TLS write fatalalert "certificate expired"。

• 使用GnuTLS時在服務(wù)器日志中記錄的錯誤信息為（過期前后時相同的）：cannot connect to proxy "proxy-openssl-1.0.1e": TCPsuccessful, cannot establish TLS to [[127.0.0.1]:20004]: invalid peercertificate: The certificate is NOT trusted. The certificate chain is revoked。

• 使用mbed TLS時在服務(wù)器日志中記錄的錯誤信息為：

過期之前：cannot connect to proxy "proxy-openssl-1.0.1e": TCPsuccessful, cannot establish TLS to [[127.0.0.1]:20004]: invalid peercertificate: revoked。

過期之后：cannot connect to proxy "proxy-openssl-1.0.1e": TCPsuccessful, cannot establish TLS to [[127.0.0.1]:20004]: invalid peercertificate: revoked, CRL expired。

?

3、PSK問題

• PSK 包含奇數(shù)個十六進制數(shù)字

• Proxy或agent不能正常啟動，在proxy或agent日志文件中記錄的錯誤信息為：invalidPSK in file "/etc/zabbix/proxy_or_agent.psk"

• 使用GnuTLS時PSK identity string的長度超過128個字節(jié)

在TLS 客戶端日志文件中記錄的錯誤信息為：gnutls_handshake()failed: -110 The TLS connection was non-properly terminated。

在TLS服務(wù)器日志文件中記錄的錯誤信息為：gnutls_handshake()failed: -90 The SRP username supplied is illegal。

• 使用mbed TLS時PSK 長度超過了32字節(jié)，在Zabbix任意組件的日志文件中記錄的錯誤信息為：ssl_set_psk():SSL - Bad input parameters to function。

?

?

?

出自http://ustogether.blog.51cto.com/8236854/1931618，如需轉(zhuǎn)載請與作者聯(lián)系。