こんにちは、OSSよろず相談室のSKです。 OSS に関するお問い合わせが日々寄せられる中で、今回も統合監視ツール「Zabbix」に関連して寄せられたお問い合わせをご紹介します。 これまで有償の管理製品を使って、各サーバーの「ホスト名」「メモリ」「CPU」「OS」などの構成情報を管理していたお客様から、次のようなご相談をいただきました。 「利用中の製品がサポート終了を迎えるため、代替手段として、すでに監視で導入しているZabbixのAPIを使って構成情報を取得できないか？」 結論から申し上げますと、Zabbix APIを利用すれば構成情報の一括取得が可能です。すでに監視ツールとしてZabbixを運用している場合、この収集プロセスを自動化・連携させることができます。 今回は、Zabbix APIの host.get メソッドを利用して、外部からサーバーの構成情報（インベントリ情報）を一括取得する具体的な手順とコマンド例を解説します。 Zabbix APIの基本仕様 Zabbix APIはHTTPベースで提供されており、クライアントとAPI間のリクエスト・レスポンスには JSON-RPC 2.0プロトコル を使用します。 APIを呼び出すためのエンドポイント（URL）は、Zabbix Webインターフェースのディレクトリにある api_jsonrpc.php です。デフォルトでは以下のパスにあります。 /usr/share/zabbix/ui/api_jsonrpc.php ステップ1：APIの認証とトークンの取得 Zabbixのデータにアクセスするには、まず認証を行ってAPIトークン（セッションID）を取得する必要があります。まだ認証されていない状態からのログインには、user.login メソッドを使用します。 以下の curl コマンドを使用して、Zabbixサーバーに認証リクエストを送信します。 ※ここでは、デフォルトの管理ユーザーである “Admin” のトークンを取得する例を紹介します。 【コマンド例】 curl -X POST -H "Content-Type: application/json" -d ' { "jsonrpc": "2.0", "method": "user.login", "params": { "username": "Admin", "password": "zabbix" }, "id": 1 }' http://172.31.34.176/zabbix/api_jsonrpc.php 認証情報が正しければ、APIから以下のようなJSONレスポンスが返されます。 【取得結果例】 { "jsonrpc": "2.0", "result": "82aa1b5b38a9fe6f6619ad40c64602dd", "id": 1 } ここで result として返された値（82aa1b5b38a9fe6f6619ad40c64602dd）が認証トークンです。 以後のAPIリクエストでは、このトークンを使用します。 ステップ2：構成情報（インベントリ情報）の取得 認証トークンが取得できたら、次に監視対象ホストの構成情報を取得します。ホスト情報の取得には host.get メソッドを使用します。 ホスト名やIPアドレスだけでなく、CPU、メモリ、OSなどの構成情報（インベントリデータ）を同時に取得するため、パラメータに selectInventory を指定します。また、すべてのデータを取得するとパフォーマンスに影響を与える可能性があるため、output パラメータを使って取得したいプロパティを明示的に絞り込むことが推奨されています。 先ほど取得したトークンは、HTTPリクエストの Authorization ヘッダーに指定します。以下は、検証環境（IPアドレス: 172.31.34.176）に対してコマンドを実行した例です。 ※コマンドの末尾に | jq を付けると結果が整形されて見やすくなります（要jqコマンドのインストール。RHEL9.4以降ではBaseOSに標準含まれています）。 【コマンド例】 curl -X POST -H 'Content-Type: application/json-rpc' -H 'Authorization: Bearer 82aa1b5b38a9fe6f6619ad40c64602dd' -d ' { "jsonrpc": "2.0", "method": "host.get", "params": { "output": ["hostid", "host", "name"], "selectInventory": ["os", "hardware", "software"] }, "id": 2 }' http://172.31.34.176/zabbix/api_jsonrpc.php | jq 【コマンド解説】 curlコマンドの全体 項目 内容 curl Webサーバーと通信を行うためのコマンドラインツール -X POST HTTPメソッドを「POST」に指定（Zabbix APIは必ずPOSTを使用します） -H ‘Content-Type: application/json-rpc’ 送信するデータがJSON-RPC形式であることをZabbixサーバに伝えるヘッダ -H ‘Authorization: Bearer <トークン>’ 取得した認証トークンを指定するヘッダ -d ‘{ … }’ Zabbixへ送信するリクエストの実データ（JSON） http://…/zabbix/api_jsonrpc.php リクエストの送信先となるZabbixサーバーのエンドポイントURL | jq 出力されるJSONデータを見やすく改行・色付けして整形するコマンド 送信するJSONデータ（-d の中身） キー (” “) 指定している値 意味・役割 jsonrpc “2.0” JSON-RPCプロトコルのバージョン（”2.0″ 固定） method “host.get” 実行したいAPIの操作名。今回はホストデータの取得を指定 params { … } 検索条件や出力フォーマットなどを定義する引数 output [“hostid”, “host”, “name”] 返却されるホストオブジェクトのフィールドを限定（全項目取得時は “extend”） selectInventory [“os”, “hardware”, “software”] ホストに紐づくインベントリ情報を同時に取得するためのパラメータ id 2 リクエストとレスポンスを紐づける任意の識別子 以下が取得結果です。 【取得結果】 { "jsonrpc": "2.0", "result": [ { "hostid": "10084", "host": "Zabbix server", "name": "Zabbix server", "inventory": { "os": "Linux version 6.12.0-211.22.1.el10_2.x86_64 (mockbuild@df33c0284dd848a197e916486944b54f) (gcc (GCC) 14.3.1 20251022 (Red Hat 14.", "hardware": "", "software": "" } }, { "hostid": "10782", "host": "WebServer1", "name": "WebServer1", "inventory": [] } ], "id": 2 } stuser この検証環境では、監視対象に “Zabbix server” と “WebServer1” の2つが存在しています。 検証環境のZabbixサーバのホスト画面 “WebServer1” はWeb監視（URL外形監視など）のみを行っており、Zabbix Agentが導入されていないため、上記の結果のようにインベントリ情報が空（[]）になります。 項目を絞り込まずにすべての情報を取得したい場合は、”output” や “selectInventory” に “extend” を指定します。また、IPアドレスなどのネットワーク情報を取得したい場合は “selectInterfaces”: “extend” を追加します。 【コマンド例】 $ curl -X POST -H 'Content-Type: application/json' -H 'Authorization: Bearer 7a6237f38929523f74cfb0acf8566f7f' -d ' { "jsonrpc": "2.0", "method": "host.get", "params": { "output": "extend", "selectInterfaces": "extend", "selectInventory": "extend" }, "id": 2 }' http://172.31.34.176/zabbix/api_jsonrpc.php | jq 取得できる項目の詳細は公式サイトをご参照ください。 Zabbix ドキュメント / 20 API https://www.zabbix.com/documentation/current/jp/manual/api Zabbix ドキュメント / 20 API / host.get https://www.zabbix.com/documentation/current/jp/manual/api/reference/host/get 【補足】APIの認証とトークンの取得 セッションの破棄（ログアウト） ステップ1で紹介した user.login メソッドで取得したトークンは、使い終わったら必ず user.logout を実行してセッションを破棄してください。破棄せずに放置すると、不要なセッションデータがデータベースに蓄積され、Zabbixのパフォーマンス低下を招く原因になります。 【セッション破棄のコマンド例】 $ curl -X POST -H 'Content-Type: application/json' -H 'Authorization: Bearer 1da473d0437c7bf69a22e6e057ffc1d7' -d ' { "jsonrpc": "2.0", "method": "user.logout", "params": [], "id": 3 }' http://172.31.34.176/zabbix/api_jsonrpc.php | jq { "jsonrpc": "2.0", "result": true, "id": 3 } 管理画面から発行する「APIトークン」の利用 毎回ログイン・ログアウト処理を行うのが手間に感じる場合は、Zabbixの管理画面から有効期限を設定できる「APIトークン」を事前に発行して利用する方法がおすすめです。 「ユーザー設定」→「APIトークン」を選択し、「APIトークンの作成」を選択します。 【APIトークン画面】      【新規APIトークン画面】 ユーザは、ここではデフォルトのAdminを選択し、有効期限を設定しています。 【APIトークン表示画面】 前画面で追加ボタンを押すと、以下のように認証トークンが表示されます。 画面を一度閉じると二度と再表示できないため、必ず閉じる前に値を控えておきましょう。   まとめ Zabbixが標準で収集しているインベントリデータとZabbix APIを組み合わせれば、有償製品を別途導入しなくても、各サーバーの構成情報を一括取得・管理できます。 また、Zabbix APIは情報の取得だけでなく、ホストやアイテム、トリガーの自動作成なども行えるため、日々の監視設定そのものをスクリプトで自動化することも可能です。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post OSSサポートの現場から！Zabbixでサーバの構成情報を取得する first appeared on SIOS Tech Lab .

こんにちは、OSSよろず相談室のSKです。 OSS に関するお問い合わせが日々寄せられる中で、今回は統合監視ツール「Zabbix」に関連して寄せられた、セキュアな通信に関するお問い合わせを2つご紹介します。 どちらもZabbixのWebコンソール（GUIポータル）へのSSL/TLS通信を安全に保つための内容ですが、Zabbix本体ではなく、Webサーバ側（Apache httpd）の ssl.conf の設定を変更します。 ケース1：TLS1.2のみに通信を制限したい 【お問い合わせ内容】 ZabbixのWebコンソールにブラウザで通信する際、現在TLS1.0と1.1が使用できる状態です。これをTLS1.2のみに制限する方法はありますか？ 【サポートからの回答】 こちらはZabbix自体の設定ではなく、Web画面を提供しているApache httpdの mod_ssl の設定となります。 /etc/httpd/conf.d/ssl.conf にて、以下のように SSLProtocol ディレクティブを設定することで、TLSv1.0 と TLSv1.1 の使用を無効化できます。 【修正例】 SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 上記のように記述することで、「すべてのプロトコル（All）を許可した上で、安全性の低いプロトコルを明示的に除外（マイナス記号 – を付与）」することになり、結果として TLSv1.2 以降のみが利用可能になります。 設定変更後は、必ずApacheの再起動またはリロードを行って設定を反映させてください。 ケース2：セキュリティ診断で指摘された古い暗号化方式を無効化したい 【お問い合わせ内容】 Zabbix環境に対してセキュリティ診断を実施したところ、Zabbixフロントエンド（Web管理画面）との暗号化通信において、古い暗号化方式の利用（SWEET32やBar Mitzvahなどに該当する事象）が検出されました。 暗号化通信は継続しつつ、検出された暗号化方式だけを利用しないように設定変更するにはどうすればよいでしょうか。 【サポートからの回答】 こちらもケース1と同様に、Apacheの ssl.conf の設定変更で対応可能です。それぞれの事象に関する原因と対処法をご案内します。 1. 3DESを使用する暗号化方式（SWEET32関連）への対応 参考情報： Red Hat 社の情報 / CVE-2016-2183 https://access.redhat.com/security/cve/cve-2016-2183 ちょっと気になる雑学：なぜ「SWEET32（誕生日攻撃）」？ 「ある部屋に23人いるだけで、誕生日が同じペアが50%以上の確率で存在する（誕生日のパラドックス）」という数学の法則を応用した攻撃手法です。「特定の鍵」を狙うのではなく「どれでもいいから暗号データの重複」を狙うため、直感より遥かに少ないデータ量で解読されてしまいます。3DES暗号の場合、通信量が「32GB」に達したあたりでこの重複確率が跳ね上がることから、この名前がつきました。 3DESを許可する記述や、3DESを使用する暗号化アルゴリズムが明示的に指定されていると、Sweet32 攻撃の影響を受けます。これらを削除することで対処が可能です。 修正例1（3DESが明記されている場合）: 変更前 apache SSLCipherSuite HIGH:3DES:!aNULL:!MD5:!SEED:!IDEA 変更後（”3DES”の記述を削除） apache SSLCipherSuite HIGH:!aNULL:!MD5:!SEED:!IDEA 修正例2（3DESの特定のアルゴリズム名が個別指定されている場合）: 　　以下の場合は” EDH-RSA-DES-CBC3-SHA “が指定されています。 変更前 apache SSLCipherSuite "ECDHE-ECDSA-AES128-GCM-SHA256 ・・・ EDH-RSA-DES-CBC3-SHA" 変更後（対象の暗号化方式 “EDH-RSA-DES-CBC3-SHA” を削除） apache SSLCipherSuite "ECDHE-ECDSA-AES128-GCM-SHA256 ・・・ " 2. RC4を含む暗号化方式（Bar Mitzvah関連）への対応 参考情報： Red Hat 社の情報 / CVE-2015-2808 https://access.redhat.com/security/cve/cve-2015-2808 Bar Mitzvahという脆弱性は、RC4 暗号アルゴリズム自体の弱点を突いた攻撃です。 ちょっと気になる雑学：なぜ「Bar Mitzvah」？ 「Bar Mitzvah（バー・ミツバ）」とは、ユダヤ教における「13歳」の男子の成人式のことです。この攻撃のベースとなったRC4暗号の弱点自体は2001年に既に発表されていたものでしたが、それから13年経った2015年になって、実用的な攻撃手法として実証（＝成人）されてしまったため、このような皮肉を込めた名前がつけられたそうです。 SSLCipherSuiteの設定に “MEDIUM” が入っていると影響を受けます。 “MEDIUM” は 128ビットの暗号化を使用するすべての暗号であるため、脆弱性診断で指摘されている暗号化アルゴリズムが許可されます。 変更前 SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5 変更後（”MEDIUM” を削除） SSLCipherSuite HIGH:!aNULL:!MD5 修正の反映と、コマンドによる事後確認 設定ファイルを修正した後は、設定を適用するためにApacheのリロード（systemctl reload httpd）または再起動（systemctl restart httpd）を行います。 また、設定が正しく反映され、意図しない暗号化方式が排除されたかどうかは、 openssl ciphers コマンドでテストすることができます。 引数に修正後の ssl.conf の SSLCipherSuite の値を指定して実行し、出力結果の「Enc」列に 3DES や RC4 が無いことを確認すると確実です。 実行例 openssl ciphers -v 'HIGH:!aNULL:!MD5:!SEED:!IDEA' まとめ ZabbixのWeb画面に関するセキュリティ要件（プロトコル制限や暗号化方式の変更など）は、Zabbixの設定ファイルを探しても見つかりません。 フロントエンドで動作しているWebサーバ（今回はApache の /etc/httpd/conf.d/ssl.conf）で設定を行うのが基本となります。 セキュリティ診断などでアラートが出た場合も、慌てずにWebサーバの暗号化スイート設定（SSLCipherSuite）を見直しましょう。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post OSSサポートの現場から！Zabbix Webコンソールのセキュリティ設定 first appeared on SIOS Tech Lab .

このドキュメントは 2026 年 04 月 08 日にリリースされた Zabbix 7.4.9 のリリースノートの日本語訳です。 ダウンロードは Zabbix ダウンロードより行えます。 以下はリリースの詳細と、最新情報 ...