3 Webサーバー

概要

このセクションでは、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 サーバーを設定します。

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 サーバーはソフトウェア署名を公開します。

署名を無効にするには、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サーバーは組み込みのエラーページを使用します。

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

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

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

情報漏洩を避けるため、Webサーバのテストページを削除することをお勧めします。

By default, the Apache web server webroot contains the index.html test page: デフォルトでは、Apache WebサーバーのWebrootにはindex.htmlテスト ページが含まれています。

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

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

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

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

これらの設定により、Zabbixフロントエンドのセキュリティが強化され、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;
       }