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

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 とのシームレスな統合も提供します。これにより、クラウドのパワーでデータセンターを拡張できます。

展開のライフサイクルを通じてセキュリティを維持するために、以下の考慮事項を確認することをお勧めします。

  • 物理的セキュリティ
  • アプライアンスのセキュリティ
  • 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)を参照し、新規および更新されたセキュリティ情報に関するアラートへのサインアップを検討してください。

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

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

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

Citrix ADCライトアウト管理(LOM)をリセットします

本番環境で使用するLOMを構成する前に、LOMの工場出荷時設定にリセットしてデフォルト設定を復元することをお勧めします。

  1. Citrix ADCシェルプロンプトで、次のコマンドを実行します。

    >ipmitool raw 0x30 0x41 0x1
    <!--NeedCopy-->
    

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

  2. LOM GUI で、[ 構成] > [SSL 認定] に移動し、証明書と秘密キーを追加します。

    また、以下のユーザー構成を実行することを強くお勧めします。LOM GUI の使用方法

    • [ 設定 ] > [ ユーザー ] > [ユーザーの変更] に移動し、nsrootスーパーユーザーアカウントのパスワードを変更します。
    • [ 設定 ] > [ ユーザー] > [ユーザーの変更 ] に移動し、ユーザーのポリシーを作成または既存のポリシーをバインドします。
    • [ 構成 ] > [ IP アクセス制御 ] > [IP アクセス制御 を追加 ] に移動し、既知の範囲の IP アドレスへのアクセスを許可するように IP アクセス制御を構成します。
    • [ 構成 ] > [ ユーザー] > [ユーザーの変更] に移動し、代替スーパーユーザーアカウントを作成し、このアカウントにポリシーをバインドします。

    LOM 設定の詳細については、 LOM 設定を参照してください。

永続データの保守と削除

Citrix ADCを別の環境に再展開したり、使用停止したり、RMAでCitrixに戻したりする場合は、永続的なデータがアプライアンスから正しく削除されていることを確認してください。

このプロセスの詳細については、次の FAQ を参照してください。https://www.citrix.com/support/programs/faqs.html

設定時の注意事項

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

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

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

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

ネットワークセキュリティの主な考慮事項

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

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

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

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

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

一般向け仮想サーバーにバインドされている場合、評判の良い 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 秘密鍵と公開鍵のペアを作成して使用します。詳細については、ナレッジセンターの記事「CTX109011: パブリックキー認証を使用してCitrix ADCアプライアンスへの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 インスタンスのセキュリティ保護:

  1. 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
    <!--NeedCopy-->
    

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

  2. 作成したユーザーとしてログインし、次の操作を実行します。
    • 現在のユーザーが 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-->
    
  3. そのVPXのコンソールで、そのユーザーとしてログインし、このユーザーにシェルアクセスが許可されていないことを確認します。

    > shell
    ERROR: Not authorized to execute this command [shell]
    <!--NeedCopy-->
    
  4. 通常の管理者ユーザー (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 インスタンスのセキュリティ保護:

  1. SVM GUI から新しい VPX インスタンスが作成されたら、インスタンス管理者ユーザーを作成し、[ シェル/SFTP/SCP アクセス ] チェックボックスをオフにします。シェルアクセスを無効にすると、svm_access_policy (action DENY) が指定されたインスタンス管理者ユーザーに明示的にバインドされます。

  2. VPX 管理者にこのユーザー情報を提供します。SDX ADMIN は、この nsroot 管理者パスワードを保持する必要があり、VPX 管理者と共有しないでください。

注:

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

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

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

    AllowTcpForwarding no

  2. ファイルを保存し、/nsconfig にコピーして、テスト中に再起動した場合に備えて、変更が維持されるようにします。

kill -SIGHUP <sshdpid> コマンドを使用してプロセスを終了するか、システムを再起動します。

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

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

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

高可用性が必要ない展開では、この機能を無効にする必要があります。

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

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

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

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

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

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

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

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

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

Citrix 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 ADC Citrix Web App Firewallのウェブページを参照してください。

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

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

セキュアなクラスタ展開: Citrix ADCクラスタノードがデータセンターの外部に分散されている場合、ノード間メッセージング(NNM)、AppNNM、および高可用性のセットアップにセキュアなRPCを使用することを強くお勧めします。

Citrix ADCクラスタ内のすべてのCitrix ADC IPアドレスおよび高可用性セットアップに対してセキュア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
  • DIAMETER, 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アプライアンスまたはバックエンドサーバーCitrix ADCによって設定されたCookieに対してHttpOnlyを有効にするには:
Citrix ADCが挿入したCookieに対してデフォルトで有効(バックエンドサーバーによって設定されたCookieに対してRewriteを介して可能)。

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

以下は、HttpOnly フラグが設定された Cookie の例です。

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

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

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

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

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

書き換えポリシーを使用して、クッキーにセキュアとHttpOnlyを挿入する:

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

: SSL VIP では、セキュア Cookie と HTTPOnly Cookie を一緒に行うことができます。非 SSL VIP の場合は、HttpOnly フラグを挿入できます。

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

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

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

  1. 書き換え機能が有効になっていない場合は、有効にします。

    enable feature REWRITE
    <!--NeedCopy-->
    
  2. 書き換えアクションを作成します(この例では、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=/)!)" -bypassSafetyCheck YES
    <!--NeedCopy-->
    
  3. アクションをトリガーする書き換えポリシーを作成します。

    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-->
    
  4. リライトポリシーをセキュリティ保護する仮想サーバーにバインドします(Secure オプションを使用する場合は、SSL 仮想サーバーを使用する必要があります)。

    bind lb vserver <vserver name> - <policy name> -priority <priority number> -gotoPriorityExpression NEXT -type RESPONSE
    <!--NeedCopy-->
    

    例:

    bind lb vserver mySSLVServer -policyName rw_force_secure_cookie -priority 100 -gotoPriorityExpression NEXT -type RESPONSE
    <!--NeedCopy-->
    

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

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

推奨事項: Citrix ADCを有効にする:Citrix ADCソフトウェアバージョン12.0では、CLIを使用してこの設定を有効にできます。Citrix ADCソフトウェアのバージョン11.1以前では、この設定は書き換えポリシーを使用して有効にできます。

  • Citrix ADCソフトウェアバージョン12.0では、Citrix ADCアプライアンスは、SSLプロファイルおよびSSL仮想サーバーの組み込みオプションとして、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-->

詳細については、「 HTTP 厳格なトランスポートセキュリティ (HSTS) のサポートを構成する」を参照してください。

  • Citrix ADCソフトウェアのバージョン11.1以前では、HTTP厳密なトランスポートセキュリティ(HSTS)を有効にするには、書き換えポリシーを作成し、グローバルにバインドするか、問題の仮想サーバーにバインドします。

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

add rewrite action <action name> insert_http_header Strict-Transport-Security ""max-age=157680000\”"

add rewrite policy <policy name> “true” <action name>

bind lb vserver <vserver name> - <policy name> -priority <priority number> END -type RESPONSE
<!--NeedCopy-->

例:

add rewrite action insert_STS_header insert_http_header Strict-Transport-Security ""max-age=157680000\”"

add rewrite policy enforce_STS "true” insert_STS_header

bind lb vserver vs1 -policyName enforce_STS -priority 100 -gotoPriorityExpression END -type RESPONSE
<!--NeedCopy-->

詳しくは、次のトピックを参照してください:

https://support.citrix.com/article/CTX205221

https://www.citrix.com/blogs/2010/09/10/strict-transport-security-sts-or-hsts-with-citrix-netscaler-and-access-gateway-enterprise/

強力な認証:

機密データ、アプリ、および管理へのすべてのアクセスに対して、強力な認証(または多要素認証-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

set ssl service <vServiceName> -ssl2 DISABLED   -ssl3  DISABLED   -tls1   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 の鍵交換が含まれます。セキュリティ、パフォーマンス、および互換性の間で最高の妥協点を提供します。

  1. TLS1.2-AES128-GCM-SHA256
  2. TLS1.2-AES-128-SHA256
  3. TLS1.2-ECDHE-RSA-AES128-GCM-SHA256
  4. TLS1.2-ECDHE-RSA-AES-128-SHA256
  5. TLS1-ECDHE-RSA-AES128-SHA
  6. TLS1.2-DHE-RSA-AES128-GCM-SHA256
  7. TLS1.2-DHE-RSA-AES-128-SHA256
  8. TLS1-DHE-RSA-AES-128-CBC-SHA
  9. 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 ユーザのデフォルトパスワードを変更するには、次の手順を実行します。

  1. スーパーユーザーとしてログオンし、構成ユーティリティを開きます。
  2. ナビゲーションペインで、[システム] ノードを展開します。
  3. 「ユーザー」ノードを選択します。
  4. [システムユーザー] ページで、nsroot ユーザーを選択します。
  5. [ パスワードの変更] を選択します。
  6. [パスワード]フィールドと[パスワードの確認]フィールドに必要なパスワードを入力します。
  7. [OK] をクリックします。

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

add system user <newuser> <password>

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

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

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

  1. スーパーユーザーとしてログオンし、構成ユーティリティを開きます。
  2. ナビゲーションペインで、[システム] ノードを展開します。
  3. 「ユーザー」ノードを選択します。
  4. [システムユーザー] ページで、既定のユーザーを選択します。
  5. [修正] を選択します。
  6. [パスワード]フィールドと[パスワードの確認]フィールドに必要なパスワードを入力します。
  7. [OK] をクリックします。

:Citrix ADCリリース11.0以降では、ローカルユーザーと管理者は強力なパスワードを選択する必要があります。パスワードの複雑さの要件の例を次に示します。

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

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

set system parameter -localAuth ( ENABLED | DISABLED ) -minpasswordlen <positive_integer> -natPcbForceFlushLimit <positive_integer> -natPcbRstOnTimeout ( ENABLED | DISABLED )
-strongpassword ( ENABLED | DISABLED ) -promptString <string> -rbaOnResponse ( ENABLED | DISABLED ) -timeout <secs>
<!--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アプライアンスはユーザーにデフォルトのパスワードを新しいパスワードに変更するように求めます。nsroot パスワードは、デフォルトの資格情報を使用した最初のログイン時に、CLIまたはGUIから変更できます。コマンドプロンプトで入力します。

set system parameter -forcePasswordChange ( ENABLED | DISABLED )

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

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

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

  1. コマンドラインインターフェイスを使用して、システム管理者としてログインします。
  2. 次のコマンドを入力します。
create kek <passphrase>
<!--NeedCopy-->

  • create system kek コマンドを実行すると、ほとんどのパスワード暗号化に KEK が使用されます(ローカルユーザパスワードは KEK で暗号化されません)。
  • KEK ファイルを削除することはできません。シェルへのアクセスがあり、誤ってキーフラグメントファイルを削除すると、構成が失われ、同期が失敗し、ログオンが失敗する可能性があります。注意すべきポイントの一部を以下に示します。

    • ダウングレード時には、インストールされているビルドと一致する古い構成ファイルを常に使用してください。そうしないと、ログオン、ソース構成、同期、フェイルオーバーが失敗する可能性があります。
    • キーフラグメントファイルのいずれかが失われたり破損したりすると、機密データの暗号化/復号化が失敗し、構成が失われ、同期の失敗、ログオンが失敗する可能性があります。
  • パスフレーズは 8 文字以上である必要があります。

アクセス制御リストの使用:

デフォルトでは、GUIやSSHを含むすべてのプロトコルとポートがCitrix ADCアプライアンス上でアクセス可能です。アクセス制御リスト(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 アドレス、および MIP アドレスで管理機能を有効にできます。有効にすると、NSIP、SNIP、アドレスへのアクセスを提供して、管理機能へのアクセスを保護します。管理者は、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-->
  • 適切なレスポンダーポリシーを使用してアプライアンスの HTTPS フロントエンドサーバーを構成して、XML-API Web サービスのセキュアなトランスポートを指定します。これは、Citrix ADCソフトウェアのリリース8.0以降を実行しているアプライアンスに適用されます。次に、一連のサンプルコマンドを示します。
enable ns feature responder

add responder policy allow_soap 'HTTP.REQ.URL.STARTSWITH("/soap").NOT' RESET

add lb vserver xml-https ssl 192.168.0.4 443

add server localhost 127.0.0.1

add service xml-service localhost HTTP 80

bind lb vserver xml-https xml-service

bind lb vserver xml-https -policyName allow_soap -type REQUEST -priority 1

add ssl certkey xml-certificate -cert testcert.cert -key testcert.key

bind ssl certkey xml-https xml-certificate
<!--NeedCopy-->
  • クライアント側の証明書を使用すると、セキュリティを強化できます。クライアント側の証明書とクライアント認証の詳細については、Citrix Docsまたはナレッジセンターの記事「CTX214874:Citrix ADCアプライアンスでクライアント証明書を作成して使用する方法」の「SSLオフロードと高速化」>「クライアント認証の構成」を参照してください。ファームウェア 10.1 以上。

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

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

add system user readonlyuser

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

ユーザー、ユーザーグループ、またはコマンドポリシーの構成について詳しくは、Citrixドキュメントを参照してください。

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

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

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

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

set system user <name> -timeout <secs>
<!--NeedCopy-->
  • ユーザレベルのタイムアウト。グループ内のすべてのユーザに適用されます。

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

set system group <groupName> -timeout <secs>
<!--NeedCopy-->
  • グローバルシステムタイムアウト。タイムアウトが設定されていないグループのすべてのユーザおよびユーザに適用されます。

GUI: [ システム ] > [ 設定] に移動し、[ グローバルシステムパラメータの設定] をクリックして、[任意のクライアントアイドル タイムアウト (秒)] パラメータを設定します。 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.conf ファイルを変更して、NTP サーバが機密パケット内の情報を開示しないようにする必要があります。

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

add ntp server <IP_address> 10

enable ntp sync
<!--NeedCopy-->

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

SNMP の設定

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

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 メッセージをログに記録するには、次の手順を実行します。

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

    local0.* @10 .100.3.53

    local1.* @10 .100.3.53

  3. 上記のロギングファシリティからのログエントリを受け入れるように syslog サーバを設定します。詳細については、syslog サーバのマニュアルを参照してください。
  4. 標準の syslog ソフトウェアを使用するほとんどの UNIX ベースサーバでは、メッセージおよび nsvpn.log ファイルのローカルファシリティ構成エントリを syslog.conf 構成ファイルに追加する必要があります。ファシリティの値は、アプライアンスで構成されている値に対応している必要があります。
  5. 既定では、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 文字に設定してください。パスワードを頻繁に変更してください。

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

無効なHTTP要求を削除するようにCitrix ADCを構成する

Citrix ADC アプライアンスは、無効なHTTP要求が仮想サーバーを通過することを防ぐために、HTTP要求の厳密なチェックと強制で構成することを強くお勧めします。これは、CLI で次のコマンドを使用して、組み込みの HTTP プロファイル nshttp_default_strict_validationを 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-->

:これらのコマンドは、Citrix ADCリリース10.5以降でのみサポートされています。

クローズ通知の設定

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

set ssl parameter -sendCloseNotify y

save ns config
<!--NeedCopy-->

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

DNSSECを使用するお客様には、以下の推奨事項を適用Citrix。

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

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

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

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

転がる KSK/ZSK x.509証明書の有効期限が切れる前の秘密鍵

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

セキュアな DNSSEC ADNS サーバ

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

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

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

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

    例:

    add service s1 <ip address> adns 53`
    <!--NeedCopy-->
    
  2. DNS キーを作成します。

    たとえば、com ドメインの権限のあるサーバーとして機能するには、次のようにします。

    create dns key -zoneName com -keytype ksK -algorithm rsASHA1 -keysize 3000 -fileNamePrefix com.ksk.rsasha1.3000
    
    create dns key -zoneName com -keytype zsk -algorithm rsASHA1 -keysize 3000 -fileNamePrefix com.zsk.rsasha1.3000
    <!--NeedCopy-->
    

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

  3. 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-->
    
  4. 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-->

注:Citrix ADCソフトウェアのリリース9.2以降、SSLv2リダイレクト機能と暗号リダイレクト機能はデフォルトで無効になっています。

Citrix ADCバージョン10.0以前のバージョンを構成して、セキュアなSSL再ネゴシエーションを使用します

Citrix ADCソフトウェアのリリース9.3eまたは10.0のセキュアでないSSL再ネゴシエーションを防止するようにCitrix ADCを構成するには、次のコマンドを実行します。

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

Citrix ADCソフトウェアの以前のリリースでは、次のコマンドを実行してSSL再ネゴシエーションを無効にします。

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

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

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

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

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

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

TLS 証明書とキーの管理

NDPP 展開用の TLS 暗号スイートの構成

NDPP 展開でサポートされる TLS 暗号スイートのリストについては、https://www.citrix.com/content/dam/citrix/en_us/documents/downloads/netscaler-adc/Common-criteria-documents-for-NetScaler-10.5.zipを参照してください。

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

  1. 仮想サーバーからすべての暗号のバインドを解除する

    unbind ssl vs v1 –cipherName FIPS
    <!--NeedCopy-->
    
  2. 次のコマンドを使用して、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
    <!--NeedCopy-->
    

信頼されたルート CA 証明書のインポート:

  1. scpまたはWinSCPなどのセキュアなファイル転送ユーティリティを使用して、サーバー発行者(ルート)証明書をCitrix ADCアプライアンスの/nsconfig/sslディレクトリに転送します。

    注:この手順を完了するには、SCP または WinSCP を通じてスーパーユーザーとして認証する必要があります。

  2. システム管理者またはスーパーユーザーとしてCitrix ADCアプライアンスにログオンし、次のコマンドを入力します。

add ssl certkey <Certificate_Name> –cert <Cert_File_Name>
<!--NeedCopy-->

注:信頼できることが知られている証明機関からのルート CA 証明書のみをインストールします。他のすべての証明書を削除します。

PKCS #12 (.PFX) 証明書とキーファイルのインポート:

証明書およびキーファイルをCitrix ADCアプライアンスにインポートする方法の詳細については、Citrix製品ドキュメントの「 SSLオフロードとアクセラレーション」>「既存の証明書とキーのインポート 」トピックを参照してください。

  1. 前のセクションの手順 1 で説明したように、.pfx ファイルを /nsconfig/ssl ディレクトリに転送します。

  2. CLIを使用してCitrix ADCアプライアンスにシステム管理者またはスーパーユーザーとして認証し、次のコマンドを実行します。

    convert ssl pkcs12 Cert-Client-1.pfx -export -certFile Cert-Client-1 -keyFile Key-Client-1
    <!--NeedCopy-->
    
  3. 証明書をCitrix ADCアプライアンスに次のように追加します。

    add ssl certkey Clent-Cert-1 –cert Cert-Client-1
    <!--NeedCopy-->
    
  4. 現在の構成を保存します。

    save ns config
    <!--NeedCopy-->
    

注: Citrix ADC 11.0 以降のリリースでは、PKCS #12(.pFX)ファイルが自動的にPEMに変換され、すべての証明書が自動的にCAに追加およびリンクされます。

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

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

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

  2. RSA 秘密キーを作成します。

    create fipsKey m1 -modulus 2048
    <!--NeedCopy-->
    
  3. 証明書署名要求 (CSR) を作成します。

    create certreq csr_1 -fipsKeyName m1 -countryName IN -stateName BA -organizationName citrix
    <!--NeedCopy-->
    
  4. CSRを認証局に提出します。

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

スーパーユーザーまたはシステム管理者としてログインし、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 セキュリティに関する推奨事項

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

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

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

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

add appfw profile default_deny_profile –defaults advanced

add appfw policy default_deny_policy NS_TRUE default_deny_profile

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

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

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

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

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

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

セキュリティの第 1 層

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

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

クロスサイトスクリプティングチェックでは、同じオリジンルールに違反する JavaScript 強化ウェブコンテンツの大規模なインストールベースを使用している企業が多いので、誤検出が発生する可能性があります。このようなサイトで 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. セキュリティプロファイルを設定します。
  2. すべての既知の脅威(ネガティブモデル)に署名を適用します。
  3. このセキュリティプロファイルをアクティブにする必要がある正しいトラフィックフローを検出できるトラフィックポリシーを設定します。

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

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

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

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

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

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

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

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

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

[イントラネットアプリケーション]機能 を使用するイントラネットアプリケーションを使用して、Citrix Gatewayプラグインによって傍受され、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 AAA セキュリティに関する推奨事項

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

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

その他の情報リソース

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

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

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