Zabbixの安全なセットアップのためのベストプラクティス

概要

このセクションでは、Zabbixを安全に設定するために遵守すべきベストプラクティスを紹介します。

ここに記載されている内容は、Zabbixの動作に必須ではありませんが、システムのセキュリティを向上させるために推奨されるものです。

最小特権の原則

Zabbixでは、常に最小特権の原則(Principle of least privilege)を使用する必要があります。
この原則は、ユーザアカウント(Zabbixフロントエンド)またはプロセスユーザ(Zabbix server /proxy またはagent)は
意図した機能を実行するために必要な権限のみを持つということを意味します。言い換えると、常にユーザアカウントは
可能な限り少ない権限で実行する必要があります。

ユーザアカウントに最小権限原則を導入する場合、Zabbixの フロントエンドユーザ タイプを考慮する必要があります。
"Admin"ユーザタイプは"Super Admin"ユーザタイプよりも少ない権限しか持ちませんが、
管理者権限を持っており、設定の管理やカスタムスクリプトの実行が可能です。

Zabbix agent の実行ユーザ

デフォルトの設定では、Zabbix serverとZabbix agent のプロセスは、単一の"zabbix"ユーザを共有します。
server 設定の機密情報(例：データベースのログイン情報)に agent がアクセスできないようにしたい場合は、
以下の手順でagent を別のユーザで実行する必要があります：

1. セキュアユーザーの作成
2. agent 設定ファイル("User"パラメータ)でこのユーザを指定する。
3. 管理者権限でエージェントを再起動します。指定したユーザには特権が与えられます。

UTF-8 エンコーディング

UTF-8はZabbixがサポートする唯一のエンコーディングです。
このエンコーディングはセキュリティ上の欠陥なく動作することが知られています。
他のエンコードを使用する場合、セキュリティ上の問題があることが判明しているため、ユーザは注意が必要です。

ZabbixフロントエンドのSSL設定

RHEL/CentOSの場合、mod_sslパッケージをインストールします:
yum install mod_ssl

SSL key用のディレクトリを作成します:

mkdir -p /etc/httpd/ssl/private 
       chmod 700 /etc/httpd/ssl/private

SSL証明書を作成します:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/httpd/ssl/private/apache-selfsigned.key -out /etc/httpd/ssl/apache-selfsigned.crt

プロンプトを適切に記入してください。最も重要なのは、コモンネームを要求する行です。
サーバーに関連づけたいドメイン名を入力する必要があります。
ドメイン名がない場合は、パブリックIP アドレスを入力することもできます。ここでは、example.com を使用します。

Country Name (2 letter code) [XX]:
       State or Province Name (full name) []:
       Locality Name (eg, city) [Default City]:
       Organization Name (eg, company) [Default Company Ltd]:
       Organizational Unit Name (eg, section) []:
       Common Name (eg, your name or your server's hostname) []:example.com
       Email Address []:

Apache のSSL configuration を設定します:

/etc/httpd/conf.d/ssl.conf
       
       DocumentRoot "/usr/share/zabbix"
       ServerName example.com:443
       SSLCertificateFile /etc/httpd/ssl/apache-selfsigned.crt
       SSLCertificateKeyFile /etc/httpd/ssl/private/apache-selfsigned.key

設定変更を反映させるため、Apacheを再起動します:

systemctl restart httpd.service

URLのルートディレクトリでZabbixを有効化する

Apacheの設定にバーチャルホストを追加し、ドキュメントルートをZabbix SSL URLに恒久的にリダイレクトするよう設定します。 このとき、忘れずにexample.comを実際のサーバ名に置き換えてください。

/etc/httpd/conf/httpd.conf
       
       #Add lines
       
       <VirtualHost *:*>
       ServerName example.com
       Redirect permanent / https://example.com
       </VirtualHost>

設定変更を反映させるために、Apache を再起動します。
systemctl restart httpd.service

Web サーバーで HTTP Strict Transport Security (HSTS) を有効にする

Zabbixフロントエンドをプロトコルダウングレード攻撃から保護するために、以下のことを推奨します。

HSTS ポリシーを有効にすることをお勧めします。

例えば、Apacheの設定でZabbixフロントエンドのHSTSポリシーを有効にする場合:

/etc/httpd/conf/httpd.conf

バーチャルホストの設定に以下のディレクティブを追加してください。

<VirtualHost *:443>
       Header set Strict-Transport-Security "max-age=31536000"
       </VirtualHost>

設定変更を反映させるため、Apache を再起動します。

systemctl restart httpd.service

Webサーバの情報公開を無効にする

Webサーバのハードニングプロセスの一環として、すべてのWebサーバのシグネチャを無効にすることをお勧めします。
Webサーバは、デフォルトでソフトウェア のシグネチャを公開します。

この署名は、Apache（例として使用）の設定ファイルに2行追加することで無効にすることができます。

ServerSignature Off
       ServerTokens Prod

PHPのシグネチャ（X-Powered-By HTTPヘッダー）は、php.iniの設定ファイルを変更することで無効にできます（デフォルトではシグネチャは無効になっています）

expose_php = Off

設定ファイルの変更を反映させるためには、Webサーバの再起動が必要です。

Apacheでmod_security (package libapache2-mod-security2) を使用することにより、さらにセキュリティレベルを上げることができます。
mod_security によって、サーバシグネチャを削除することができます。インストール後に"SecServerSignature"を任意の値に変更できます。

ソフトウェアシグネチャの削除・変更方法については、お使いのWebサーバーのドキュメントを参照してください。

デフォルトのWebサーバのエラーページを無効にする

情報漏洩を防ぐため、デフォルトのエラーページを無効化することをお勧めします。
Webサーバは、デフォルトで組み込みのエラーページを使用しています:

デフォルトのエラーページは、Webサーバのハードニングプロセスの一環として、置き換え/削除する必要があります。
”ErrorDocument" ディレクティブは (例としてApache) Webサーバ用のカスタムエラーページ/テキストを定義するために使用されます。

デフォルトのエラーページを置き換える/削除する方法については、お使いのWebサーバのドキュメントを参照してください。

Webサーバのテストページを削除する

情報漏洩を防ぐため、Webサーバのテストページは削除することをお勧めします。
デフォルトでは、WebサーバーのWebrootには、index.htmlと呼ばれるテストページが含まれています。
（Ubuntu の Apache2 を例としています）:

テストページは、Webサーバのハードニングプロセスの一環として削除するか、利用できないようにする必要があります。

Zabbixの設定

デフォルトでは、Zabbixは*X-Frame-Options HTTP response ヘッダを SAMEORIGIN に設定し、
ページと同じオリジンを持つフレームにのみコンテンツを読み込むことができるように設定されています。

外部URLからコンテンツを取得するZabbixフロントエンド要素(すなわち URL ダッシュボード ウィジェット) は、
取得したコンテンツをサンドボックスで表示し、サンドボックスの制限をすべて有効にしています。

これらの設定により、Zabbixフロントエンドのセキュリティが強化され、XSS攻撃やクリックジャッキング攻撃から保護します。
"Super Admins" は以下のことが可能です。
変更

iframe sandboxing と X-Frame-Options HTTP レスポンスヘッダー のパラメータを必要に応じて追加してください。
デフォルトの設定を変更する前に、リスクとメリットを慎重に検討してください。
サンドボックスまたはX-Frame-Optionsを完全にオフにすることは推奨されません。

OpenSSLを使用したWindows版のZabbix agent

OpenSSLを使用してコンパイルされたWindows版のZabbix agent は、C:¥openssl-64bitに置かれたSSL設定ファイルに到達しようとします。
ディスクC:\の openssl-64bitディレクトリ は、非特権ユーザでも作成可能です。
そのため、セキュリティ強化のために、このディレクトリを手動で作成し、管理者以外のユーザーから書き込み権限を剥奪する必要があります。
32ビット版と64ビット版のWindowsでは、ディレクトリ名が異なりますのでご注意ください。

共通パスワードのリストを含むファイルの隠蔽

パスワードのブルートフォースアタックの複雑性を高めるために、以下のような方法があります。
ui/data/top_passwords.txt へのアクセスを制限することをお勧めします。

このファイルには、最も一般的なパスワードやコンテキスト固有のパスワードのリストが含まれており
Avoid easy-to-guess passwords パラメータが[passwordpolicy] (/manual/web_interface/frontend_sections/administration/authentication#internal_authentication) で有効になっている場合、
ユーザーがそのようなパスワードを設定できないようにするために使用されます。

例えば、NGINX では location ディレクティブを使用してファイルへのアクセスを制限することができます。

location = /data/top_passwords.txt {​​​​​​​ 
       deny all; 
       return 404; 
       }​​​​​​​ 

Apacheでは、 - .htacess ファイルで:

<Files "top_passwords.txt"> 
       Order Allow,Deny 
       Deny from all 
       </Files> 

セキュリティの脆弱性

Zabbix Java gatewayのlogbackバージョン1.2.7およびそれ以前のバージョンでは、
設定ファイルの編集に必要な権限を持つ攻撃者が、不正な設定を行うことが可能です。
これにより、攻撃者はLDAPサーバから読み込まれた任意のコードを実行できるようになります。

CVE-2021-42550 の脆弱性は Zabbix 5.4.9以降修正されています。
しかし、追加のセキュリティ対策として、以下のことを行うことを推奨します。
/etc/zabbix/zabbix_java_gateway_logback.xml ファイルのパーミッションをチェックし、
"zabbix" ユーザに書き込み権限がある場合は、読み取り専用に設定することを推奨します。