English

お問い合わせ

BLOG

MIRACLE ZBX 3.0 の暗号化機能を使ってみよう

本ドキュメントでは、MIRACLE ZBX 3.0 系や Zabbix 3.0 系から新しく実装された暗号化通信機能について紹介します。弊社製品の MIRACLE ZBX には、Linux だけに限らず暗号化ライブラリが標準で組み込まれていますので、インストール後すぐに使うことができます。

はじめに

本ドキュメントでは、MIRACLE ZBX 3.0 系や、Zabbix 3.0 系から新しく実装された暗号化通信機能を紹介します。弊社製品の MIRACLE ZBX には暗号化ライブラリが標準で組み込まれており (※1)、すべてのサーバ・プロキシとほとんど (※2) のエージェントとの間で、Linux だけに限らず、Windows や UNIX などが混在する環境でもインストール直後から暗号化通信を行うことができます。

※1 バックエンドに mbed TLS を採用し、静的リンクをすることで追加の依存パッケージを発生させることなく暗号化通信を実現しました。

※2 バージョン 3.0.7-1 現在、64bit 版 ML3 を除くすべてのエージェントで対応

動作環境

暗号化通信の機能は MIRACLE ZBX 3.0.0-1 から対応していますが、3.0.7-1 より古いエージェントでは、一部の環境で暗号化通信に対応していません。最新のバージョンの MIRACLE ZBX を使用していただくことをおすすめします。

以下に 2017 年 5 月 8 日現在の対応状況一覧を示します。以降のバージョンの対応状況については、アップデート情報をご確認ください。

  使用している mbed TLS 対応していないシステム
3.0.0-1 1.3.14 ML3(64bit), Solaris(SPARC)
3.0.1-1 1.3.14 ML3(64bit), Solaris(SPARC)
3.0.3-1 1.3.14 ML3(64bit), Solaris(SPARC)
3.0.4-1 1.3.14 ML3(64bit), Solaris(SPARC)
3.0.5-1 1.3.18 ML3(64bit), Windows(64bit)
3.0.7-1 1.3.18 ML3(64bit)

概要

MIRACLE ZBX の暗号化はサーバとエージェント間の通信を暗号化することができます。VPN やトンネリング等を行わなくてもインターネット越しのマシンを安全に監視できるようになりました。

近年、インターネットにおける犯罪が高度化し、システムへの不正侵入や情報漏洩などが多発しています。通信内容を暗号化しておくことで不正侵入された場合の情報流出のリスクを低くすることが出来ます。

また MIRACLE ZBX で一元して設定を行うため、各環境ごとに異なった手順での暗号化設定を行う必要はありません。

暗号化に必要なオプション

MIRACLE ZBX の暗号化には、事前共有鍵暗号化方式及び証明書暗号化方式の 2 種類の方法があり、事前共有鍵暗号化方式は設定が容易、証明書暗号化方式は証明書の秘密鍵が紛失・漏洩した際、証明書失効リスト (CRL、今回は解説を省略します。) を利用することで当該証明書のみを無効にできるといった利点あります。お使いの環境に合わせた暗号化方式を利用してください。

暗号化を有効にするには、設定ファイルと Web インターフェースの両方から設定を行う必要があります。エージェントとプロキシは zabbix_agentd.conf または zabbix_proxy.conf で以下の 10 項目すべてを指定できます。サーバは zabbix_server.conf で証明書暗号化関連の 4 項目を指定でき、他の項目は Web インターフェースから指定します。以下に出てくる「上流」とはエージェントから見たサーバまたはプロキシ ( プロキシ経由接続の場合 )、プロキシから見たサーバとなります。

暗号化全般

  • TLSConnect
    アクティブ監視に用いられます。unencrypted ( 暗号化なし )、psk ( 事前共有鍵暗号化 )、cert ( 証明書暗号化 ) から「一つだけ」選びます。選択した方式で上流に接続しようとします。
  • TLSAccept
    パッシブ監視に用いられます。unencrypted、psk、cert から「一つ以上」選びます。選択した方式を上流から受け付けます。

事前共有鍵暗号化関連

TLSConnect か TLSAccept に psk を指定した場合は全て記入する必要があります。

  • TLSPSKIdentity
    共有鍵 ID を文字列のまま書きます
  • TLSPSKFile
    共有鍵の書かれたファイルを指定します

証明書暗号化関連

TLSConnect か TLSAccept に cert を指定した場合は最低でも必須の 3 項目を記入する必要があります。下記の「証明書による暗号化の手順」章に図があるので合わせて確認ください。

  • TLSCAFile ( 必須、zabbix_server.conf にある )
    ルート証明書ファイルを指定します
  • TLSCertFile ( 必須、zabbix_server.conf にある )
    自身の証明書ファイルを指定します
  • TLSKeyFile ( 必須、zabbix_server.conf にある )
    自身の証明書の秘密鍵ファイルを指定します
  • TLSCRLFile ( 任意、zabbix_server.conf にある )
    証明書失効リストファイルを指定します
  • TLSServerCertIssuer ( 任意 )
    上流の証明書の発行者を指定します
  • TLSServerCertSubject ( 任意 )
    上流の証明書のサブジェクトを指定します

以下にサーバとエージェント間の暗号化を行う 2 種類の手順例を示します。

事前共有鍵による暗号化の手順

事前共有鍵暗号化を行うには以下の 2 つが必要です。

  • 共有鍵 (PSK)
  • 共有鍵 ID (PSK アイデンティティ )

共有鍵は最大 32 バイトのバイナリ列で、 16 進数の ASCII 文字 (64 文字まで ) で記載されます。

以下のコマンドで PSK を生成できます。OpenSSL を使用しています。

(some-machine)# openssl rand -hex 32 > /etc/zabbix/psk
(some-machine)# cat /etc/zabbix/psk
38e1fa5ab7deb00c28a314072d3edb1524c06aa9c6f0f42d05af8fede93b8743

このファイルを各環境の同じパスにコピーします。(Windows の場合は /etc/zabbix/ を C:\Program Files\ZABBIX Agent\ 等に置き換えてください。以下同。)

共有鍵 ID は共有鍵を識別するための文字列で、ネットワークを平文で流れます。秘密の文字列を使用しないように注意しましょう。128 バイトまでの UTF-8 文字列を使用できます。

エージェントの設定ファイル (/etc/zabbix/zabbix_agentd.conf) を編集し、サービスを再起動します。

TLSConnect=psk
TLSAccept=psk
TLSPSKIdentity=zbxpsk
TLSPSKFile=/etc/zabbix/psk

(agent)# service zabbix-agent restart

続いてサーバの設定画面から
「ホスト」→対象のホスト名→「暗号化」を選択していき、「ホストへの接続」を「PSK」に切り替え「ホストからの接続」に「PSK」を追加します。

直下に項目が追加するので
「PSK アイデンティティ」に共有鍵 ID ("zbxpsk")、「PSK」に共有鍵ファイルの中身 (16 進数の ASCII 文字、"38e1fa...") をそれぞれ追加します。

「更新」を選択すると設定が更新され、エージェントとの通信が暗号化されます。

MIRACLE ZBX 設定画面 ホスト - 暗号化 - PSK

証明書による暗号化の手順

証明書暗号化は事前共有鍵暗号化に比べて準備が煩雑です。

まず秘密鍵を 3 組 (ca と server と agent) 作成し、ca を自己署名、 server と agent を ca で署名した証明書を作成します。本記事末尾の generate-zbx-cert-sample.sh に簡易的な生成スクリプトを記しました。OpenSSL のインストールされた環境で使用してください。適当な空のディレクトリ内で実行することをおすすめします。

いくつかのファイルが生成されますが、最終的に必要なのは

  • ca.crt
  • server.crt
  • server.key
  • agent.crt
  • agent.key

の 5 ファイルです。ca.key と demoCA ディレクトリは新たに証明書を追加する場合に必要となります。

以下に生成される各ファイルの概念図を示します。

 証明書暗号化 - 概念図

サーバの /etc/zabbix 以下に

  • ca.crt
  • server.crt
  • server.key

を、エージェントの /etc/zabbix 以下に

  • ca.crt
  • agent.crt
  • agent.key

をそれぞれ配置してください。

簡略化のため一つのスクリプトですべてのファイルを作成していますが、各マシンで秘密鍵と csr ( 署名要求 ) ファイルを作成し、csr ファイルを ca.key の所有者に送って crt ( 証明書 ) ファイルを返してもらうことで秘密鍵をネットワークで経由しないで済みます。

サーバとエージェントの設定ファイルをそれぞれ編集し、再起動します。

  • /etc/zabbix/zabbix_server.conf

TLSCAFile=/etc/zabbix/ca.crt
TLSCertFile=/etc/zabbix/server.crt
TLSKeyFile=/etc/zabbix/server.key

(server)# service zabbix-server restart

  • /etc/zabbix/zabbix_agentd.conf

TLSConnect=cert
TLSAccept=cert
TLSCAFile=/etc/zabbix/ca.crt
TLSCertFile=/etc/zabbix/agent.crt
TLSKeyFile=/etc/zabbix/agent.key
TLSServerCertIssuer=CN=ca.example.com,O=ExampleCompany,ST=SomeState,C=XX ( 任意 )
TLSServerCertSubject=CN=server.example.com,O=ExampleCompany,ST=SomeState,C=XX ( 任意 )

(agent)# service zabbix-agent restart

TLSServerCertIssuer 及び TLSServerCertSubject は記載することで別の証明書を利用してしまうことを防ぐことができます。設定に記入するための Issuer と Subject の文字列は以下のコマンドで確認できます。スクリプト内で生成時に指定しているフォーマットと異なるのでご注意ください。長いですが、これでひとつのコマンドです。

(server)# 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/server.crt

続いてサーバの設定画面から「ホスト」→対象のホスト名→「暗号化」を選択していき、「ホストへの接続」を「証明書」に切り替え、「ホストからの接続」に「証明書」を追加します。

直下に項目が追加するので「発行者」と「サブジェクト」を任意で記載し、「更新」を選択すると設定が更新され、エージェントとの通信が暗号化されます。

MIRACLE ZBX 設定画面 ホスト - 暗号化 - 証明書

付録

generate-zbx-cert-sample.sh

#!/bin/bash
# 各証明書の所有者情報 (Subject)
AGENT_SUBJ="/C=XX/ST=SomeState/O=ExampleCompany/CN=agent.example.com"
SERVER_SUBJ="/C=XX/ST=SomeState/O=ExampleCompany/CN=server.example.com"
CA_SUBJ="/C=XX/ST=SomeState/O=ExampleCompany/CN=ca.example.com"
# 有効期限 ( 約 10 年 )
DAYS=3650
# openssl.cnf ファイルの代替となるテキスト
CA_CONFIG='
[ ca ]
default_ca = CA_default
[ CA_default ]
dir = ./demoCA
certs = $dir/certs
crl_dir = $dir/crl
database = $dir/index.txt
new_certs_dir = $dir/newcerts
serial = $dir/serial
default_md = default
policy = policy_match
x509_extensions = usr_cert
name_opt = ca_default
cert_opt = ca_default
default_md = sha256
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
commonName = supplied
[ req ]
default_bits = 2048
distinguished_name = req_distinguished_name
default_md = sha256
[ req_distinguished_name ]
[ usr_cert ]
basicConstraints = CA:FALSE
nsComment = "OpenSSL Generated Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
'

# 既存の証明書があれば削除
rm -ri {ca,server,agent}.{key,csr,crt} demoCA

# 各証明書用に秘密鍵を 3 組用意
openssl genrsa 2048 > ca.key
openssl genrsa 2048 > server.key
openssl genrsa 2048 > agent.key

# 各秘密鍵から署名要求を作成
openssl req -config <(echo "$CA_CONFIG") -new -key ca.key -subj $CA_SUBJ > ca.csr
openssl req -config <(echo "$CA_CONFIG") -new -key server.key -subj $SERVER_SUBJ > server.csr
openssl req -config <(echo "$CA_CONFIG") -new -key agent.key -subj $AGENT_SUBJ > agent.csr

# ca 用証明書を自己署名
openssl x509 -sha256 -days $DAYS -req -signkey ca.key < ca.csr > ca.crt

# ルート証明書で署名を行うために必要なファイルを作成
mkdir -p demoCA/{newcerts,crl,private,certs}
touch demoCA/index.txt
echo 01 > demoCA/serial

# server 及び agent 用証明書に署名
yes | openssl ca -config <(echo "$CA_CONFIG") -days $DAYS -cert ca.crt -keyfile ca.key -in server.csr > server.crt
yes | openssl ca -config <(echo "$CA_CONFIG") -days $DAYS -cert ca.crt -keyfile ca.key -in agent.csr > agent.crt

注意事項

  • 本ドキュメントの内容は、予告なしに変更される場合があります。
  • 本ドキュメントは、限られた評価環境における検証結果をもとに作成しており、全ての環境での動作を保証するものではありません。
  • 本ドキュメントの内容に基づき、導入、設定、運用を行なったことにより損害が生じた場合でも、当社はその損害についての責任を負いません。あくまでお客さまのご判断にてご使用ください。
サイバートラストのテレワークソリューション
採用情報ページ リニューアル
組込み Linux にプラスして 長期間の製品ライフサイクルをサポート EM+PLS