ネタバレ：1.11未満のOpen vSwitchバージョンは、「フローフラッド」という形式の攻撃に対して脆弱です。攻撃者は、比較的小さなパケットストリームを任意の仮想マシンのアドレスに送信することでネットワークを中断できます。 バージョン1.11以前は影響を受けません。 ほとんどのOVSサーバーは、引き続きOVS 1.4または1.9（LTSバージョン）を使用します。 そのようなシステムの管理者は、OVSの新しいバージョンにアップグレードすることを強くお勧めします。



歌詞：私が最初にこの問題を再現できてから1年半以上経ちました。 苦情に関するOVSニュースレターは、「次のバージョンでは修正する」と述べ、半年後に修正しました。 ただし、この修正はLTSバージョンには影響しません。つまり、OVSを使用するほとんどのシステムは依然として脆弱です。 Citrixに何度か連絡しようとしました（Xen Serverの一部としてOVSの最も脆弱なバージョンを使用しているため-当時はそれが悪用のメイン製品でした）が、明確な反応はありませんでした。 現在、管理者はほとんど血を流さずに問題を修正する機会があるため、非常に再現しやすく、非常に混乱し、診断しやすい問題の説明を公開することにしました。「フロー輻輳」、「フローフラッド攻撃」、「奇妙な未知のゴミ」の問題「すべてが奇妙に機能する」 以前は、この問題に関するコメントとメーリングリストで何度か書きましたが、ロシアの問題を完全に説明する火薬を持っていなかったので、問題の本質は一般のIT担当者には明らかでした。 修正しました。



次の行hping3 -i u10 virtual.machine.ip



は、仮想マシンが実行されている仮想化ホストをhping3 -i u10 virtual.machine.ip



します。 また、仮想化ホストだけでなく、1.11より前のOpen vSwitchバージョンを実行しているシステム。 バージョン1.4.3および1.9に特に重点を置いています。これらはLTSバージョンであり、最も頻繁に使用されるためです。



同じ呼び出しのより深刻なバージョン、今回はネットワークを使用するためのルールに違反しています： hping3 --flood --rand-source virtual.machine.ip



発信トラフィックの比率（〜10-60 Mbit / s）と被害者のインターフェースの（潜在的な）帯域幅（2x10G、利用可能な攻撃/攻撃帯域幅の比率は約1：300-1：1000）で、従来のDoS攻撃ではなく、脆弱性について具体的に話すことができますフラッディング、アップリンクチャネルの目詰まりを非動作状態にします。



仮想化ホスト側の症状：接続を開く際の予期しない遅延、ovs-vswitchdプロセスによるCPU消費が100％に増加する、新規または非アクティブセッションのパケット損失。 OVS 1.4を使用すると、ovs-vswitchdプロセスはCPUを100％消費するだけでなく、メモリを使い果たし、毎分最大20メガバイトの速度で実行します。これは、優れたOOM祖父がやって来て、教育的な会話を行うまでです。



通常のネットワークの問題とは異なり、pingを実行すると「突破」される可能性が高く、フローがカーネルに到達するとすぐにpingは問題なく動作しますが、新しい接続を確立することはできません。 これは問題の診断を非常に複雑にします。なぜなら、心理的な「pingがあります-ネットワークが機能しています」を取り除くのは非常に難しいからです。 これに加えて、ホスト上の「噴出された」sshセッションがそれほど困難なく同じように動作し続けると、ホストのネットワークの問題は非常に困難になると管理者に確信させます。 インターフェイスへのフラッドが特定のしきい値（〜50-80Mb / s）を超えると、適切なネットワークアクティビティが停止します。 しかし、記載されている問題の潜行性は、サービスの大幅な低下が非常に低い負荷で発生するという事実にあります。その下では、標準的なネットワーク診断は「すべてが正常です」と報告します。



私はこの機会にsi14に謝罪します。si14は実験室の仮想ネットワークの奇妙な点について話しましたが、その存在を証明することはできませんでしたが、私はすべてが順調であったことを「見ました」。何かが間違っていると疑われたが、彼は明白な衝突テストを見つけることができた。



XenServerの場合、ローカル管理トラフィックもOpen vSwitchブリッジを通過し、すべてのブリッジが1つのovs-vswitchdプロセスによって処理されるため、OVSの状況は複雑です。つまり、幸せな管理者はこれらの症状を見ることができず、sshで彼を入れません。 そして、もし彼らが私を行かせたら、上記の「問題なし」について見てください。 NAS / SANトラフィックもブリッジを通過するため、原因が消失した後でも、仮想マシンは動作不能のままになる可能性があります。 この場合、問題の症状は「遅延とパケット損失で始まった予期しないフリーズ」です。



「プロダクションマネージャー」の観点からの脆弱性の説明-ADSLで10〜50メガバイトのチャネルを持つ学生は、少なくとも1台の仮想マシンがインターネット上のインターフェースで「見える」場合、10ギガビットポートで仮想化サーバーファーム全体を配置できます。 そして、仮想マシン内のルール/ ACLはほとんど役に立ちません。 仮想マシンのユーザーは誰でも、インターネットにアクセスしなくても同じものを配置できます。

問題の技術的な説明

（ Openvswitch実装ポストの概要からのイラスト）

理由：Open vSwitchの古いバージョンは同様のフローを結合できず、新しいフローに似たイーサネットフレームを検出すると、検査プロセスが非常に遅いため（ハッシュテーブルの驚異的な速度に対して）、常にフレームを検査のためにnetlinkソケットを介してovs-vswitchdプロセスに送信しますカーネル内）、およびovs-vswitchd自体がシングルスレッドであり、システム内で唯一のものである場合、多くの新しいフローが出現する条件下でのネットワークパフォーマンスは、ユーザースペースアプリケーションの速度によって制限されるように見えます（そして、カーネルへの移動/ネットリンクを介した戻り） しばらくすると、既存のカーネルフローが新しいエントリに置き換えられ、既存のカーネルフローが（非常にアクティブでない限り）混雑します。新しいフローを復元する可能性は、競合他社の数、つまり洪水に反比例します。 さらに、正真正銘のセッション内のパケット数は何の役割も果たしません。セッション全体が唯一のフローです。 それが長い間盲点として機能していたものです。単一のTCPセッションでのバーストテストでは、CPU使用率がほとんどゼロのギガビットトラフィックが喜んで報告されました。

カーネルフローとオープンフローフロー

重要なのは、カーネルフローとオープンフローフローの違いを理解することです。 オープンフローフローは、フローにビットマスクが付随することを意味します。より正確には、オープンフロー形式は対象フィールドの表示を意味します。 この場合、残りのフィールドについては、暗黙的に「重要ではない」、つまり「*」を意味します。



Open vSwitchの古いバージョンのカーネルモジュールは、ルールを操作するためにかなり洗練されたメカニズムを使用しますが、これには1つの欠点しかありません。マスクとスターをサポートしていません。



メカニズムは次のとおりです。着信イーサネットフレームの場合、L2で始まりL4（つまり、TCPポート番号）で終わるすべてのヘッダーが選択され、TCPの「ウィンドウサイズ」や「セグメント番号」 「。 それらはすべてバイナリ構造にパックされ、その後、この構造からハッシュが考慮されます。 次に、このハッシュはルールのハッシュテーブルで検索され、ルールに一致する場合は使用されます。 一致するものがない場合、パッケージは検査のためにユーザースペースのよりインテリジェントなプログラム（ovs-vswitchd）に送信され、このプログラムはそのようなパッケージの処理に関する新しいルールを送り返します。 オープンフローのルール、およびovs-ofctlを使用して手動で課されるルールは、ovs-vswitchdによって正確に処理され、カーネルモジュールはそれらについて何も認識しません。 これは、「スイッチのような動作」を意味する「通常の」ルールの場合に特に当てはまります。 しかし、通常のドロップでもユーザースペースでの検査が必要です。ドロップには、ほとんどの場合、着信ポートと発信ポートのすべての可能な組み合わせが含まれないため、OVSの観点からは、アスタリスクが含まれます。



ハッシュテーブルは、ルールの数に依存しない素晴らしいパフォーマンスを提供します（つまり、10,000個のルールが1つとほぼ同じ速度で処理されます）。



残念ながら、新しい各パッケージのヘッダーが異なる場合、そのような新しいパッケージはそれぞれユーザースペースで検査されます。 遅くて悲しいです。



OVSの当初のアイデアは、TCPセッション内では、すべてのパケットが同じであり、セッション全体に対して1つのルールが存在するというものでした。 残念なことに、上記の行をコピーした邪悪な「hakkir Vasya」は、この期待を破ることができます。



新しいバージョンでは、この問題はmegaflowを使用して解決されました。

メガフロー

バージョン1.11以降、Open vSwitchに登場しています。 Megaflowはopenflowに属していませんが、ovs-vswitchdとカーネルモジュールの相互作用に関係しています。 残念ながら、メガフローの価格は非常に明確です-場合によっては、パフォーマンスが5〜20％低下します。 幸い、見返りに、ovs-vswitchdはいかなる状況でも不均衡な量のリソースを消費しません。



メガフローとは何ですか？ これについては、C で詳しく説明しています 。 私が理解していることから、「マスク」の概念が表示され、マスク自体はカーネルデータパス全体に固有であり、検索時にそれらすべてを考慮する必要があります。つまり、検索の複雑さはo（1）ではなくo（マスク）になります。 これにより、パフォーマンスがわずかに低下します。 しかし、洪水が発生した場合、言いようのないブレーキとサービス拒否の中で、これは朗報です。 そして、おそらく、唯一の方法です。



さらに、多くのインストールでマスクが非常に少なくなり、パフォーマンスの低下はごくわずかです。 たとえば、「単純なスイッチ」の制御されていないモード、つまり、通常、ほとんどの場合、単一のマスクが含まれます。

野生の攻撃

記事の冒頭で「hping / npingによるサービス拒否攻撃」に関するものであったという事実にもかかわらず、実際の問題ははるかに広範です。 何らかの理由で多くの異なるアドレスから仮想マシンに多くの呼び出しがある場合、または多くのセッションが単純に確立される場合、OVSの動作の観点からは、「攻撃」と「高負荷」に違いはありません。 仮想マシンを使用して、多数の小さな画像を含む非常に人気のあるブラウザーゲームの統計を配布するときに、実際にこれを観察しました。 多くの選手がいました、多くの写真がありました、彼らは小さかったです。 合計-300〜500バイトのサイズで毎秒数千の新しいTCPセッション。 この場合、15-20メガビットの非常に緩やかなフローが得られました。 また、各セッションはユーザー空間に移動するため、古いバージョンのOVSの最悪のケースです。



追加の問題は、ネットリンクにバッファがあり、ネットワークインターフェイスにバッファがあり、OVSにバッファがあることです。 着信パケットは単にドロップするのではなく、キューに入れられ、プロセッサに100％の負荷がかかります（はい、800個中100個が使用可能）。 これにより、新しいフローの処理の遅延が増加します。 さらに、この遅延は診断が非常に困難です。遅延は最初のパケットでのみ発生し、後続のパケット（作成されたフローのフレームワーク内）はすべて迅速に処理されます。



待ち時間の増加は、問題の2番目の部分につながります。既存のTCPセッションからのパケットが十分長い時間キューにある場合、そのようなセッションに関するレコードはカーネルフローテーブルから消去されます。 そして、パッケージは再び検査に進み、新しいカーネルフローを作成します。これにより、OVSはさらに「呼吸も移動もしない」状態になります。



問題は入力/出力に関して対称的であることに注意してください。 それは、外側の「ハッキル・ヴァシャ」だけでなく、内側の「ハッキル・ヴァシャ」でもあります。 何千もの新しいセッションを外部に送信する仮想マシンは、同じ問題を引き起こします。これらの問題は、ハッカーの隣にいるすべての人に関係します。 ネットワークを介して近隣にパケットが送信されると、1台の仮想マシンが仮想化サーバーのホスト全体のサービス品質を麻痺させるか、大幅に低下させる可能性があります。



このような死は、公共プロバイダーにとっても同様であることは明らかです。 以前の作業では、ほとんどのOVS機能をカットするかなりugいパッチを作成する必要がありました（その時点ではメガフローがなかったため）。可能な限り最小のパラメーターセットのみをフレームのバイナリプリント（ハッシュの作成元）に残しました。 彼らはこれをアップストリームに持ち込みませんが、私は問題を解決しました。 そして、メガフローを備えたOVS 1.11のリリース前には、約半年が残りました...

問題の大きさ

配布キット	OVSバージョン	脆弱性
Debian Sqeeze	x	パッケージなし
Debian Wheezy	1.4.2	脆弱なバージョン+メモリリーク
Debian Sid	1.9.3	脆弱なバージョン（ここには最先端のものがあります）
Ubuntu 12.04	1.4	脆弱なバージョン+メモリリーク
Ubuntu 14.04	2.0	乾杯、乾杯。
XenServer 5.5	1.4.2	脆弱なバージョン+メモリリーク
XenServer 6.2	1.4.3	脆弱なバージョン。 今までは、1.9でさえありません！
RHEL / CentOS 5	x	パッケージが提供されていません
RedHat / CentOS 6.5	x	カーネルモジュールのみ、ユーザースペースなし
Fedora 21	2.1	一番新鮮！

（お気に入りのディストリビューションのOVSバージョンに関する情報は歓迎され、追加されます。ディストリビューションWebサイトへのリンクを含むバージョンを示すことをお勧めします）

OVSは、オープンソースバージョンと多くのプロプライエタリバージョン（仮想マシンへのトラフィックに引き続きOVSを使用）の両方で、OpenStackの推奨標準ブリッジであるため、デフォルトのOpenStackインストールのほとんどが問題を起こしやすいと言えます。 ディストリビューションは主に問題のあるバージョンであるため、同様の問題はOVSに基づいたlibvirtのフルタイムインストールを想定しています。

おわりに

更新、更新、更新。 幸いなことに、CentOS 5ユーザーや他の巨大な愛好家にとって、OVS 1.11カーネルモジュールは2.6.18をサポートしています（ただし、3.8以下）ので、ほとんどのシステムで動作します。 新しいカーネルでは、新しいバージョンのOVS-2.0または2.1（2014年5月上旬にリリースされたばかり）を使用する価値があります。 重要な潜在的な問題は、OVSの更新時にカーネルモジュールを更新しない場合、結果のカーネルモジュールが機能しないことです（ただし、コマンドラインユーティリティは作業容量を表示しようとします）。



2番目の問題：脆弱性が修正されたすべてのバージョンはLTSではありません。 これは、非LTSのサポートが事実上ないため（そしてバグ修正は次のバージョンでのみ行われるため）、新しいバージョンがリリースされるとすぐに更新する必要があることを意味します。



関連リンク ：

• ウィキペディアの記事： en：Open vSwitch 、 en：Open vSwitch 、 en：OpenFlow 、 en：OpenFlow
• Open vSwitchをダウンロードする
• Open vSwitchアーキテクチャのビデオ
• OVSフロー処理管理マニュアル

PS誰かが仮想マシンから「それがどのように機能するか」をチェックすることに決めた場合-起動後、Ctrl-Cを押さない可能性が高いことに注意してください。 より正確には、押すだけですが、サーバーはあなたに聞こえず、インターフェイスにフラッドを送信し続けます。そのような仮想マシンを再起動することさえ困難です-コントロールが同じブリッジを通過する場合、シャットダウンまたは再起動コマンドは単にホスト上のユーティリティに到達しません。