none
管理用と仮想用のネットワークの分離について RRS feed

  • 質問

  • Hyper-Vでのネットワーク構成について質問させていただきます。

    現在NICを2枚搭載しているマシン上でHyper-V2.0を構築しています。

    ゲストはWSUS用サーバでMicrosoft Updateからパッチファイルをダウンロードするためだけの

    サーバです。

    直接外部ネットワークと接続するため、社内ネットワークと接続しているホストとはネットワークを

    完全に分離したいと考えています。

    NIC1に管理用、NIC2に仮想マシン用の設定を行い、[管理オペレーティングシステムにこのネットワーク

    アダプタの共有を許可する]のチェックをはずしました。

    これでホストーゲスト間のネットワークは分離されたことになると思うのですが、

    もし仮想マシンが外部ネットワークからネットワーク攻撃を受けた場合、ホスト側には問題は

    ないのでしょうか。

    セキュリティ上、社内ネットワークへの侵入がおこなわれることに不安を感じています。

    もしHyper-V上での設定以外で安全な方法があるようでしたら、あわせてアドバイスをいただけると

    大変助かります。

    以上、宜しくお願いいたします。

    2010年6月7日 1:57

回答

  • ネットーワークを介した攻撃といいましても様々なものがあります。

    インターネットに物理的に接続されており、通信できる状態であれば、公開されているポートをスキャンしてセキュリティーホールを突いて不正侵入を行う。

    DOSやDDoSといわれる、不正パケットを大量に送信してネットワークの通信自体を不能にする。

    ネットワーク盗聴などによりメールなど通信内容を盗み見される。

    などなど他にもたくさんありますが、今回ご心配されているホストサーバーへの攻撃という点においては直接というよりは、ホスト上の仮想マシンを介して行われると考えたほうがよいと思います。

    通信自体はホストサーバーは外部とは遮断されいますが、仮想マシン自体はホスト上で稼動しており、かつ外部と接続していますので、たとえばあまり考えにくいことですが、仮想マシンが何らかの手段で不正に操作されリブートを永遠に繰り返してしまうといったことなど仮想マシンのCPUやDiskI/Oが高負荷状態となればホストサーバーへの負荷が懸念されます。
    また、仮想マシンは内部ネットワークとも繋がっているのであればそこからホストサーバーへの進入も考えられます。

    また、外部からリモートデスクトップなどを狙ってパスワード解析を仕掛けてくる場合もありますので、必要のない機能や役割はインストールせず最小限の機能で運用する必要があります。

    などなど、完全に密閉された環境ではない限り確実に安全とは言い切れないところがありますので、修正パッチなどの適切な適用や、ファイヤーウォールの適切な配置が重要となります。

     

     


    WIN1
    • 回答としてマーク ひろみん 2010年6月9日 4:27
    2010年6月8日 8:01
    モデレータ
  • 言われている設定で、ひとまずは安全だと言えます。

    漠然と不安に思われているようなので、セキュリティへの考え方の一般論を余談として書いておきます。

    絶対の安全というものは存在しません。どのようにしてリスクを下げるのか、リスクを下げるコストが妥当な範囲なのかって事になります。

    子パーティションに侵入された場合に、親パーティションや他の子パーティションが安全なのかと言うと、Hyper-V はソフトウェア的に仮想マシンを分離しているので、何らかの方法を使って親パーティションやほかの子パーティションに侵入されるリスクはあります。
    ただ、現状で子パーティションから親パーティションや、他の子パーティションを直接攻撃できる脆弱性が発表されていないので、すぐに危険な状態に陥るというわけではないでしょう。

    このリスクを軽減したいのであれば、物理マシンで構築して、物理的に隔離し、ファイアウォールなどで分離する必要があります。
    では、ファイアウォールで分離すれば安全なのかと言うと、ファイアウォールを突破されればおしまいなので、リスクを低減するだけで絶対安全になるというわけではありません。
    仮にファイアウオールを突破できなくても、DNS キャッシュボィゾニングでアップデートファイルを配布している MS のサーバ IP アドレスが書き換えられてしまえば、アップデートファイルそのものの信頼性が怪しくなってしまいますね。

    安全な DNS 環境を構築して、更にファイアウォールのセキュリティ監視を専門業者に依頼して、常時監視してもらい、怪しい通信を検出した際には通信を切断してもらうって契約をすると... これはかなり高い安全性を確保できます。

    ここまでやると、コストもかなり膨らみます。求められているセキュリティはこのコストに見合うものでしょうか?

    それでは、物理的にネットワークを分離すれば安全なのかと言うと、持ち込みの USB メモリとか侵入経路は色々想定されます。

    セキュリティに「こうすれば大丈夫」みたいな万能解は存在しません。漠然と「安全」「危険」だけを言っても、不安が募るだけです。
    # 最低限こうしないとリスクが高くなりすぎるってのはありますけど

    セキュリティを設計する際は、どんなリスクから何を守るのかを具体的に想定して、多角的にリスクを下げる必要があります(結果的に多層防御が一番の有効打になります)
    リスク低減の処置を施しても、ほぼ間違いなく残存リスクが残ります(これをゼロにしようとすると膨大なコストが必要になる)ので、残存リスクとどう付き合うのかを考えて、残存リスクが現実のものにならないように、日々監視や運用をする必要があります。

    WSUS がインターネットから丸見えにならないようにファイヤウォールを入れ、全てのサーバとクライアント PC の Windows Update とウイルス対策ソフトのパターンを最新に更新するのは最低限必要ですが、それ以上のセキュリティはケースバイケースになりますね。


    MVP for Virtual Machine : Networking
    • 回答としてマーク ひろみん 2010年6月9日 4:27
    2010年6月8日 8:43
    モデレータ
  • こんにちは。

    ホスト上の仮想マシンを介しての攻撃も要警戒ですが、Hyper-V特有の構造を考えると、仮想マシンを介さない直接的な影響もあります。

    まず、"Hyper-Vではハイパーバイザにはドライバが存在せずホストOSがドライバを管理する"について説明します。

    GuestOSからのネットワークの通信は、入力、出力共にホストOSの仮想Switchを経由して物理NICを通っていきます。
    この仮想Switchを制御するのはホストOSのドライバ:vmswtich.sysです。

    このため、例えホストOSとGuestOSのネットワークを分離しても、ネットワークの通信は必ずホストOSのドライバ:vmswtich.sysへの負荷を発生させます。


    例1: ホストOSとGuestOSのネットワークを分離した状態

    外部 <--> ホストOSのvmswitch.sys <--> GuestOS

     

    例1: ホストOSとGuestOSのネットワークを接続した状態

    外部 <--> ホストOSのvmswitch.sys <--> GuestOS
                        |
                        |-->ホストOSとの通信経路


    ホストOSとGuestOSのネットワークが接続されていれば、外部=>vmswitch.sys=>GuestOS=>vmswitch.sys=>ホストOS という経路を警戒する必要があります。
    ホストOSとGuestOSのネットワークが接続されていない場合でも、ホストOSのvmswitch.sysを通りますので、これはこれで警戒が必要です。

    例えば、ゲストOSにDDos攻撃をかければ、vmswitch.sysの負荷を上げる分、ホストOSの攻撃は可能です。

    ただ、Murashima Syuichiさんの言われる
    "絶対の安全というものは存在しません。どのようにしてリスクを下げるのか、リスクを下げるコストが妥当な範囲なのかって事になります。"
    "セキュリティに「こうすれば大丈夫」みたいな万能解は存在しません。漠然と「安全」「危険」だけを言っても、不安が募るだけです"
    が理にかなった答えだと思います。理論上ホストOSへの影響がゼロではないからといって万能解を求めても、その答えはどこにもありません。現実的な対処をお勧めします。

    • 回答としてマーク ひろみん 2010年6月9日 4:27
    2010年6月8日 9:30
  • こんにちは。

    まず、"ゲストOSが使用しているNIC"の設定を行っていても、ホストOSのvmswitch.sysの処理は必ず通りますので、社内ネットワークに侵入される心配はゼロではありません。
    あとは、現実的に侵入する方法があるか、ないかです。方法が見つかれば、恐らくマイクロソフトのセキュリティ情報で公開されるだろうとは思います。

    ただ、vmswitch.sys経由でホストOSに侵入する事は、非常に困難だと思います。理由は、BufferOverFlowなどの常套手段が使えないからです。
    詳細については、質問されても答えることはありません。ひろみんさんにその意図は無くとも、詳細に答えれば結果的にクラックの幇助になるからです。

    個人的にはvmswitch.sys経由でホストOSに侵入する事は不可能だと思いますし、ひろみんさんは無意味に不安になっているだけで、この不安を消してくれと言われても、それは無理というものです。

    世界には神がかったクラッカーが存在しますので、もしかしたらvmswitch.sys経由でホストOSに侵入する方法を見付ける人間がいるかもしれません。いないかもしれません。未来を予言してくれという話であれば、これも無理というものです。

    もう一度言います。現実的な対処をお勧めします。

    • 回答としてマーク ひろみん 2010年6月9日 4:28
    2010年6月9日 3:56

すべての返信

  • お世話になります。

    さらに調査を進めてみたところ、Hyper-Vではハイパーバイザにはドライバが存在せず

    ホストOSがドライバを管理するということが判明しました。

    ということはゲストOSのネットワークドライバがなんらかの攻撃を受けた場合(ネットワーク攻撃に

    詳しくないので見当違いのことを言っていたら申し訳ありません)、ホストOSにも影響があると

    考えられるのでしょうか。

    公開サーバをお持ちの方でセキュリティに詳しい方のご意見も是非お伺いしたいです。

    (どのように攻撃される可能性があるのかなど)

     

    2010年6月8日 2:04
  • ネットーワークを介した攻撃といいましても様々なものがあります。

    インターネットに物理的に接続されており、通信できる状態であれば、公開されているポートをスキャンしてセキュリティーホールを突いて不正侵入を行う。

    DOSやDDoSといわれる、不正パケットを大量に送信してネットワークの通信自体を不能にする。

    ネットワーク盗聴などによりメールなど通信内容を盗み見される。

    などなど他にもたくさんありますが、今回ご心配されているホストサーバーへの攻撃という点においては直接というよりは、ホスト上の仮想マシンを介して行われると考えたほうがよいと思います。

    通信自体はホストサーバーは外部とは遮断されいますが、仮想マシン自体はホスト上で稼動しており、かつ外部と接続していますので、たとえばあまり考えにくいことですが、仮想マシンが何らかの手段で不正に操作されリブートを永遠に繰り返してしまうといったことなど仮想マシンのCPUやDiskI/Oが高負荷状態となればホストサーバーへの負荷が懸念されます。
    また、仮想マシンは内部ネットワークとも繋がっているのであればそこからホストサーバーへの進入も考えられます。

    また、外部からリモートデスクトップなどを狙ってパスワード解析を仕掛けてくる場合もありますので、必要のない機能や役割はインストールせず最小限の機能で運用する必要があります。

    などなど、完全に密閉された環境ではない限り確実に安全とは言い切れないところがありますので、修正パッチなどの適切な適用や、ファイヤーウォールの適切な配置が重要となります。

     

     


    WIN1
    • 回答としてマーク ひろみん 2010年6月9日 4:27
    2010年6月8日 8:01
    モデレータ
  • 言われている設定で、ひとまずは安全だと言えます。

    漠然と不安に思われているようなので、セキュリティへの考え方の一般論を余談として書いておきます。

    絶対の安全というものは存在しません。どのようにしてリスクを下げるのか、リスクを下げるコストが妥当な範囲なのかって事になります。

    子パーティションに侵入された場合に、親パーティションや他の子パーティションが安全なのかと言うと、Hyper-V はソフトウェア的に仮想マシンを分離しているので、何らかの方法を使って親パーティションやほかの子パーティションに侵入されるリスクはあります。
    ただ、現状で子パーティションから親パーティションや、他の子パーティションを直接攻撃できる脆弱性が発表されていないので、すぐに危険な状態に陥るというわけではないでしょう。

    このリスクを軽減したいのであれば、物理マシンで構築して、物理的に隔離し、ファイアウォールなどで分離する必要があります。
    では、ファイアウォールで分離すれば安全なのかと言うと、ファイアウォールを突破されればおしまいなので、リスクを低減するだけで絶対安全になるというわけではありません。
    仮にファイアウオールを突破できなくても、DNS キャッシュボィゾニングでアップデートファイルを配布している MS のサーバ IP アドレスが書き換えられてしまえば、アップデートファイルそのものの信頼性が怪しくなってしまいますね。

    安全な DNS 環境を構築して、更にファイアウォールのセキュリティ監視を専門業者に依頼して、常時監視してもらい、怪しい通信を検出した際には通信を切断してもらうって契約をすると... これはかなり高い安全性を確保できます。

    ここまでやると、コストもかなり膨らみます。求められているセキュリティはこのコストに見合うものでしょうか?

    それでは、物理的にネットワークを分離すれば安全なのかと言うと、持ち込みの USB メモリとか侵入経路は色々想定されます。

    セキュリティに「こうすれば大丈夫」みたいな万能解は存在しません。漠然と「安全」「危険」だけを言っても、不安が募るだけです。
    # 最低限こうしないとリスクが高くなりすぎるってのはありますけど

    セキュリティを設計する際は、どんなリスクから何を守るのかを具体的に想定して、多角的にリスクを下げる必要があります(結果的に多層防御が一番の有効打になります)
    リスク低減の処置を施しても、ほぼ間違いなく残存リスクが残ります(これをゼロにしようとすると膨大なコストが必要になる)ので、残存リスクとどう付き合うのかを考えて、残存リスクが現実のものにならないように、日々監視や運用をする必要があります。

    WSUS がインターネットから丸見えにならないようにファイヤウォールを入れ、全てのサーバとクライアント PC の Windows Update とウイルス対策ソフトのパターンを最新に更新するのは最低限必要ですが、それ以上のセキュリティはケースバイケースになりますね。


    MVP for Virtual Machine : Networking
    • 回答としてマーク ひろみん 2010年6月9日 4:27
    2010年6月8日 8:43
    モデレータ
  • こんにちは。

    ホスト上の仮想マシンを介しての攻撃も要警戒ですが、Hyper-V特有の構造を考えると、仮想マシンを介さない直接的な影響もあります。

    まず、"Hyper-Vではハイパーバイザにはドライバが存在せずホストOSがドライバを管理する"について説明します。

    GuestOSからのネットワークの通信は、入力、出力共にホストOSの仮想Switchを経由して物理NICを通っていきます。
    この仮想Switchを制御するのはホストOSのドライバ:vmswtich.sysです。

    このため、例えホストOSとGuestOSのネットワークを分離しても、ネットワークの通信は必ずホストOSのドライバ:vmswtich.sysへの負荷を発生させます。


    例1: ホストOSとGuestOSのネットワークを分離した状態

    外部 <--> ホストOSのvmswitch.sys <--> GuestOS

     

    例1: ホストOSとGuestOSのネットワークを接続した状態

    外部 <--> ホストOSのvmswitch.sys <--> GuestOS
                        |
                        |-->ホストOSとの通信経路


    ホストOSとGuestOSのネットワークが接続されていれば、外部=>vmswitch.sys=>GuestOS=>vmswitch.sys=>ホストOS という経路を警戒する必要があります。
    ホストOSとGuestOSのネットワークが接続されていない場合でも、ホストOSのvmswitch.sysを通りますので、これはこれで警戒が必要です。

    例えば、ゲストOSにDDos攻撃をかければ、vmswitch.sysの負荷を上げる分、ホストOSの攻撃は可能です。

    ただ、Murashima Syuichiさんの言われる
    "絶対の安全というものは存在しません。どのようにしてリスクを下げるのか、リスクを下げるコストが妥当な範囲なのかって事になります。"
    "セキュリティに「こうすれば大丈夫」みたいな万能解は存在しません。漠然と「安全」「危険」だけを言っても、不安が募るだけです"
    が理にかなった答えだと思います。理論上ホストOSへの影響がゼロではないからといって万能解を求めても、その答えはどこにもありません。現実的な対処をお勧めします。

    • 回答としてマーク ひろみん 2010年6月9日 4:27
    2010年6月8日 9:30
  • Murashima Syuichi様

    お世話になります。

    セキュリティについての考え方、大変参考になりました。

    確かに万能解を求めるのは無意味だと思います。問題となるリスクがなんなのかをきちんと把握できていませんでした。

    今回の場合、親パーティションが動作不能になるのは最悪問題ではないのですが、第3者が親につながっている社内ネットワークに侵入してしまい、それに気づかない状況に陥ってしまうことが一番問題であると考えています。(つまりここがバックドアになってしまうのではないかと。)

    その点を一番にフォローしたいと考えた場合、ネットワーク侵入検知システムのようなものを子パーティションに導入すれば発見することが出来るのでしょうか?

    もちろん最低限必要とされているファイアーウォールと最新のセキュリティパッチを導入していることは前提条件と考えています。

     

    2010年6月9日 0:58
  • 中年やっちゅうねん様

    お世話になります。

    Hyper-Vでのネットワークドライバの仕組みについての解説、大変勉強になりました。

    >ホストOSとGuestOSのネットワークが接続されていない場合でも、ホストOSのvmswitch.sysを通りますので、これはこれで警戒が必要です。

    おっしゃられる通り、その点をもっとも警戒しています。ただ、DDos攻撃による被害がホストOSの動作異常で済むのであれば最悪問題ではないと考えています。どちらかというと社内ネットワークに侵入されたことによる情報漏えいのリスクをもっとも警戒しており、それを防ぐ手段を考えています。

    とりあえず現在は社外ネットワークに接続するときはホストOSのNICからネットワークケーブルをはずした状態で、ゲストOSが使用しているNICに外部ケーブルを接続し、MicrosoftUpdateとの同期を行っています。同期とダウンロードが完了した時点で社内ネットワークに接続しなおすようにしているのですが、これでも社内ネットワークに侵入される心配はまだ残っているでしょうか?

    2010年6月9日 1:12
  • WIN1様

    お世話になります。

    ネットワーク攻撃についてのご説明どうもありがとうございます。

    >通信自体はホストサーバーは外部とは遮断されいますが、仮想マシン自体はホスト上で稼動しており、かつ外部と接続していますので、たとえばあまり考えにくいことですが、仮想マシンが何らかの手段で不正に操作されリブートを永遠に繰り返してしまうといったことなど仮想マシンのCPUやDiskI/Oが高負荷状態となればホストサーバーへの負荷が懸念されます。

    そのような危険性も考えられるのですね。ネットワークの侵入ばかりを心配していたのでホストへの負荷を

    リスクとして捉えていませんでした。

    確かに「完全に密閉された環境」ではないので確実とは言い切れないと思います。リスクのひとつとして捉え、

    運用面でフォローを考えたいと思います。

    どうもありがとうございました。

    2010年6月9日 1:14
  • 侵入検知システムは IDS と呼ばれるアプライアンス製品が最近多いですね。

    サーバにインストールするウイルス対策ソフトを導入すると、侵入の検出や排除は可能ですが、ウイルス対策ソフトも完全ではなく、すり抜けられるケースも良くありますので過信は禁物です。


    MVP for Virtual Machine : Networking
    2010年6月9日 3:18
    モデレータ
  • こんにちは。

    まず、"ゲストOSが使用しているNIC"の設定を行っていても、ホストOSのvmswitch.sysの処理は必ず通りますので、社内ネットワークに侵入される心配はゼロではありません。
    あとは、現実的に侵入する方法があるか、ないかです。方法が見つかれば、恐らくマイクロソフトのセキュリティ情報で公開されるだろうとは思います。

    ただ、vmswitch.sys経由でホストOSに侵入する事は、非常に困難だと思います。理由は、BufferOverFlowなどの常套手段が使えないからです。
    詳細については、質問されても答えることはありません。ひろみんさんにその意図は無くとも、詳細に答えれば結果的にクラックの幇助になるからです。

    個人的にはvmswitch.sys経由でホストOSに侵入する事は不可能だと思いますし、ひろみんさんは無意味に不安になっているだけで、この不安を消してくれと言われても、それは無理というものです。

    世界には神がかったクラッカーが存在しますので、もしかしたらvmswitch.sys経由でホストOSに侵入する方法を見付ける人間がいるかもしれません。いないかもしれません。未来を予言してくれという話であれば、これも無理というものです。

    もう一度言います。現実的な対処をお勧めします。

    • 回答としてマーク ひろみん 2010年6月9日 4:28
    2010年6月9日 3:56
  • Murashima Syuichi様

    中年やっちゅうねん様

    重ねてのご返答大変感謝します。

    今回の回答で大方の不安は解消されましたし、また現実的にどのように対応していけばいいのかの目処がつきましたのでこれで解決とさせていただきます。

    意図せず、不適切な質問をしてしまったようで申し訳ありませんでした。

    以上、どうもありがとうございました。

    2010年6月9日 4:25