Citrix ADCの安全な導入ガイド

Citrix ADC MPX、VPX、およびSDXセキュリティのベストプラクティス

December 7, 2022

寄稿者:

Citrix ADC MPXアプライアンスは、Webサイトの高速化、L4-L7トラフィック管理、統合されたCitrix Web App Firewall を提供し、サーバーの負荷を軽減するアプリケーション配信Controller です。Citrix ADC VPXインスタンスは、Citrix ADC MPXアプライアンスのすべての機能を持ち、標準サーバー上で実行され、Citrix XenDesktop やXenAppなどのWebアプリケーションでより高い可用性を実現する仮想アプライアンスです。Citrix ADC SDXアプライアンスは、VPXのすべての柔軟性とMPXのパフォーマンスのための高度な仮想化を提供します。MPX、VPX、SDX を使用することで、大量の共有ネットワークサービスをプロセッサ集約型のアプリケーション固有のサービスから分離することで、Web アプリケーション配信インフラストラクチャを最適化するフレックスまたは真のマルチテナンシーソリューションを展開できます。Citrix ADCアプライアンスは、Citrix OpenCloud Accessとのシームレスな統合も提供し、クラウドの力でデータセンターを拡張できます。

展開のライフサイクルを通じてセキュリティを維持するために、次の考慮事項を確認Citrix。

物理的セキュリティ
アプライアンスのセキュリティ
Network Security
管理と管理

展開が異なれば、セキュリティに関する考慮事項も異なる場合があります。このドキュメントでは、特定のセキュリティ要件に基づいて、適切なセキュアな展開を決定する際に役立つ、一般的なセキュリティガイダンスを提供します。

重要：

ソフトウェアバージョンリリース12.1から、NetScalerはCitrix ADCにブランド名変更されました。詳しくは、https://www.citrix.com/about/citrix-product-guide/を参照してください。

導入ガイドライン

Citrix ADC を展開するときは、物理的およびアプライアンスのセキュリティに関する次のベストプラクティスを考慮してください。

物理的セキュリティのベストプラクティス

Citrix ADCアプライアンスを安全な場所に展開する

Citrix ADCアプライアンスは、アプライアンスを不正アクセスから保護するために、十分な物理アクセス制御を備えた安全な場所に展開する必要があります。最低でも、サーバルームへのアクセスは、ロック、電子カードリーダー、またはその他の同様の物理的方法で制御する必要があります。

その他の対策には、CCTVなどの電子監視システムを使用して、部屋の活動を継続的に監視することが含まれます。不正侵入が発生した場合、このシステムからの出力はセキュリティ担当者に通知する必要があります。CCTV がある場合、記録された映像は監査目的で利用できます。

アプライアンスのフロントパネルとコンソール・ポートへの安全なアクセス

Citrix ADCアプライアンスまたはVPXホスティングサーバーは、適切なキーまたはその他の物理的な方法でロックできるラックまたはケージに配置する必要があります。ロックにより、Citrix ADCアプライアンス、またはVPX展開では仮想化ホストコンソールの物理ポートにアクセスできなくなります。

電源の保護

Citrix ADCアプライアンス（またはホスティングサーバー）は、適切な無停電電源で保護する必要があります。停電が発生した場合、無停電電源装置はアプライアンスの継続的な動作を保証するか、または物理的なまたは仮想のCitrix ADCの制御されたシャットダウンを可能にします。無停電電源装置の使用は、電源スパイクに対する保護にも役立ちます。

暗号化キーの保護

展開の暗号化キーに追加の保護が必要な場合は、FIPS 140-2 レベル 2 準拠のアプライアンスの使用を検討してください。FIPSプラットフォームは、ハードウェアセキュリティモジュールを使用して、アプライアンス内の重要な暗号化キーを不正アクセスから保護します。

Citrix ADCアプライアンスのセキュリティのベストプラクティス

アプライアンスのソフトウェアの更新の実行

展開前に、アプライアンスが最新のファームウェアバージョンで更新されていることを確認することを強くお勧めします。リモートで実行する場合は、SFTPやHTTPSなどのセキュアなプロトコルを使用してアプライアンスをアップグレードすることをお勧めします。

また、Citrix製品に関連するセキュリティ情報も確認することをお勧めします。新規および更新されたセキュリティ情報について詳しくは、Citrix Security Bulletins Webページhttps://support.citrix.com/securitybulletinsを参照し、新規および更新されたセキュリティ情報のアラートhttps://support.citrix.com/user/alertsへの登録を検討してください。

Citrix ADC VPXアプライアンスをホストするサーバーのオペレーティングシステムのセキュリティ保護

Citrix ADC VPXアプライアンスは、標準の仮想化サーバー上で仮想アプライアンスを実行することも、Citrix ADC SDX上で仮想アプライアンスとして実行することもできます。

通常の物理セキュリティ手順の適用に加えて、役割ベースのアクセス制御と強力なパスワード管理により、仮想化ホストへのアクセスを保護する必要があります。また、サーバが使用可能になったときにオペレーティングシステムの最新のセキュリティパッチでサーバを更新し、仮想化のタイプに該当する場合は最新のウイルス対策ソフトウェアをサーバ上に展開する必要があります。Citrix ADC SDXプラットフォームを使用してCitrix ADC VPXをホストするお客様は、Citrix ADC SDX用に最新のファームウェアバージョンを使用していることを確認する必要があります。

Citrix ADCライトアウト管理（LOM）をリセットする

実稼働環境で使用するためにLOMを構成する前に、LOMを出荷時設定にリセットしてデフォルト設定に戻すことをお勧めします。

Citrix ADC シェルプロンプトで、次のコマンドを実行します。
```
>ipmitool raw 0x30 0x41 0x1

```
注: 上記のコマンドを実行すると、LOM が工場出荷時のデフォルト設定にリセットされ、すべての SSL 証明書が削除されます。LOMポートを再構成する方法については、「 Citrix ADC MPXアプライアンスの管理ポートが消灯」を参照してください。
LOM GUI で、[ 構成] > [SSL 認定] に移動し、証明書と秘密キーを追加します。

また Citrix ユーザー構成を行うことを強くお勧めします。LOM GUI を使用する:
- [ 構成 ] > [ ユーザー] > [ユーザーの変更 ] に移動し、 nsroot スーパーユーザーアカウントのパスワードを変更します。
- [ 構成 ] > [ ユーザー] > [ユーザーの変更] に移動し、ユーザーのポリシーを作成するか、既存のポリシーをバインドします。
- [ 構成 ] > [ IP アクセスコントロール] > [追加] に移動し、既知の IP アドレス範囲へのアクセスを許可するように IP アクセスコントロールを設定します。
- [ 構成 ] > [ ユーザー] > [ユーザーの変更] に移動し、代替スーパーユーザーアカウントを作成し、このアカウントにポリシーをバインドします。
LOM 設定の詳細については、 LOM 設定を参照してください。

永続データの保守と削除

Citrix ADCが別の環境に再デプロイされたり、廃止されたり、RMAの下でCitrix に返却されたりした場合は、永続データがアプライアンスから正しく削除されていることを確認します。

このプロセスについて詳しくは、「 ADCアプライアンスをCitrixに送信する前にデータを消去する」を参照してください。

設定ガイドライン

ネットワークセキュリティ

Citrix ADCアプライアンスを実稼働環境に展開する場合は、以下の主要な構成変更を行うことを強くお勧めします。

Citrix ADC管理者インターフェイス（NSIP）をインターネットに公開しないでください。
Citrix ADC デフォルトのSSL証明書を置き換える必要があります。
GUI にアクセスし、デフォルトの HTTP インターフェイスが無効になっている場合は、HTTPS（HTTP over TLS）を使用する必要があります。

次のセクションでは、推奨されるその他の変更に加えて、これらの重要な考慮事項について詳しく説明します。

ネットワークセキュリティに関する重要な考慮事項

NSIP をインターネットに公開しないでください。

Citrix ADC Management IP（NSIP）をパブリックインターネットに公開せず、適切なステートフルパケットインスペクション（SPI）ファイアウォールの背後に展開することを強くお勧めします。

Citrix ADC デフォルトのTLS証明書を置き換えます。

Citrix ADCアプライアンスの初期構成中に、デフォルトのTLS証明書が作成されます。これらの証明書は、実稼働環境での使用を目的としていないため、置き換える必要があります。

Citrix ADCアプライアンスは、信頼できる認証局（CA）からの証明書、またはエンタープライズ認証局の適切な証明書のいずれかを使用するように構成することをお勧めします。

一般向け仮想サーバーにバインドされている場合、評判の良い CA からの有効な TLS 証明書は、インターネット向けの Web アプリケーションのユーザーエクスペリエンスを簡素化します。Web サーバーとのセキュアな通信を開始するときに、ユーザー Web ブラウザはユーザーの操作を必要としません。デフォルトのCitrix ADC証明書を信頼できるCA証明書に置き換えるには、ナレッジセンターの記事CTX122521：「Citrix ADCアプライアンスのデフォルト証明書を、アプライアンスのホスト名に一致する信頼できるCA証明書に置き換える方法」を参照してください。

または、カスタム TLS 証明書と秘密キーを作成して使用することもできます。これにより、同等のレベルのトランスポート層セキュリティが提供されますが、TLS 証明書をユーザーに配布する必要があり、Web サーバーへの接続を開始するときにはユーザーの操作が必要です。カスタム証明書を作成する方法の詳細については、ナレッジセンターの記事「CTX121617： Citrix ADCアプライアンスに自己署名証明書を作成してインストールする方法」を参照してください。

TLS証明書の管理と構成の詳細については、このガイドの「Citrix ADC TLSの推奨事項」セクションを参照してください。

管理者インターフェイスへの HTTP アクセスを無効にします。

Citrix ADC管理インターフェイスおよびGUIへのトラフィックを保護するには、HTTPSを使用するようにCitrix ADCアプライアンスを構成する必要があります。次の手順を実行します：

2048ビット以上のRSA秘密鍵と公開鍵のペアを作成し、HTTPSとSSHのキーを使用してCitrix ADC IPアドレスにアクセスし、出荷時にプロビジョニングされた512ビットRSA秘密鍵と公開鍵のペアを置き換えます。
強力な暗号スイートのみを使用するようにアプライアンスを設定し、アプライアンスの暗号スイートの「DEFAULT」セットを強力な暗号スイートに変更します。NIST スペシャルパブリケーション 800-52 (リビジョン 1) のセクション 3.3 で、承認された TLS 暗号スイートのリストを使用することをお勧めします。この文書は、NIST Web サイトの次のアドレスにあります。 https://www.nist.gov/publications/guidelines-selection-configuration-and-use-transport-layer-security-tls-implementations?pub_id=915295
SSH 公開キー認証を使用して管理者インターフェイスにアクセスするようにアプライアンスを設定します。Citrix ADC のデフォルトキーは使用しないでください。独自の 2048 ビットの RSA 秘密鍵と公開鍵のペアを作成して使用します。詳細については、Knowledge Center 記事「CTX109011：公開キー認証を使用してCitrix ADCアプライアンスへのSSHアクセスを保護する方法」および「Citrix製品ドキュメント：ローカルシステムユーザーのSSHキーベース認証」を参照してください。
これらの新しい証明書を使用するようにCitrix ADCを構成したら、次のコマンドを使用してGUI管理インターフェイスへのHTTPアクセスを無効にすることができます。

set ns ip <NSIP> -gui SECUREONLY
<!--NeedCopy-->

管理GUIへのセキュアなアクセスを構成する方法の詳細については、ナレッジセンターの記事「CTX111531：アプライアンスのSNIP/MIPアドレスを使用してCitrix ADC GUIへのセキュアアクセスを有効にする方法」を参照してください。

その他のネットワークセキュリティに関する考慮事項

SDX の管理を信頼していない VPX 管理者の VPX シェルアクセスを制限します。

別の人にSVMのVPXを管理させることが望ましい状況では、SVM管理者は、VPXでのシェルアクセスが制限されたVPX管理者ユーザーを作成し、制限された管理者ユーザーアカウントのみをVPX管理者に提供する必要があります。

一部の操作では、シェルアクセス (SSL 証明書の管理など) が必要な場合があります。ただし、VPXインスタンスシェルへのアクセス権を付与される必要があるのは、SVMの管理を信頼する個人に限られます。このセクションで後述する RBAC レベルのコマンドは、これらのアカウントに割り当てることができます。これらの推奨事項は、すべての SVM-IP/VPX-NSIP（L2/L3）管理ワークフローに適用され、安全なアクセス監査の目的で従う必要があります。

次の手順を使用して、VPX 管理者からシェルアクセスを削除できます。

既存の VPX インスタンスのセキュリティ保護：

VPX CLIにnsrootまたはスーパーユーザーとしてログインします。

このアカウントを使用せず、 nsroot スーパーユーザーアカウントを作成することをお勧めします。 nsroot アカウントを使用するときは、パスワードが特殊文字で強力であることを確認してください。強力なパスワードの詳細については、「管理および管理」を参照してください。
- SDX システム上の VPX インスタンスにユーザーと RBAC ポリシーを作成します。
- そのユーザーをポリシーにバインドします。
```
    > add system user userabc
    Enter password:
    Confirm password:
    Done
    > bind system user userabc superuser 2
    Done
    > add system cmdpolicy shell deny (shell)
    Done
    > bind system user userabc shell 1
    Done

```
注: この例では、シェルアクセスを拒否するシステム cmdpolicy (例: cmdpolicy name: shell) が作成されます。このポリシーは、作成されたユーザー userabc) に優先度が高い状態でバインドされます。デフォルトのスーパーユーザーcmdpolicyも、システムユーザーよりも低い優先度としてバインドされます。この設定では、作成されたシステムユーザにはスーパーユーザ RBAC ポリシーがありますが、シェルアクセスは拒否されます。

作成したユーザーとしてログインし、次の操作を実行します。

現在のユーザーが RBAC ポリシーを適用していることを確認します。
ユーザーが許可されているコマンドをすべて実行します。(例: show system cmdpolicy)
シェルの cmd を実行して、シェルアクセスが制限されていることを確認します。

ログイン名: userabc

サーバーからの事前認証バナーメッセージ:

| #############################################################################
> ##
| #
>  #
| #        WARNING: Access to this system is for authorized users only
>  #
| #         Disconnect IMMEDIATELY if you are not an authorized user!
>  #
| #
>  #
| #############################################################################
> ##
|
End of banner message from server
Keyboard-interactive authentication prompts from server:
| Password:
End of keyboard-interactive prompts from server
Last login: Thu May 13 04:11:15 2021 from 10.10.1.1
Done
<!--NeedCopy-->

> whoami
    UserName:  userabc        LoggedIn:  "Thu May 13 04:18:50 2021"
Done
<!--NeedCopy-->

そのVPXのコンソールで、そのユーザーとしてログインし、このユーザーにシェルアクセスが許可されていないことを確認します。
```
> shell
ERROR: Not authorized to execute this command [shell]

```

通常の admin ユーザ (nsroot) としてログインし、シェルアクセスが許可されていることを確認します。

> shell
Copyright (c) 1992-2013 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.

root@Zela-40G-10#
<!--NeedCopy-->

新しい VPX インスタンスのセキュリティ保護:

SVM GUI から新しい VPX インスタンスが作成されたら、インスタンス管理者ユーザーを作成し、[ シェル/SFTP/SCP アクセス ] チェックボックスをオフにします。シェルアクセスを無効にすると、 svm_access_policy (アクション DENY) は指定されたインスタンス管理者ユーザーに明示的にバインドされます。
VPX 管理者にこのユーザー情報を提供します。SDX ADMINはこのnsroot管理者パスワードを保持する必要があり、VPX管理者と共有してはなりません。

注記:

nsroot パスワードを変更するには、SVM にログオンしてインスタンスを選択し、パスワードを変更します。VPX CLIからnsrootパスワードを変更しないでください。
RBAC ユーザーの詳細については、「ユーザー、ユーザーグループ、およびコマンドポリシー」を参照してください。
SVMからCitrix ADCアプライアンスのパスワードを変更する方法については、Citrix ADCインスタンスの変更を参照してください。
インスタンス管理によるCitrix ADCアプライアンスのプロビジョニングについては、 Citrix ADCインスタンスの追加を参照してください。

SSH ポート転送を無効にします。

Citrix ADCアプライアンスでは、SSHポート転送は必要ありません。この機能を使用しない場合は、次の手順で無効にすることをお勧めします。

次の行を追加して /etc/sshd_config ファイルを編集します。

AllowTcpForwarding no
ファイルを保存して /nsconfig にコピーし、テスト中に再起動した場合に備えて変更が保持されるようにします。
以下のコマンドを使用して、 sshd プロセスを再起動します。
```
kill -HUP `cat /var/run/sshd.pid`

```

Citrix ADCアプライアンスを高可用性で構成します。

継続的な操作が必要な展開では、Citrix ADCアプライアンスを高可用性セットアップで展開できます。アプライアンスのいずれかが機能しなくなった場合、またはオフラインアップグレードが必要な場合、このようなセットアップは継続して動作します。

高可用性セットアップの構成方法については、 Citrix Docsの「 高可用性」>「高可用性の構成 」および「Citrix ADCで高可用性ペアを設定する方法」を参照してください。

ピアアプライアンス間のセキュアな通信をセットアップします。

Citrix ADCアプライアンスを高可用性、クラスタ、またはGSLBセットアップで構成した場合は、アプライアンス間の通信をセキュリティで保護します。

アプライアンス間の通信をセキュリティで保護するには、内部ユーザーアカウントまたはRPCノードのパスワードを変更し、［ Secure ］オプションを有効にすることをお勧めします。RPCノードは、構成およびセッション情報のシステム間通信に使用される内部システムエンティティです。

Citrix ADCアプライアンス機能は、内部ユーザーアカウントが無効になっているときに、内部通信にSSHキーベースの認証を使用することもできます。このような場合は、キー名を「ns_comm_key」に設定する必要があります。詳細については、「 SSHキーとパスワードなしでCitrix ADCアプライアンスにアクセスする」を参照してください。

デフォルトのパスワードを変更します。

セキュリティを強化するために、オンプレミスとクラウド環境の両方で、管理者、および内部ユーザーアカウントまたはRPCノードのパスワードを変更することをお勧めします。パスワードを頻繁に変更することをお勧めします。

管理者パスワード: 管理者パスワードの変更を参照してください。
内部ユーザアカウントまたは RPC ノードのパスワード: RPC ノードのパスワードの変更を参照してください。

注

また、内部ユーザーアカウントを無効にして、代わりにキーベース認証を使用することをお勧めします。

ネットワーク・セキュリティ・ドメインとVLANを設定します。

Citrix ADC アプライアンスの管理インターフェイスへのネットワークトラフィックは、物理的または論理的に通常のネットワークトラフィックから分離することを強くお勧めします。推奨されるベストプラクティスは、次の 3 つの VLAN を使用することです。

外部インターネット VLAN
管理 VLAN
内部サーバ VLAN

LOMポートを管理VLANの一部にするようにネットワークを構成することをお勧めします。

Citrix ADCアプライアンスをツーアームモードで展開する場合は、特定のポートを特定のネットワーク専用に割り当てます。VLAN タギングと 2 つのネットワークを 1 つのポートにバインドする必要がある場合は、2 つのネットワークのセキュリティレベルが同じ、または類似していることを確認する必要があります。

2 つのネットワークのセキュリティレベルが異なる場合は、VLAN タギングを使用しないでください。代わりに、特定のネットワークごとに専用のポートを用意し、アプライアンスのポートに分散された独立したVLANを使用することを検討してください。

Citrix Web App Firewallの使用を検討する： Citrix ADC Premiumエディションライセンスアプライアンスは、ポジティブなセキュリティモデルを使用し、コマンドインジェクション、SQLインジェクション、クロスサイトスクリプティングなどの脅威に対する保護のための適切なアプリケーションの動作を自動的に学習する組み込みのCitrix Web App Firewallを提供します。

Citrix Web App Firewall を使用すると、ユーザーはコードを変更することなく、構成をほとんど変更することなく、Webアプリケーションにセキュリティを強化できます。詳しくは、「Citrix Webアプリケーションファイアウォールの概要」を参照してください。

非管理アプリケーションへのアクセスを制限する：次のコマンドを実行して、非管理アプリケーションがCitrix ADCアプライアンスにアクセスする機能を制限します。

set ns ip <NSIP> -restrictAccess enabled
<!--NeedCopy-->

安全なクラスタ導入： Citrix ADCクラスタノードがデータセンターの外部に分散している場合は、ノード間メッセージング（NNM）、AppNNM、および高可用性の設定に安全なRPCを使用することを強くお勧めします。

Citrix ADCクラスタ内のすべてのCitrix ADC IPアドレスと高可用性セットアップに対してSecure RPC機能を有効にするには、次のコマンドを実行します。

set rpcnode <ip> -secure on
<!--NeedCopy-->

注:他の設定が必要になる場合があります。詳細については、Citrix Docsサイトのクラスタリングのトピックを参照してください。

L3クラスター展開に展開すると、Citrix ADCノード間のパケットは、送信元ノードと宛先ノードのNSIPアドレスをルーティングに使用する暗号化されていないGREトンネルを介して交換されます。IPsec トンネルが存在しない場合、インターネット経由で交換が行われると、NSIP はインターネット上に公開されます。これは、Citrix ADC セキュリティのベストプラクティスに準拠していないため、推奨されません。

クラスターをL3機能で使用するために、独自のIPSecソリューションを確立することを強くお勧めします。

IP 転送機能が使用されていない場合は、次のコマンドを使用して L3 モードを無効にします。

disable ns mode L3
<!--NeedCopy-->

グローバルサーバー負荷分散（GSLB）にセキュア MEP を使用する： GSLB の Citrix ADC アプライアンス間の MEP を暗号化するには、NSCLI から次のコマンドを実行します。

set rpcNode <GSLB Site IP> -secure yes
<!--NeedCopy-->

ロードバランシングの永続性クッキーを保護します。

SSL/TLSチャネルに加えて、負荷分散永続性Cookieを暗号化することをお勧めします。この方法の詳細については、「 HTTP Cookie の永続性」を参照してください。

DTLS DDoS 増幅攻撃を軽減するための HelloverifyRequest パラメーター:

Citrix ADCリリース12.1ビルド62.xおよびリリース13.0ビルド79.xから、このhelloverifyrequestパラメータはデフォルトで有効になっています。DTLS プロファイルでhelloverifyrequestパラメータを有効にすると、攻撃者またはボットがネットワークスループットを圧倒し、アウトバウンド帯域幅の枯渇につながるリスクを軽減できます。つまり、DTLS DDoS 増幅攻撃を軽減するのに役立ちます。

helloverifyrequestパラメータのステータスを表示するには、ADC CLI プロンプトで、次のように入力します。

show dtlsProfile
<!--NeedCopy-->

インフラストラクチャモード設定を使用してCitrix ADCアプライアンスのパススルートラフィックを保護する

Citrix Web App Firewallインフラストラクチャモードの設定は、Citrix ADCアプライアンスのパススルートラフィックを保護するために使用できます。これらのインフラストラクチャモード設定は、アプリケーションを中断することなく、基本的なレベルのセキュリティを提供します。次の一覧は、使用可能なインフラストラクチャモードの設定をまとめたものです。

セッション・ステート保護
セッション固定保護 (HTTP のみを有効にする)
HSTS (HTTP 厳密なトランスポートセキュリティ (HSTS) を有効にする)
強固な認証
エンドツーエンド SSL 優先 (TLS 1.2 および TLS 1.1)
プロキシ HTTPS/他のすべてのトラフィックを拒否

セッション・ステート保護:

推奨事項： Citrix ADCを有効にする：ほとんどのエンティティでデフォルトで有効

［ セッション状態保護 ］設定はデフォルトで有効になっており、特に構成する必要はありません。Citrix ADCアプライアンスが接続をプロキシするように構成されている場合。たとえば、フローがTCP以上の構成済み仮想サーバーまたはサービスを選択すると、Citrix ADCアプライアンスはステートフルセッションを作成します。Citrix ADCアプライアンスは引き続きこれらの接続の状態を維持し、このステートマシンに該当するパケットのみが処理されます。他のパケットは廃棄されるかリセットされます。

次のサービスタイプエンティティは、Citrix ADCアプライアンス上でこのステートフルな動作を実現します。

ADNS_TCP
直径、DNS_TCP
FTP-c
GRE-c
HTTP
MYSQL、MSSQL
NNTP
ORACLE
PUSH, PPTP
RTSP、RDP
SIP_SSL, SIP_TCP
SMPP
SSL, SSL_BRIDGE, SSL_DIAMETER, SSL_PUSH
SSL_TCP、SYSLOG_TCP
TCP
ADNS_TCP
RNAT (rnat_tcpproxy は有効)

セッション固定保護 (HttpOnly フラグを有効化するか、書き換えポリシーを追加する):

推奨事項：Citrix ADCアプライアンスまたはバックエンドサーバーによって設定されたCookieに対してHttpOnlyを有効にするには
Citrix ADC：Citrix ADCが挿入したCookieに対してデフォルトで有効になっています。バックエンドサーバーによって設定されたCookieの書き換えを介して可能です。

HttpOnly: HttpOnly フラグでCookie にタグを付けると、このCookie にはサーバーのみがアクセスする必要があることがブラウザに示されます。クライアントスクリプトから Cookie にアクセスしようとする試みは固く禁じられています。HttpOnlyクッキーは、適切に実装されていれば、一般的なクロスサイトスクリプティング攻撃の膨大なクラスを排除するのがはるかに難しくなります。

httpOnly フラグが設定されたクッキーの例を次に示します。

Set-Cookie: ASP.NET_SessionId=ig2fac55; path=/; HttpOnly
<!--NeedCopy-->

Citrix ADCによって挿入されたCookieは、デフォルトでHttpOnlyフラグを設定して、Cookieがスクリプト不可であり、クライアントアプリケーションに公開されてはならないことを示します。したがって、クライアントサイドスクリプトは Cookie にアクセスできず、クライアントはクロスサイトスクリプティングの影響を受けません。

コマンドラインインターフェイスを使用して HttpOnly フラグ設定を有効にするには、次の手順を実行します。

コマンドプロンプトで入力します。

set lb parameter -HttpOnlyCookieFlag (ENABLED)  
<!--NeedCopy-->

書き換えポリシーを使用して Cookie に Secure と HttpOnly を挿入します。

書き換えポリシーは、バックエンドサーバーから送信された Cookie に対してのみ Secure と HTTP を挿入します。

注:SSL VIP に対しては、セキュアクッキーと HttpOnly クッキーを併用できます。非 SSL VIP の場合は、HttpOnly フラグを挿入できます。

Citrix ADCでは、サーバーによって設定されたCookieにHTTPのみとセキュアフラグを含めることができます。

HttpOnly-クッキーのこのオプションを指定すると、Web ブラウザは HTTP (または HTTPS) プロトコルのみを使用してクッキーを返します。JavaScript document.cookie 参照などの HTTP 以外のメソッドは Cookie にアクセスできません。このオプションは、クロスサイトスクリプティングによる Cookie の盗難を防ぐのに役立ちます。
セキュア -クッキーに対するこのオプションを使用すると、送信が SSL で暗号化されているときに、Web ブラウザは Cookie 値のみを返します。このオプションは、接続の盗聴によるクッキーの盗難を防ぐために使用できます。

コマンドラインインターフェイスを使用して書き換えポリシーを作成するには、次の手順を実行します。

リライト機能がまだ有効になっていない場合は有効にします。
```
enable feature REWRITE

```

書き換えアクションを作成します (この例では、Secure フラグと HttpOnly フラグの両方を設定するように構成されています)。どちらかが欠けている場合は、必要に応じて他の組み合わせに変更します)。

add rewrite action <action name> replace_all http.RES.full_Header ""path=/; Secure; HttpOnly"" -search "regex(re!(path=/\\; Secure; HttpOnly)|(path=/\\; Secure)|(path=/\\; HttpOnly)|(path=/)!)" -bypassSafetyCheck YES
<!--NeedCopy-->

例:

add rewrite action act_cookie_Secure replace_all http.RES.full_Header ""path=/; Secure; HttpOnly"" -search "regex(re!(path=/\\; Secure; HttpOnly)|(path=/\\; Secure)|(path=/\\; HttpOnly)|(path=/)!)"

or

add rewrite action act_cookie_Secure replace_all http.RES.full_Header ""path=/; Secure; HttpOnly"" -search "regex(re!(path=/\\; Secure; HttpOnly)|(path=/\\; Secure)|(path=/\\; HttpOnly)|(path=/)!)" -bypassSafetyCheck YES
<!--NeedCopy-->

注： Citrix ADCリリース13.1以降では、bypassSafetyCheckパラメータは適用されません。ただし、13.1 より前のリリースでは、このパラメータがサポートされています。

アクションをトリガーする書き換えポリシーを作成します。

add rewrite policy <policy name> "http.RES.HEADER("Set-Cookie").EXISTS" <action name>
<!--NeedCopy-->

例:

add rewrite policy rw_force_secure_cookie "http.RES.HEADER("Set-Cookie").EXISTS" act_cookie_Secure
<!--NeedCopy-->

書き換えポリシーをセキュリティ保護する仮想サーバーにバインドします ([Secure] オプションを使用する場合は、SSL 仮想サーバーを使用する必要があります)。
```
bind lb vserver <vserver name> - <policy name> -priority <priority number> -gotoPriorityExpression NEXT -type RESPONSE

```
例:
```
bind lb vserver mySSLVServer -policyName rw_force_secure_cookie -priority 100 -gotoPriorityExpression NEXT -type RESPONSE

```
詳しくは、https://support.citrix.com/article/CTX138055を参照してください。

HSTS (HTTP 厳密なトランスポートセキュリティ (HSTS) を有効にする):

Citrix ADC コマンドラインを使用してHSTSを有効にするには：

コマンドプロンプトで入力します。

add ssl vserver <vServerName> -HSTS ( ENABLED ) maxage <positive_integer> -IncludeSubdomains ( YES | NO)
<!--NeedCopy-->

または

add ssl profile <name> -HSTS ( ENABLED ) -maxage <positive_integer> -IncludeSubdomains ( YES | NO )
<!--NeedCopy-->

詳細については、以下のトピックを参照してください。

強力な認証:

機密データ、アプリ、および管理へのすべてのアクセスに対して、強力な認証（または多要素認証-MFA）を有効にする必要があります。

多要素認証の機密アプリの設定方法の詳細については、「多要素 (nFactor) 認証」を参照してください。

エンドツーエンド SSL 優先 (TLS 1.2 および TLS 1.1):

フロントエンドとバックエンドの両方に SSL を使用することをお勧めします。セキュリティ脆弱性が報告されているため、SSLv3 と TLS v1.0 を SSL エンティティで無効にすることができます。TLS 1.1 と TLS 1.2 のみ有効にできます。可能であれば、クライアント側のVIPにはTLS 1.2バージョンのみを使用してください。これは SSL エンティティレベルまたはプロファイルレベルで実行でき、すべての SSL エンティティはプロファイルから SSL 設定を継承します。

コマンドラインインターフェイスを使用して SSL エンティティを無効にするには、次の手順を実行します。

コマンドプロンプトで入力します。

set ssl vserver <vServerName> -ssl2 DISABLED   -ssl3  DISABLED   -tls1   DISABLED   -tls11   DISABLED

set ssl service <vServiceName> -ssl2 DISABLED   -ssl3  DISABLED   -tls1   DISABLED   -tls11   DISABLED
<!--NeedCopy-->

SSL プロファイルが有効な場合は、次のコマンドを使用します。

set ssl profile <frontend profile> -ssl3  DISABLED   -tls1   DISABLED  -tls11  DISABLED

set ssl profile <backend profile> -ssl3  DISABLED   -tls1   DISABLED  -tls11  DISABLED
<!--NeedCopy-->

Citrix ADC推奨暗号スイート：

Citrix ADCでサポートされている次の暗号には、「必須破棄」リストにはコンポーネントが含まれていません。これらの暗号は、鍵交換（RSA、DHE、ECDHE）によって編成され、次に高性能の暗号を上部に配置し、セキュリティの高い暗号を下部に配置します。

RSA キーエクスチェンジ暗号スイートの推奨:

TLS1-AES-128-CBC-SHA
TLS1-AES-256-CBC-SHA
TLS1.2-AES-128-SHA256
TLS1.2-AES-256-SHA256
TLS1.2-AES128-GCM-SHA256
TLS1.2-AES256-GCM-SHA384

DHE キー交換暗号スイートの推奨:

TLS1-DHE-RSA-AES-128-CBC-SHA
TLS1-DHE-RSA-AES-256-CBC-SHA
TLS1.2-DHE-RSA-AES-128-SHA256
TLS1.2-DHE-RSA-AES-256-SHA256
TLS1.2-DHE-RSA-AES128-GCM-SHA256
TLS1.2-DHE-RSA-AES256-GCM-SHA384

ECDHE キーエクスチェンジ暗号スイートの推奨:

TLS1-ECDHE-RSA-AES128-SHA
TLS1-ECDHE-RSA-AES256-SHA
TLS1.2-ECDHE-RSA-AES-128-SHA256
TLS1.2-ECDHE-RSA-AES-256-SHA384
TLS1.2-ECDHE-RSA-AES128-GCM-SHA256
TLS1.2-ECDHE-RSA-AES256-GCM-SHA384

暗号スイートを優先順に推奨:

次の暗号のリストには、RSA、DHE、および ECDHE キー交換が含まれます。これは、セキュリティ、パフォーマンス、および互換性の間で最も優れた妥協点を提供します。

TLS1.2-AES128-GCM-SHA256
TLS1.2-AES-128-SHA256
TLS1.2-ECDHE-RSA-AES128-GCM-SHA256
TLS1.2-ECDHE-RSA-AES-128-SHA256
TLS1-ECDHE-RSA-AES128-SHA
TLS1.2-DHE-RSA-AES128-GCM-SHA256
TLS1.2-DHE-RSA-AES-128-SHA256
TLS1-DHE-RSA-AES-128-CBC-SHA
TLS1-AES-128-CBC-SHA

プロキシ HTTPS/他のすべてのトラフィックを拒否:

可能な限り、安全なSSLバージョン（TLSv1.1およびTLSv1.2）と安全な暗号を使用して、データの暗号化を強化するために SSL VIP を用意してください。VIP およびバックエンド SSL サービスの SSL を有効にする際には、SSL TPS と SSL スループットを考慮する必要があります。

管理と管理

このセクションでは、Citrix ADCおよびCitrix ADC SDXアプライアンスのセキュリティを強化するために適用できる特定の構成変更の例を示します。Citrix ADC構成のベストプラクティスに関するガイダンスについては、Citrix ADCアプライアンスの一般的な実装に関する推奨設定とベストプラクティスの記事を参照してください。

システムアカウントとユーザーアカウント

スーパーユーザアカウントのパスワードを変更する: ビルトイン管理者スーパーユーザ (nsroot) は削除できません。そのため、そのアカウントのデフォルトパスワードを安全なパスワードに変更してください。admin ユーザのデフォルトパスワードを変更するには、次の手順を実行します。

スーパーユーザーとしてログオンし、構成ユーティリティを開きます。
ナビゲーション区画で [Systems] ノードを展開します。
[ユーザ] ノードを選択します。
[システムユーザ] ページで、 nsroot ユーザを選択します。
[ パスワードの変更] を選択します。
[パスワード] フィールドと [パスワードの確認] フィールドに、必要なパスワードを入力します。
［OK］をクリックします。

代替スーパーユーザーアカウントを作成する: スーパーユーザーアカウントを作成するには、以下のコマンドを実行します。

add system user <newuser> <password>

bind system user <newuser> superuser 0
<!--NeedCopy-->

既定のnsrootスーパーユーザーアカウントの代わりに、このスーパーユーザーアカウントを使用します。

Citrix ADC SDX展開の場合、管理者は初期セットアップ後にCitrix ADC SDXアプライアンスとそのGUI管理コンソールのデフォルトの資格情報を変更する必要があります。デフォルトユーザのパスワードを変更するには、次の手順に従います。

スーパーユーザーとしてログオンし、構成ユーティリティを開きます。
ナビゲーション区画で [Systems] ノードを展開します。
[ユーザ] ノードを選択します。
[システムユーザ] ページで、デフォルトユーザを選択します。
[修正] を選択します。
[パスワード] フィールドと [パスワードの確認] フィールドに、必要なパスワードを入力します。
［OK］をクリックします。

システムユーザーの強力なパスワード:

Citrix ADCで作成されたシステムユーザーアカウントには、強力なパスワードを使用することをお勧めします。パスワードの複雑さの要件の例を次に示します。

パスワードの長さは 8 文字以上にする必要があります。
パスワードには、辞書の単語や辞書の単語の組み合わせを含めないでください。
パスワードには、少なくとも 1 つの大文字、1 つの小文字、1 つの数字、および 1 つの特殊文字を含める必要があります。

強力なパスワードを適用するには、2 つのパラメータを設定します。1 つはパスワードの最小文字数用で、もう 1 つはパスワードの複雑さを強制するパラメータです。

set system parameter -minpasswordlen <positive_integer> -
-strongpassword ( ENABLED | DISABLED )
<!--NeedCopy-->

複数の管理者を必要とする展開では、RADIUS、TACACS+、LDAP (S) などの外部認証方式を使用してユーザを認証することを検討してください。詳しくは、「外部ユーザー認証」を参照してください。

管理アクセスのためにシステムユーザーアカウントをロックする： Citrix ADCアプライアンスでは、システムユーザーを24時間ロックし、ユーザーへのアクセスを拒否できます。Citrix ADCアプライアンスは、システムユーザーと外部ユーザーの両方の構成をサポートします。コマンドプロンプトで次のように入力します。

set aaa parameter –persistentLoginAttempts DISABLED

ここで、ユーザーアカウントをロックするには、コマンドプロンプトで次のように入力します。

lock aaa user test

GUI を使用してこの機能を設定する方法については、「ユーザーアカウントとパスワードの管理」を参照してください。

管理アクセス用にロックされたシステムユーザーアカウントのロックを解除する： システムユーザーと外部ユーザーは、lock authentication、authorization、and auditinguserコマンドを使用して24時間ロックできます。Citrix ADCアプライアンスでは、ロックされたシステムユーザーのロックを解除できます。コマンドプロンプトで入力します。

unlock aaa user test GUI を使用してこの機能を設定する方法については、「ユーザーアカウントとパスワードの管理」を参照してください。

システムユーザーアカウントの管理アクセスを無効にする: アプライアンスで外部認証が設定されており、管理者がシステムユーザーによる管理アクセスへのログオンアクセスを拒否したい場合は、システムパラメータの LocalAuth オプションを無効にする必要があります。

注：外部サーバーを構成する必要があります。

コマンドプロンプトで、次のように入力します。

set system parameter localAuth <ENABLED|DISABLED>

例:

set system parameter localAuth DISABLED GUI を使用してこの機能を設定する方法については、「ユーザーアカウントとパスワードの管理」を参照してください。

管理ユーザーのパスワード変更を強制する： nsroot セキュア認証の場合、システムパラメータで forcePasswordChange オプションが有効になっていると、Citrix ADCアプライアンスはユーザーにデフォルトのパスワードを新しいパスワードに変更するように求めます。デフォルトのクレデンシャルを使用して、初回ログイン時に CLI または GUIからnsrootパスワードを変更できます。コマンドプロンプトで入力します。

set system parameter -forcePasswordChange ( ENABLED | DISABLED )

この機能の構成方法の例については、「ユーザーアカウントとパスワードの管理」を参照してください。

SSHキーとパスワードなしを使用したCitrix ADCへのアクセス： 多くのCitrix ADCアプライアンスを管理する必要がある環境では、SSHキーとパスワードなしの使用を検討してください。この機能の構成方法については、「 SSHキーとパスワードなしでCitrix ADCアプライアンスにアクセスする」を参照してください。

データ保護のためのシステムメインキーの作成： Citrix ADC 12.1からCitrix ADC 13.0—71.44では、LDAP認証に必要なサービスアカウントパスワードやローカルに保存された認証、承認、監査ユーザーアカウントなどの特定のセキュリティパラメータを保護するためにシステムメインキーを作成する必要があります。

注： Citrix 13.0～76.31以降のリリースでは、アップグレードプロセスでランダムなシステムメインキーがデフォルトで自動的に作成されます。

システムメインキーを作成するには、次の手順に従います。

コマンドラインインターフェイスを使用して、システム管理者としてログインします。
以下のコマンドを入力します。

create kek <passphrase>
<!--NeedCopy-->

注記:

create system kek コマンドを実行すると、ほとんどのパスワード暗号化に KEK が使用されます (ローカルユーザーのパスワードは KEK では暗号化されません)。
KEK ファイルは削除しないでください。シェルアクセス権があり、キーフラグメントファイルを誤って削除すると、構成の損失、同期の失敗、ログオンの失敗につながる可能性があります。以下に、注意すべき点を示します。
- ダウングレード時には、インストールされているビルドと一致する古い設定ファイルを必ず使用してください。そうしないと、ログオン、ソース構成、同期、フェイルオーバーが失敗する可能性があります。
- キーフラグメントファイルのいずれかが失われたり破損したりすると、機密データの暗号化/復号化が失敗し、その結果、構成の損失、同期の失敗、ログオンの失敗につながる可能性があります。
パスフレーズは 8 文字以上にする必要があります。

アクセス制御リストを使用する:

デフォルトでは、GUIやSSHを含むすべてのプロトコルとポートにCitrix ADCアプライアンスからアクセスできます。Access Control List（ACL; アクセスコントロールリスト）は、明示的に指定されたユーザーだけがポートとプロトコルにアクセスできるようにすることで、アプライアンスを安全に管理するのに役立ちます。

アプライアンスへのアクセスを制御するための推奨事項：

Citrix Gatewayを使用して、アプライアンスへのアクセスをGUIのみに制限することを検討してください。GUIに加えてアクセス方法を必要とする管理者の場合、Citrix Gatewayは、ポート80、443、および3010のデフォルトの「拒否」ACLで構成する必要があります。ただし、これらのポートにアクセスするには信頼できるIPアドレスには明示的な「許可」を使用します。

このポリシーは、次の NSCLI コマンドを使用して、信頼できる IP アドレスの範囲で使用するために拡張できます。

add acl local_access allow -srcip 192.168.0.1-192.168.0.3 -destip 192.168.0.1-192.168.0.3

apply acls
<!--NeedCopy-->

SNMP を使用する場合は、ACL を使用して SNMP トラフィックを明示的に許可します。次に、一連のサンプルコマンドを示します。

add acl snmp1-ssh ALLOW -srcip 10.0.0.1-10.0.0.20 -destip 192.168.0.2-192.168.0.3 -destport 161 -protocol udp

add acl snmp2-ssh ALLOW -srcip 172.16.0.1-172.16.0.20 -destip 192.168.0.2-192.168.0.3 –destport 161 -protocol udp

apply acls
<!--NeedCopy-->

前述の例では、適切に定義されたコミュニティに対するクエリーであっても、2 つの定義済みサブネットに対するすべての SNMP クエリーへのアクセス権がコマンドによって提供されます。

NSIP アドレスと SNIP アドレスで管理機能を有効にできます。有効にすると、管理機能へのアクセスを保護するために、NSIP、SNIP、ACL 付きのアドレスへのアクセスを提供します。管理者は、ping コマンドでアクセスできないようにアプライアンスを設定することもできます。

OSPF および IPSEC は、TCP または UDP ベースのプロトコルではありません。したがって、アプライアンスでこれらのプロトコルをサポートする必要がある場合は、ACL を使用して、これらのプロトコルを使用するトラフィックを明示的に許可してください。ACL を定義するには、次のコマンドを実行して、プロトコル番号によって OSPF および IPSec を指定します。

add acl allow_ospf allow -protocolnumber 89

add acl allow_ipsec allow -protocolnumber 50
<!--NeedCopy-->

XML-API Web サービスを使用する場合は、次のタスクを実行して API インターフェイスをセキュリティで保護します。
ACL を使用して、インターフェイスにアクセスするためのアクセス許可をホストに提供します。たとえば、10.0.0.1-20 および 172.16.0.1-20 IP アドレス範囲のホストが XML-API インターフェイスにアクセスできるようにするには、次のコマンドを実行します。

add acl xml-api1 ALLOW -srcip 10.0.0.1-10.0.0.20 -destip 192.168.0.2-192.168.0.3 -destport 80 -protocol tcp

add acl xml-api2 ALLOW -srcip 172.16.0.1-172.16.0.20 -destip 192.168.0.2-192.168.0.3 -destport 80 -protocol tcp

apply acls
<!--NeedCopy-->

内部ポートに ACL を適用するには、次のコマンドを使用します。

set l3param -implicitACLAllow DISABLED
<!--NeedCopy-->

メモ:implicitaclAllow コマンドのデフォルト値は ENABLEDです。

内部ポートからACLを削除するには、次のコマンドを使用します。

set l3param -implicitACLAllow ENABLED
<!--NeedCopy-->

クライアント側の証明書を使用すると、セキュリティを強化できます。クライアント側の証明書とクライアント認証の詳細については、クライアント認証またはナレッジセンターの記事 CTX214874：ファームウェア10.1以降を搭載したCitrix ADCアプライアンスでクライアント証明書を作成して使用する方法を参照してください。

管理ユーザーに対して役割ベースのアクセス制御を使用します。

Citrix ADCアプライアンスには、オペレーター、読み取り専用、ネットワーク、スーパーユーザーなど、4つのコマンドポリシーまたは役割が含まれています。また、コマンドポリシーを定義し、ロールごとに異なる管理アカウントを作成し、ロールに必要なコマンドポリシーをアカウントに割り当てることもできます。次に、読み取り専用ユーザーに読み取り専用アクセスを制限するコマンドの例を示します。

add system user readonlyuser

bind system user readonlyuser read-only 0
<!--NeedCopy-->

ユーザー、ユーザーグループ、またはコマンドポリシーの設定の詳細については、「ユーザー、ユーザーグループ、およびコマンドポリシー」を参照してください。

システムセッションタイムアウトを設定します。

セッションタイムアウト間隔は、セッション（GUI、CLI、または API）が使用されていないときにアクティブのままになる時間を制限するために提供されます。Citrix ADCアプライアンスの場合、システムセッションタイムアウトは次のレベルで構成できます。

ユーザーレベルのタイムアウト。特定のユーザーに適用されます。

GUI: [ **システム ] > [ ユーザ管理 ] > [ユーザ] に移動し、ユーザを選択し、ユーザのタイムアウト設定を編集します。** CLI: コマンドプロンプトで、次のコマンドを入力します。

set system user <name> -timeout <secs>
<!--NeedCopy-->

ユーザーグループレベルのタイムアウト。グループ内のすべてのユーザーに適用されます。

GUI: [ システム ] > [ ユーザー管理 ] > [ グループ] に移動し、グループを選択して、グループのタイムアウト設定を編集します。 CLI: コマンドプロンプトで、次のコマンドを入力します。

set system group <groupName> -timeout <secs>
<!--NeedCopy-->

グローバルシステムタイムアウト。タイムアウトが設定されていないグループのすべてのユーザおよびユーザに適用されます。

GUI: [ システム ] > [ 設定] に移動し、[ グローバルシステムパラメータの設定] をクリックして、[ANY Client Idle Timeout (sec)] パラメータを設定します。 CLI: コマンドプロンプトで、次のコマンドを入力します。

set system parameter -timeout <secs>
<!--NeedCopy-->

ユーザに指定されたタイムアウト値は、最も優先度が高くなります。ユーザに対してタイムアウトが設定されていない場合は、メンバグループに設定されたタイムアウトが考慮されます。グループに対してタイムアウトが指定されていない（またはユーザがグループに属していない）場合は、グローバルに設定されたタイムアウト値が考慮されます。timeout がどのレベルでも設定されていない場合、デフォルト値の 900 秒がシステムセッションタイムアウトとして設定されます。

また、管理者が設定したタイムアウト値を超えてセッションタイムアウト値を設定できないように、タイムアウト値を制限することもできます。タイムアウト値は 5 分から 1 日に制限できます。タイムアウト値を制限するには:

GUI: [ システム ] > [ 設定] に移動し、[ グローバルシステムパラメータの設定] をクリックして、[制限付きタイムアウト] フィールドを選択します。
CLI: コマンドプロンプトで、次のコマンドを入力します。

set system parameter -restrictedtimeout <ENABLED/DISABLED>
<!--NeedCopy-->

ユーザーが RestrictedTimeout パラメーターを有効にした後、タイムアウト値がすでに 1 日より大きい値または 5 分未満の値に設定されている場合、ユーザーはタイムアウト値を変更するように通知されます。ユーザがタイムアウト値を変更しない場合、デフォルトでは、次回のリブート時にタイムアウト値が 900 秒（15 分）に再設定されます。

また、アクセスするインターフェイスごとにタイムアウト時間を指定することもできます。ただし、特定のインターフェイスに指定されたタイムアウト値は、インターフェイスにアクセスしているユーザに設定されたタイムアウト値に制限されます。たとえば、 publicadmin ユーザーのタイムアウト値が 20 分であるとします。ここで、インターフェイスにアクセスする場合、ユーザーは 20 分以内のタイムアウト値を指定する必要があります。

各インターフェイスでタイムアウト時間を設定するには、次の手順を実行します。

CLI: 次のコマンドを使用して、コマンドプロンプトでタイムアウト値を指定します。

set cli mode -timeout <secs>
<!--NeedCopy-->

API: ログインペイロードにタイムアウト値を指定します。

ログ記録と監視

ネットワークタイムプロトコルの構成

アプライアンスではネットワークタイムプロトコル（NTP）を有効にし、信頼できるネットワークタイムサーバーを使用するように構成することをお勧めします。NTP を有効にすると、ログエントリとシステムイベントの記録時間が正確になり、他のネットワークリソースと同期されます。

NTP を設定するときは、機密性の高いパケット内の情報を NTP サーバが公開しないように、ntp.conf ファイルを変更する必要があります。

次のコマンドを実行して、アプライアンスで NTP を設定できます。

add ntp server <IP_address> 10

enable ntp sync
<!--NeedCopy-->

追加する信頼できる NTP サーバごとに ntp.conf ファイルを変更します。サーバエントリごとに、対応する制限エントリが必要です。ntp.conf ファイルは、アプライアンスのシェルプロンプトからfind . –name ntp.confコマンドを実行することによって見つけることができます。

SNMP の設定

Citrix ADCアプライアンスは、バージョン3のSNMPプロトコルをサポートしています。SNMPv3 には、認証、アクセスコントロール、データ整合性チェックなどの管理機能とセキュリティ機能が組み込まれています。詳しくは、「 SNMPv3クエリ用のCitrix ADCの構成」を参照してください。

注：

シトリックスでは、SNMPv1やSNMPv2の代わりにSNMPv3を使用することをお勧めします。

SNMP マネージャを 1 つでも設定しない場合、アプライアンスはネットワーク内のすべての IP アドレスからの SNMP クエリーを受け入れ、応答します。以下のコマンドを実行して SNMP マネージャを追加し、この動作を制限します。

add snmp manager <IP_address>
<!--NeedCopy-->

SNMP が不要な展開では、次のコマンドを使用して機能を無効にする必要があります。

set ns ip <IP_Address> -snmp disabled
<!--NeedCopy-->

外部Citrix ADCログホストへのロギングを構成する

Citrix ADC監査サーバーは、カーネルおよびユーザーレベルのデーモン内の異なるモジュールによって収集されたすべての状態とステータス情報をログに記録します。監査サーバーを使用すると、管理者はイベント履歴を時系列順に表示できます。監査サーバーは、アプライアンスからログを収集する SYSLOG サーバーに似ています。監査サーバーは管理者の資格情報を使用して、1 つ以上のアプライアンスからログを取得します。

ローカル監査サーバ設定

次のコマンドを実行して、Citrix ADCアプライアンスのローカル監査サーバーへのロギングを構成します。 > set audit nslogparams –serverip <hostname> -serverport <port>

リモート監査サーバ設定

リモートコンピューターの監査サーバーへのログ記録を構成するには、そのコンピューターに監査サーバーをインストールします。監査サーバーのオプションの例を次に示します。

./audserver -help
usage : audserver -[cmds] [cmd arguments]
cmds cmd arguments: -f <filename> -d debug
-help - detail help
-start - cmd arguements,[starts audit server]
-stop - stop audit server
-verify - cmd arguments [verifies config file]
-addns - cmd arguments [add a netscaler to conf file]
-version - prints the version info
<!--NeedCopy-->

これにより、アプライアンスの ns.log ファイルだけで生成された監査メッセージをロギングする機能が提供されます。すべての syslog メッセージをログに記録するには、次の手順を実行します。

ローカルファシリティの /nsconfig/syslog.conf ファイルからログファイルの指定を削除します。
次のエントリと同様に、ログファイルの仕様を、リモート Syslog ホストのログホスト名または IP アドレスに置き換えます。

local0.* @10 .100.3.53

local1.* @10 .100.3.53
前述のロギングファシリティからのログエントリを受け入れるように Syslog サーバを設定します。詳細については、Syslog サーバのマニュアルを参照してください。
標準の syslog ソフトウェアを使用するほとんどの UNIX ベースのサーバでは、メッセージおよび nsvpn.log ファイル用のローカルファシリティ設定エントリを syslog.conf 設定ファイルに追加する必要があります。ファシリティの値は、アプライアンスに設定されている値に対応している必要があります。
UNIX ベースのコンピューターのリモート Syslog サーバーは、既定ではリモートログをリッスンしません。したがって、次のコマンドを実行して、リモート syslog サーバを起動します。

syslogd -m 0 –r
<!--NeedCopy-->

注:監査サーバーにデプロイされている syslog バリアントの同等のオプションを参照してください。

LOM構成

LOMインターフェイスを保護するために、次の対策を講じることを強くお勧めします。

LOM ポートをインターネットに公開しないでください。
SPI ファイアウォールの背後に LOM を展開します。
信頼できないネットワークトラフィックから論理的に（別個の VLAN）または物理的（別個の LAN）に分離されたネットワークセグメントに LOM を展開します。
LOMおよびCitrix ADC管理ポートに異なるユーザー名、パスワード、SSL証明書、およびSSLキー値を設定します。
LOM 管理インターフェイスへのアクセスに使用するデバイスが、ネットワーク管理専用であり、他の管理デバイスポートと同じ物理 LAN または VLAN にある管理ネットワークセグメントに配置されていることを確認します。
LOM IP アドレスを簡単に識別して分離するには、LOM 管理インターフェイスと管理サーバー用に特別な IP アドレス (プライベートサブネット) を予約します。管理アプライアンスの LAN インターフェイスでは、予約済み IP サブネットを使用しないでください。DHCP によって割り当てられるダイナミック IP アドレスは、LAN セグメント外の MAC アドレスに基づくファイアウォールアクセスコントロールリストの実装が困難になるため、推奨されません。
パスワードは、英数字と特殊文字を組み合わせて 8 文字以上に設定します。パスワードは頻繁に変更してください。

アプリケーションとサービス

アップグレードヘッダーを削除または渡すようにCitrix ADCアプライアンスを構成します

バックエンドサーバーへの攻撃を防ぐために、新しいパラメーター PassProtocolUpgrade が HTTP プロファイルに追加されました。このパラメータの状態に応じて、アップグレードヘッダーはバックエンドに送信されるリクエストで渡されるか、リクエストを送信する前に削除されます。

PassProtocolUpgrade パラメーターが有効になっている場合、アップグレードヘッダーはバックエンドに渡されます。サーバーはアップグレード要求を受け入れ、応答で通知します。
このパラメータを無効にすると、アップグレードヘッダーが削除され、残りのリクエストがバックエンドに送信されます。

PassProtocolUpgrade パラメータが次のプロファイルに追加されます。

nshttp_default_profile-デフォルトで有効になっています
nshttp_default_strict_validation-デフォルトでは無効になっています
nshttp_default_internal_apps-デフォルトでは無効になっています
nshttp_default_http_quic_profile-デフォルトで有効になっています

Citrixでは、PassProtocolUpgradeパラメーターを無効に設定することをお勧めします。

CLI を使用して PassProtocolUpgrade パラメータを設定します。

コマンドプロンプトで、次のように入力します。

set ns httpProfile <name> [-passProtocolUpgrade ( ENABLED | DISABLED )]

GUI を使用して PassProtocolUpgrade パラメータを設定します。

[ システム]-> [プロファイル]-> [HTTP プロファイル] に移動します。
HTTP プロファイルを作成または編集します。
「 パス・プロトコル・アップグレード 」チェックボックスを選択します。

無効なHTTP要求をドロップするようにCitrix ADCを構成する

Citrix ADCアプライアンスは、無効なHTTP要求が仮想サーバーを通過するのを防ぐために、HTTP要求を厳密にチェックおよび強制するように構成することを強くお勧めします。これは、CLI で次のコマンドを使用して、組み込みの HTTP プロファイル nshttp_default_strict_validateを 1 つ以上の仮想サーバーにバインドすることで実行できます。

show ns httpProfile (Shows the available http profile (default+user configured profiles))

set lb vserver <vserver name> -httpProfileName nshttp_default_strict_validation
<!--NeedCopy-->

このオプションを使用するお客様は、本番環境にリリースする前に、ステージング環境で変更をテストすることをお勧めします。

HTTP 非同期攻撃に対する保護は、厳密な HTTP 検証プロファイル (nshttp_default_strict_validation) ではデフォルトで有効になっています。クライアント向けのすべてのエンティティに厳密なプロファイルを使用します。

HTTPリクエストの密輸攻撃とその軽減の詳細については、サポート記事「 Citrix ADC-HTTPリクエスト密輸リファレンスガイド」を参照してください。

HTTP サービス拒否攻撃に対する保護の設定

Citrix ADCアプライアンスのファームウェアは、「スロー読み取り」タイプの攻撃など、HTTPサービス拒否攻撃に対する限定的な対策をサポートしています。アプライアンスのシェルプロンプトからnsapimgr ユーティリティを使用して、これらの機能を設定できます。

small_window_threshold (既定値は 1)
small_window_idle_timeout (デフォルト = 7 秒)
small_window_cleanthresh (既定値は 100)
small_window_protection (既定値では有効)

デフォルト設定は、低速読み取り攻撃を含む HTTP サービス拒否攻撃を防止するのに十分ですが、他の攻撃ではパラメータの調整が必要になる場合があります。

このような攻撃から保護するには、アプライアンスのシェルプロンプトから次のnsapimgrコマンドを使用して、 small_window_thresholdプロパティを上方向に調整します。

$ nsapimgr –ys small_window_threshold=<desired value>

注：small_window_threshold 必要な値は、展開内の着信トラフィックパターンに基づいて設定できます。指定できる範囲は 0 ～ 2^32 です。

HTTP サービス拒否攻撃に対する保護を確認するには、アプライアンスのシェルプロンプトからnsconmsg –d stats コマンドを使用して次のカウンタを監視します。

nstcp_cur_zero_win_pcbs: このカウンタは、現在ウィンドウ値が低いPCBの数を追跡します。
nstcp_err_conndrop_at_pass：このカウンタは、一方の側から他方の側にパケットを渡す際に、nscfg_small_window_idletimeout 値を超えたことをアプライアンスが検出したときにインクリメントされます。
nstcp_err_conndrop_at_retx: このカウンタは、再送信中に経過した時間が nscfg_small_window_idletimeout 値を超えると増分されます。
nstcp_cur_pcbs_probed_withKA: このカウンタは、KA プローブでプローブされたサージキュー内の PCB の数を追跡します。

このオプションを使用するお客様は、本番環境にリリースする前に、ステージング環境で変更をテストすることをお勧めします。

TCPスプーフィング攻撃から防御するようにCitrix ADCを構成する

次のコマンドを使用すると、TCP スプーフィング攻撃からバックエンドサーバーを保護できます。

set ns tcpProfile profile1 -rstWindowAttenuate ENABLED -spoofSynDrop ENABLED

Done

set lb vserver lbvserver1 -tcpProfileName profile1

Done
<!--NeedCopy-->

このオプションを使用するお客様は、本番環境にリリースする前に、ステージング環境で変更をテストすることをお勧めします。

特定のHTTPヘッダーを受け入れるようにCitrix ADCを構成する

特定のHTTPヘッダーのみを受け入れるようにCitrix ADCアプライアンスを構成できます。これは、特定の定義されたHTTPヘッダーを持つネットワークトラフィックがバックエンドサーバーに渡されないように制限する書き換えアクションを追加することで実現できます。

次のグローバル書き換えアクションは、Host、Accept、test などのヘッダーを持つネットワークトラフィックのみをサーバーに送信します。

add rewrite action act1 replace_all q/HTTP.REQ.FULL_HEADER.after_str("\r\n")/     q{TARGET.REGEX_SELECT(re/(iu)^(Host|Accept|test):.*\r\n/) ALT ""} -pattern q{re/(U).+:.+r\n/}

add rewrite policy pol1 HTTP.REQ.IS_VALID act1

bind rewrite global pol1 100
<!--NeedCopy-->

クローズ通知の設定

クローズ通知は、SSL データ伝送の終了を示す安全なメッセージです。RFC 5246 に準拠:クライアントとサーバーは、切り捨て攻撃を回避するために、接続が終了しているという情報を共有する必要があります。どちらの当事者も、終了メッセージの交換を開始できます。どちらの当事者も close_notify アラートを送信することでクローズを開始できます。クロージャアラートの後に受信したデータはすべて無視されます。他の致命的なアラートが送信されない限り、接続の書き込み側を閉じる前に、各パーティは close_notify アラートを送信する必要があります。 TLS 終了イベントの監査イベントを確実にキャプチャするには、スーパーユーザーまたは sysadmin として CLI にログオンし、次のコマンドを実行します。

set ssl parameter -sendCloseNotify y

save ns config
<!--NeedCopy-->

セキュアな管理 GUI、NITRO API、および RPC 通信

Citrix ADCおよびCitrix Gateway アプライアンスで管理GUI、NITRO API、およびRPC通信を保護するために、アプライアンスに設定maxclientForHttpdInternalServiceが追加されます。このチェックボックスは、デフォルトでオフになっています。管理 GUI、NITRO API、および RPC 通信を保護するには、パラメータを有効にする必要があります。

また、次のシェルコマンドを使用して、/etc/httpd.conf の maxClients値と一致するようにmaxclientForHttpdInternalServiceを設定することをお勧めします。maxClients のデフォルト値は 30 です。

nsapimgr_wr.sh -ys maxclientForHttpdInternalService=<val>
<!--NeedCopy-->

maxclientForHttpdInternalService値の設定と、この設定をサポートするCitrix ADCバージョンの詳細については、「https://support.citrix.com/article/CTX331588」を参照してください。

DNSSEC セキュリティに関する推奨事項

DNSSECを使用しているお客様には、次の推奨事項を適用することをお勧めします。

KSK/ZSK秘密鍵にはRSA 1024ビット以上を使用する

NISTでは、DNS管理者は、2015年10月1日まで、1024ビットのRSA/SHA-1またはRSA/SHA-256 ZSKを維持することを推奨しています。

DNSSEC キーの有効期限に対する SNMP アラームの有効化

デフォルトでは、Citrix ADCアプライアンスではDNSSECキーの有効期限に関するSNMPアラームが有効になっています。キーの有効期限の通知は、dnskeyExpiry という SNMP トラップを介して送信されます。3 つの MIB 変数 dnskeyName、およびdnskeyUnitsOfExpiryが dnskeyExpiry SNMP トラップとともに送信されます。詳細については、Citrix ADC SNMP OIDリファレンスを参照してください。

x.509 証明書が期限切れになる前に KSK/ZSK 秘密キーをロールオーバーする

Citrix ADCアプライアンスでは、事前公開および二重署名の方法を使用して、ゾーン署名キーとキー署名キーのロールオーバーを実行できます。詳しくは、Citrix Docsの「ドメインネームシステム」>「DNSSECの構成 」トピックを参照してください。

セキュア DNSSEC ADNS サーバー

アプライアンスが DNSSEC プロキシモードに設定されている場合、バックエンド ADNS サーバーからの応答をキャッシュし、キャッシュされた応答を DNS クライアントに転送します。

Citrix ADCアプライアンスが特定のゾーンに対して権限を持っている場合、ゾーン内のすべてのリソースレコードがCitrix ADCで構成されます。権限のあるゾーンに署名するには、ゾーンのキー (ゾーン署名キーとキー署名キー) を作成し、そのキーを ADC に追加して、ゾーンに署名する必要があります。

Citrix ADC を権限のあるサーバーとして構成するには、次の手順に従います。

ADNS サービスを追加します。

例：

add service s1 <ip address> adns 53`
<!--NeedCopy-->

DNS キーを作成します。

たとえば、comドメインの権限のあるサーバーとして機能するには、次のようにします。
```
create dns key -zoneName com -keytype ksK -algorithm rsASHA512 -keysize 3000 -fileNamePrefix com.ksk.rsasha1.3000

create dns key -zoneName com -keytype zsk -algorithm rsASHA512 -keysize 3000 -fileNamePrefix com.zsk.rsasha1.3000

```
注:DNS キーは一度作成する必要があります。作成したキーは /nsconfig/dns に保存されます。

DNS キーを追加します。

例：

add dns key com.zsk.3000 /nsconfig/dns/com.zsk.rsasha1.3000.key /nsconfig/dns/com.zsk.rsasha1.3000.private
add dns key com.ksk.3000 /nsconfig/dns/com.ksk.rsasha1.3000.key /nsconfig/dns/com.ksk.rsasha1.3000.private
<!--NeedCopy-->

comゾーンの NS レコードと SOA レコードを追加し、ゾーンに署名します。

add dns soaRec com -originServer n1.com -contact citrix
add dns nsrec com n1.com
add dns zone com -proxyMode no
add dns addRec n1.com 1.1.1.1

sign dns zone com
<!--NeedCopy-->

注:さらに、DNS グローバルパラメータで DNSEC 拡張パラメータを有効にする必要があります。

Citrix ADCを権限のあるドメインネームサーバーとして構成する方法の詳細については、Citrix Docsの「ドメインネームシステム」>「Citrix ADCをADNSサーバーとして構成する 」トピックを参照してください。

レガシー構成

SSLv2リダイレクトを無効にするようにCitrix ADCを構成する

Citrix ADCアプライアンスでSSL v2リダイレクト機能を有効にすると、アプライアンスはSSLハンドシェイクを実行し、構成されたURLにクライアントをリダイレクトします。この機能を無効にすると、アプライアンスは SSL v2 クライアントでの SSL ハンドシェイクプロセスの実行を拒否します。

SSLv2 リダイレクトを無効にするには、次のコマンドを実行します。

set ssl vserver <vserver_name> -sslv2redirect DISABLED -cipherredirect DISABLED
<!--NeedCopy-->

非セキュアSSL再ネゴシエーションを防止するようにCitrix ADCを構成する

SSL 再ネゴシエーションを無効にするには、次のコマンドを実行します。

set ssl parameter -denySSLReneg ALL
<!--NeedCopy-->

次のコマンドは、セキュアクライアントおよびサーバに対してのみ再ネゴシエーションを許可します。

set ssl parameter -denySSLReneg NONSECURE
<!--NeedCopy-->

詳細については、「 -denySSLREneg パラメーターの構成と使用方法」を参照してください。

NDCPP コンプライアンス証明書チェックの設定

NDCPP 準拠証明書チェックは、アプライアンスがクライアント（バックエンド接続）として動作するときに適用されます。SSL 証明書に SAN が存在する場合は、証明書の検証時にコモンネームを無視します。

コマンドプロンプトで次のコマンドを入力して、SSL パラメータの「ndcppComplianceCertCheck」属性を構成します。

set ssl parameter [-quantumSize <quantumSize>] [-crlMemorySizeMB <positive_integer>] [-strictCAChecks (YES | NO)] [-sslTriggerTimeout <positive_integer>] [-sendCloseNotify (YES | NO)] [-encryptTriggerPktCount <positive_integer>] [-denySSLReneg <denySSLReneg>] [-insertionEncoding (Unicode|UTF-8)] [-ocspCacheSize <positive_integer>][- pushFlag <positive_integer>] [- dropReqWithNoHostHeader (YES | NO)] [-pushEncTriggerTimeout <positive_integer>] [-ndcppComplianceCertCheck ( YES | NO)] [-heterogeneousSSLHW (ENABLED | DISABLED )]
<!--NeedCopy-->

例:

set ssl parameter -quantumSize 8 -crlMemorySizeMB 256 -strictCAChecks no -ssltriggerTimeout 100 -sendClosenotify no -encryptTriggerPktCount 45 -denySSLReneg NONSECURE -insertionEncoding unicode -ocspCacheSize 10 -pushFlag 3 -dropReqWithNoHostHeader YES  -pushEncTriggerTimeout 100 ms -ndcppComplianceCertCheck YES
<!--NeedCopy-->

Citrix ADC 暗号化に関する推奨事項

このセクションでは、Citrix ADCアプライアンスで暗号化素材が正しく保護されていることを確認するために従う必要のあるいくつかの重要な手順について詳しく説明します。また、アプライアンス自体、バックエンドサーバー、およびエンドユーザーの両方を保護するために、この資料を使用するようにアプライアンスを構成する方法についても説明します。

TLS 証明書とキーを管理する

nDCPP 導入用の TLS 暗号スイートの設定

nDCPP 導入では、次の TLS 暗号スイートがサポートされています。

TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

MPX-14000 FIPSでサポートされている暗号のリストについては、https://docs.citrix.com/en-us/citrix-adc/downloads/cipher-support-on-a-citrix-mpx-sdx-14000-fips-appliance.pdfを参照してください。

承認された暗号スイートだけがアプライアンスに設定されるようにするには、CLI から次の設定手順を実行します。

仮想サーバからすべての暗号をバインド解除する
```
unbind ssl vs v1 –cipherName FIPS

```
次のコマンドを使用して、TLS1-AES-256-CBC-SHA のみをバインドし、TLS1-AES-128-CBC-SHA のみをバインドします。
```
bind ssl vs v1 –cipherName <cipher>

bind ssl vs v1 -cipherName TLS1-AES-256-CBC-SHA

```

信頼できる CA を使用した証明書とキーペアのインストール:

パブリックまたはエンタープライズ認証局 (CA) から証明書を取得するには、まず秘密キーと証明書署名要求 (CSR) を生成する必要があります。次の手順を実行します：

システム管理者またはスーパーユーザーとしてCitrix ADC CLIに認証します。

RSA プライベートキーを作成します。

create fipsKey m1 -keytype RSA -modulus 2048 -exponent F4
<!--NeedCopy-->

証明書署名要求 (CSR) を作成します。

create certreq csr_1 -fipsKeyName m1 -countryName IN -stateName BA -organizationName citrix
<!--NeedCopy-->

CSR を認証局に送信します。

ほとんどの商用およびエンタープライズ CA では、CSR は電子メールリクエストで送信されます。ただし、送信方法はエンタープライズ CA 環境によって異なる場合があります。CA は有効な証明書を電子メールで返しますが、これもエンタープライズ CA によって異なる場合があります。CA から証明書を受け取ったら、/nsconfig/ssl ディレクトリに安全にコピーします。

スーパーユーザーまたは sysadmin としてログインし、CLI から次のコマンドを実行します。 > add ssl certKey ck_1 -cert cert1_1 -fipsKey m1

Citrix ADC-FIPS 推奨事項

FIPSベースの展開でCitrix ADC SDXを構成する

既存のFIPSユーザーで、真のマルチテナンシーのためにCitrix ADC SDXアプライアンスを使用している場合は、FIPS認定のCitrix ADC MPXアプライアンスを使用してTLSを終了し、トラフィックをCitrix ADC SDXアプライアンスに転送します。または、Thales 外部 HSM を使用することもできます。 FIPS認定バージョンのCitrix ADCをハードウェアセキュリティモジュール（HSM）とともに使用する場合は、FIPS暗号カードのパスワードを変更し、デフォルトのセキュリティ担当者（SO）を変更し、新しいユーザーパスワードを次のように設定します。FIPS対応のCitrix ADCアプライアンスのデフォルトのSOパスワードがわからない場合は、Citrixテクニカルサポートにお問い合わせください。注:このタスクを実行できるのは、スーパーユーザーまたはシステム管理者のみです。

set ssl fips -initHSM Level-2 <soPassword> <oldSoPassword> <user-Password> [-hsmLabel <string>]

save configuration

initHSM
<!--NeedCopy-->

FIPS 初期化レベル。アプライアンスは現在、レベル 2 (FIPS 140-2) をサポートしています。これは必須の議論です。設定可能な値:レベル 2

hsmLabel

ハードウェアセキュリティモジュール (HSM) を識別するラベル。

最大長：31

注:FIPS カード上のすべてのデータは、前述のコマンドで消去されます。

HSM パスワードを安全な場所に保存する

HSM のパスワードは、会社の運用手順に従って安全な場所に保管する必要があります。

注：HSM は、ログイン試行が 3 回失敗するとロックされます。ロックされると、動作不能になり、設定を変更できなくなります。

その他の機能

このセクションでは、展開されたアプライアンスのセキュリティを向上させるためにCitrix Web App FirewallとCitrix Gatewayの両方に適用できる構成変更の例と、複数の階層またはセキュリティの構築に関する情報を提供します。このセクションでは、Citrix ADCまたはCitrix Gateway をSAML SPまたはSAML IdP、またはその両方として使用する場合の構成の詳細についても説明します。

Citrix Web App Firewall セキュリティに関する推奨事項

RFC コンプライアンスチェックでは、WAFプロファイルのデフォルトrfcprofileとして ‘APPFW_RFC_BLOCK’ を保持することをお勧めします。
WAFはSamesite Cookie属性値の挿入をサポートしており、「Strict」または「Lax」の値を選択することで、Cookie を同じサイトまたはクロスサイトのコンテキストに制限できます。

アプライアンスをツーアームモードでデプロイする

ツーアームモードのインストールでは、アプライアンスはアプライアンスが保護するユーザと Web サーバの間に物理的に配置されます。接続はアプライアンスを通過する必要があります。この配置により、アプライアンスの周りのルートを見つける可能性が最小限に抑えられます。

「デフォルト拒否」ポリシーを使用する

Citrix Web App Firewall ポリシーと一致しないすべての要求をブロックするには、管理者がグローバルレベルですべての拒否ポリシーを設定することをお勧めします。次に、グローバルレベルで「deny all」ポリシーを設定するコマンドのサンプルセットを示します。

add appfw profile default_deny_profile -defaults advanced

add appfw policy default_deny_policy true default_deny_profile

bind appfw global default_deny_policy <PRIORITY>
<!--NeedCopy-->

注意: PRIORITY 設定では、デフォルトのポリシーが最後に評価されるようにする必要があります（要求が他の構成済みポリシーと一致しない場合のみ）。

Citrix ADCソフトウェアには、appfw_blockなどのデフォルトプロファイルが含まれています。このプロファイルは、構成時にCitrix Web App Firewallポリシーに一致しない要求をブロックします。以下のコマンドを実行して、デフォルトプロファイルを設定します。

set appfw settings -defaultProfile appfw_block
<!--NeedCopy-->

Citrix Web App Firewall — 複数階層のセキュリティを構築

次のガイドラインは、ご使用の環境とサポートされているアプリケーションに応じて、複数階層のセキュリティを構築するのに役立ちます。

各層の SessionCookieName パラメーターに異なる値を設定します。

set appfw settings -sessionCookieName "citrix_ns_id_1"
<!--NeedCopy-->

第1層のセキュリティ

第 1 層のセキュリティを構築するには、次の手順を実行します。

バッファオーバーフロー、SQL インジェクション、クロスサイトスクリプティングを有効にします。
開始 URL は、どの URL にアクセスする必要があるかをアプリケーションが特定し、強制的なブラウジングから保護する必要がある場合に必要です。
[フィールド形式を有効にする] アプリケーションがフォームフィールドへの入力を期待しているかどうかをチェックします。

クロスサイトスクリプティングチェックでは、同じオリジンルールに違反する JavaScript 拡張 Web コンテンツの大規模なインストールベースが多くの企業にあるため、誤検出が生じる可能性があります。このようなサイトで HTML クロスサイトスクリプティングチェックを有効にする場合は、チェックが正当なアクティビティをブロックしないように、適切な例外を生成する必要があります。

最初の層を展開し、誤検出を探し、例外をデプロイして、次の層に移ります。段階的な実装は、AppFW デプロイメントの管理に役立ちます。

第 2 層のセキュリティ

第 2 層のセキュリティを構築するには、次の手順を実行します。

バッファオーバーフロー、SQL インジェクション、クロスサイトスクリプティングに加えて、プロファイルでシグニチャを有効にします。1300個以上のシグネチャがあります。すべてのシグニチャルールを有効にするのではなく、アプリケーションの保護に該当するシグニチャのみを有効にするようにしてください。

2 番目の層を展開し、誤検出を探し、例外をデプロイして、次の層に移ります。段階的な実装は、Citrix Web App Firewall展開の管理に役立ちます。

第 3 層のセキュリティ

第 3 層のセキュリティを構築するには、次の手順を実行します。

アプリケーションのニーズに基づいて、CSRF タグ付け、Cookie の一貫性などの高度なプロファイルセキュリティチェックを有効にします。フォームが必要なアプリケーションの一部でのフィールドの一貫性。
高度なセキュリティチェックでは、より多くの処理が必要になり、パフォーマンスに影響する可能性があります。アプリケーションに高度なセキュリティが必要でない限り、基本プロファイルから始めて、アプリケーションに必要なセキュリティを強化することができます。

基本Citrix Web App Firewallプロファイルで無効になっているセキュリティチェックはすべて、HTTPレスポンスのオブジェクトに対して実行されます。したがって、これらのセキュリティー検査はリソースを大量に消費します。Citrix Web App Firewallが応答側の保護を実行する場合、個々のクライアントに送信された情報を記憶する必要があります。たとえば、フォームがCitrix Web App Firewallによって保護されている場合、応答で送信されたフォームフィールド情報はメモリに保持されます。次のリクエストでクライアントがフォームを送信すると、情報が Web サーバーに送信される前に、不整合がないかどうかがチェックされます。この概念をセッション化といいます。開始 URL 内の URL エンクロージャ、Cookie の一貫性、フォームフィールドの一貫性、および CSRF フォームのタグ付けなどのセキュリティチェックは、すべてセッション化を意味します。これらのセキュリティチェックで使用されるCPUおよびメモリリソースの量は、Citrix Web App Firewallを介して送信されたリクエストの数に応じて直線的に増加します。例：

フォームフィールドの一貫性チェックを有効にする:このチェックは、Web フォームがクライアントによって不適切に変更されていないかどうかを確認するために必要です。フォーム内の重要な情報を提供しホストするアプリケーションでは、このチェックが必要です。
CSRF フォームのタグ付けチェック:このチェックはフォーム用です。クロスサイトリクエストフォージェリ (CSRF) フォームのタグ付けチェックは、保護された Web サイトからユーザーに送信された各 Web フォームに一意で予測不可能な FormID をタグ付けし、ユーザーから返された Web フォームを調べて、指定された FormID が正しいことを確認します。このチェックは、クロスサイトリクエストフォージェリ攻撃から保護します。アプリケーションに Web ベースのフォームがある場合は、このチェックを有効にする必要があります。このチェックでは、Web フォームを詳細に分析する他の特定のセキュリティチェックと比較して、CPU の処理能力は比較的少なくて済みます。したがって、保護されたWebサイトやCitrix Web App Firewall自体のパフォーマンスを大幅に低下させることなく、大量の攻撃に対処できます。

Citrix Web App Firewall ワークフロー手順

次の図は、Citrix Web App Firewall ワークフローの手順を示しています。

Citrix Web App Firewall ワークフロー手順

Citrix Web App Firewallワークフローに関連する手順の概要は次のとおりです。

セキュリティプロファイルを設定します。
すべての既知の脅威、つまりネガティブモデルに署名を適用します。
このセキュリティプロファイルを有効にする必要がある正しいトラフィックフローを検出できるトラフィックポリシーを設定します。

これで、本番トラフィックがシステムを通過する準備が整いました。第 1 レベルのフローが完了しました。さらに、学習インフラストラクチャを構成します。多くの場合、お客様は本番トラフィックで学習したいと思っているため、シグニチャを適用することでリスクを回避できます。次の手順を実行します：

学習インフラストラクチャを設定します。
学習した保護ルールを展開します。
ライブになる前に、適用されたシグネチャとともに学習データを検証します。

Citrix Gateway のセキュリティに関する推奨事項

「デフォルト拒否」ポリシーを使用する

管理者は、グループベースでリソースへのアクセスを選択的に有効にする承認ポリシーの使用に加えて、グローバルレベルで「すべて拒否」ポリシーを使用してCitrix Gateway を構成することをお勧めします。

既定では、DefaultAuthorizationAction パラメーターは [拒否] に設定されています。この設定を確認し、各ユーザーに明示的なアクセス権を付与します。CLI で show defaultAuthorizationAction コマンドを使用すると、設定を確認できます。グローバルレベルですべてのリソースを拒否するようにパラメータを設定するには、CLI から次のコマンドを実行します。

set vpn parameter -defaultAuthorizationAction DENY
<!--NeedCopy-->

サーバー間の TLS1.1/1.2 通信を使用する

Citrix Gateway アプライアンスと、LDAPやWeb Interfaceサーバーなどの他のサービスとの間のリンクには、TLS1.1/1.2を使用することを強くお勧めします。このプロトコルの古いバージョンである 1.0 および SSLv3 以前の使用は推奨されません。

「イントラネットアプリケーション」機能を使用するイントラネットアプリケーションを使用して、Citrix Gateway プラグインによって傍受され、ゲートウェイに送信されるネットワークを定義します。インターセプトを定義するコマンドのサンプルセットを以下に示します。

add vpn intranetApplication intra1 ANY 10.217.0.0 -netmask 255.255.0.0 -destPort 1-65535 -interception TRANSPARENT

bind vpn vserver v1 –intranetapp intra1
<!--NeedCopy-->

認証、承認、および監査のセキュリティに関する推奨事項

Citrix ADCまたはCitrix GatewayアプライアンスがSAML SPまたはSAML IdP、またはその両方として構成されている場合、推奨される構成の詳細については、記事https://support.citrix.com/article/CTX316577を参照してください。

SAML 認証の詳細については、 SAML 認証を参照してください。

その他の情報リソース

Citrix ADCおよびCitrix Gateway アプライアンスに関するその他のセキュリティ情報については、次のリソースを参照してください。

Citrixセキュリティポータル：http://www.citrix.com/security
Citrix ADC製品マニュアル

Citrix ADCの構成についてさらにサポートが必要な場合は、サポートリクエストを送信してください。https://www.citrix.com/support.html

このコンテンツの正式なバージョンは英語で提供されています。Citrixドキュメントのコンテンツの一部は、お客様の利便性のみを目的として機械翻訳されています。Citrixは機械翻訳されたコンテンツを管理していないため、誤り、不正確な情報、不適切な用語が含まれる場合があります。英語の原文から他言語への翻訳について、精度、信頼性、適合性、正確性、またはお使いのCitrix製品またはサービスと機械翻訳されたコンテンツとの整合性に関する保証、該当するライセンス契約書またはサービス利用規約、あるいはCitrixとのその他すべての契約に基づき提供される保証、および製品またはサービスのドキュメントとの一致に関する保証は、明示的か黙示的かを問わず、かかるドキュメントの機械翻訳された範囲には適用されないものとします。機械翻訳されたコンテンツの使用に起因する損害または問題について、Citrixは責任を負わないものとします。

この情報は役に立ちましたか?

Citrix ADC MPX、VPX、およびSDXセキュリティのベストプラクティス

December 7, 2022

寄稿者:

December 7, 2022

寄稿者:

この情報は役に立ちましたか?