パナソニックの攻撃

最近、ネットワーク機器の動作の中断の原因を分析して、非常に興味深い状況を明らかにしました。 調査はほぼ1か月続き、その結果、一連のイベントが特定され、それによって企業のサブネットが歓声を上げることができました。



この記事は、それがどのように解決されたかについての詳細な分析を含む、かなり興味深いパズルです。 このケースは、システム管理者とネットワーク管理者だけでなく、通常のMFPの背後に隠れて、目立たないようにオフィスの隅に立って、翼で待っているものを疑うことのない一般ユーザーにとっても興味深いと思います...



そして、「これは不可解なグリッチです」または「この機器の動作はジンバブエ南部の天気と降雨量に依存する」などのフレーズをよく使用する人にとって、この記事は単に「読まなければならない」です。論理と常識。 そして、この記事はこれを鮮明に確認するものです。





そのため、すべての企業ネットワークスイッチのログに次のメッセージが表示され始めました。 「％SPANTREE-2-LOOPGUARD_BLOCK：VLAN 000XのポートFastEthernet0 / 24をブロックするループガード」 。 おそらく、知識のある人はすぐにCisco IOSのスタイルでメッセージを認識し、残りについては説明します。スイッチはネットワークのループを修正したため、24番目のポートで一部のVLAN Xのトラフィックをブロックしました。 この記事では、1つのVLANを1つのサブネットとして理解できます（ただし、この記事のみで、説明したイベントを理解するためだけです）。 アクセスレベルスイッチについて説明しており、24番目のポートがネットワークの残りの部分に接続しているため、このスイッチに接続し、同じサブネットにいるユーザーが影響を受けます。



喜ばしい状況は2つだけでした。1つ目はポートが1秒未満でブロックされ、2つ目はユーザーからの苦情がなかったことです。 またね そのため、問題を整理し、ノイズをあまり多くせずに問題を解決します。



利用可能なログを分析したところ、問題は1日平均2〜3回、常に勤務時間中に発生したことがわかりました。 このため、十分なデータを収集するのに長い時間がかかりました。



実際のループが存在するという考えは、存在する権利がなかったため、すぐに完全に破棄されました（経験が示唆されました）。 その瞬間、すぐにネットワークに特定のプロセスがあり、それが何らかの形でスイッチを「ループを検出」することが明らかになりました。



まず第一に、時間内のいくつかのイベントの相関関係を求めて、すべてのログを調べました。 そして、この「ループ検出」が発生するたびに、同じVLANにあるキヤノンのネットワークプリンターの1つとの接続が切断されることがわかりました。 これは2〜3秒の差で起こったので、私は彼がネットワーク上で気分を悪くする何かを聞き、ネットワークポートをジャグリングしたり、場合によってはオーバーロードしたりするという結論に達しました。 彼に行くのは面倒でしたが、明らかに同じ理由で彼は気分が悪くなりました。



同じVLANのすべての参加者が聞くことができる唯一のこと、つまり第2レベルの単一のブロードキャストドメインは、もちろんブロードキャスト、つまり 実際のブロードキャストパケット。



まあ、これはおそらく放送されているので、それから私もそれを聞くことができます。 別の車を置き、目的のVLANに接続し、24時間体制でディスクにすべてを書き込むプロトコルアナライザーでスニファーを起動しました。 絶対にすべてですが、私が聞くことができるものだけ。 彼は何を聞くことができましたか？ そして、彼は興味のない自分のトラフィックと、すべてのブロードキャストネットワークトラフィックを聞くことができました。 さらに必要ありません。



スニファーの作業の最初の結果は私を驚かせました...穏やかに言えば。 特定のネットワークセグメントについて、つまり このすべてのVLANについて、標準は毎秒500〜1000ブロードキャストパケットでした。



ここで、私はおそらく少し余談します。 すぐに激怒する人もいます。 まず、ネットワークセグメントは非常に大きく、一目で200〜300台のマシンです。 第二に、IPXトラフィックはこのセグメントにリダイレクトされ、非常に積極的にブロードキャストを使用します。 したがって、これらのトラフィック強度の値は私をまったく驚かせませんでした。



しかし、これは驚いた：





一部のネットワークスイッチが「ループ」を修正したまさにその瞬間に、ネットワーク上のブロードキャストトラフィックは1秒あたり20'000パケットで屋根を通過しました。 しかし、どこから？



この時点で、いくつかのポイントがすでに明らかになっています。 「ループ」を修正したのはCisco2950シリーズスイッチのみで、ネットワークには2つしかありません。 ほとんどの場合、このイベントは両方のスイッチですぐに発生しましたが、時々、一方のスイッチでのみ問題が発生し、もう一方のスイッチには触れませんでした。 問題が毎日2回、まったく同じ時間に2回、絶対に繰り返されなかったときに1回から3回発生したことが最も興味深いことがわかりました。 グラフは、午前10時27分に問題が発生したことを示しています。 Xの2時間目は午前9時34分でした。 毎日この時間に状況が繰り返されました。 これが最初の手がかりでした。



グラフの一番上の黒い線は、スニファーによってキャプチャされたすべてのトラフィックです。 青はすべてのARP要求です。 ご存知のように、ARP要求はブロードキャストパケットによって送信され、このトラフィックの存在は私の理解に適合しています。 しかし、20,000パケットのこの波の頂上全体が構成されるのは、ARP要求からです！ また、緑色の線の小さなしぶきに注目する価値があります。 これはSNMPトラフィックです（一言で言えば-ネットワーク管理プロトコル）。 また、赤いスプラッシュはユニキャストフラッドです。 しかし、後でそれらに戻ります。



スニファーログの分析は1日以上遅れました。 また、問題が明らかになった時点で、ネットワークがユニキャストフラッド、つまり やや単純な言語では、Cisco3560などの多数のスイッチ（これは500ルーブル用のスイッチではなく、これは対応するコストを伴う企業レベルの管理ネットワーク機器です）がしばらくの間ダムハブとして機能し始めました。 これは完全に不可解でした。 状況はおとぎ話のように発展しました-さらに悪化しました。 そして、私はこれを行うことができる特定のモンスターに直面しなければなりませんでした！



そして、ARPリクエストの嵐とユニキャストトラフィックの洪水の中で、私は4つのパッケージを何とか選びました。 問題が明らかになった時点で常に表示されていた4つのパッケージ。最も重要なことは、最初のパッケージが常にこのWaveの表示前に表示されていたことです。



これらはどのようなパッケージですか？ 1つのソースからの4つの完全に同一のブロードキャストパケット。 より正確には、ある時点の9時34分、別の時点の10時27分、さらには任意の時点で3番目の時点からです。 そのため、このパッケージは次のようになりました。







一般的に、犯罪者はいません。 特定のパナソニックMFPは、サブネット内でTTL = 1のブロードキャストパケットをUDPポート3892（pcc-image-port）に送信することで、自身を公表しました。 それで、何がそんなにひどいのでしょうか？



一見、本当に何もありません。 しかし、ここで日本の開発者の技術の奇跡を見ることへの関心は怠byによって克服されました。 MACアドレスを持っているので、私はすぐにこのデバイスの場所を特定し、それに向かいました。 私は、MFP、MFPのようなハイテクなものは見ませんでした。 しかし、その後、思考が生じました。 MFPデータが接続されているスイッチのポートは、このようなパケットを形成する前に常にジャーク（リンクアップ/ダウン）されます。 2つのオプションがありました。 再起動して形成するか、何らかの理由でネットワークインターフェイスの動作を再開します。 いずれにせよ、このMFPをリブートすると、この状況をシミュレートできます。



ヘッドショットでした！ MFPを再起動して、この状況を何度もシミュレートしました。 疑いはありませんでした-それだけです-悪！



しかし、問題を見つけることは戦いの半分であり、それがなぜ起こるのか、特になぜ毎回同時に起こるのかを理解するのははるかに困難ですが、より興味深いのでしょうか？ 最初の考えは何ですか？ もちろん、スケジュールに従ってMFPを再起動してください！ ネットワークのこのセグメントには合計で3つのそのようなMFPがあり、わずか1、2年前にインストールされていることがわかりました。 これらの鉄片のWebインターフェースにアクセスできるようになったので、私はそれらを上下に揺さぶりましたが、スケジュールされた再起動の問題はありませんでした。 そして、ここ...そしてここで、これらのMFPのシステム時間が実際のMFPに対応していないことに気付きました。 そして、それは異なりました...一方では9時間34分、他方では10時間27分！ つまり 彼らは正確に午前0時、正確には午前0時に再起動しましたが、内部時計に従っています。



信号機は、Panasov PBXにそのような機能があることを確認しました-真夜中に再構築します。 どうやら、MFPはPBXの継承を受け取ったようです。これは、FAXマシンが明らかにその直接の祖先だったためです。 3番目のMFPについては、多くの場合、手動で再起動され、ソケットから引き抜かれたため、任意の時点で問題が発生したようです。



したがって、犯人は明確に特定されました-MFPパナソニック。 また、これらのイベントが一定の時間に発生する理由が明らかになりました。これは、ランダムな時間に問題が発生する理由が明らかになったのと同じです。 ただし、ネットワークにこのような量のARPトラフィックが存在する理由、スイッチが悪化している理由、およびフラッドの発生元を理解する必要がありました。





以下の調査の詳細は省略します。 パナソニックの独自のソフトウェアにインストールされた後、スニファーを備えたマシンでさらに調査が行われたことを注意してください。 しかし、彼の研究はもはやそれほどエキサイティングではなかったので、事実と結果に移りましょう。



など。 疑わしいMFPが含まれるときにネットワーク上で発生するイベントの完全な年表（途中で、各イベントのブロードキャストパケットの数をカウントします）：



1.オンにすると、上記のダンプが提供されたパケットが形成され、ネットワーク全体に送信されます。 パケットは4回送信されますが、このパケットを受信するすべてのデバイスは、最初のそのようなパケットにのみ応答するため、他のパケットは無視します。 そうでなければ、ブロードキャストトラフィックの波は4倍になります！ そして今、これらが実際に4つのブロードキャストパケットであることに注意してください。



2.クライアントマシンにインストールされたソフトウェア（この3892rdポートをリッスンするPCCMFLPD.EXE）がこのパッケージを受け取ります。 たとえば、このようなクライアントが60台あり、各MFPに20台あることを示します（はい、そのような大規模オフィス）。



3.そして、予期しないことが起こります。 このソフトウェアは、SNMPを介してMFPと通信します。 そして、そのようなパケットを受信するすべてのクライアントは、ブロードキャストSNMP要求get-next-requestを送信します。 これは別の60ブロードキャストパケットであることに注意してください。



4. SNMPを実行している各デバイスは、そのようなパケットを受信したため、それに応答したいと考えています。 そしてそれは、このリクエストを送信した人のMACアドレスを知る必要があることを意味します。 そして、SNMPを介して動作するこれら3台のMFPを含め、ネットワークに100台のデバイスがあると想像してみましょう。 どこから来たの？ 基本的に、これらは印刷に使用されるHPプリントサーバーです。 そして、私たちは何を得ますか？ 100個のデバイスのそれぞれが、60個のクライアントのそれぞれに応答したいと考えています。 したがって、このような各デバイスは60のARP要求を送信します。 そして、私たち自身のために、ネットワーク上の6000件のブロードキャストリクエストに注意しましょう。 ところで、ARP要求。 ええ、すでに揚げた匂いがしますが、これはほんの始まりです=）。



5.次に、すべてのスイッチが始まった2つのスイッチについて思い出しましょう。 はい、同じCisco2950。 事実、彼らは非常に多くのブロードキャストトラフィックをかき集めたときに、ブロードキャストストームと見なします。 通常、この現象は、1つのパケットが無限に円を巡回するときにネットワーク内のループを伴います。 ただし、これらのスイッチは、ポートのブロックを次のように説明しています。 「ループガードブロックポート」 、つまり 「ループからの保護のためのポートブロッキング」（曲がっていますが、はっきりしていると思います）。 さて、ポートはブロックされており、道化師のようです。 しかし、違います！ ポートのブロックが解除されると、スイッチはTCN（Topology Change Notifier）などのメッセージをこのSTPツリーインスタンスのルートに送信します。 トポロジ変更通知。 そして、このSTPツリーのルートスイッチは、このようなメッセージにどのように反応しますか？ もちろん、すべてすべてすべてTC（トポロジ変更）を送信します。 TCを受信するすべてのスイッチは、エージングタイムMACアドレステーブルをドロップすることが知られています。 第一に、これはネットワークでユニキャストフラッドを取得する方法であり、第二に、他のネットワークにルーティングするスイッチでは、誘導問題が発生します。 MACアドレスが不明な宛先にパケットをルーティングできません。どうすればよいですか？ ARPリクエスト！ つまり 特定のVLANのルーティングが発生するすべてのインターフェイスは、ARPテーブルによって特定のネットワークのすべてのノードによってポーリングされるため、そこに格納されている情報の正確性が明確になります。 さて、私たち自身のためにより多くのARP要求を祝います 。 さて、ここにARPの突風があります！





実際、私たちの年表の5番目のポイントは正確ではなく、事実にケチです。 微妙な点がたくさんありますが、一般的に言えば、すべてはそうではありませんが、非常に近いものです。 しかし、これは意図的に行われたため、これらの行の意味は、可能な限り多くの読者にとって明確であり、数ページでボリュームが縮尺しませんでした。 さらに、STPの原理とユニキャストFlood'aの出現の理由の簡単な説明でさえ、さらに2つの3つの記事を取り上げます。



PS一般的に、パナソニックはそれとどこで関係していますか？ MFPの時刻を正しく設定すれば、問題はありません。 夜には、すべてのユーザーのマシンの電源がオフになり、ネットワーク上に最初のパケットを聞く人はいません。 パナソニックに対する不満はなく、そうすることはできません。 一部は非難する。 純粋に技術的には、正確に真夜中に機器を再起動することは実際には良い考えです。接続を切断したり設定を変更したりすることができないのは残念です。



PS2そしてここにシスコ？ はい、シスコへの苦情はありません。 2950番目の腺は弱く、放送の嵐と正直に戦い、港を塞いでいます。 3560はTCに対しても正直に反応し、洪水を引き起こします（繰り返しますが、このトピックにはまだ多くの微妙な点があります）。



PS3そしてユーザーはどこにいますか？ しかし、まったくそうではありません！ 判明したように、同じ2950番目のスイッチでは、このネットワークセグメントに単一のユーザーはいません。 この問題に対応するのは、これらのスイッチだけです。 ポートを完全にブロックするのではなく、このVLANのみをブロックしますが、残りのVLANは中断することなく動作することに注意してください。 つまり 本当に問題はありませんでした。 しかし、なんという可能性！ しかし、ユーザーがいた場合...彼らは間違いなく、ネットワークはジンバブエ南部の天気と降雨量に依存していると言うでしょう。 あなたが見るように、私が説明したくないものを除いて、すべてが説明できます。



PS4これは目に見えない前線の分野での小さな勝利です...パナソニックのMFPを震えなしで見るのは難しいです...人生のためのアイデア、それを気にしてください！ =）