TECHNICAL BRIEF

TECHNICAL BRIEF
ピアツーピア（Peer-to-Peer）アプリケーションに対する帯域管理
ブロードバンドの急激な拡大により、より多くのユーザがピアツーピア(P2P)プロトコルを使い始め、ソフトウェア、
マルチメディアファイル、アプリケーションなどの非常に大きなサイズのファイルを共有しています。この傾向に
より、急激に広範囲にわたってトラフィックフローが増加しています。
もしあなたが、BitTorrent、eMule、DirectConnect、Kazaa などの大量の帯域消費に頭を悩ませているなら、
TCP ポート番号によって帯域に制限をかけるような従来のレートシェーピングの技術は役に立たないでしょう。
パケット解析によるアプリケーションの特徴判別を利用した、より強力な技術が必要となってきます。
従来のレートシェーピング技術は、新種のアプリケーションをコントロールするには十分であると言えません。た
とえば、BitTorrent はブロードバンド接続を経由してユーザファイルを転送するデスクトップマシンによって使用
されるプロトコルです。しかし、BitTorrent を使用して大量のデータを送信するには、ブロードバンド運営者のネ
ットワークに大きな負荷をかけてしまいます。BitTorrent のトラフィックを禁止することは、すでにいくつかのブロ
ードバンド運営者によって行われており、残念なことに現在ユーザとブロードバンド運営者間における論争の中
心となっています。
この文書は BIG-IP® Local Traffic Manager（以下、BIG-IP LTM）の機能である iRules とレートシェーピングを
使用して、帯域の追加に無駄な費用を払うことなく、種別の異なるトラフィックを区別し、それぞれ個別にコント
ロールを行い、大きな性能向上をもたらす方法を説明するものです。
iRules とレートシェーピングの組み合わせによって、以下のことを実現します。
・クリティカルなアプリケーションが、優先度の低いトラフィックによって影響を受けないようにする。
・優先度の高いアプリケーションにより多くの帯域を与えることによって、最適なアプリケーション・パフォ
ーマンスを提供する。
・レートシェーピンングに特化した製品を排除し、トラフィック管理を単純化し集中管理する。
・帯域の借用、トラフィックのキューイングといった柔軟な帯域制限を提供する。
・あらゆるトラフィックの変化に基づき、レートクラスをコントロールする。
・特定の種別のアプリケーション・トラフィックを、許可された境界内だけにとどめておく。
ネットワーク・トラフィック管理の強化
ネットワーク・トラフィックをコントロールするには、全てにあてはまるような単純な手法をとるよりも、ネットワーク
管理者はよりアプリケーション志向の手法をとりネットワークのデータを伝送し配信する必要があります。
BitTorrent のトラフィックの場合においては、F5 ネットワークス（以下、F5）は次のような事項を提案します。
F5 Networks Japan K.K.
1
June, 2007
TECHNICAL BRIEF
ステップ１- パケットのインスペクションにより BitTorrent トラフィックを特定する
ステップ２- BitTorrent トラフィックを分離するルールを導入する
ステップ３- BitTorrent トラフィックにのみ適用するレートシェーピングのポリシーを割り当てる
BIG-IP LTM が提供する iRules とレートシェーピングの機能により、あらゆるトラフィック種別の帯域使用量をコ
ントロールします。Figure 1 では BitTorrent トラフィックの帯域使用量をどのようにレートシェーピングがコントロ
ールするかを示しています。
次のセクションではこの手順のそれぞれのステップについて記述し、BitTorrent アプリケーション・シグネチャを
特定するサンプルの iRule を提供しながら、おおよそあらゆる種別のトラフィックのコントロールを行う手法につ
いて記述します。
BitTorrent トラフィックの検知
近頃 AT&T Labs によって発表された資料によると、クライアント同士を流れるデータパケットのインスペクション
が、BitTorrent トラフィックを検知するには良い方法です。BitTorrent クライアント同士が通信を始める際、ハンド
シェイクの後、サイズが事前に指定されたメッセージの終わることのないストリームが流れていきます。
BitTorrent ハンドシェイク・メッセージのヘッダでは、次のようなフォーマットを使用しています。
先頭のバイトは、”19”という値の固定された文字となり、文字列の値は”BitTorrent protocol”となります。この共
通のヘッダに基づいて BitTorrent トラフィックを判別するには、次のシグネチャを使用できます。
F5 Networks Japan K.K.
2
June, 2007
TECHNICAL BRIEF
・ TCP ペイロードの先頭のバイトは、19(0x13)という文字である。
・次の 19 バイトは、”BitTorrent protocol”となる。
iRules を使用して、BitTorrent トラフィックを検知する
iRules は、ダイレクト、フィルタおよびパーシストしたいアプリケーション・トラフィックを判別して区別することに
使用できる、強力かつシンプルなツールです。iRules によって、アプリケーションのタイプ、カテゴリ、優先度に
基づいた最速のレスポンスのために、いつどこでトラフィックを送信するかというトラフィック操作の最適化を行
い、ビジネスの必要性に基づいてアプリケーションのスイッチングをカスタマイズできます。
次の例は、TCP コネクションが BitTorrent 通信を開始し、他の種類のトラフィックに影響を与えることなく管理を
行う際、トラフィックを拾い上げて判別するための iRule です。
when CLIENT_ACCEPTED {
TCP::collect 0 0 // クライアントTCPハンドシェイク接続の終了後、start data collection after client TCP handshake connection is
// completed
}
when CLIENT_DATA {
append payload [TCP::payload] // assign the collected contents in “payload”
if {[string length $payload] < 6} { // pass directly if collected contents is less
// than 6
TCP::release
return //end Rules operation, and not carry out subsequent statements
}
TCP::release //release the collected contents and go along subsequent work
binary scan $payload cc5 bt_size bt_protocol //analyze packet content obtained.
if {($bt_protocol == "66 105 116 84 111") && ($bt_size == 19)} {
log "Torrent traffic from [IP::remote_addr]" // add Log if it needs to record IP address
Rate Class p2p_bt //if pattern matches, put it in Rate Class ‘p2p_bt’ for processing
}
}
一度 TCP クライアントがアクセプトされると、BIG-IP LTM が TCP コネクションの最初のパケットのペイロードを
精査し、BitTorrent プロトコルのシグネチャとのマッチを探します。BIG-IP LTM のレートシェーピング機能を使用
すると、BitTorrent プロトコルのシグネチャを使用してトラフィックをコントロールし、定義したポリシーに合致する
レートクラスをアサインできます。この例では、もし TCP ペイロードが BitTorrent ペイロードであれば、レートクラ
F5 Networks Japan K.K.
3
June, 2007
TECHNICAL BRIEF
ス”p2p_bt”にアサインされるというものです。
また、ネットワーク上のほかの全てのトラフィックから BitTorrent トラフィックを区別して、個別の WAN 回線を通
過するように BitTorrent トラフィックをルーティングしたり、
BitTorrent トラフィックに割り当てる帯域の総計を制限したり、この文書に記述されている帯域管理のテクニック
を組み合わせて使用するなど、BitTorrent トラフィックに対して特殊な処理の実行もできます。
一度コネクションが確立されると、同じクライアントセッション内のその後に続く全てのパケットは、BIG-IP LTM
のセッション維持機能によって”p2p_bt”として指定されます。最初のペイロードパケットの先頭部分以外は、セ
ッションの全てのパケットを精査する必要がないため、パケット・インスペクションによるスイッチング機能の低下
を最小限にとどめます。
帯域コントロール
ブロードバンド運営者によるユーザトラフィックの管理に使用される、重要な帯域コントロール機能は以下のよう
なものになります。
・単一ユーザ（IP）に対して、ピアツーピア（P2P）アプリケーションの帯域を制限する
・選ばれたユーザグループに対して、P2P アプリケーションの帯域を制限する
・単一ユーザ（IP）に対して、特定のアプリケーション（BitTorrent、WWW、FTP など）の帯域を制限す
る。
・選ばれたユーザグループに対して、特定のアプリケーションの帯域を制限する。
・アプリケーション種別によって、送出トラフィックの帯域を制限する。
レートシェーピング機能により、BIG-IP LTM は以下のことを実現します。
・帯域の制限
・帯域のバーストのコントロール
・トラフィックの方向性による帯域の制限
BIG-IP LTM は、レートクラスごとに帯域をコントロールします。したがって、他のレートクラスに定義したルール
とは独立して、全てのレートシェーピングルールに準ずる単一のレートクラス内でトラフィックをコントロールする
ことができます。特定のトラフィック種別を判別して区別する iRule を帯域コントロール機能と共に使用すること
で、次のようにトラフィックをコントロールします。
・ベースのスループットレート
・帯域のバーストおよび借り出しが発生した際、トラフィックが許可される絶対的な制限
・帯域の借り出しが発生する前にベーストラフィックを超えてバーストが許可される最大バイト数
・レートクラスが適用されるトラフィックの方向性（全て、クライアント、サーバ）
・そのクラスが帯域を借用できるレートクラス
・レートクラスにおいてトラフィックのキューとデキューを行う方式
F5 Networks Japan K.K.
4
June, 2007
TECHNICAL BRIEF
また、単一あるいはグループの仮想サーバと Pool を通過するトラフィックフローに対して、それぞれのレートク
ラス内でポリシーを定義することができます。
次の例では、ベーシックレートクラスに対するインターフェイスとプロパティをあらわしています。
過度なクリティカルではないトラフィックに制限をかける
P2P 通信を許可しているような標準的なサービスプロバイダ環境は、複雑なコネクションを形成するネットワー
クを持っています。これらのコネクションは一人のエンドユーザから始まり、アクセスネットワークから他のアクセ
スネットワークへコアネットワークのバックボーンを経由し、異なる場所にいる目的のエンドユーザへ到達しま
す。
BitTorrent において使用されている、これらの P2P 接続において重要なトラフィックの合流地点は、メトロポリタ
ン・エリア・ネットワーク（MAN）ルータとサービスプロバイダのネットワーク・バックボーンを接続しているルータ
の間に存在します。トラフィック管理の観点において、これらの合流地点は極めて影響度の大きいトラフィック管
理地点です。何千ものユーザがここを通過して、P2P ファイル送信を行うためにサービスプロバイダのバックボ
ーンにアクセスしています。F5 が提供するトラフィックコントロールは、物理的にこの合流地点に位置する一つ
のネットワーク機器によって、ネットワーク運営者がこの合流地点上で何千ものユーザの管理を実現します。
この文書で参考とする顧客は、BIG-IP をブリッジとしてインラインに導入し、BitTorrent トラフィックを管理するた
めに MAN ルータとバックボーンルータの間に挟んでいます。
F5 Networks Japan K.K.
5
June, 2007
TECHNICAL BRIEF
この設定において、BIG-IP LTM は Giga ファイバインターフェイスをブリッジしています。MAN スイッチに直接接
続されているアップリンクポートは、BIG-IP LTM を経由してバックボーンルータに接続されており、そして
BIG-IP LTM はブリッジとしてスイッチングを行っています。二つのルータを直接つないでいるポートは、優先度
の低いバックアップとして設定されています。
都市をつなぐバックボーンへのアクセスはますます増加の傾向にあり、ブロードバンド管理者にとって、クリティ
カルではない過度なトラフィックを制限することは、国全体のトラフィック性能を劇的に向上させることになる。特
に BitTorrent のような検知が難しい特性を持つ特定のアプリケーションにおいて、何千ものユーザによる帯域
の消費を優先付けたり制限したりすることは、大変に価値のあることである。これらの合流地点の場所は一般
的に中央オフィスのような設備内に存在しており、トラフィックポリシーの定義に BIG-IP を使用すれば単一でわ
かりやすいグラフィカル・ユーザインターフェイスによって行うことができます。
F5 Networks Japan K.K.
6
June, 2007
TECHNICAL BRIEF
パフォーマンス向上の計算
ベースラインの決定
トラフィックポリシーを策定することは、まだチューニングされていないネットワークのベースラインとなるパフォ
ーマンスを計算し、文書化することから始まります。ネットワーク・パフォーマンスのベースラインを決定するに
は、各種のモニタリング・ソリューション（MRTG、Cacti、Cricket）が使用できます。
帯域消費ベースライン
特定種別のトラフィックを管理するポリシーを作成する前に、パフォーマンスのベースラインを決定するには、
BIG-IP LTM スイッチを通過するトラフィックの負荷を測定する必要があります。システムを通過する入力と出力
トラフィックの折れ線グラフを作成するために、シンプルなモニタリングを設定します。Figure 3 は、一般的なトラ
フィックパフォーマンス・モニターシステムによって収集されたトラフィックの表です。
このネットワーク合流地点を通過するトラフィックは、8 時から 24 時までが多く、この時間帯では 60MB/s を極め
て頻繁に超えていることがわかります。
特定アプリケーションの帯域消費
ネットワーク間のトラフィックのベースラインを決定することには、各種アプリケーション別のトラフィックのグラフ
化も含まれています。モニタリング・ソフトウェアを使い、一般的なインターネット・アプリケーションを解析し、ど
F5 Networks Japan K.K.
7
June, 2007
TECHNICAL BRIEF
の種別のアプリケーションがレートクラスを保持すればメリットがでるのかを決定します。Figure 4 にて、FTP と
WWW トラフィックのトラフィック消費が示されており、これらのアプリケーションが帯域幅の総計から考えると、
不釣合いな帯域消費であることが見て取れます。
多くの場合、ある種のアプリケーションを優先度を高く、あるいは低くしたいと考えるでしょう。たとえば、WWW
と FTP を優先度の低いトラフィックとして位置づけたいと考えることもあるかもしれません。しかし、これらのアプ
リケーションの優先度を変更するインパクトを理解するために、トラフィックポリシーを適用する前に、WWW と
FTP トラフィックの総計を見てください。
帯域管理の導入
ベースラインを策定すると、アプリケーション・パフォーマンスの向上のために、iRules とレートシェーピングを同
時に使用できます。次のセクションにおいては、以下のものに対して作成する帯域制限のポリシーについて記
述します。
・ P2P トラフィック
・ WWW アプリケーション
・複数の種類のアプリケーション
P2P トラフィックの帯域制限
一般的なトラフィック管理のルールは低い優先度であったり、コントロールされていないときには過度に帯域を
F5 Networks Japan K.K.
8
June, 2007
TECHNICAL BRIEF
消費してしまうような、特定アプリケーションの帯域を制限するものです。サービスプロバイダの場合において
は、複数のネットワークセグメントやユーザに対して P2P アプリケーションの帯域を制限することがトラフィックを
管理する上で、有効な手法となります。
F5 においては、以下のようにして、特定の IP ネットワークセグメント内で P2P トラフィックの帯域のみを制限し、
このトラフィックポリシーを適用するユーザを選定します。
・ iRules によって特定の IP ネットワーク内で P2P プロトコルを解析し、P2P アプリケーションを起動して
いるユーザを特定のレートクラスに割り当てる。
・ BIG-IP レートシェーピングによって、そのレートクラスに対する IP ネットワークセグメントの P2P アプリ
ケーションを制限するポリシーを定義する。
もし、ピーク時だけ P2P トラフィックの帯域の合計を制限したい場合にはどうなるでしょう。レートクラスを設定し
た時、Figure 5 にあるようにユーザのモニタリングシステム上にて、トラフィックの推移を観察することができま
す。
Figure5 では、ユーザの P2P ダウンロード速度が、17:46:12 以降から 18:23:01 を過ぎたあたりまで、ユーザ
P2P ダウンロード速度はユーザ一人当たり、1K/s に制限されています。この時間帯において、全てのユーザの
合計ダウンロードトラフィックは、コントロールされているネットワークセグメントにおいては、1M/s に制限されて
います。
F5 Networks Japan K.K.
9
June, 2007
TECHNICAL BRIEF
WWW アプリケーションの帯域制限
F5 では、WWW アプリケーションのみを帯域制限することができます。この種のトラフィックポリシーの効果を分
析するには、以下のことを行ってください。
・ WWW アプリケーションを特定する iRules を書き、HTTP トラフィックを別個のレートクラスに割り当てる
・レートシェーピングを使用して、レートクラスを作成し、HTTP トラフィックに対するユーザプリケーション
帯域を制限する
・ネットワークモニタリングシステム上でトラフィックの推移を観察する
Figure 6 では、19:22 から 19:46 の間、事前定義された範囲内にユーザの HTTP トラフィックがとどまっている
ことをあらわしています。
HTTP が制限されているとき、ページが開く速度は遅くなり、HTTP アプリケーションのパフォーマンスは減少し
ます。帯域制限が行われた後、19:46 に制限が取り除かれると、ユーザの HTTP トラフィックは、40MB/s 周辺
まで上昇します。テスト中、HTTP 以外のアプリケーションの性能を落とさないように、トラフィックポリシーを有
効にしている間は HTTP トラフィックを 18M/s に制限しています。
F5 Networks Japan K.K.
10
June, 2007
TECHNICAL BRIEF
複数アプリケーションの帯域制限
iRules とレートシェーピングを使用することにより、異なる種別のアプリケーションに対してトラフィックスループ
ットをカスタマイズできます。これを実現するため、それぞれのアプリケーションを特定する iRule を作成し、コン
トロールしたいアプリケーション毎にレートクラスを作成してください。そして適切な種別のトラフィックにレートク
ラスを割り当ててください。
次のテーブルは BIG-IP レートシェーピングの柔軟性と、トラフィックの管理やネットワークリソースの最適化に
無数のポリシーを定義することができることがわかるポリシーのリストです。
F5 Networks Japan K.K.
11
June, 2007
TECHNICAL BRIEF
Figure 7 では、四つの異なるトラフィックに対して使用された、四つの異なるポリシーの効果が示されています。
顧客における導入
ブロードバンドの困難に直面したある顧客が、MAN とバックボーンの間にアプリケーションごとに帯域の制限を
BIG-IP LTM に設定し、トラフィックの制限を管理するために別々のレートクラスを使用しました。
・ P2P トラフィックは 4MB/s
・他の全ての HTTP トラフィックは 20MB/s
・ eMule ユーザは 1MB/s(eMule トラフィックの見地は、BitTorrent トラフィックの検知方法とほぼ同じであ
り、この場合それぞれのペイロードパケットの最初の一文字は、0xE3 である。
(情報ソース：AT&T Labs-Research)
・他の全ての P2P トラフィックは 1MB/s
Figure 8 では、四つの異なる種別のトラフィックに BIG-IP LTM のポリシーを使用する前と後のトラフィックスル
ープットが示されています。
F5 Networks Japan K.K.
12
June, 2007
TECHNICAL BRIEF
F5 Networks Japan K.K.
13
June, 2007
TECHNICAL BRIEF
まとめ
F5 が提供するトラフィック管理製品、BIG-IP LTM によってサービスプロバイダは、ともすればコントロール不可
能なユーザ・アプリケーションのインパクトをたくみに管理できます。サービスプロバイダがネットワーク管理を
活性化するための、重要な機能は以下のとおりです。
・ iRules – 正確なコントロールのために、特定の種別のトラフィックを判別する。iRules によって BIG-IP
LTM はパケットのコンテンツを読み取ることができ、パケット内のトラフィックシグネチャを判別する。さ
らに、そのアプリケーション・シグネチャを持つ全てのトラフィックを特定のレートクラスへアサインでき
る。
・レートシェーピング- BIG-IP のレートシェーピングは、さまざまな手法により特定種別のトラフィックを管
理する能力と柔軟性を提供。レートシェーピングは、F5 の TMOS フルアプリケーション・プロキシ・アー
キテクチャ上で開発されたものであり、全ての方向性（インバウンドやアウトバンド）においてスループッ
トを管理する。レートシェーピングによって、異なる種別のトラフィックに対する帯域使用率を管理し、優
先付けをする個別のレートクラスに対して、異なるトラフィックポリシーを作成する。
この文書では、ブロードバンドの問題にフォーカスしたが、レートシェーピングは、以下のような機能を持ってい
ます。
・トラフィック制限、優先付け、借用
・高い優先度のアプリケーションやトラフィックに十分な帯域を保持する
・トラフィックとアプリケーションの制限を定義する
・これらのリソースがスパイクやバーストすることを許される範囲のコントロール
・帯域貸し出しのフルサポート
・トラフィック種別を優先付けするトラフィックキューイング（stochastic fair queue, FIFO ToS priority
queue）
・ L2 から L7 までの柔軟なトラフィッククラス分け
F5 ネットワークスについて
米国ワシントン州シアトルに本拠を置く F5 ネットワークスは、アプリケーション・デリバリ・ネットワーキングのグ
ローバル・リーダーです。アプリケーションの安全性・可用性・高速化を図り、企業が行ったアプリケーション投
資を最大限活用するソリューションを提供します。ネットワークにインテリジェンスや管理性を持たせ、アプリケ
ーションの負荷を下げることで、リソース消費量を抑えながら、アプリケーションの高速化を実現します。F5 の
拡張性に富んだアーキテクチャは、アプリケーションおよびネットワークの保護、アプリケーションの最適化や高
い信頼性、そのすべてを 1 台の共有プラットフォーム上に統合します。世界 10,000 社以上の企業やサービスプ
ロバイダが、アプリケーションの可用性を高める F5 に信頼を寄せています。
F5 ネットワークスに関する詳細は、www.f5.com をご覧ください。
F5 Networks Japan K.K.
14
June, 2007
TECHNICAL BRIEF
--追記
日本国内で最もよく使用されている P2P アプリケーションである、Winny を検知し、特定のレートクラスにアサイ
ンする iRule のサンプルを提供します。なお、Winny プロトコルの仕様については、ITpro サイト内の「Winny の
通信解読に挑戦！」
(http://itpro.nikkeibp.co.jp/article/COLUMN/20060511/237617/) を参考にさせていただきました。
Winny プロトコルのシグネチャは、以下の Winny2.0b7.1 におけるプロトコルの仕様をもとにして作成します。
・ TCP ハンドシェイク後、最初のペイロードパケットの TCP ペイロードは、固定長の 11 バイト
・第一パケットの TCP ペイロードにおいて、3 バイト目から 6 バイト目までが、4 バイトの RC4 暗号鍵に
なっている
・ 7 バイト目から 11 バイト目までが、5 バイトの通信ブロックになり、この通信ブロックを RC4 暗号鍵にて
復号化すると、16 進数にて「01 00 00 00 61」というデータになる
この内容のパケットを識別することによって、誤検知の確立は一兆分の一以下にとどまります。したがって、こ
の仕様を Winny プロトコルのシグネチャとして使用し、iRule を作成していきます。
iRules による暗号、復号
Winny プロトコルのように、暗号処理が施されているプロトコルであればなお、膨大なトラフィックの中からのプ
ロトコルの検知は複雑になります。Winny トラフィックの特定を行うのであれば、プロトコル内の暗号処理を復号
化する仕組みが必要となります。BIG-IP LTM の iRules には、すでに AES 暗号処理が組み込まれており、す
でに実際のサイトにおいて、HTTP Cookie の暗号化処理などに使用されています。しかし、Winny で使用され
ている RC4 暗号については v9.4 は現在未実装です。RC4 暗号の外部プログラムを呼び出すことについても
現在時点ではできません。したがって、F5 ネットワークスジャパンでは iRules の中に RC4 暗号解読のコードを
組み込みました。こういったことが可能となるのも、iRules の柔軟性ゆえです。
Winny 検知 iRules が与える影響
この iRule では、Winny の特性に従って、以下の処理を行っています。
1.
最初の TCP データパケットが 11 バイトであるかを確認
2.
#1 が真のとき最初の 2 バイトをスキップ
3.
3 バイト目から 7 バイト目の RC4 暗号鍵を取り出す
4.
8 バイト目から 11 バイト目のデータを、#3 で取り出した鍵によって復号化する
5.
十進法の並びで、8 バイト目から 11 バイト目が「1 0 0 0 97」と合致するかを確認
6.
Winny トラフィックを Drop する
ここで重要なことは、この複雑な復号化コードは、最初の TCP データパケットが 11 バイトのものに対してのみ実
行されるということです。それ以外のトラフィックについては、復号化コードを通らずそのまま通過します。したが
F5 Networks Japan K.K.
15
June, 2007
TECHNICAL BRIEF
って、機器全体のパフォーマンスに与える影響を最小限に食い止めることができます。
とはいえ、Winny 検知を行うには ISP に BIG-IP LTM を配置することが前提となり、その必要帯域を考慮すると
BIG-IP 8400 以上の製品を必要とするでしょう。BIG-IP 8400 以上の製品と BIG-IP ソフトウェア v9.4 以上の
組み合わせであれば、複数の CPU 処理を行うことができるので、復号化処理によるインパクトも減少します。
なお、この iRule では Winny トラフィックを Drop していますが、もちろん既述のとおり、特定の帯域を割り当てる
処理も一部の変更だけで可能です。
rule detect_winny {
when CLIENT_ACCEPTED {
# collect winny header
TCP::collect 11
}
when CLIENT_DATA timing on {
# first packet should be 11 bytes
if {[IP::stats pkts in] == 3 && [TCP::offset] == 11} {
### Initilize variables
binary scan [TCP::payload 11] Sc4c5 junk seed data
####
# RC4 KSA
###
set key(x) 0
set key(y) 0
set index1 0
set index2 0
# initilize key array (pre-KSA generation)
array set key { {state,0} {0} {state,1} {1} {state,2} {2} ¥
{state,3} {3} {state,4} {4} {state,5} {5} ¥
{state,6} {6} {state,7} {7} {state,8} {8} ¥
{state,9} {9} {state,10} {10} {state,11} {11} ¥
{state,12} {12} {state,13} {13} {state,14} {14} ¥
{state,15} {15} {state,16} {16} {state,17} {17} ¥
F5 Networks Japan K.K.
16
June, 2007
TECHNICAL BRIEF
{state,18} {18} {state,19} {19} {state,20} {20} ¥
{state,21} {21} {state,22} {22} {state,23} {23} ¥
{state,24} {24} {state,25} {25} {state,26} {26} ¥
{state,27} {27} {state,28} {28} {state,29} {29} ¥
{state,30} {30} {state,31} {31} {state,32} {32} ¥
{state,33} {33} {state,34} {34} {state,35} {35} ¥
{state,36} {36} {state,37} {37} {state,38} {38} ¥
{state,39} {39} {state,40} {40} {state,41} {41} ¥
{state,42} {42} {state,43} {43} {state,44} {44} ¥
{state,45} {45} {state,46} {46} {state,47} {47} ¥
{state,48} {48} {state,49} {49} {state,50} {50} ¥
{state,51} {51} {state,52} {52} {state,53} {53} ¥
{state,54} {54} {state,55} {55} {state,56} {56} ¥
{state,57} {57} {state,58} {58} {state,59} {59} ¥
{state,60} {60} {state,61} {61} {state,62} {62} ¥
{state,63} {63} {state,64} {64} {state,65} {65} ¥
{state,66} {66} {state,67} {67} {state,68} {68} ¥
{state,69} {69} {state,70} {70} {state,71} {71} ¥
{state,72} {72} {state,73} {73} {state,74} {74} ¥
{state,75} {75} {state,76} {76} {state,77} {77} ¥
{state,78} {78} {state,79} {79} {state,80} {80} ¥
{state,81} {81} {state,82} {82} {state,83} {83} ¥
{state,84} {84} {state,85} {85} {state,86} {86} ¥
{state,87} {87} {state,88} {88} {state,89} {89} ¥
{state,90} {90} {state,91} {91} {state,92} {92} ¥
{state,93} {93} {state,94} {94} {state,95} {95} ¥
{state,96} {96} {state,97} {97} {state,98} {98} ¥
{state,99} {99} {state,100} {100} {state,101} {101} ¥
{state,102} {102} {state,103} {103} {state,104} {104} ¥
{state,105} {105} {state,106} {106} {state,107} {107} ¥
{state,108} {108} {state,109} {109} {state,110} {110} ¥
{state,111} {111} {state,112} {112} {state,113} {113} ¥
{state,114} {114} {state,115} {115} {state,116} {116} ¥
{state,117} {117} {state,118} {118} {state,119} {119} ¥
{state,120} {120} {state,121} {121} {state,122} {122} ¥
{state,123} {123} {state,124} {124} {state,125} {125} ¥
{state,126} {126} {state,127} {127} {state,128} {128} ¥
F5 Networks Japan K.K.
17
June, 2007
TECHNICAL BRIEF
{state,129} {129} {state,130} {130} {state,131} {131} ¥
{state,132} {132} {state,133} {133} {state,134} {134} ¥
{state,135} {135} {state,136} {136} {state,137} {137} ¥
{state,138} {138} {state,139} {139} {state,140} {140} ¥
{state,141} {141} {state,142} {142} {state,143} {143} ¥
{state,144} {144} {state,145} {145} {state,146} {146} ¥
{state,147} {147} {state,148} {148} {state,149} {149} ¥
{state,150} {150} {state,151} {151} {state,152} {152} ¥
{state,153} {153} {state,154} {154} {state,155} {155} ¥
{state,156} {156} {state,157} {157} {state,158} {158} ¥
{state,159} {159} {state,160} {160} {state,161} {161} ¥
{state,162} {162} {state,163} {163} {state,164} {164} ¥
{state,165} {165} {state,166} {166} {state,167} {167} ¥
{state,168} {168} {state,169} {169} {state,170} {170} ¥
{state,171} {171} {state,172} {172} {state,173} {173} ¥
{state,174} {174} {state,175} {175} {state,176} {176} ¥
{state,177} {177} {state,178} {178} {state,179} {179} ¥
{state,180} {180} {state,181} {181} {state,182} {182} ¥
{state,183} {183} {state,184} {184} {state,185} {185} ¥
{state,186} {186} {state,187} {187} {state,188} {188} ¥
{state,189} {189} {state,190} {190} {state,191} {191} ¥
{state,192} {192} {state,193} {193} {state,194} {194} ¥
{state,195} {195} {state,196} {196} {state,197} {197} ¥
{state,198} {198} {state,199} {199} {state,200} {200} ¥
{state,201} {201} {state,202} {202} {state,203} {203} ¥
{state,204} {204} {state,205} {205} {state,206} {206} ¥
{state,207} {207} {state,208} {208} {state,209} {209} ¥
{state,210} {210} {state,211} {211} {state,212} {212} ¥
{state,213} {213} {state,214} {214} {state,215} {215} ¥
{state,216} {216} {state,217} {217} {state,218} {218} ¥
{state,219} {219} {state,220} {220} {state,221} {221} ¥
{state,222} {222} {state,223} {223} {state,224} {224} ¥
{state,225} {225} {state,226} {226} {state,227} {227} ¥
{state,228} {228} {state,229} {229} {state,230} {230} ¥
{state,231} {231} {state,232} {232} {state,233} {233} ¥
{state,234} {234} {state,235} {235} {state,236} {236} ¥
{state,237} {237} {state,238} {238} {state,239} {239} ¥
F5 Networks Japan K.K.
18
June, 2007
TECHNICAL BRIEF
{state,240} {240} {state,241} {241} {state,242} {242} ¥
{state,243} {243} {state,244} {244} {state,245} {245} ¥
{state,246} {246} {state,247} {247} {state,248} {248} ¥
{state,249} {249} {state,250} {250} {state,251} {251} ¥
{state,252} {252} {state,253} {253} {state,254} {254} ¥
{state,255} {255}
}
# begin KSA
for {set counter 0} {$counter < 256} {incr counter} {
set index2 [expr {([lindex $seed $index1] + $key(state,$counter) + $index2) % 256}]
set n $key(state,$counter)
set key(state,$counter) $key(state,$index2)
set key(state,$index2) $n
set index1 [expr {($index1 + 1) % 4}]
}
####
# RC4 PRGA
###
### Initilize variables
set unenc_data {}
# begin PRGA
for {set counter 0} {$counter < 5} {incr counter} {
set key(x) [expr {($key(x) + 1) % 256}]
set key(y) [expr {($key(state,$key(x)) + $key(y)) % 256}]
set n $key(state,$key(y))
set key(state,$key(y)) $key(state,$key(x))
set key(state,$key(x)) $n
set xorIndex [expr {($key(state,$key(x)) + $key(state,$key(y))) % 256}]
lappend unenc_data [expr {([lindex $data $counter] ^ $key(state,$xorIndex)) & 0xFF}]
}
set winny_signature { 1 0 0 0 97 }
if {$unenc_data == $winny_signature} {
log "Rejecting winny connection from [IP::client_addr] -> [IP::local_addr]"
F5 Networks Japan K.K.
19
June, 2007
TECHNICAL BRIEF
TCP::close
}
}
}
}
以上
F5 Networks Japan K.K.
20
June, 2007

Download Report