概要

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

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

アクセス制御

最小権限の原則

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

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

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

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

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

UTF-8 エンコーディング

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

Windowsインストーラーのパス

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

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

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

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

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

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

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ヘッダーを完全にオフにすることはお勧めできません。

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

OpenSSLでコンパイルされたZabbix Windowsエージェントは、c:\openssl-64bitにあるSSL構成ファイルにアクセスしようとします。 ディスクC:の"openssl-64bit"ディレクトリは、非権限ユーザーでも作成できます。

そのため、セキュリティ強化のため、このディレクトリを手動で作成し、管理者以外のユーザーからの書き込みアクセスを取り消す必要があります。

32bit版と64bit版のWindowsでは、ディレクトリ名が異なることに注意してください。

暗号化

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

パスワードのブルートフォース攻撃の複雑さを増すために、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>

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