パート１から４を読んでおいてください。

もう一度、わたしの最初のブログからWireShark キャプチャを書きます。

※    図

上の図のDifferentiated Servicesフィールドの一部である２つのECN (Explicit Congestion Notification) ビットに注意してください。それらはブログ３で1998年に書かれたRFC2474からの“現在は使われていない”ビットです。“現在は使われていない”（普通は:) 二つのビットはRFC3168で1998年に定義されました。

二つのECNビットは混雑状態を示すためにホストかルータに使われています。

• ECN-Capable Transport (ECT) = 10 or 01
• Not-ECN-Capable Transport (Not-ECT) = 00
• Congestion Experienced (CE) = 11NOTE: Routers treat the ECT(0) and ECT(1) codepoints as equivalent. Senders are free to use either the ECT(0) or the ECT(1) codepoint to indicate ECT, on a packet-by-packet basis.

TCPとECNの操作

Wikipediaには書いてないのでいくつかの文を貼り付けておきます。

＜貼り付け開始＞

IPヘッダーのECNビットによると、TCPはTCPヘッダーで送信者が送る情報を減らすために送信者に信号を送るTCPヘッダーで二つのフラッグを使用します。これはECNエコーと下記で説明するCongestion Window Reduced (CWR)です。

TCPコネクションでのECNの使用はオプションです。ECNが使われるにはSYNとSYN－ACKセグメントの最適なオプションを取り入れることにより作られるコネクションで交する必要がある。ECNがTCPコネクションに関して取り決められると送信者はECN-capableコードポイントで全てのデータセグメントに印を付けます。これから起こる混在状態を検出するルータはECN-capableパケットに完全に落とすというよりもCongestion　Experienced コードポイントで印を付けることを選択します。

　Congestion　Experienced コードポイントでTCPセグメントを受信すると、TCPレシーバーがECNエコーフラッグセットでの確認を送信します。ECNエコービットはパッケトを落として混雑ウィンドウを減らす送信者へ混雑状況を提示します。Congestion Window Reduced コードポイントでセグメントを送ることで混雑表示を認識します。

＜貼り付けの終わり＞

写真を見ていると思います。もっと勉強したければ、ＲＦＣを読んで下さい。1981年まで保存されたビットを彼らが使っていて2001年にその使用方法を見つけたと想像してください。

それは先を読んでのことですか、それとも何？

よいビットは80年代初旬戻って保存されました。ＥＣＮエコーフラッグの設定をやめる時を決定するＴＣＰレシーバーを有効にするためにTCPヘッダー（ＣＷＲフラッグ）に二つ目の新しいフラッグを導入しました。

CWRフラッグはＴＣＰヘッダーのResearved フィールドのビット8に割り当てられます

上部はRFC793に定義されたTCPヘッダーのバイト14と13（ビットではない）の新しい定義です。2006年のRFC4774はECNに関して改善を試みていますが、このシリーズからの休暇が必要です。

最後に、ECNビットの表示をレポートしているScrutinizerｖ７のネットフローレポートはどのようにECNビットを表示するか下記を見てください。

ネットワークの混雑状況を示すためにネットフローのECNビットを使えないかなと考えています。　　　お読みいただきありがとうございました。

Scan の監視

インターネットでのSYN, XMAS, RST/ACK, FIN,等の監視は主に驚くべきものになります。あなたのインターネットコネクションの３アタックタイプのボリュームは頻繁に行われ（1時間ごと）本当のセキュリティ脅威よりももっと迷惑なものです。なぜ、私は彼らを‘迷惑なもの’と呼んでこのインターネットスキャンを減らすのでしょう。これらのコネクションのコンスタントな一斉攻撃を止めるのは不可能だからです。それらを追跡し止めるのは不可能ですが、あなたたちは6から10以上に匹敵するものを止めることはできます。ほとんどの会社において、それらをブロックすることでシンプルにスキャンを取り扱っています。

上記スキャンの監視は確実に内部で行われる必要があります。例えば内部にSYNスキャンを検出することは悪い物に感染する原因をつくります。悪いものとはソフトウェアダウンロードか内部でないマシン使用を通してネットワークの中に入ってきます。 おそらくパソコンが自宅で感染し会社に持ち込まれるのです。　これはどんなときでも起こります。

侵害されたインターネットホスト
その他のセキュリティー実行は内部ホストがインターネットで通信している監視に関わっています。もしbadリストに並んでいるホストでトラフィックを交換したら、イベントはアクションを引き起こします（通信ブロックなど）。なぜならその‘リスト’はインターネットに影響を及ぼします。インターネットルータでのみ行われるこのタイプのトラフィックやネットフローエクスポート、ｓフローエクスポートの準備費を調べたりするものです。I

False Positive Alarmsはどうなのか
自然なビジネスアプリケーションのせいでfalseアラームが全てのソリューションで起こります。しかし、すばらしくデザインされたセキュリティーシステムはセレクトルータ、スイッチとエンドシステムを可能にします。エンドシステムとは各異常検出アルゴリズムから排除されるためのものです。システムヘルプの期間は様々な活動を獲得し、システムの精密さをよりよく認識させ予期せぬトラフィックパターンに警告を与えてくれます。それぞれのアルゴリズムにルータとスイッチを選択してください：

選択されたアルゴリズムから特定のホストを排除します：

フローAnalyticsに検出された様々なトラフィック異常の部分的なリストはマニュアル１４ページにあります。このブログのパート2では特定の活動パターンのアラームと同様に通信とフロー活動について論じます。

Michael Patterson
Scrutinizer Product Manager
Follow Me on Twitter

Huawei-3Com Co., Ltd (H3C) は、2003年11月にHuawei と 3Com の共同事業として、運営を開始しました。 2006年に3Comは、HuaweiのH3Cの株を買い取ることによって、彼らは、正式に別々の方向性に進みました。H3Cは、中国にある3Comのように、Huawei が合意した非競合協定が終了するまで繁栄し続けていました。

しかしながら、NetStream パケットは、共同事業とともに進んでいました。NetStreamパケットは、多くのNetFlow analyzers に支えられて、容易に3型を作り、現在、NetFlow パケットの型v5/v8/v9に似た、　v5/v8/v9の3型があります。

しかし、NetStream パケットの解説情報のインターフェイスは、スタンダードMIB II を使用せずに、彼らの所有するインターフェースMIBを使用しています。

Huaweiのスイッチやルーターを使用しているトルコの顧客と密接に働いて、Huawei のインターフェイスインデックスにアクセスするコードを開発し、NetStreamパケットのための正しいインターフェイス情報を報告することができました。

もしあなたがHuaweiか、またはNetStream をサポートしている3Com のネットワーク機器を使用し、あなたのネットワークをモニタリングするツールのためにScrutinizerを使用したいとお考えなら、たならば、詳しくは、Plixer Technical Supportまでご連絡をお願いいたします。

- Joanne

先週、Plixerのネットワークトラフィック分析論のアップグレードされた発売により、これらの質問の答えは、非常に明確になりました。

Scrutinizer v7.3によって、Plixer International は、なぜNetFlowとsFlowトラフィック分析論において、リーダーなのかを表しています。NBARサポート、新しい報告フィルターの数、そして新しい分析ツールの数の全てによって、あなたのネットワーク上で何が起きているのか、より簡単に分析します。

不正な動きのアルゴリズムは、多くのホストを通過している点滅したポートをスキャンする人々を捕まえるために設計されています。

このことは、通常、攻撃に通用するサービスがあるかどうか確認するために、ホストは、ホストIPごとに、1回フローを送るということを意味します。

この図表は、同じサブネット上で、ひとつのホストが複数のホストへパケットを送っていることを表しています。このケースでは、80ポートのウェブサービスを監視しています。

ひとつのサーバーだけが応答しました。このことは、“インターネットの悪者”が1x.1.1.1で更なる攻撃をするであろうと言うことを示しています。

このアルゴリズムの閾値は、以下によって設定可能です:

Admin Tab -> Settings -> Flow Analytics

不正な動きの閾値は、固有の起点/機器の数が比率の中のTCPフローが侵害する必要のある送り先にセットされています。

不正な動きの比率は、起点アドレス、例えば、10：1あたりのフローごとのパケット比率です。1：1のような低い比率は、通常、不正な動きを表しています。

疑わしげに見えたトラフィックを偶然見つけることは、遠い過去のことになってしまいました。Scrutinizer v7.3 とフロー分析論によって、今、あなたは、ネットワーク上で警報を出すことが可能になります。

私は、Scrutinizer v7.3の全ての新しい特徴と報告を近日中にブログに書きますので、確認してみてください。

-Scott

多くの人はまだCiscoルータを買っていますが、購買者はルータスイッチをもっと安値で使えることに気付いています。HP Procurve に関する目玉商品のリストは実にすばらしいのですが、商品を市場に出す俊敏さはバグ修正が無料であっても、うまく実行されたということにはならない。

HP ProcurveでsFlowをセットアップ

Sフローを例に挙げてみましょう。4年前にはProcurveでsFlowをセットアップすることはかなり困難でした。このことは、コマンドライン経由でSNMPのOIDを設定し、10進法IPアドレス(192.168.0.XXX)を16進数(HEX)へ変換し、sFlowを送り続けられるようにタイマーを時々(1日に1回)リセットするバッチファイルを集めることに関係していました。

この件に関するＨＰからの電話サポートはよくありませんでした。最終的には私たちの助けにならない英語を話す人にいきつきました。私たちは結局、当時最高だったAlcatelから買ったスイッチを返品しました。私たちは数ヵ月後、顧客のためのProcurveに関するsFlowを見つけ、その過程を記録しました。電話越しにカスタマーセットアップをサポートする過程は4時間にもなりました。

現在のProcurve

私たちは最近すばらしい要素管理（リンク状態、ポート全域、管理状態）とsFlowセットアップのプロセスの改善を表示するGUIウェブとの契約のためにProcurveを好み始めました。私たちはまだ予備スイッチ同様Alcatelをもっています。両方ともsFlowを送るために設定されます。

私たちはネットフローｖ９をサポートするEnterasys N-series スイッチを現在は使用しています。

sFlowかNetFlowか

私たちにはsFlowエクスポートとNetFlowエクスポートをセットアップする専用のウェブサイトがあります。sFlowかNetFlowのどちらがよいのかに関する質問があれば、Network World かcontacting Enterasys, の“Is sFlow better than NetFlow” を読むことをお勧めします。それらは両方をサポートしているスイッチを生産しています。NetFlowとsFlowのトピックについての公平な意見は見つけるのに苦労します。

最近発売された彼らのNetFlow分析で、Plixerは、NBARの報告を含む、いくつかの新しい報告を紹介しています。Cisco’のNBAR テクノロジーは、ホストによって使用されたアプリケーションを分類するルータを通じて、トラフィックの移動を詳しくパケット診断をします。例えば、H323, Telnet, RTP, ExchangeとSkypeは、NetFlowで分類されて、エクスポートされています。

“適応性のあるNetFlowは、標準NetFlowによって報告された情報基準において、大いに拡張する可能性があると私たちは感じ、そして同時に感じていました。“とPlixer CTOのMarc Bilodeau は、言っています。“ScrutinizerのNetFlowとsFLow分析バージョン7.3で、Plixerは、適応性のあるNetFlowの導入のみならず、重要な利点の実行においても、NetFlowのその他のバージョンよりも群を抜いています。

“伝統的に、ソースとディスティネーションポートだけは、NetFlowv5とv9の中でエクスポートされていました（例えば、TCPポート80）。適応性のあるNetFlowは、NetFlowv9において、適切なファームウェアのアップデートによって、NBARをエクスポート可能にすることが改善されています。フロー分析論のあるScrutinizerは、NBARフローが使用しているほとんどのコンビネーションフィールドにおいて、閾値とアラームをセットすることが可能です。”

Plixerのネットワークトラフィック分析の最新バージョンは、NBARサポートに加え、フローボリューム、フロー接続、ホストボリューム、ペアボリュームなど他にも、いくつか多くのトラフィック監視報告タイプを加えています。

フロー分析論と呼ばれる、主力製品を強化するScrutinizerのネットワーク動作分析(NBA)は、例えば、進入違反、DNS違反、悪質な活動違反、不完全なフロー違反など、今後の悪質なトラフィックを探知するため、新しいアルゴリズムが加えられました。

価格と供給
Scrutinizer NetFlowとsFLow分析v7.3は、現在ダウンロード可能です。
Scrutinizerは、NetFlow分析ツールは完全に無料ですが、24時間以上保存された過去のデータと追加トラフィックの診断上の特徴、フロー分析モジュールは、$1,995から可能です。

Scrutinizerの製品価格に関する詳しい情報は、のページをご参照ください。

Jon Mills
Marketing & Public Relations Manager

Ciscoの競合企業はネットフローを有効にすることはルータやスイッチを自由に動かせると思ってほしいと考えています。

Ｓフローの創始者はこのことをあなたに信じてほしいと思っています。私たちはＳフローサポーターですが、事実をはっきりさせる機会を持ちたいと考えました。

一般的には、ほとんどの利用者はネットフローが有効になる時のルータのＣＰＵの微増（2～3%）しか見ていません。わたしはこのトピックをさらに調べることにしました。この下にネットフローがパフォーマンスに与える影響についてCiscoが皆様に伝えることを挙げます。（スライド74と75を見てください）。

・    ネットフローバージョン５を約15％（プラットフォームによって最大20％）有効にすることとＣＰＵ使用増加のエクスポート

・    ネットフローバージョン8を有効にすることは2から5％（複数集約のための6%の使用可能な数による？）ＣＰＵ利用を増加させます

・    ネットフローは cat6000 supervisor と 12000 Engine 3 Line Cardsにあるハードウェアで実行されます。

Ｓフロースイッチのように、Enterasys スイッチはＣＰＵに影響がないハードウェアを使用しているネットフローエクスポートを実行している。いくつかのベンダーはハードウェアパフォーマンスにネットフローが常に影響していると私たちに思ってほしいらしいが、それは真実ではない。

Micheal Patterson

Scrutinizer　製品　マネージャー

下記のウェブ放送、　Using the search utility　はどのくらい簡単にできるか示すいくつかのシンプルなステップで時間を限定しフローエクスポートデバイスを選択したIPアドレスやアプリケーションポートを表示します。

このウェブ放送にもあるように、一度攻撃ホストは排除されるとすぐ、あなたの管理者にメールをするScrutinizerｖ7にあるレポートを実行することができます。

もう一つの方法はネットフローとSフローコレクターで、これもあなたのネットワークトラフィック分析の助けとなるでしょう。

Joanne

Vyatta　press releaseによると、一番最初に開発された（今でも成し遂げたのはここのみ）オペレーティング　システムのVC6にアップグレードする必要があります。

彼らは同じハードウェアの両方のテクノロジーのサポートで私が頼りにしている初めの会社です。

通常ベンダーはハードウェアにｓフローを実行していますがVyattaはネットフローｖ5とv9サポートをしたのと同じようにソフトウェアにｓフローを実行しています。

こちらにVyatta　資料の５ページを抜粋したネットフローを有効にするコマンドがあります。

この資料は沢山の”show “コマンドも並べています。

Vyattaはよくやってくれました。　私たちはConfigure NetFlowページに彼らのハードウェアを載せてあります。