Citrix ADC / Citrix Gateway に対する DTLS Amplification DDoS 攻撃

<2021/1/5 追記> 予定より早く機能拡張がリリースされたようです。

Citrix has added a feature enhancement for DTLS which, when enabled, addresses the susceptibility to this attack pattern. The enhancement builds are available on the Citrix downloads page for the following versions:

Citrix ADC and Citrix Gateway 13.0-71.44 and later releases
NetScaler ADC and NetScaler Gateway 12.1-60.19 and later releases
NetScaler ADC and NetScaler Gateway 11.1-65.16 and later releases

Citrix ADC / Citrix Gateway でDTLSを使用する場合、この機能拡張をインストールした上で、“Hello Verify Request”の検証を有効にする必要があるようです。詳細は、CTX289674をご参照ください。

<2020/12/30 追記> 下記に引用しているCTX289674によると、2021/1/12に、この問題に対処するための機能拡張が提供される予定になっているようです。

Citrix expects to have this enhancement available on the Citrix downloads page for all supported versions on Jan 12, 2021.

まだ情報出しの段階のようですが、タイトルのことが確認されているようです。

support.citrix.com

 At this time, the scope of attack is limited to a small number of customers around the world, and further, there are no known Citrix vulnerabilities associated with this event. 

 とのことなので、今のところ即座にデータ漏洩等の問題が存在している訳ではなさそうですが、運用されている方はちょっと注意が必要かもしれませんね。

もし攻撃を受けた場合、一時的な緩和策として、DTLSを無効にするようにとなっています。

 set vpn vserver <vpn_vserver_name> -dtls OFF 

 NOTEにも書かれていますが、この場合、Citrix Gateway 越しのEDT通信ができなくなります。

今のところEDT必須のアプリケーションって、存在するのかどうかはわかりませんが……。

Enlightened Data Transportとか、名前が悪いよ名前がー

Citrix MyAccount でライセンスのリホストができなくなっている話

自分もつい最近知ったのですが、これまで Citrix MyAccount サイトのライセンス管理ツールを使用してできていた、ライセンスファイルのリホスト操作ができなくなり、リホストする必要がある場合はカスタマーサービスに依頼しなければならないようです。

support.citrix.com

従来は、例えば検証環境のライセンスサーバーに割り当てたライセンスファイルをリホストして本番環境に移動するとか、DRサイトのライセンスサーバーのホスト名をメインサイトのライセンスサーバーのホスト名と別にしなければならない場合に、同一プロダクトIDのライセンスをリホストで別ライセンスサーバーに割り当てるということが自前でできていたのですが、それができなくなっています (後者はちょっと微妙ですが) 。

この「微妙」というのがグレーゾーンでして…。前提として、(オンプレミス) Citrix ライセンスサーバーは、Citrix サイトと通信してライセンスの検証をするような動作はしないんですね。ですから、ライセンスサーバーはインターネットと直接通信できない内部ネットワークに配置することも可能です。

一方、単一のプロダクトIDのライセンスをリホストでどんどん別々のライセンスサーバーに割り当てるということは、やろうと思えばできてしまっていた訳ですが、そういうことはやらないようにしましょうね、というのが言わば「紳士協定」であった訳です。

上記ドキュメント内で「弊社内にて本機能のご利用状況について精査させていただいた結果、本来期待される状況とは異なる結果となりましたため、セルフサービスでの機能を削除する事とさせていただきました。」とありますが、まあそういうことなんだろうな、というのが私の感想です。

Citrix ライセンスは猶予期間の動作を含め、これまでは割と「ゆるめ」な扱いだった印象ですが、 Perpetual ライセンスを完全に廃止して Subscription モデルのみに移行したり、急激に制限を厳しくしている感じがありますね。

www.citrix.com

今どきのなんでも as a Service な流れからすると致し方ないのでしょうが…。

検証などを生業としている人間からすると、ちょっと世知辛くなってきたなあというのが、正直なところではあります。

JMP Serverの証明書期限切れでConnection Serverからアクセスできなくなった場合の対処法

１年ほど前に構築した、Horizon環境のJMPサーバーに、突然アクセスできなくなってしまいました。

Horizon Consoleの[設定]－[JMP設定]のメニューを開くと、構成済みのJMP ServerのURLにアクセスできていません。Horizon Consoleに接続しているブラウザの開発者ツールを使用して、JMP ServerからHTTP 401応答が返ってきていることが確認できました。

詳細を調べるには、JMP Serverのログファイル (私の検証環境では C:\Program Files(x86)\VMware\JMP\com\xmp\logs\server_jmp.production.log ) を参照します。

このログから、JMP ServerがHTTP 401応答を返した原因が "Unable to load the public decryption keys or public decryption keys are already expired" であることが分かりました。

この問題の対処方法については、KB76627にまとめられています。

kb.vmware.com

JMP Serverにインストールされているopenssl.exeコマンドを使用して、証明書を再発行するというものですが…

exeファイルが置かれている C:\Program Files(x86)\VMware\JMP フォルダは、環境変数PATHの値に追加されていないでしょうから、事前に追加しておきます。

あるいは、作業フォルダが C:\Program Files(x86)\VMware\JMP\com\keys ですから、  ..\..\openssl.exe と指定してもよいでしょう。

それともう一点、opensslのconfigファイルが見つからないというエラーが出てくる場合があります。

JMP Serverと一緒にインストールされているopensslの構成ファイルは、exeファイルと同じフォルダにある C:\Program Files(x86)\VMware\JMP\openssl.cfg ファイルですが、このファイルのパスを、環境変数 OPENSSL_CONF の値に追加しておく必要があります。

jp.globalsign.com

初期設定もそうですが、JMP Serverは、この証明書まわりの設定がちょっと厄介ですね…

vCenter Server のアップデート失敗後、VAMIに繰り返しダイアログが表示されて操作できなくなった時の対処法

少し前のことですが、vCenter Server 7.0のVAMIに表示されている最新のアップデートを「ステージングしてインストール」したところ失敗し、その失敗メッセージのダイアログを閉じても繰り返し表示され、その他の操作が一切できない状態になってしまいました。

困った事に、SSOドメインの管理者だけでなく、仮想アプライアンス(Photon Linux)のrootでログインしても同じ状態となり、再起動しても効果がありません。

該当のアップデートは、SSHでアプライアンスにログインし、CLIで実行できたものの、

docs.vmware.com

アップデートのインストールと再起動後も、VAMIで操作できない状態は変わりませんでした。

この状態になってしまった場合、アプライアンスのローカルshellまたはSSHでログインし、手動で /etc/applmgmt/appliance/software_update_state.conf ファイルを削除しなくてはいけないようです。

tinkertry.com

上記ブログ記事を参考にして手順を実施したところ、問題なくVAMIにログインして操作ができるようになりました。

vCenter Server 自己署名証明書の期限切れ

こちらの記事でも紹介されているように、vCenter Serverの自己署名証明書を使っている場合、バージョンによっては、証明書の期限切れになってしまうところがそろそろ出てきているようです。

kcana.hatenablog.jp

ある日突然、vSphere Clientに接続できなくなってしまったことではじめて気付いた…なんてパターンも多そうですね。

実際に期限切れになってしまった時の対処法ですが、KBにまとめられています。 

https://kb.vmware.com/s/article/68171

まず最初にSTS (Security Token Service)証明書の再作成が必要で、VCSAの場合はpythonスクリプト、Windows版の場合はPowerShellスクリプトを、それぞれのKBのページからダウンロードして実行するようです。

https://kb.vmware.com/s/article/76719

https://kb.vmware.com/s/article/79263

直接関係ない話ですが、VCSA環境で管理者の作業端末がWindowsな場合、作業端末にダウンロードしたファイルをWinSCPでVCSAにアップするようにしている場合があると思いますが、この場合、VCSAでSSHだけでなくローカルシェルも有効にし、デフォルトシェルをアプライアンスシェルからbashに変更しておく必要があります。

https://kb.vmware.com/s/article/2107727?lang=ja

その後、VCSAの証明機関が発行した、有効期限の切れた証明書の置き換えはCertificate Managerツールで行えるようです。

https://kb.vmware.com/s/article/2097936?lang=ja

英語版のKBによると、VCSA 7.xではvCenter User Interfaceからこの操作が行えるらしいですが…まだ試せていないです(汗)。

以下のBlog記事も参考になりますね。

luchodelorenzi.com

Citrix Cloudでデリバリーグループが削除できない時は

Citrix Cloud関連の検証をしたあと、クリーンアップをしようとして軽くハマりかけたので、メモ。

前提の話として、Citrix CloudでVirtual Apps and Desktopサービスからリソース公開をする際に、リソースへのアクセス設定をデリバリーグループではなくCitrix Cloud側で行うように設定することができます。

この時、デリバリーグループで定義したデスクトップやアプリケーションは、「ライブラリ」として管理され、Citrix Cloudで管理しているその他のサービスと同じように、どのドメインのユーザーやグループのメンバーがサブスクライブできるかを、ライブラリごとに設定することができるようになります。

https://docs.citrix.com/ja-jp/citrix-cloud/citrix-cloud-management/assign-users-to-offerings-using-library.html

さて、実際の環境ではそれほど頻繁にやる作業ではないと思うんですが、デリバリーグループを削除しようとしたときに、「まだライブラリにサブスクリプションが残ってるから削除できないよ」的なメッセージが出て、操作が失敗しました。

ところが、ライブラリ側で確認するとサブスクリプション数は0になっている、つまり誰もサブスクライブしていない状態にちゃんとなっています。

結論から言うと、この場合PowerShell SDK、つまりPowerShellベースのコマンド行ツールを使わないと削除できないようです。

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

なんでそのような状態になってしまったのかという原因は不明なんですが、ライブラリ設定やデリバリーグループの設定より先に、リソースロケーションの削除などから始めてしまうという、乱暴なクリーンアップのやり方をしてしまったのが原因じゃないかなあとは思っています…。

ちなみに、最初に上記のドキュメントで紹介されているコマンドレットを実行した時には、エラーとなりました。「これをもってしてもアカンのかい」と、ちょっと絶望しかけたのですが、エラーメッセージをよく見てみると、デリバリーグループにアプリケーション公開の設定がまだ残っていたのが原因のようでした。

Cloud Studioで、デリバリーグループから公開アプリケーション定義をすべて削除した後、再実行すると、デリバリーグループは無事削除されました。

Citrix Tech Zone

ご存知の方もそれなりにいるのではないかと思うのですが、Citrixのドキュメントサイト  https://docs.citrix.com には、Tech Zoneというタイトルのドキュメントコレクションがあります。

https://docs.citrix.com/en-us/tech-zone.html

メーカーの製品ドキュメント、という響きから思い当たるようなマニュアル的なコンテンツではなく、設計するうえでの考慮事項や、Citrixテクノロジーの詳細についても取り上げていて、なかなか興味深い資料が置かれていたりします。　https://citrix.com/blogs の焼き直しって言わない。

例えば、COVID-19の影響で早急にVDIへの移行が必要な状況において、Microsoft Azure が提供するWindows Virtual DesktopとCitrix Cloudが提供するCitrix Virtual Apps and Desktops serviceとの組み合わせが注目されていたりしますが、そのPoCガイドがTech Zoneで公開されていますね。

https://docs.citrix.com/en-us/tech-zone/learn/poc-guides/cvads-windows-virtual-desktops.html

今のところまだ英語コンテンツが中心で、日本語コンテンツについては機械翻訳されたものがいくつかある、という状況のようですが、このコンテンツについてローカライズしてほしい！というフィードバックがたくさん届いたら、考慮してくれるかも！？

https://docs.citrix.com/ja-jp/tech-zone.html

お願いですから、7.15 LTSRでローカライズしたVDI Handbookを復活させてください…　英語版だとまだアクセスできるじゃないですかあ…

https://docs.citrix.com/ja-jp/xenapp-and-xendesktop/7-15-ltsr/document-history.html