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

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

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

  • 物理的セキュリティ
  • アプライアンスのセキュリティ
  • ネットワークセキュリティ
  • 管理と管理

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

重要:

ソフトウェアバージョン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アプライアンス(またはホスティングサーバー)は、適切な無停電電源装置(UPS)で保護する必要があります。停電が発生した場合、UPSはアプライアンスの継続的な動作を保証するか、物理または仮想のCitrix ADCの制御によるシャットダウンを可能にします。UPSの使用は、電力スパイクに対する保護にも役立ちます。

暗号化キーの保護

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

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

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

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

また、Citrix製品に関連するセキュリティ情報も確認することをお勧めします。新しいセキュリティ情報および更新されたセキュリティ情報については、Citrixセキュリティ情報の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の工場出荷時設定にリセットしてデフォルト設定を復元Citrix。

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

    >ipmitool raw 0x30 0x41 0x1
    

    : 上記のコマンドを実行すると、LOM は工場出荷時のデフォルト設定にリセットされ、すべての SSL 証明書が削除されます。LOM ポートを再構成する方法については、[Citrix ADC MPXアプライアンスの管理ポートをライトアウト](/en-us/netscaler-hardware-platforms/mpx/netscaler-mpx-lights-out-management-port-lom.html

  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証明書が作成されます。これらの証明書は、実稼働環境での使用を目的としていないため、置き換える必要があります。

Citrix ADC アプライアンスは、信頼できる認証局(CA)からの証明書またはエンタープライズ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 秘密鍵と公開鍵のペアを作成して使用します。詳細については、ナレッジセンターの記事 CTX109011:公開鍵認証を使用してCitrix ADCアプライアンスへのSSHアクセスを保護する方法 を参照してください。

  • これらの新しい証明書を使用するようにCitrix ADCを構成したら、次のコマンドを使用してGUI管理インターフェイスへのHTTPアクセスを無効にすることができます。

set ns ip <NSIP> -gui SECUREONLY

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

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

Citrix ADCアプライアンスを展開する際には、ネットワーク関連のセキュリティに関する次の考慮事項も考慮する必要があります。

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

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

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

    AllowTcpForwarding no

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

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

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

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

ハイアベイラビリティの設定方法の詳細については、Citrix およびCitrix ADCで高可用性ペアを設定する方法の「ハイアベイラビリティ」>「ハイアベイラビリティの設定」トピックを参照してください。

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

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

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

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

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

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

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

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

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

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

LOMポートを管理VLANの一部にするようにネットワークを構成Citrix。

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

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

:Citrix ADC VPXアプライアンスは、タグ付きVLANをサポートしていません。

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

Citrix Web App Firewall を使用すると、ユーザーはコードを変更することなく、構成をほとんど変更することなく、Webアプリケーションにセキュリティを強化できます。詳細については、Citrix ADC Citrix Web App Firewallのウェブページを参照してください。

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

set ns ip <NSIP> -restrictAccess enabled

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

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

set rpcnode <ip> -secure on

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

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

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

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

disable ns mode L3

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

set rpcNode <GSLB Site IP> -secure yes

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

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

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

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

Set-Cookie: ASP.NET_SessionId=ig2fac55; path=/; HttpOnly

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

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

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

set lb parameter -HttpOnlyCookieFlag (ENABLED)  

書き換えポリシーを使用して、クッキーにセキュアと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
    
  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
    

    例:

    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
    
  3. アクションをトリガーする書き換えポリシーを作成します。

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

    例:

    add rewrite policy rw_force_secure_cookie "http.RES.HEADER("Set-Cookie").EXISTS" act_cookie_Secure
    
  4. リライトポリシーをセキュリティ保護する仮想サーバーにバインドします(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を有効にする: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)

または

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

詳しくは、「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

例:

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

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

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

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

デフォルトの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>

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

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

データ保護用のシステムマスターキーを作成する: Citrix ADC 11.0リリースでは、LDAP認証に必要なサービスアカウントのパスワードやローカルに保存された認証、承認、およびユーザーアカウントの監査を行います。 システムマスターキーを作成するには、次の手順を実行します。

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

  • 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
  • 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

上記の例では、コマンドにより、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
  • 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
  • 適切なレスポンダーポリシーを使用してアプライアンスの 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

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

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

add system user readonlyuser

bind system user readonlyuser read-only 0

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

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

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

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

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

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

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

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

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

set system parameter -timeout <secs>

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

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

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

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

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

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

  • CLI:次のコマンドを使用して、コマンドプロンプトでタイムアウト値を指定します。
set cli mode -timeout <secs>
  • API: ログインペイロードでタイムアウト値を指定します。

ログ記録と監視

ネットワークタイムプロトコルの設定

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

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

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

add ntp server <IP_address> 10

enable ntp sync

追加する信頼できる 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>

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

set ns ip <IP_Address> -snmp disabled

外部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

これは、アプライアンスの 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

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

LOM構成

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

  • LOM ポートをインターネットに公開しないでください。
  • SPI ファイアウォールの背後に LOM を展開します。
  • LOM を、信頼できないネットワークトラフィックから論理的(別個の VLAN)または物理的(別個の LAN)に分離されたネットワークセグメントに展開します。
  • 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

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

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 の数を追跡します。

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

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

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

set ns tcpProfile profile1 -rstWindowAttenuate ENABLED -spoofSynDrop ENABLED

Done

set lb vserver lbvserver1 -tcpProfileName profile1

Done

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

特定の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

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

クローズ通知の設定

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

set ssl parameter -sendCloseNotify y

save ns config

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

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

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

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

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

デフォルトでは、DNSSECキーの有効期限に関するSNMPアラームはCitrix ADCアプライアンス上で有効になっています。キーの有効期限の通知は、dnskeyExpiry という SNMP トラップを介して送信されます。dnskeyExpirySNMP トラップとともに、3 つの MIB 変数、dnskeyName、 およびdnskeyUnitsOfExpiryが送信されます。詳細については、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を権限のあるサーバーとして構成するには、次の手順に従います。

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

    例:

    add service s1 <ip address> adns 53`
    
  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
    

    注: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
    
  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

: さらに、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

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

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

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

set ssl parameter -denySSLReneg NONSECURE

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

set ssl parameter -denySSLReneg ALL

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

set ssl parameter -denySSLReneg NONSECURE

詳細については、「-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
    
  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
    

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

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

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

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

add ssl certkey <Certificate_Name> –cert <Cert_File_Name>

注:信頼できることが知られている証明機関からのルート 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
    
  3. 証明書をCitrix ADCアプライアンスに次のように追加します。

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

    save ns config
    

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

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

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

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

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

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

    create certreq csr_1 -fipsKeyName m1 -countryName IN -stateName BA -organizationName citrix
    
  4. CSR を CA に送信します。

ほとんどの商用およびエンタープライズ 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

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

HSMLabel

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

最大長さ:31

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

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

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

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

その他の機能:Citrix Web App Firewall とCitrix Gateway

このセクションでは、展開されたアプライアンスのセキュリティを向上させるためにCitrix Web App FirewallとCitrix Gateway の両方に適用できる構成変更の例を示します。このセクションでは、複数の階層またはセキュリティを構築する方法についても説明します。

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>

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

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

set appfw settings -defaultProfile appfw_block

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 レベルが完了します。 さらに、学習インフラストラクチャを設定します。多くの場合、お客様は本番トラフィックで学習したいと思っているため、シグニチャを適用することでリスクを回避できます。 a. 学習インフラストラクチャを設定します。 b. 学習したルールを保護用に 展開します。 c. ライブになる前に、適用されたシグネチャとともに学習データを検証します。

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

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

Citrix Gateway には、グローバルレベルで「すべて拒否」ポリシーを設定することをお勧めします。また、承認ポリシーを使用してグループ単位でリソースへのアクセスを選択的に有効にすることもできます。

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

set vpn parameter -defaultAuthorizationAction DENY

サーバー間の 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

その他の情報リソース

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

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

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