Citrix XenServer Free 5.6セキュリティまたは「...異なるハイパーバイザーを見つける必要がある」

仮想化テクノロジーがさらに開発されると、より多様な「ITテクノロジーの巨人」が市場に参入します。 Xenプロジェクト自体がオープンソースソリューションとして長い間存在していたという事実にもかかわらず、Citrix XenServerのような統合ハイパーバイザーを備えたこのようなオペレーティングシステムは最近、エンタープライズレベルの顧客の注目を集めています。 当初、OSはロー/ミッドエンド企業に焦点を合わせ、マルチサーバーアーキテクチャのコストを最小化する問題を解決することを目的としていました。 しかし、開発の過程で、Citrixは高可用性や同様にActive Directory統合などの重要なものをハイパーバイザーに統合しました。 したがって、現時点では、VMWare ESX / ESXiの真の代替として位置付けられているCitrix XenServerの商用バージョンがあります。 しかし、ご存じのとおり、ハイパーバイザーには特別なセキュリティ要件が課されています。 これは、ハイパーバイザーをキャプチャすると、会社がそれだけでなく、すべての仮想マシンも失う可能性が高いという事実によるものです。




ベンダーは、システム自体とHardening / Security Guideクラスマニュアルの両方を設定する方法に関するドキュメントをますますリリースしています。 Citrixは、Common Criteria Security Target and User Security Guideをリリースしました。 これらのドキュメントには多くの推奨事項とヒントがありますが、実用的な情報が少なすぎます。 CCSTドキュメントでは、保護されたオブジェクトの正式な説明と実際の設定の数を見つけることができます。 ユーザーセキュリティでは、会社は一般的なシステム保護方法論について説明しました。 したがって、残念ながら、すべての側面を完全にカバーする完全なCitrixセキュリティガイドが欠落しています。

2011年、CitrixはISSA Security Organization of the Yearのタイトルを獲得しました。 「Secured By Design」という用語はCitrix製品に適用されることが強調されました。 おそらく、この会社のソリューションの一部はこのカテゴリに起因する可能性がありますが、XenServerのサーバー製品の調査では、設計のいくつかの仕様の存在と、Citrix専門家グループによるこの用語の解釈の一意性が示されました。 この記事では、Citrix Free XenServer 5.6.0の動作のいくつかの側面と、このシステムの実際の使用中に発生する可能性のあるセキュリティの問題について説明します。 この特定のバージョンの選択は、かなり高い有病率と人気によるものです。 以下で述べられていることの多くは、第6ファミリのバージョンで変更されていません。

ハイパーバイザー全体の基盤はXenAPI（XAPI）です。 これは、スーパーユーザー権限を持つシステムによって実行されるデーモンであり、システム自体と仮想マシンを管理するためのインターフェースを提供します。 Red Hat Enterprise Linuxオペレーティングシステムの直接の親Asとして、ハイパーバイザーはその先祖から多くの標準ソリューションを継承しました。 これは、XAPIへの接続を担当するPAMモジュールです。

このモジュールは、デフォルトでsystem-authの標準設定を完全に含むように構成されています。 実際には、これは、システム内のアカウントを持つすべてのユーザーが、APIを使用してルートパスワードを変更する場合を除き、pool-admin特権でXAPI要求を実行できることを意味します。 システムのこの機能は文書化されており、FreeおよびAdvanceのバージョンに固有のものです。 Citrixのポリシーによると、これらのXenServerバリアントを使用する場合、「シングルレベル」ユーザー（LSU（ローカルスーパーユーザー））を持つシステムがあります。 Citrixのこの決定は、企業レベルの製品を構築するというイデオロギーの枠組みの中で一般に理解されているとは思えません。

この特異性により、ハイパーバイザーをマルチユーザーシステムとして使用するフレームワークにいくつかの問題が生じます。 区別を作成するには、xapiモジュールのPAM設定を調整して、ハイパーバイザーを制御できる人数を制限する必要があります。 これには多くの可能性があり、標準のPAMツールはすべて自由に使用できます。 PAPI機能の説明とXAPIセキュリティを構成するためのアイデアは、Andrew G. MortanとThorsten Kukukによる「The Linux-PAM System Administrators Guide」にあります。

XAPIの別の特定の機能は、システム内のHTTP / HTTPSを介したリモート制御の可用性です。 デーモンは、管理インターフェースでポート80および443を開いたままにします。 この記事では、制御ネットワークが物理的に分離される可能性があるため、この問題がやや深刻でないマルチインターフェイスシステムについては考慮しません。 しかし、私はこのレイアウトが実稼働ソリューションに必要であることに注意したいと思います。



多くの場合、管理インターフェイスは、データ転送とカスケード仮想マシンにも共通しています。 したがって、SSLトンネルを使用せずにポート80を制御すると、攻撃者は少なくともスニファーを使用してシステム設定を取得し、コードの挿入を成功させるか、制御セッションを最大限に傍受することができます。 オプションとして、iptablesが最適です。 一般に、システムの80 \ 443ポートに着信するトラフィックを制限する価値があります。 この質問は、Citrix XenServer 5.6 Platinum EditionのCitrix Common Criteria Evaluated Configuration Guideで説明する価値があります。
次の疑わしい場所を明確にするために、Citrix XenServerのモータリングについてもう少し詳しく見てみましょう。 仮想マシンへのアクセスを容易にするために、ハイパーバイザーはゲストシステムのテキスト/グラフィックコンソールのXAPIへの転送を使用します。 これを行うには、小さなプログラムvnctermを使用します。 作業のイデオロギーはほぼ次のとおりです。XAPIによってコンソールが要求されると、 vnctermプロセスのフォークがループバックインターフェイスで作成され、XAPIでユーザーに送信されます。



これは、ハイパーバイザーホスト自体を含むすべてのホストで発生します。 いくつかの例外を除きます。 認証のためにハイパーバイザーを送信する代わりに、ハイパーバイザーのホストに接続すると、Citrixの作成者コードが実行され、rootとしてローカルコンソールに即座にアクセスできます。



Active Directoryにバインドせずにサーバー上でXAPIアクセスを持つユーザーは、ハイパーバイザーホストへのルートアクセスを取得できます。

vnctermの二次的な問題として、すべてのセッションが1つだけであることに注意してください。 つまり、rootとしてゲストシステム上にセッションを作成し、ゲストシステムからログアウトすることを忘れることで、開いているVNCチャネルを残します。 このゲストシステムへの次の要求で、すべてのXAPIユーザーは同じオープンセッションを受け取ります。 システムの侵害は避けられません。 ローカルユーザー認証は、自動xsconsoleブートを使用したmingetty –autologinルートでも自動的に行われることに注意してください。



これは重要ではありませんが、shコードを注入することは理論的には可能です。 したがって、システムへのスーパーユーザー特権の付与を制限する必要があります。

システムの別の問題のある部分は、XenMotionモードのサーバー間の仮想マシンの転送です。 プレーンテキストモードでシステムの80番目のポートを介して発生します。 したがって、攻撃者はその場でデータを傍受することができます。 この問題に対する唯一の解決策があります-IPレベルの暗号化ツールの使用です。 しかし、これはデータを転送するときの唯一の問題ではありません-iSCSIサービスはデフォルトでクリアテキストで資格情報も送信します。 この問題は、CHAPをアクティブにすることで解決します。

Citrix XenServerは、LVMの形式とVHDファイルの形式の仮想マシンのいくつかのストレージモードを使用します。 LVMパーティションまたは個別のファイルとして。 スーパーユーザーのみがパーティションをマウントする権利を持っているため、最初のモードは条件付きで安全と見なすことができます。 ただし、別のファイル形式のVHDモードのストレージは、別のセキュリティ問題です。 ファイルは、サーバースクリプトrw-rrの標準umaskを使用して作成されます。 したがって、システムのすべてのユーザーが仮想マシンを使用できます。 この問題は、Positive Technologies Citrix XenServer 5.6セキュリティガイドで説明されているスクリプト修正方法によって解決されます。

システムはRHELの子孫であるため、yumアドインとともにRPMパッケージ管理システムを継承しました。 最初はシステムで、些細な「yum update」を試しても、システムの更新は受信されません。 Linux構築の恐竜が美しいスクリーンセーバーの後ろに隠れていることは明らかです。 問題は、Citrixがyum構成レベルでCentOSリポジトリへの接続をブロックしていることです。 もちろん、それらを再び有効にしてシステムの更新を実行することは問題ではありません。 しかし、Citrixがシステム内のいくつかの標準的なものを「厳密に忠実な」独自のものに変更したという事実により、このアクションはハイパーバイザーの早期の休息につながり、現在ローリングアップデートはシステムの崩壊につながります。 システム内の一部のパッケージは、セキュリティスキャナーによって重大な脆弱性（dhclientなど）があると定義されているため、アップデートのインストールは必須になります。 このような問題を解決するには、セキュリティスキャナー、yum、dump、忍耐が必要です。

「箱から出してすぐに」システムの一般的な設定から、pam_unix.soモジュールの設定に重要なエラーがあることに注意したいと思います。 具体的には、/ etc / shadowのパスワード保存モードが有効になっていません。
したがって、/ etc / passwdファイルに対する標準のアクセス許可が与えられている場合、システムパスワードハッシュへの潜在的なアクセスがあります。 これは、NFSリポジトリを使用したシステムの運動性にも適用されます。 Citrix XenServer管理ガイドでは、NFSサーバーでno_root_squashオプションを設定することをお勧めします。 このようなソリューションはハイパーバイザーの標準であり、iptablesなどを使用して、外部ストレージから可能な限りそのようなストレージを分離する必要があります。 また、もちろん、ファイル作成モードを調整し、ルートユーザーを特殊なシステムユーザーに再マッピングする必要があります。

したがって、全体的な結果を要約すると、初期構成のCitrix Free XenServer製品には、いくつかの深刻な「設計」セキュリティ問題が存在する可能性があります。 それらの多くはRHELファミリーに共通の問題であり、その他はこのシステムに固有のものです。 もちろん、Citrixの観点から見ると、これらは問題ではなく、ハイパーバイザーのアーキテクチャ機能です。 セキュリティ問題とこのOSを保護するための一般的な方法論については、「Positive Technologies：Citrix XenServerセキュリティガイド」で説明されます。これは近い将来にオープンベータテストが行​​われます。