3 Webサーバー

概要

このセクションでは、Webサーバーを安全に設定するためのベストプラクティスを説明します。

Zabbix SSL へのルート URL リダイレクトの強制

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

# 次の行を追加します:

<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 Webインターフェースに対して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サービスを再起動します。

# RHEL系システムでは:
systemctl restart httpd.service

# Debian/Ubuntuでは
systemctl restart apache2.service

ZabbixでのSecureおよびSameSiteセッションCookieの強制

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

  • 同一ドメインのiframeを埋め込んだ場合に、ダッシュボードのURLウィジェットで「user not logged in」と表示される。
  • HTTPSではなくHTTP経由でダッシュボードにアクセスするユーザーが、ログインの問題に直面する可能性がある。
  • 特定のZabbixメニューセクションやホストへのURLを共有できない。

これらの問題を軽減するには、ユーザーがSameSiteポリシーを調整できるようにする必要があります。

1. Secure cookie

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

Zabbixでsecure cookieを有効にするには、Webサーバーの設定に次の設定を追加または変更します。

Apacheの場合:

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

Nginxの場合:

proxy_cookie_path / "/; Secure";

ZabbixのWebインターフェースがHTTPS経由でアクセスされていることを確認してください。そうでない場合、Secure フラグ付きのCookieは送信されません。

2. SameSite属性の設定

Webサーバーの設定でもSameSite属性を強制できます。

Apacheの場合:

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

Nginx（version 1.19.3+）の場合:

proxy_cookie_flags ~ samesite=Strict; # より具体的にするには ~ を 'zbx_session' に置き換える

WebサーバーでContent Security Policy (CSP) を有効にする

Zabbix Webインターフェースをクロスサイトスクリプティング (XSS)、データインジェクション、および同様の攻撃から保護するため、WebサーバーでContent Security Policyを有効にすることを推奨します。
そのためには、Webサーバーが HTTPヘッダー を返すように設定します。

以下のCSPヘッダー設定は、デフォルトのZabbix Webインターフェースのインストール、およびすべてのコンテンツがサイトのドメイン（サブドメインを除く）に由来する場合にのみ適用されます。
たとえば、URL ウィジェットでサイトのサブドメインや外部ドメインのコンテンツを表示する場合、OpenStreetMap から別の地図エンジンに切り替える場合、または外部CSSやウィジェットを追加する場合には、別のCSPヘッダー設定が必要になることがあります。
Duo Universal Prompt 多要素認証 メソッドを使用している場合は、仮想ホストの設定ファイルにあるCSPディレクティブへ "duo.com" を追加してください。

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サービスを再起動します。

# RHELベースのシステム:
systemctl restart httpd.service

# Debian/Ubuntu
systemctl restart apache2.service

Webサーバー情報の公開を無効にする

セキュリティを向上させるため、すべてのWebサーバー署名を無効にすることを推奨します。

デフォルトでは、Webサーバーはソフトウェア署名を公開しています。

署名は、Apacheの設定ファイルに次のパラメータを追加することで無効にできます。

ServerSignature Off
ServerTokens Prod

PHPの署名（X-Powered-By HTTPヘッダー）は、php.ini 設定ファイルを変更することで無効にできます（デフォルトでは署名は無効です）。

expose_php = Off

設定ファイルの変更を適用するには、Webサーバーの再起動が必要です。

さらにセキュリティを強化するには、Apacheで mod_security ツール（パッケージ libapache2-mod-security2）を使用できます。 このツールを使用すると、サーバー署名からバージョンのみを削除するのではなく、サーバー署名自体を削除できます。 mod_security をインストールした後、"SecServerSignature" を任意の値に設定することで、サーバー署名を任意の値に変更できます。

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

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

情報漏えいを防ぐため、デフォルトのエラーページを無効にすることを推奨します。

デフォルトでは、Webサーバーは組み込みのエラーページを使用します。

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

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

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

情報漏えいを防ぐため、Webサーバーのテストページを削除することを推奨します。

デフォルトでは、Apache Webサーバーのwebrootには index.html のテストページが含まれています。

デフォルトのテストページの削除方法については、Webサーバーのドキュメントを参照してください。

X-Frame-Options HTTPレスポンスヘッダーの設定

デフォルトでは、Zabbixは Use X-Frame-Options HTTP header パラメータが SAMEORIGIN に設定された状態で構成されています。
これは、コンテンツがページ自身と同じオリジンを持つフレーム内でのみ読み込めることを意味します。

外部URLからコンテンツを取得するZabbix Webインターフェースの要素（具体的には、URL ダッシュボードウィジェット）は、すべてのサンドボックス制限を有効にしたサンドボックス内で取得したコンテンツを表示します。

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

一般的なパスワード一覧ファイルを隠す

パスワードのブルートフォース攻撃の難易度を高めるために、ui/data/top_passwords.txt ファイルへのアクセスを制限することを推奨します。
このファイルには、最も一般的でコンテキスト固有のパスワードの一覧が含まれており、そのようなパスワードの設定をユーザーが行えないようにします（パスワードポリシーで 推測されやすいパスワードを避ける パラメータが有効な場合）。

top_passwords.txt ファイルへのアクセスを制限するには、Webサーバーの設定を変更します。

Apache では、.htaccess ファイルを使用してファイルアクセスを制限できます。

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

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

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