2 ポイント 投稿者 GN⁺ 2024-09-04 | 1件のコメント | WhatsAppで共有
  • サーバーがPCに近い汎用ハードウェアへ収束した後も、障害対応・起動・リモートインストールを扱うアウトオブバンド管理は、クライアントとサーバーを分ける中核機能として残っている
  • IPMIは製品名ではなく仕様であり、HP iLOやDell DRACのようなベンダーごとの管理システムはIPMIと重なる部分があるものの、それぞれ異なる歴史と拡張機能を持つ
  • IPMIはBMC上で動作し、ネットワーク・シリアルベースのアウトオブバンドインターフェースと、OSドライバー経由のインバンドインターフェースをあわせて提供する
  • 実際の実装では、Web UI、SSH、VNC、UDP 623ベースのコマンド、リモートコンソール、仮想メディア、センサー・電源・ファン・ウォッチドッグ制御を提供するが、特にセキュリティ露出に弱い
  • Intel MEとIntel AMTはクライアントPC側の類似技術だが、AMTとvProの条件があるため、一般消費者向け機器でサイドバンドネットワークアクセスが可能だという通説はおおむね当てはまらない

サーバーが「大きなコンピューター」になるまで

  • クライアント・サーバーコンピューティングは、複数の端末が1台のコンピューターに接続されていたタイムシェアリングの進化から始まった
  • 端末はコンピューターと同じアーキテクチャである必要はなく、この認識は初期のクライアント・サーバーシステムにも引き継がれた
  • 1990年代半ばのPC革命はクライアント側にWinTelという単一文化を生んだが、2000年代までサーバーでは別個のOSやアーキテクチャを使うことが珍しくなかった
    • SPARCとSolarisの組み合わせはサーバーで広く使われていた
    • IBMのミニコンピューターアーキテクチャと複数のOSも重要なサーバープラットフォームだった
    • JavaはSolaris/SPARCバックエンドとWindows/x86クライアント間でのコード再利用を可能にし、エンタープライズアプリケーションに貢献した
  • 時間がたつにつれ、サーバー専用アーキテクチャはPCアーキテクチャのコスト・性能競争に対して次第に不利になっていった
  • サーバーソフトウェアも、垂直スケーリングと高可用性中心から、水平スケーリングと緩やかな信頼性要件へ移行し、エンタープライズ級コンピューターの利点は小さくなった
  • 現在のサーバーの差別化要素は、主にマルチソケットSMP・NUMA、複雑なストレージコントローラーとトポロジー、そしてアウトオブバンド管理機能にある

アウトオブバンド管理は何を解決するのか

  • アウトオブバンド管理とは、OSや汎用コンポーネントが正常に動作していなくても、別の管理用コンピューターを通じてサーバーにアクセスできる機能である
  • SSHは、OS上のソフトウェアが提供するインバンド管理の典型例である
  • アウトオブバンド管理は別個のハードウェア・ソフトウェアスタックが担い、伝統的にはOSやCPUの協力を必要としなかった
  • 今日では、この機能はサーバーのリモートコンソールで最もよく表れている
    • 内蔵のIP KVMのように動作し、ローカルのモニターとキーボードが接続されているかのようにサーバーを操作できる
    • 「仮想メディア」機能はISOファイルをアップロードして物理デバイスのように見せられるため、OSのインストールに便利である
  • こうした機能は新しい概念ではなく、ビジネスコンピューティングの歴史全体にわたって類似機能が見られる
  • 比較的現代的なサーバーには、通常いくつかの段階の管理機能が組み込まれていた
    • ハードウェア状態を示すLCDやLEDのようなローカル運用者インターフェース
    • 初期ブートローダーや継続的な低レベル管理システムにアクセスするためのシリアルコンソール
    • マシンのワークロードをリモート管理する、より高レベルな管理システム
  • 今日でも前面パネルの障害表示やシリアル管理機能は残っているが、オンライン交換可能な冗長部品の範囲は以前より縮小している

IPMIとBMCの関係

  • IPMIは特定製品ではなく、Intel IPMI仕様である
  • 主要サーバーベンダーはたいてい独自のIPMI実装を持ち、HP iLOやDell DRACといった名称を使っている
    • こうしたシステムはIPMIより前から存在していた場合もあり、「単なるIPMI」と呼ぶのは正確ではない
    • 新興メーカーはファームウェアベンダーの標準提供物をそのまま使い、IPMIと呼ぶことが多い
  • IPMIソフトウェアは通常、**BMC(Baseboard Management Controller)**と呼ばれるプロセッサー上で実行される
  • IPMIとBMCという用語は、ときにほぼ同義で使われる
  • LOM(Lights-Out Management)はおおむね古い用語だが、HP(E)がIntegrated Lights-Outという名称を使い続けているため残っている
  • BMCは、クライアントコンピューターでファン速度制御などを担うSMC(System Management Controller)と区別する必要がある
    • 両コンポーネントには歴史的な関連がある
    • サーバーではBMCがこうした機能の大半を処理する
  • IPMIは2つのアクセス方式を仕様化している
    • ネットワークやシリアル接続を通じたアウトオブバンドインターフェース
    • OSがドライバー経由でアクセスするインバンドインターフェース
  • インバンドアクセスのおかげで、Linuxのipmitoolのようなツールが実行中のOSからIPMIとやり取りできる
  • IPMIは独立した管理システムである一方、利便性のためにOSへローカルインターフェースも提供するので、この構造を理解しておくと用語の混同が減る

実際のIPMI利用形態とセキュリティ上の制約

  • IPMI製品は次第にWebアプリケーション中心で機能を提供するようになっている
  • 専用クライアントソフトウェアを持つ製品も多いが、機能が内蔵Webアプリへ移っていく流れがある
  • Webインターフェースの品質は実装ごとの差が大きく、総じて良いとは言いがたい
  • ほとんどのサーバーには、IPMIまたはmanagementと表示された専用イーサネットインターフェースがある
  • IPMI管理インターフェースは、セキュリティと信頼性のため、専用の物理ネットワークに置くのが最も望ましい
    • 主ネットワークに性能や安定性の問題が起きても、IPMIにはアクセスできる必要がある
    • 専用物理ネットワークには時間・空間・コストがかかる
  • 管理ネットワークを一般的なネットワーク機器上のVLANで構成する妥協案も一般的である
    • 独立したプライベートネットワークのように動作するが、実際の機器は共有される
    • 分離はソフトウェアで実現される
  • 追加ケーブルを避けるために、IPMIはサイドバンドネットワーキングも提供する
    • BMCがOSの使う同じNICと直接通信する
    • NICは異なる2つのインターフェースのように見せ、IPMIトラフィックはホストトラフィックと同じパケットストリームに混在するが、別のMACアドレスを使う
    • IPMIとアプリケーショントラフィックの分離が弱くなるため、セキュリティ面での配慮が必要になる
  • 多くのIPMI実装は深刻なセキュリティ問題を抱えてきたため、信頼できない利用者にアクセス可能な状態にしてはならない
  • ネットワーク機能は実装ごとに異なるが、共通してUDP 623ベースの標準インターフェースが探索と基本コマンドに使われる
  • SSHとWebインターフェースは一般的で、リモートコンソールにはVNCもよく使われる
  • IPMIで実行できる基本機能は次のとおり
    • FRUまたはベンダー部品番号レベルでハードウェアモジュール一覧を確認する
    • センサー、電源状態、ファンなどの基本ハードウェア機能を制御する
    • 標準のウォッチドッグタイマーを使う
  • ウォッチドッグタイマーは、OS上のソフトウェアと組み合わせることで、アプリケーションが異常状態に陥った際にサーバーをリセットさせられる
  • ウォッチドッグのタイムアウトは、システム起動後に接続して無効化する時間を確保できるだけ十分長く設定する必要がある

Intel ME、AMD ST、AMTとクライアントPCの例外

  • IPMIはエンタープライズサーバーでは一般的だが、通常のクライアントコンピューターや小型・低消費電力コンピューターではまれである
  • Intel MEとAMD STは、ほぼすべてのIntel・AMDプロセッサーに存在するOOB管理コントローラーに近い例外的存在である
  • Intel MEはIntel AMT(Active Management Technology)を可能にする構成要素である
  • AMTはクライアントマシンにアウトオブバンド管理を普及させようとした試みであり、IPMIに似た機能をほぼ一通り提供する
  • AMTは大きな成功を収めなかったが、その主な理由はIntelがAMT機能の大半を高価なエンタープライズ管理プラットフォームと組み合わせて使うよう制限したためである
  • オープンソースのAMTクライアントは存在するが、実際にAMTを利用できるマシンを見つけるという問題が残る
  • AMTのサイドバンド管理はセキュリティコミュニティの懸念を招いたが、実際に可能となるには次の条件がすべて必要である
    • プロセッサーがAMT対応であること
    • マザーボードチップセットがAMT対応であること
    • NICがAMT対応であること
    • この3つの機器はいずれもvProバッジ付きのIntel製品に限られる
  • 消費者向け機器ではIntel NICが人気ではないという点だけを見ても、サイドバンドアクセスはまれだと言える
  • vProは比較的上位のプロセッサーとチップセットに限定される
  • Intel MEが消費者向け機器でサイドバンドネットワーキングによりアクセス可能だという広く流布した「事実」は、通常は当てはまらず、その理由はIntelのソフトウェアライセンスだけではない
  • Intel ME自体はAMTなしではアウトオブバンド管理機能をほとんど持たないが、Secure BootやDRMのような信頼実行コンポーネントをホストし管理するための便利な基盤として使われているように見える
  • Intel MEは第三者が監査できず、過去には重大なセキュリティ脆弱性を抱えていたこともある
  • 現代の消費者向けARM SoCも同様の能力を持っており、特定のx86ベンダーだけの問題では終わらない

1件のコメント

 
GN⁺ 2024-09-04
Hacker Newsの意見
  • 最新情報とは少し異なる部分がある。IntelはCPU/GPU全般でAMDに後れを取っており、N100系のように低消費電力・ファンレス用途にうまく合う例外だけが目立っている
    そのためIntel CPUは、既存環境を同じメーカーのCPUで更新する必要がある組織が主に買う傾向にある。たとえばvSphereのEVCのように、新しいプロセッサを同じメーカーの旧モデルのように動作させ、CPUアーキテクチャ間のホットマイグレーションやハードウェア交換時の停止最小化を狙う場合に使われる
    それ以外では、ほぼ全てが処理性能あたりでより良く、安いAMD CPUへ向かう雰囲気だ。Intel NICは全般的に悪くなく、コンシューマー機器でも徐々に増えている。ただしX710は例外で、VMwareなどの「エンタープライズ」互換リストに載っていながら、1年以上にわたりドライバー問題で静かなネットワーク障害やクラッシュを引き起こしていた
    サーバー購入組織にとっては、Supermicroはおおむね良い選択肢になり得る。より安く、フォームファクター、シャーシ、部品、スロット数などの柔軟性が高く、おおむね信頼できるが、サポートはDell/HPEの理論上のサポートほど安定していないため、冗長構成で最も向いている
    またIPMI仕様は、より完全で安全、標準化され、まともなAPIを提供するRedfishに置き換わりつつある。数年前以降の主流サーバーなら、IPMIとあわせてRedfishも備えている可能性が高い
    最近、空売り調査会社HindenburgがSupermicroの怪しい点を暴露するレポートを出したが、ハードウェア自体はいまなお最上級で、大手クラウド事業者も利用している: https://hindenburgresearch.com/smci/

    • ワークステーション用にSupermicroとASRock Rackのボードを両方触ってみたが、Supermicroのボードは2024年製品ではなく、2005年に作られたボードのように感じた
      ACPIの省電力未対応、4ピン/3ピンファン対応の不足により3ピンファンは常に100%速度、2010年代そのままのIPMI Webインターフェース、ヒートシンクを使えなくするNVMe配置、ボード上のラベルもない不透明なジャンパーが大量にある
      一方、同等クラスのASRock Rackボードは比べものにならないほど良かった
    • Supermicroの問題は空売りレポートではなく、Secure Boot鍵の流出だ。信頼のルートが破られ、相当数のハードウェアを安全にできなくなった
      https://arstechnica.com/security/2024/07/secure-boot-is-comp...
    • 最近のIntel CPUはスペック上は悪くなさそうに見えるが、実際には焼ける問題がある
      プロセスが微細化するほど寿命の問題が大きくならざるを得ないので、それほど驚くことではない。移動性欠陥のような問題が、より簡単に大きなトラブルを引き起こし得る。マイクロコードがマザーボードに過剰な電圧を要求した問題だと言われており、それも正しいが、チップが環境変化により敏感になっているのも事実だ
      以前はIntel NICの性能とLinux互換性が好きで、Intel SSDも好きだった。ただし、安い競合製品よりP95〜P99区間の性能が少し良いという点を読み取る必要があり、コンピューターが遅いと感じていら立つ瞬間こそがまさにそのP95〜P99だった。AnandTechを好きでありながら嫌いでもあった理由の一つは、こうした核心をよく見落としていたからだ
    • Supermicro PSUが独自のIPMIユーティリティなしにPMBusでアクセスできればよいのだが、そうではない。しかもx86専用なので、ppc64elではインターフェースする方法がない
      オープンソースなら簡単にビルドできたはずだ
      https://www.supermicro.com/en/solutions/management-software/...
    • RedfishでIPMI SSL証明書を最新状態に保つよう自動化しているが、新しい証明書を取り込む過程が、ベンダーごとのRedfish実装ごとに少しずつ異なる魔法を要求する
      証明書名、エンコーディングなど、証明書のアップロードと差し替えだけでも、各ベンダーの奇妙な違いを処理するPythonモジュール群を持っている。本来ならどこでも動く標準的なPUTリクエスト数本で終わるべきで、Redfish APIドキュメントもそう信じさせるが、現実は違う
      なので、標準化されている、あるいは使い物になるという点には同意しにくく、Webインターフェースを直接操作していた時代と同じくらい腹立たしい
  • コンパクトまたは低消費電力のコンピューターにこだわるならIPMIなしで生きるしかない、という話に対する一つの選択肢は、AtomベースのSupermicro MicroATXボードにIPMIを載せ、奥行きの短い1Uシャーシで小型のNoctuaファンを使って静かに冷却することだ
    自宅で古いモデルを使っているが、静かで小さく、見たことのあるDell R2x0モデルよりずっと魅力的だった。IPMIやECC RAMのようなサーバー機能があり、ミニPCより優れ、作りの甘いRasPiより安定していた
    個人的にIPMIポートをメインLANに挿すことはしないが、分離した状態ではかなり便利で、いじって遊ぶのも楽しかった

    • ASRock Rackには、X470、X570、X670のようなチップセットに標準のAM4/AM5チップを使いつつ、IPMIやECCのようなサーバー機能を多く提供するボードがある。AMD側ではECCはすでに一般的なほうに見える
      自分のボードには5950Xを載せたが、しばらくは5600Gでもよく使えた。mATX/ATXなので一般的なケースと一般的な電源ユニットに収まり、ラックは不要だ
    • IPMIや他の管理インターフェースは別の管理VLANに分離し、専用VPN経由でのみアクセスできるようにしている
    • そういうAtomボードを何台も持っている。記事を読んだ瞬間に最初に思い浮かんだことで、記事がIPMIは大型機器を意味すると言うまでにはかなり時間がかかっていた
  • IPMI のない機器にリモートアクセス機能を追加したいなら、30ドルの RISC-V NanoKVM のようなものを試せる
    HDMI キャプチャとエンコード、Ethernet/Wi-Fi、ATX 電源制御を提供し、一般的な Linux ディストリビューションを実行する
    https://www.aliexpress.com/item/1005007369816019.html
    https://github.com/sipeed/NanoKVM

    • いま、おもちゃのミニ PC にフルキットを付けて試しているところ。数ワットしか消費しない小さな RISC-V デバイスで、まだ Wi-Fi はないが、HDMI 出力を Web UI にキャプチャしつつ、PC には4種類のデバイスとしてエミュレートされる
      USB キーボード、USB マウス、起動 ISO を保存してインストールや復旧に使う USB フラッシュドライブ、そしてかなり優秀な USB NIC として動作する
      この USB NIC は、PC から管理用 SSH ポートだけを公開する用途に使えるので、PC に一種の専用 IPMI インターフェースができたような感じになる。最新のソフトウェアには WireGuard と Tailscale のサポートも入り、VPN で直接接続できる
      まだ細かな問題はあるが、開発者たちが素早く修正しているところ
    • ATX 電源制御ブレークアウトを使うには、60ドルの フルバージョン が必要。このブレークアウトは、ATX 信号を載せた奇妙な物理 USB-C コネクタに接続する
      自作もできそうだが、USB-C コネクタははんだ付けするには本当に嫌な相手
    • AliExpress がなぜこのデバイスを米国の顧客に販売しないのか気になる
    • ソフトウェア側は オープンソースではない ので、代替品より良いとは言えない
      また一つ、信頼できない KVM というだけ
  • 1990年代後半に、Intel 製のサーバーを何台も設置したことがある。Intel のリファレンスプラットフォームを「ベアボーン」コンピュータとして出荷し、RAM とストレージはインテグレーターが入れる方式で、LANDesk Server Manager Pro と “Emergency Management Card”(EMC) で lights-out 管理を行っていた
    AP450GX、BB440FX、RC440FX のような、Pentium Pro から初期 Pentium II 期の機器だった
    x86 プラットフォームのリファレンスコードは死なないという点を考えると、現在の IPMI 構造物のうち、どれほど多くの部分がこのハードウェアとソフトウェアから続いているのか、よく気になっていた。Intel LANDesk Emergency Management Card のデフォルトパスワードは “calvin” で、初期の Dell iDRAC を扱ったことがあれば見覚えのあるパスワードだろう。偶然ではないと思う
    ちなみに Intel 社員から、EMC のコード名は “Hobbes” だったと聞いたが、文書化されたものは見つけられなかった
    EMC の各バージョンは eBay でしばしば見かけ、ISA 版と PCI 版の両方があった。カード上の x86 PC であり、一部または全部には内蔵 UPS があった。アウトオブバンド管理を接続するための PCMCIA スロット、外部電源装置があり、カードのホストバスインターフェースと独自コネクタを介してサーバーのマザーボードに接続されていた
    いくつかの EMC バージョンのファームウェアをダウンロードして調べたところ、一部は組み込み DOS マシンのように見えた。いつかやってみたいおもちゃプロジェクトとして残っているので、まだコードをリバースエンジニアリングしたり qemu で動かしたりはしていないが、試してみたい
    Intel リファレンスプラットフォームを販売していた Unisys、Fujitsu、ALR/Gateway、NCR のようなサードパーティーもこのカードを提供していた。販売リストでこのカードを見かけたら Intel リファレンスプラットフォームだという良い手がかりになり、“LDSM” への言及も手がかりになる
    この系譜を知っている人がいれば、本当に興味深いだろう
    https://www.intel.com/pressroom/archive/releases/1998/ld1030...
    https://web.archive.org/web/20240903131630/https://www.ebay....

  • Intel ME と AMD PSP は、CPU をホストファームウェアが実際に実行できる x86 PC のような状態 にするうえで大きな役割を果たしている
    初期化の複雑さがあまりに高くなったため、従来の初期 BIOS 起動コードのように奇妙に制限されたアセンブリですべてのロジックを書くよりも、C でプログラム可能な扱いやすい別個の組み込みコア上でソフトウェアとして処理するほうが理にかなっている
    一部の HPE ProLiant では、この低レベル初期化の一部を実際に iLO が実行しているように見える。その起動段階では iLO がフレームバッファも直接制御しており、G10 では「コンソールをホストに渡す」といったメッセージが一瞬表示されたあと、ディスプレイが再初期化されてファンクションキーの案内が出る
    Dell も似たようなことをしていそうだが、初期段階では “Please wait” と大きなローディング表示だけが出て、進行状況は見えない

  • IPMI や他の解決策も良いが、欲しいのは常に実行中の UEFI シェルへの標準シリアルインターフェース だ。そのシリアルポートにどうアクセスするかは自分で何とかする問題

    • シェルが依存する UEFI ブートサービスは、ブートローダーや OS が ExitBootServices() を呼び出した後は利用できない
      コードは文字どおり RAM から外され、その領域は OS に返されるため、実装は簡単ではない
    • Sun SPARC や他の Unix システムで懐かしいのは、非常に低いレベルで きちんとしたリモートアクセス が可能だったこと
      BIOS/UEFI のリモートコンソールはいつも扱いづらく、成功するかどうかがまちまちだった。入出力を合わせるには、GRUB やカーネル設定をしばしばいじる必要があった
    • サーバーハードウェアはたいてい、シリアル経由で UEFI にアクセスできるようにしてくれる。それでも リモート電源制御 は必要ではないかと思う
  • IPMIは有用だが、商用企業がハードウェアを長期にわたってきちんとサポートしてくれるとは信じられない、という事実をはっきり示している
    IPMI上で動くOSは、システムが新しいうちはたいてい比較的安全だが、新しいCPUソケットが出ると、メーカーは古いシステムのアップデートにだんだん関心を失っていく。同じIPMIハードウェアが旧型・新型の両方のボードに載っていても同じだ
    IPMIハードウェアに自前のOSを載せられるなら、はるかに有用になるだろう。そうすればインターネットに直接つないでも安全にできる。現状ではVPN、SSHポートフォワーディング、別ネットワークセグメントのようなサイドバンド通信が必要で、IPMIを支えるために追加のハードウェアや設定が大量に発生する
    大規模導入では追加コストはうまく分散されるが、小規模導入ではかなり大きな負担になる。単体の機器をコロケーションする程度なら、価値がないほどだ
    IPMIをインターネットに直接かつ安全に公開できないため、結局、機器ごとに何らかのPiを取り付けることになった。そうするとシリアルポートを使うのも同じくらい簡単で、むしろさらに簡単だ。結局、VAX、Sun、Alphaの時代からあった標準的なシリアルポート制御に戻るわけで、考えれば考えるほど、安全でないネットワークインターフェイスよりずっと筋が通っている

  • もっと小規模なデプロイ、たとえば1万コア程度の規模なら、インテグレーターを通して自前で構築すると思う
    Gigabyte/ASRock Rackのマザーボード、Epyc 9003シリーズ、RAM 384GB、一般的な冗長電源構成なら、ノードあたり7,000ドル程度で、電力効率もかなり良くできる
    内蔵IPMIもかなり良く、ipmitoolとの相性もよく、通常はRedfish関連機能もある程度入っている

  • IPMIは本当に好きだが、ホームラボ用途で気に入らない点は、アイドル時の消費電力が約5W増えること
    Gigabyte MC12-LE0ボードとRyzen Pro 5650の組み合わせはホームサーバーとして50ドル程度なので当然の選択に見えるが、消費電力が高くなる点にはどうしても完全には納得できない
    Dell T20/T30のような古い機器にはIntel AMTがあり、機能ははるかに弱くセキュリティ上の欠陥もあるが、MeshCommanderと組み合わせれば少なくともリモート管理の手段は得られる。MeshCommanderは残念ながら終了し、リリースもあちこちから消えてしまったが、運よくMSIとNodeパッケージをサーバーに保存しておいた
    Raspberry 4と8ドルの単純なUSB-HDMIキャプチャカードでPiKVM V2を試してみる予定だ: https://docs.pikvm.org/v2/
    一部機能がない点を除けば、リモート管理をまったくサポートしない機器にもより汎用的に使えそうで、有望に見える

    • 追加の消費電力は電源ユニットの品質に大きく左右される。高負荷時とアイドル時のどちらでも効率的な電源ユニットを作るのはかなり難しい
      BMCが、時にはNICに内蔵されたBMCが、本当にそれだけ電力を食うのかは疑わしい。しかもRaspberry 4でPiKVMを使えば5Wを超えるだろう
    • ファームウェアが公開された今はNanoKVMを調べているところだ
      https://github.com/sipeed/NanoKVM
    • MeshCommanderのリリースはまだhttps://www.meshcommander.com/から入手でき、NPMでもインストール可能だ
      使ったことはないが、後継としてはhttps://meshcentral.com/が目標に見える
    • MeshCommander 0.96はWebサイトから再び入手できる。開発者が新しい職場に慣れるためだった、という内容を読んだ
  • IPMIにおける大きな疑問は、デフォルトキーが何かという点だ
    サプライチェーンのどこかで誰かがIPMIキーを追加でインストールしていたり、デフォルトキーがあったりすれば、その人物はコンピューターをリモート管理できる
    https://www.rapid7.com/blog/post/2013/07/02/a-penetration-te...

    • そのリンクの追加引用にもあるように、IPMI 2.0の認証プロセスでは、クライアントが認証する前に、サーバーが要求されたユーザーのパスワードに対するsalted SHA1またはMD5ハッシュをクライアントへ送ることが求められる
      IPMIではパスワードの最大長も20文字だ。現実には、ハッシュが秘密であり続けると期待できるのは、限られた契約期間内で動く既知のペネトレーションテスターに対してだけで、時間が無制限にある実際の攻撃者に対してはそうではない、という点を見るべきだ
      この点については非常に批判的だ。仕様に入ってから20年たっている。ソフトウェアの利点は、ハードウェアより変更しやすいことではないのか。「VLANに入れるべきだ」と言うのは簡単だが、評価に出向いてみると、IPMIはほとんど常に業務ネットワークにつながっている
      デフォルトに愚かなものを入れれば、愚かな構成が世界中に広まり、知識あるセキュリティ管理者がいないすべての会社が「サーバーを買う」瞬間もそこに含まれる
    • 常に物理的に分離されたネットワーク上に置くべきで、システムとNICを共有するBMCは避けるべきだ