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

概要

このセクションには、Zabbix を安全な方法で設定するために遵守すべきベスト プラクティスが含まれています。

ここに含まれるプラクティスは、Zabbix の機能には必要ありません。 システムのセキュリティを強化するために推奨されます。

アクセス制御

最小権限の原則

Zabbixでは常に最小権限の原則を使用する必要があります。 この原則は、ユーザーアカウント(Webインターフェース) またはプロセスユーザー(Zabbixサーバー/プロキシ/エージェント) が、意図した機能を実行するために必要な権限のみを持つことを意味します。 言い換えると、ユーザーアカウントは常に、できるだけ少ない権限で実行する必要があります。

'zabbix'ユーザーに追加の権限を与えると、設定ファイルにアクセスし、インフラストラクチャ全体のセキュリティを侵害する可能性のある操作を実行できるようになります。

ユーザー アカウントに最小権限の原則を実装する場合、Zabbix Webインターフェースのユーザータイプを考慮する必要があります。 "Admin"ユーザータイプの権限は"Super Admin"ユーザータイプよりも低いですが、設定の管理やカスタムスクリプトの実行を許可する管理権限があることを理解することが重要です。

一部の情報は、権限を持たないユーザーでも利用できます。 たとえば、管理 → スクリプト はSuper Admin以外は利用できませんが、スクリプト自体はZabbix APIを使用して取得できます。 グローバルスクリプトで利用可能な機密情報の公開を避けるために、スクリプトのアクセス許可を制限し、機密情報 (アクセス資格情報など) を追加しないようにする必要があります。

Zabbixエージェントのセキュアユーザー

デフォルト構成では、ZabbixサーバーとZabbixエージェントのプロセスは単一の'zabbix'ユーザーを共有します。 エージェントがサーバー設定の機密情報 (データベースのログイン情報など) にアクセスできないようにしたい場合は、エージェントを別のユーザーとして実行する必要があります。

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

SSL設定への書き込み権限の無効化(Windows)

Windows上でZabbixエージェントをコンパイルし、OpenSSLを保護されていないディレクトリ(例: c:\openssl-64bit、C:\OpenSSL-Win64-111-static、C:\dev\openssl)に配置している場合は、管理者以外のユーザーによるこのディレクトリへの書き込み権限を必ず無効にしてください。無効にしないと、Zabbixエージェント2は権限のないユーザーが変更できるパスからSSL設定を読み込み、潜在的なセキュリティ脆弱性が発生します。

UNC path access on Windows by Zabbix agent

Zabbix agents on Windows follow UNC paths (SMB shares like \\server\share\file.txt) in items like vfs.file.*, vfs.dir.*, and perf_counter*. This can be a security risk in some contexts.

When Windows is asked to access a UNC path, it tries to authenticate on that server. This means that a malicious request to Zabbix agent can expose the NTLM hash to the requesters server. Users can mitigate this with AllowKey, DenyKey configuration parameters if they need to.

暗号化

ZabbixのWebインターフェースのSSLのセットアップ

RHELベースのシステムでは、mod_sslパッケージをインストールします :

dnf 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アドレスを入力することができます。

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を有効にする

RHEL ベースのシステムでは、仮想ホストをApache構成 (/etc/httpd/conf/httpd.conf)に追加し、ドキュメントルートの永続的なリダイレクトをZabbix SSL URLに設定します。 example.com は実際のサーバー名に置き換えてください。

# Add lines:

<VirtualHost *:*>
    ServerName example.com
    Redirect permanent / https://example.com
</VirtualHost>

変更を適用するため、Apacheサービスを再起動します。

systemctl restart httpd.service

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

Zabbix Webコンソールをプロトコルダウングレード攻撃から保護するには、WebサーバーでHSTSポリシーを有効にすることをお勧めします。

Apache構成でZabbixフロントエンドのHSTSポリシーを有効にするには、次の手順に従います。

1. 仮想ホストの構成ファイルを見つけます。

  • RHELベースのシステムの場合、/etc/httpd/conf/httpd.conf
  • Debian/Ubuntuの場合、/etc/apache2/sites-available/000-default.conf

2. 次のディレクティブを仮想ホストの設定ファイルに追加します。

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

3. 変更を適用させるため、Apacheサービスを再起動します。

# On RHEL-based systems:
systemctl restart httpd.service

# On Debian/Ubuntu
systemctl restart apache2.service

ZabbixでセキュアなセッションクッキーとSameSiteセッションクッキーを強制する

Zabbixを構成する場合、セキュリティを強化し、クロスサイトリクエストフォージェリ(CSRF)攻撃を防ぐために、セッションクッキーにセキュアな属性とSameSite属性を強制することが不可欠です。ただし、SameSite=Strictを強制すると、次のような特定のシナリオで問題が発生する可能性があります。

  • 同じドメインのiframeを埋め込むと、ダッシュボードURLウィジェットに"ユーザーはログインしていません"と表示される。
  • HTTPSではなくHTTP経由でダッシュボードにアクセスするユーザーは、ログインの問題に直面する可能性がある。
  • 特定のZabbixメニューセクションまたはホストへのURLを共有できない。

これらの問題を軽減するには、ユーザーがSameSiteポリシーを調整する方法が必要です。

1. セキュアなクッキー

secureフラグを設定すると、クッキーがHTTPS経由でのみ送信されるようになり、暗号化されていない接続での露出が防止されます。

Zabbixでセキュアクッキーを有効にするには、Webサーバー構成で次の設定を追加または変更します:

Apacheの場合:

Header always edit Set-Cookie ^(.*)$ $1;Secure

Nginxの場合:

proxy_cookie_path / "/; Secure";

ZabbixフロントエンドがHTTPS経由でアクセスされていることを確認します。そうでない場合、Secureフラグ付きのクッキーは送信されません。

2. SameSite属性の構成

Webサーバー設定でSameSite属性を適用することもできます:

Apacheの場合:

<IfModule mod_headers.c>
Header onsuccess edit Set-Cookie (.*) "$1; SameSite=Strict"
</IfModule>

Nginx(バージョン1.19.3+)の場合:

proxy_cookie_flags ~ samesite=Strict; # 特異性のために~を'zbx_session'に置き換えます

Webサーバーでコンテンツセキュリティポリシー (CSP)を有効にする

Zabbix Webインターフェースをクロスサイトスクリプティング (XSS)、データ インジェクション、および同様の攻撃から保護するには、Webサーバーでコンテンツセキュリティポリシーを有効にすることをお勧めします。 これを行うには、HTTPヘッダーを返すようにWeb サーバーを設定します。

次のCSPヘッダー設定は、デフォルトのZabbix Webインターフェースインストールおよびすべてのコンテンツがサイトのドメイン (サブドメインを除く) から発信されている場合にのみ適用されます。 たとえば、サイトのサブドメインまたは外部ドメインのコンテンツを表示するように URL ウィジェットを構成している場合、別のCSPヘッダー構成が必要になる場合があります。 OpenStreetMapを別のマップエンジンに追加するか、外部CSSまたはウィジェットを追加します。

Apache構成でZabbix WebインターフェースのCSPを有効にするには、次の手順に従います。

1. 仮想ホストの設定ファイルを見つけます。

  • RHELベースのシステムの場合、/etc/httpd/conf/httpd.conf
  • Debian/Ubuntuの場合、/etc/apache2/sites-available/000-default.conf

2. 次のディレクティブを仮想ホストの設定ファイルに追加します。

<VirtualHost *:*>
    Header set Content-Security-Policy: "default-src 'self' *.openstreetmap.org; script-src 'self' 'unsafe-inline' 'unsafe-eval'; connect-src 'self'; img-src 'self' data: *.openstreetmap.org; style-src 'self' 'unsafe-inline'; base-uri 'self'; form-action 'self';"
</VirtualHost>

3. 変更を適用させるため、Apacheサービスを再起動します。

# On RHEL-based systems:
systemctl restart httpd.service

# On Debian/Ubuntu
systemctl restart apache2.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 (libapache2-mod-security2パッケージ)を使用すると、追加のセキュリティレベルを達成できます。 mod_securityを使用すると、サーバー署名からバージョンを削除するだけでなく、サーバー署名を削除できます。mod_securityをインストールした後、"SecServerSignature"を任意の値に変更することで、署名を任意の値に変更できます。

ソフトウェア署名を削除/変更する方法については、Web サーバーのドキュメントを参照してください。

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

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

デフォルトのエラーページは、Webサーバーの強化プロセスの一環として置き換えまたは削除する必要があります。 例えばApache Webサーバーならば、"ErrorDocument"ディレクティブを使用してカスタムエラーページ/テキストを定義できます。

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

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

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

Webサーバーの強化プロセスの一環として、テストページを削除するか、使用できないようにする必要があります。

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

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

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

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

一般的なパスワードリストのファイルを非表示にする

パスワードのブルートフォース攻撃の複雑さを増すために、Webサーバーの設定を変更してファイルui/data/top_passwords.txtへのアクセスを制限することをお勧めします。 このファイルには、最も一般的なパスワードとコンテキスト固有のパスワードのリストが含まれており、パスワードポリシーで 推測されやすいパスワードを避けるパラメーターが有効になっている場合に、ユーザーがそのようなパスワードを設定できないようにするために使用されます。

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

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

Apacheの場合は.htaccessファイルを使用します。

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

UTF-8 エンコーディング

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

Windowsインストーラーのパス

Windowsインストーラーを使用する場合は、適切なアクセス許可なしでカスタムパスを使用すると、インストールのセキュリティが損なわれる可能性があるため、インストーラーによって提供されるデフォルトのパスを使用することをお勧めします。

Macros in user-defined global scripts

To enhance security, it is recommended to use macro functions instead of plain macros in user-defined global scripts, as macros are not automatically escaped.

ZabbixセキュリティアドバイザリとCVEデータベース

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