安全な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 エンコーディング

Zabbix がサポートするエンコーディングは UTF-8 のみです。 セキュリティ上の欠陥なく動作することが知られています。 ユーザーは他のエンコーディングを使用する場合、既知のセキュリティ上の問題があることを留意してください。

Windows installer paths

When using Windows installers, it is recommended to use default paths provided by the installer as using custom paths without proper permissions could compromise the security of the installation.

ZabbixのWebインターフェースのSSL設定

RHELの場合、mod_sslパッケージをインストールします：

yum install mod_ssl

SSL鍵用のディレクトリを作成します：

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

プロンプトに対して適切な値を入力します。特に重要な行は、Common Nameを指定する行です。サーバーに関連付けるドメイン名を入力する必要があります。ドメイン名がない場合は、代わりにパブリック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の設定を編集します：

/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

Web サーバーの強化

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サーバのハードニングプロセスの一環として削除するか、利用できないようにする必要があります。

X-Frame-Options HTTP 応答ヘッダーを設定する

デフォルトでは、Zabbix は X-Frame-Options HTTP response header がSAMEORIGINに設定されて設定されています。つまり、ページ自体と同じオリジンを持つフレームにのみコンテンツをロードできます。

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

これらの設定により、Zabbix フロントエンドのセキュリティが強化され、XSS およびクリックジャッキング攻撃に対する保護が提供されます。 スーパー管理者は、必要に応じて iframe sandboxing および X-Frame-Options HTTP response header パラメータを 変更できます。 デフォルト設定を変更する前に、リスクと利点を慎重に検討してください。 サンドボックスまたは X-Frame-Options を完全にオフにすることはお勧めしません。

Windows で SSL 構成ファイルへの書き込みアクセスを取り消す

OpenSSL でコンパイルされた Zabbix Windows エージェントは、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 セキュリティ アドバイザリと CVE データベース

Zabbix セキュリティ アドバイザリと CVE データベース を参照してください。