仮想マシンの Linux ホスト サーバーがインターネットに接続されておらず、LAN でのみ使用され、Proxmox のような比較的よくテストされたディストリビューションを使用している場合、カーネル引数を介してすべての脆弱性軽減策をオフにすることはどの程度危険でしょうかmitigations=off
。
さらに、このような緩和策をすべて無効にすると、どのようなパフォーマンスの向上が見られるかをテストした人はいますか?
最近、緩和策によって生じる大きな打撃を見て、これが私にとって疑問になりましたretbleed
。https://www.phoronix.com/review/retbleed-benchmark
この考え方は、上記のカーネル引数を介して、または影響の大きい緩和策を個別にオフにすることによって、すべてまたは一部の緩和策を削除した場合に、どのような影響(良い影響と悪い影響の両方)が生じるのかという好奇心にまで広がりました。
答え1
Linuxカーネルフラグは、mitigations=[on|off]
ここにリストされているハードウェアの脆弱性に対する利用可能なすべてのカーネル緩和策を簡単に有効/無効にするための単一のトグルです。https://docs.kernel.org/admin-guide/hw-vuln/index.html
もちろん、その影響は CPU に完全に依存します。
CPU が既知の脆弱性のいずれに対しても脆弱でない場合は、緩和策は適用されず、影響は実質的にゼロになるはずです。
CPUが何らかの脆弱性を抱えている場合(CPU自体に脆弱性があるのでしょうか?全てそれらのどれが影響するかは、特定の脆弱性とワークロードによって異なります。
リスク分析に関しては、ワークロードとユーザー ベースによっても異なります。
パブリック VPS プロバイダーによって運営されている仮想化ホストでは、ゲストに対する信頼度が低く、同僚だけが使用する内部仮想化ホストに比べて悪意のある (または侵害された) ゲストである可能性がはるかに高くなります。
たとえば、CI/CD パイプラインやコンピューティング クラスターに使用される仮想化ホストでは、すべてのゲストの存続期間は短く、信頼されたイメージからデプロイされ、最大 2 時間実行された後、再び破棄されます。そこでは、得られるすべてのパフォーマンスが必要なため、緩和策を無効にします。
別の共有クラスターでは、より古典的なサーバー統合ワークロードをホストしています。そこにデプロイされたゲストは、数時間ではなく「永久に」実行できます (実行する可能性が高くなります)。運用ワークロードと非運用ワークロードが混在しており、ゲストは DevOps チームによって管理されていますが、すべてのチームがシステムとアプリケーションのパッチ適用と更新に熱心ではありません。
悪意のあるゲストや侵害されたゲストのリスクははるかに高く、特定のワークロードのパフォーマンスが低下する可能性は許容できるトレードオフであるため、そこでは緩和策が有効になり、ゲストに公開される CPU フラグが制限されます。
答え2
ネットワークの外部から間接的にでもサーバーに接続するのは本当に不可能なのでしょうか?
これが、最初に自問すべき質問です。LAN に 2 つのネットワーク接続 (1 つはその LAN への接続、もう 1 つはインターネットに接続された別のネットワークへの接続 (できれば複数のファイアウォール層を経由)) を持つマシンからアクセスできる場合、そのサーバーをインターネットに接続したことになります。
また、マシンが攻撃に対して脆弱になるためには、インターネットに接続する必要はないということを覚えておいてください。マシンは、USB スティック、フロッピー ディスク、または端末に入力されたコマンドを介して、単にマシンに損害を与えようとするマルウェアに感染する可能性があります。
結局のところ、すべてのセキュリティは、すべてのパフォーマンス改善と同様に妥協です。得られる見返りに対して許容できるリスクのレベルはどの程度でしょうか。
パフォーマンスの向上の可能性を調べるには、ネットワーク接続がまったくない状態でマシンでテストを実行し、自分の目で確かめてください。 おそらくそれほど大きな効果は得られないでしょうが、古いハードウェアをもう少し長く使えるようにする余分な CPU サイクルを絞り出すには十分かもしれません。そうすれば、新しいサーバーの予算を本当に獲得すべきだと上層部に納得させる時間ができます。
答え3
「... LAN でのみ使用され、Proxmox のような比較的よくテストされたディストリビューションを使用している場合、カーネル引数 mitigations=off を介してすべての脆弱性緩和策を無効にすると、どの程度危険でしょうか?」
...
「この考え方は、上記のカーネル引数を介して、または影響の大きい緩和策を個別に無効にすることによって、すべてまたは一部の緩和策を削除すると、どのような影響 (良い影響と悪い影響の両方) が生じるかという好奇心にまで広がりました。」
それでも、責任や、たとえ少数の問題であっても修復にかかる時間の増加を考慮する必要があるかもしれません。
とはいえ、ほとんどの緩和策は最新の CPU にすでに組み込まれているため、緩和策をオフにすると、新しいシステムでのパフォーマンスの低下はほとんど、またはわずかになります。緩和策をオフにすると通常は遅くなりますが、他のベンチマークと同様に例外もあります。
「...このような緩和策をすべて無効にすると、どのようなパフォーマンスの向上が見られるでしょうか?」
Phoronix の Michael Larabel 氏は次のように述べています。
2022年12月7日の記事では次のように述べられています。「Intel Raptor Lake 緩和影響パフォーマンス比較」:
「...ほとんどの場合、Raptor Lake にまだ関連するソフトウェア関連の緩和策は、パフォーマンスに大きな違いが生じることなく、そのままにしておくことができます。」
2022年9月30日の記事では次のように述べられています。「AMD Zen 4では、CPUセキュリティ緩和策を無効にしても意外に意味がない」:
「... 実行された 190 の異なるベンチマークの広範囲にわたって、デフォルトの緩和策を維持すると、緩和策をオフにして実行するよりも全体的に約 3% 高速になりました。基本的に、他の古いプロセッサで通常見られるものとは逆です。」
古いシステムでは、不満を持った従業員が退職前に権限を昇格したり、LAN に損害を与えたりする可能性があることを考慮する必要があります。従業員の不満の一部は、時代遅れの機器を使用していることによって引き起こされる可能性があり、彼らはそれをあなたに対して利用します。また、テザリングされた携帯電話は「インターネットに接続されていない」という推定に反し、携帯電話を充電しながら不正なアプリを実行したり、巧妙に作成された電子メールを開いたりすると、存在する脆弱性を悪用することしかできません。