このセクションには、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 を別のユーザで実行する必要があります:
Zabbix がサポートするエンコーディングは UTF-8 のみです。 セキュリティ上の欠陥なく動作することが知られています。 ユーザーは他のエンコーディングを使用する場合、既知のセキュリティ上の問題があることを留意してください。
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.
RHELの場合、mod_sslパッケージをインストールします:
SSL鍵用のディレクトリを作成します:
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のサービスを再起動します:
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 header がSAMEORIGIN
に設定されて設定されています。つまり、ページ自体と同じオリジンを持つフレームにのみコンテンツをロードできます。
外部 URL (つまりURL ダッシュボード ウィジェット) からコンテンツをプルする Zabbix フロントエンド要素は、すべてのサンドボックス制限が有効になっているサンドボックスで取得されたコンテンツを表示します。
これらの設定により、Zabbix フロントエンドのセキュリティが強化され、XSS およびクリックジャッキング攻撃に対する保護が提供されます。 スーパー管理者は、必要に応じて iframe sandboxing および X-Frame-Options HTTP response header パラメータを 変更できます。 デフォルト設定を変更する前に、リスクと利点を慎重に検討してください。 サンドボックスまたは X-Frame-Options を完全にオフにすることはお勧めしません。
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
ディレクティブを使用してファイルへのアクセスを制限することができます。
Apacheでは、 - .htacess
ファイルで:
Zabbix セキュリティ アドバイザリと CVE データベース を参照してください。