[comment]: # ({f4bccb67-40cfdec2})
# 3 Webサーバー

[comment]: # ({/f4bccb67-40cfdec2})

[comment]: # ({2ff4365d-129e34f5})
#### 概要

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

[comment]: # ({/2ff4365d-129e34f5})

[comment]: # ({a38dec5b-bb3706f4})
#### ルートURLからZabbix SSLへのリダイレクトを強制する

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

```ini
# 行を追加:

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

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

```bash
systemctl restart httpd.service
```

[comment]: # ({/a38dec5b-bb3706f4})

[comment]: # ({3d62d250-c7ee0bb2})
#### WebサーバーでHTTP Strict Transport Security (HSTS)を有効にする

Zabbix Webコンソールをプロトコルダウングレード攻撃から保護するには、Webサーバーで[HSTS](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security)ポリシーを有効にすることをお勧めします。

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

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

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

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

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

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

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

# On Debian/Ubuntu
systemctl restart apache2.service
```

[comment]: # ({/3d62d250-c7ee0bb2})

[comment]: # ({09df8737-8057bf9f})
#### 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'に置き換えます

[comment]: # ({/09df8737-8057bf9f})

[comment]: # ({0291801e-55d3532e})
#### Webサーバーでコンテンツセキュリティポリシー (CSP)を有効にする

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

::: noteimportant
次のCSPヘッダー設定は、デフォルトのZabbix Webインターフェースインストールおよびすべてのコンテンツがサイトのドメイン (サブドメインを除く) から発信されている場合にのみ適用されます。
たとえば、サイトのサブドメインまたは外部ドメインのコンテンツを表示するように [*URL*](/manual/web_interface/frontend_sections/dashboards/widgets/url) ウィジェットを構成している場合、別のCSPヘッダー構成が必要になる場合があります。 *OpenStreetMap*を別のマップエンジンに追加するか、外部CSSまたはウィジェットを追加します。
Duo Universal Prompt [多要素認証](/manual/web_interface/frontend_sections/users/authentication/mfa)方式を使用している場合は、仮想ホストの構成ファイルのCSPディレクティブに"duo.com"を必ず追加してください。 
:::

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

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

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

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

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

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

# On Debian/Ubuntu
systemctl restart apache2.service
```

[comment]: # ({/0291801e-55d3532e})

[comment]: # ({cc2b15aa-cd09dcd1})
#### Webサーバー情報の公開を無効にする

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

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

![](../../../../assets/en/manual/installation/requirements/software_signature.png)

署名を無効にするには、Apache構成ファイルに次のパラメータを追加します。

```ini
ServerSignature Off
ServerTokens Prod
```

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

```ini
expose_php = Off
```

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

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

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

[comment]: # ({/cc2b15aa-cd09dcd1})

[comment]: # ({2053690e-720052da})
#### Webサーバーのデフォルトエラーページを無効にする

情報漏洩を避けるため、デフォルトのエラーページを無効にすることをお勧めします。

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

![](../../../../assets/en/manual/installation/requirements/error_page_text.png)

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

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

[comment]: # ({/2053690e-720052da})

[comment]: # ({5dd327a4-ba1547c0})
#### Webサーバーのテストページを削除する

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

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

![](../../../../assets/en/manual/installation/requirements/test_page.png)

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

[comment]: # ({/5dd327a4-ba1547c0})

[comment]: # ({47163d34-7e4e4a45})
#### X-Frame-Options HTTP応答ヘッダーを設定する

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

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

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

[comment]: # ({/47163d34-7e4e4a45})

[comment]: # ({ac11e1b7-3f76ae70})
#### 一般的なパスワードリストのファイルを非表示にする

パスワード総当たり攻撃の複雑さを増すために、`ui/data/top_passwords.txt`ファイルへのアクセスを制限することをお勧めします。
このファイルには、最も一般的でコンテキスト固有のパスワードのリストが含まれており、ユーザーがそのようなパスワードを設定できないようにします ([パスワードポリシー](/manual/web_interface/frontend_sections/users/authentication#internal_authentication)で *推測しやすいパスワードを避ける*パラメーターが有効になっている場合)。

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

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

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

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

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

[comment]: # ({/ac11e1b7-3f76ae70})
