このセクションでは、Zabbixを安全に設定するために遵守すべきベストプラクティスを紹介します。
ここに記載されている内容は、Zabbixの動作に必須ではありませんが、システムのセキュリティを向上させるために推奨されるものです。
Zabbixでは、常に最小特権の原則(Principle of least privilege)を使用する必要があります。
この原則は、ユーザアカウント(Zabbixフロントエンド)またはプロセスユーザ(Zabbix server /proxy またはagent)は
意図した機能を実行するために必要な権限のみを持つということを意味します。言い換えると、常にユーザアカウントは
可能な限り少ない権限で実行する必要があります。
"zabbix" ユーザに特別なパーミッションを与えると、設定ファイルへのアクセスや操作の実行が可能になり、
インフラ全体のセキュリティが脅かされる可能性があります。
ユーザアカウントに最小権限原則を導入する場合、Zabbixの フロントエンドユーザ タイプを考慮する必要があります。
"Admin"ユーザタイプは"Super Admin"ユーザタイプよりも少ない権限しか持ちませんが、
管理者権限を持っており、設定の管理やカスタムスクリプトの実行が可能です。
一部の情報は、非特権ユーザーでも利用可能です。 例えば、Administration → Scripts は"Super Admin" 以外では利用できませんが、
スクリプト自体はZabbix APIを利用することで実行可能です。スクリプトで利用できる機密情報の漏洩を防ぐために、
スクリプトのパーミッションを制限し、(アクセス認証などの)機密情報を追加しないようにしてください。
デフォルトの設定では、Zabbix serverとZabbix agent のプロセスは、単一の"zabbix"ユーザを共有します。
server 設定の機密情報(例:データベースのログイン情報)に agent がアクセスできないようにしたい場合は、
以下の手順でagent を別のユーザで実行する必要があります:
UTF-8はZabbixがサポートする唯一のエンコーディングです。
このエンコーディングはセキュリティ上の欠陥なく動作することが知られています。
他のエンコードを使用する場合、セキュリティ上の問題があることが判明しているため、ユーザは注意が必要です。
RHEL/CentOSの場合、mod_sslパッケージをインストールします:
yum install mod_ssl
SSL key用のディレクトリを作成します:
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を再起動します:
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
Zabbixフロントエンドをプロトコルダウングレード攻撃から保護するために、以下のことを推奨します。
HSTS ポリシーを有効にすることをお勧めします。
例えば、Apacheの設定でZabbixフロントエンドのHSTSポリシーを有効にする場合:
バーチャルホストの設定に以下のディレクティブを追加してください。
設定変更を反映させるため、Apache を再起動します。
Webサーバのハードニングプロセスの一環として、すべてのWebサーバのシグネチャを無効にすることをお勧めします。
Webサーバは、デフォルトでソフトウェア のシグネチャを公開します。
この署名は、Apache(例として使用)の設定ファイルに2行追加することで無効にすることができます。
PHPのシグネチャ(X-Powered-By HTTPヘッダー)は、php.iniの設定ファイルを変更することで無効にできます(デフォルトではシグネチャは無効になっています)
設定ファイルの変更を反映させるためには、Webサーバの再起動が必要です。
Apacheでmod_security (package libapache2-mod-security2) を使用することにより、さらにセキュリティレベルを上げることができます。
mod_security によって、サーバシグネチャを削除することができます。インストール後に"SecServerSignature"を任意の値に変更できます。
ソフトウェアシグネチャの削除・変更方法については、お使いのWebサーバーのドキュメントを参照してください。
情報漏洩を防ぐため、デフォルトのエラーページを無効化することをお勧めします。
Webサーバは、デフォルトで組み込みのエラーページを使用しています:
デフォルトのエラーページは、Webサーバのハードニングプロセスの一環として、置き換え/削除する必要があります。
”ErrorDocument" ディレクティブは (例としてApache) Webサーバ用のカスタムエラーページ/テキストを定義するために使用されます。
デフォルトのエラーページを置き換える/削除する方法については、お使いのWebサーバのドキュメントを参照してください。
情報漏洩を防ぐため、Webサーバのテストページは削除することをお勧めします。
デフォルトでは、WebサーバーのWebrootには、index.htmlと呼ばれるテストページが含まれています。
(Ubuntu の Apache2 を例としています):
テストページは、Webサーバのハードニングプロセスの一環として削除するか、利用できないようにする必要があります。
デフォルトでは、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 は、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
ディレクティブを使用してファイルへのアクセスを制限することができます。
Apacheでは、 - .htacess
ファイルで:
Zabbix Java gatewayのlogbackバージョン1.2.7およびそれ以前のバージョンでは、
設定ファイルの編集に必要な権限を持つ攻撃者が、不正な設定を行うことが可能です。
これにより、攻撃者はLDAPサーバから読み込まれた任意のコードを実行できるようになります。
CVE-2021-42550 の脆弱性は Zabbix 5.4.9以降修正されています。
しかし、追加のセキュリティ対策として、以下のことを行うことを推奨します。
/etc/zabbix/zabbix_java_gateway_logback.xml
ファイルのパーミッションをチェックし、
"zabbix" ユーザに書き込み権限がある場合は、読み取り専用に設定することを推奨します。