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

もう一度、わたしの最初のブログから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ビットを使えないかなと考えています。　　　お読みいただきありがとうございました。

VoIPやビデオのようなアプリケーションのネットワークを通じて、QoSno優先順位を決めようと、多くの企業がDiffServ ドメインを設定しています。サービスが標準にならない時、この会社はよくトラブル解決ルーティーンの一つとしてネットフローAnalysisに転向します。もし これらの頭文字が分からなければ、Tos, DSCP やネットフロー…. 「What the DiffServ」  に関する私の5つのパートのブログがあなたの助けになってくれるでしょう。

QoSサービスを話している時多くの人はDSCPと呼ばれるToSフィールドの6ビットの一部について話しています。下がその例です。

赤い四角でECTという文字と囲ってある上記のものに注意して下さい。これはDSCPを使用している時、残り8ビットToSフィールドを作っているExplicit Congestion Notification 2ビットです。このフィールドはそれらを実行するビジネスアプリケーションスタートとしてとても重要になってきてきます。

Wikipedia: “TCPは送信する情報を減らすために送信者に信号を送るTCPヘッダーの中で二つのフラッグを使用しています。これは下記で説明するECN-echo (ECE) とCongestion Window Reduced (CWR) ビットです。 とにかく上のスクリーンキャプチャーのDSCPバリューの一つに関して掘り下げてみましょう。そして約2ダースレポートから選択しましょう。

  BTW: 各レポートは追加レポートコンビネーションを持っています。

DSCP 0 ECT (00000010) フィルターが通ったか分かる上の赤い枠を参照して下さい。さらに勧めていき、DSCPトラフィックのしきい値を設定するためにフローAnalyticsを使いましょう。しきい値が私たちに教えてくれます。

上記野しきい値に追加のフィルターを使うことができます。

•異なるルータ・スイッチでのインタフェース 

• 特定のIPアドレスかサブネット（それらを除外していても）

• TCP フラッグ
• 追加DSCPバリューをプラス
• など

かなりクールです。Scrutinizerがもう一つのレベルにToS レポートするのを考えるのが好きです。多くの企業が今日のネットワークメディアアプリケーショントラブル解決のためにレポートの精度を要求しています。

 マルチメディアマルチキャストアプリケーション使用とbandwidth消費の上昇によって、それらのリンクやトラッフィクタイプを監視することはとても重要になってきています。

しかし、マルチキャストトラフィックがカウントされずに、ネットフローｖ5を実行させているかどうか知っていましたか。

ｖ5でルータはマルチキャストパケットが複製されている時間をカウントしませんし、ｖ5はegress監視をサポートしていないので複製後、ユニークアウトバウンドIPに記録もしません。

その結果多くのマルチキャストトラフィックを失うことになります。

これを解決するためにはネットフローｖ9とegress/ingress監視機能を使用する必要があります。

まず初めに、マルチキャストトラフィックをサポートするルータを有効にします。

有効になったら、マルチキャストパターンへのフロー監視を有効にする二つの設定がでてきます。

・       ip multicast netflow output-counters

・       ip multicast netflow rpf-failure

はじめのip multicast netflow output-countersコマンドはマルチキャストパケット転送とバイトの数を計上します。

２つめのip multicast netflow rpf-failureコマンドはRPFチェックを失敗したマルチキャストパケットのトラックを保存します。

この二つのコマンドを有効にしたら、次の二つのうちどちらか選択してマルチキャスト計上するためにどちらのインタフェースが良いかを特定することができます。

・       ip multicast netflow ingress

・       ip multicast netflow egress　　　　ふたつの違いはなんでしょう。

ip multicast netflow ingressアカウントは各パケットが何回複製されているかカウントするフローレコードを作成します。ip multicast netflow egressは外に出て行くインタフェースのための新しいレコードを作成します。

注意として、たくさんのマルチキャストトラフィックを作成するとして、egressコマンドを使用したらigressの監視とは対象的にたくさんのフローレコードを作成します。

あなたのネットフローへの試みの助けになりますように！

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

Scrutinizerのスケール
私は、先週政府のお客様と一緒に仕事をしました。結合した1736のインターフェイスで440ルータからネットフローを受信している、彼のScrutinizer上の重要部分を調べてみてください。あなたはたびたび、私がとても大きなボリュームのルータと比較的軽い集合体のネットフローボリュームを見ることに驚かれることでしょう。あなたがご覧になった通り、Scrutinizerは、休みなく音を立てて進んでいました。

見守るべきこと
200UDPを超えるネットフローのデータグラム（毎秒毎に約6,000フロー）を送っているルータは、データベースにとても大きなテーブルを作っています。個別のテーブルが大きくなり過ぎると、初期段階のレポートの際に、低速応答を引き起こす可能性があります。このことは、エッジルータに関するレポートが早い理由であり、そして、コア・ルータの報告では、更に数秒要する可能性があります。Scrutinizerは、フローボリュームのブレークダウンによって、この板ばさみ状態の手がかりとなります:

• コレクター毎
• リスニングポート毎（例えば、2055)
• ルータ毎

私たちは、同じ種類においてフローが抜け落ちることにも注意を払っています。有能なネットフローの報告ツールは、この情報もまた提供するはすです。このことについては、おってブログに乗せます。今は、上記のスクリーンキャプチャでのMFSN傾向に注意しておいてください。

概要
私は、一度、二つのcatalystスイッチだけを持つお客様と一組のScrutinizerのコピーを持つ200を超えるインターフェイスを見たことがあります。今や、私たち個有のライセンス供与により、払ったお金に見合うだけのものを得ます。Scrutinizerは、世界のいくつかの大きなネットワークと比例し、変化します。

Michael Patterson
Scrutinizer Product Manager

個人的に、私は、ほとんどの場合、YouTubeに発表しているいくつかの事柄を偏向しています。

このwebcastは、Scrutinizer　v6.Xを使用し、記録されていますが、もしあなた方の質問がnetwork traffic analysisのためのsFlowとNetFlow Collectionの違いに関するものだとしたら、その内容は、まだ非常に有益であると考えています。

ご自由にPlixerのYouTubeをご覧ください。

Brad Reeseの助言により私たちは、NetworkWorldに “NetFlowよりsFlowの方がよいということをよく見よ”と言う記事を公表しました。これは、技術的洞察にとても良いと思います。

TechWiseTVのJimmy-Ray事務長が一度Network Worldのブログに書かれていたコメントによると、「両方をインストールし、両方を弄り回して、データを抽出してみて、NetFlowをより好む理由は、

＊    より多くの設定オプションがある。

＊    よりフル装備の無料コレクターがある。

＊    他のapplication off systemにより,自分のものにすることができる詳細でエクスポート可能な記録がある。

＊    MPLSに関して、NetFlowが優れている

＊    NetFlowは、より進化すると思われる。sFlowは、いくつかバージョンがアップグレードしているが、マルチな設定オプションは、ない。

私は、誰もがJimmy-Ray事務長とRobb　Boydを好きだと思います。彼らの表現は素晴しいです。彼らは、Ciscoに偏見をもった数少ないベンダーですが、しかしその反面、Ciscoは、とても手強い相手であるということを覚えておいてください。

Enterasys の両サポート　

Enterasysの人々は、彼らのNシリーズのスウィッチでNetFlowを、CシリーズでsFlowを実行しています。両方の実行は、ハードウェアにて行われています。どちらがいいのでしょうか？最も公平な意見を彼らから得ることができるでしょう。

Jon　Mills

Marketing　＆　Public　Relation　Manager

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

私たちは、登場すると宣言し、今、実現しました。

最新のPlixer自身のNetFlow監視アプリケーション　を搭載している、新しいマイグレーション機能の効能によって、私たちは、いま、以前よりもスムーズにScrutinizer NetFlow & sFlow Analyzer v6 からv7 変換することができます。

現在、あなたは、この新しいツールのアシスタントによって、あなたのが去に使用したNetFlow データと複雑なフラッシュマップを正しく、新たにインストールすることができるでしょう。

このNetFlowデータのマイグレーション過程には、少し制限があることをご承知おきください。もしあなたがネットワークトラフィックの分析のために今なおScrutinizer version 6をお使いで、それらについてより詳しくお知りになりたい場合には、contact Plixer support　にご連絡をお願いいたします。また、もし、その他の新しい特徴や最新版で修正可能かどうかご興味があるようでしたら、Scrutinizer version 7.2 release notes.をご覧ください。

もしあなたが市場に出ているもっとも画期的な Windows NetFlow コレクターの稼動を心待ちにしているならば、 私たちのサポートチームへご連絡ください。私たちは、あなたがマイグレーション開始するのをお手伝いいたします！

Plixer Support
(207) 324-8805 ext: 4