セキュリティ
欠陥のあるルーターがウィスコンシン大学のインターネット時刻サーバーを氾濫させる (2003年)
Flawed Routers Flood University of Wisconsin Internet Time Server (2003) (pages.cs.wisc.edu)
要約
2003年5月、ウィスコンシン大学マディソン校は、数百ギガビット毎秒に及ぶ大量のインターネットトラフィックに襲われました。調査の結果、これは悪意のあるDDoS攻撃ではなく、住宅用低価格インターネット製品の設計上の深刻な欠陥が原因であることが判明しました。この問題は、大学、製造元、インターネット標準、コミュニティが連携して解決策に取り組む多角的なアプローチを必要としています。
全文翻訳
欠陥のあるルーターがウィスコンシン大学のインターネット時刻サーバーを氾濫させる
Netgearは解決に向けて大学と協力
Dave Plonka、2003年8月21日 - ウィスコンシン大学マディソン校 $Date: 2006/07/19 15:20:28 $ plonka at doit dot wisc dot edu
概要
2003年5月、ウィスコンシン大学マディソン校は、キャンパスの公開ネットワーク時刻プロトコル(NTP)サーバー宛ての、継続的かつ大規模なインターネットインバウンドトラフィックの受信者となりました。フラッドトラフィックのレートは、毎秒数十万パケット、毎秒数百メガビットに達しました。その後、このフラッディングの発生源は、世界中の文字通り数十万の実際のインターネットホストであることが判明しました。しかし、悪意のある分散型サービス拒否(DDoS)攻撃として始まったのではなく、根本原因は実際には、住宅用を対象としたあるベンダーの低価格インターネット製品数十万個の設計における深刻な欠陥でした。これらの製品の予期せぬ動作は、UW-Madisonにとって今後数年間にわたる重大な運用上の問題となります。この文書には、これらの製品の深刻な設計上の欠陥に関する初期の公開情報が含まれています。さらに、大学、製品の製造元、関連するインターネット標準(RFC)、および公開インターネットサービスとユーザーコミュニティが関与する、解決に向けた私たちの継続的かつ多角的なアプローチについて論じます。
目次
欠陥のあるルーターがウィスコンシン大学のインターネット時刻サーバーを氾濫させる
Netgearは解決に向けて大学と協力
初期のフラッド
図1. 初期フラッド
フラッドのブロック
背景:シンプルなネットワーク時刻プロトコル(SNTP)
図2. SNTPリクエストパケット
図3. ユニキャストSNTP応答パケット
フラッドの継続
図4. フラッドの継続:1ヶ月後
調査
ソースネットワークへの連絡
図5. ピア機関へのEメール通知
背景情報の収集
Netgearコードの調査
Netgearへの連絡
図6. NetgearサポートへのEメール
図7. NetgearサポートからのEメール
レビュープロセス
欠陥のあるSNTPクライアント
Netgear顧客への影響
影響を受けるNetgear製品のコードアップグレード
図8. 影響を受けるNetgear製品
欠陥製品のカウント
図8a. Netgear SNTPクライアント(日別)
提案される修正
初期修正:「インスタント」コード
ネットワーク運用オプション:サービス提供か、切断か?
終局A:UW-Madison Netgear Anycast時刻サービス
図10. WiscNet BGPベースのAnycast時刻サービス
終局B:リクエストの抑制を試みる
図11. グローバルBGPルーティングテーブルを使用したリクエストの抑制
終局B:必要なIPリソース
図12. BGPベースの抑制に必要なIPリソース
インターネットコミュニティへの通知
インターネットのベストプラクティスとプロトコル標準の明確化
ステータス、2003年8月21日
図13. 最近のフラッド
後記
謝辞
分析ツール
参考文献/さらなる情報
よくある質問
このサービス拒否(意図せずとも)を引き起こしたことに対するNetgearの責任はどの程度ですか?
Netgearクライアントに応答を返す偽のサーバーを設置して、人々がアップグレードするように仕向けることを検討しましたか?
これらの製品の予想寿命はどれくらいですか?
図13の「シャークフィン」スパイクは、先週の電力網の障害(Blackout 2003)とその後の「ローリング」復旧と関係がありますか?
あなたのネットワークへの意図しないフラッディングを引き起こす欠陥に苦しむ、言及されたもの以外のデバイスはありますか?
この記事がSlashdottedされた影響は何でしたか?
なぜ従来のメーカーのリコール/欠陥解決策が可能性としてないのですか?
私は[ITプレス]に所属していますが、お話しする時間はありますか?
この話はプレスでどのように取り上げられましたか?
初期のフラッド
図1は、2003年5月13日から15日(火曜日から木曜日)の48時間における私たちのキャンパスへのインバウンドトラフィックのグラフです。
図1. 初期フラッド
グラフの前半は、私たちのキャンパスの典型的なトラフィックレベルを示しており、ピーク時のインバウンドパケットレートは約40,000パケット/秒でした。しかし、ご覧のとおり、現地時間の5月14日午前8時頃から、主に私たちのコモディティインターネットサービスプロバイダーであるWiscNetからの追加トラフィックにより、インバウンドパケット/秒レートが劇的に増加しました。午前9時40分頃には、この追加トラフィックが私たちの測定インフラストラクチャと一部のレガシーな学内ルーターに問題を引き起こし始めました。午前11時には、プロトコルとポート番号によってインバウンドフラッドトラフィックを特定しました。それは私たちの公開時刻サーバー宛てであり、私たちはWiscNetの境界ルーターで上流で着信トラフィックをブロックし、一時的に問題を緩和しました。これは、ネットワークオペレーターが、悪意のあるサービス拒否フラッド攻撃の反応として取る典型的な行動であり、私たちはこれがその一つであると仮定しました。
フラッドのブロック
問題のトラフィックは、76バイトのIPパケットでUDPポート番号123(NTP)宛てであったため、ネットワーク時刻プロトコル(NTP)クエリであるように見えました。しかし、これらのパケットには珍しい特徴がありました。多くのソースから来ているように見えましたが、すべて同じソースポート番号:23457を持っていました。したがって、私たちのルーターを設定して、私たちのNTPサーバーへのインバウンドクエリのサブセットのみをブロックし、他の正当なリクエストを通常通りサービスし続けることが可能でした。私たちは、ポート23457から送信され、問題のNTPサーバーのポート123(NTP)宛てのすべてのUDPトラフィックをブロックしました。(番号23457は、23456の次の番号として手作業で選ばれたように見えます。)この時点で、私たちはこれを「攻撃者」の単純さのせいにして、多くのランダムなソースアドレスを偽装していると仮定し、そのままにしておきました。「スクリプトキディ」が開始するフラッド攻撃はしばしば数時間で収まるため、フラッドも収まるだろうと推測しました。
背景:シンプルなネットワーク時刻プロトコル(SNTP)
RFC2030よりDave Millsによる言い換え:シンプルなネットワーク時刻プロトコル(SNTP)は、インターネット上のコンピュータークロックを同期するために使用されるネットワーク時刻プロトコル(NTP)の適応版です。これは、RFC-868で説明されているUDP/TIMEプロトコルの精度と信頼性の期待値を持つ、シンプルでステートレスなリモートプロシージャコール(RPC)システムです。SNTPは、完全なNTP実装のパフォーマンスが不要な場合に使用できます。SNTPはNTPと同じパケットフォーマットを使用することに注意してください。このため、SNTPクライアントは、完全なピアツーピアNTPプロトコルの複雑さを実装していなくても、NTPサーバーを利用できます。SNTPの会話は通常、次の手順に従います。時刻を知りたいクライアントは、SNTPリクエストを含むUDPパケットを、NTPサーバーのウェルノウンなNTPポート番号123に送信し、応答を待ちます。
図2. SNTPリクエストパケット
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LI | VN |Mode | Stratum | Poll | Precision |
| =0|= 1-4|= 3 | = 0 | = 0 | = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Delay |
| = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Dispersion |
| = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference Identifier |
| = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Reference Timestamp (64 bits) |
| | = 0 |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Originate Timestamp (64 bits) |
| | = 0 |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Receive Timestamp (64 bits) |
| | = 0 |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Transmit Timestamp (64 bits) |
| | = n | (ゼロ、またはクライアントが送信したリクエスト時刻)
| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
サーバーは、ウェルノウンなNTPポート番号123からSNTPクライアントへのSNTP応答を含むUDPパケットで応答します。
図3. ユニキャストSNTP応答パケット
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LI=| VN |Mode | Stratum | Poll | Precision |
|0-2|=req.|= 4 | = 1 - 14 | (無視