欠陥のあるルーターがウィスコンシン大学のインターネット時刻サーバーを氾濫させる (2003年)
Flawed Routers Flood University of Wisconsin Internet Time Server (2003) (pages.cs.wisc.edu)
要約
2003年5月、ウィスコンシン大学マディソン校は、数百ギガビット毎秒に及ぶ大量のインターネットトラフィックに襲われました。調査の結果、これは悪意のあるDDoS攻撃ではなく、住宅用低価格インターネット製品の設計上の深刻な欠陥が原因であることが判明しました。この問題は、大学、製造元、インターネット標準、コミュニティが連携して解決策に取り組む多角的なアプローチを必要としています。
全文翻訳
欠陥のあるルーターがウィスコンシン大学のインターネット時刻サーバーを氾濫させる
| 要約 |
| 2003年5月、ウィスコンシン大学マディソン校は、キャンパス内の公開ネットワーク時刻プロトコル（NTP）サーバーへの大規模なインバウンドインターネットトラフィックの継続的な氾濫の受信者であることが判明しました。氾濫トラフィックのレートは毎秒数百キロパケット、毎秒数百メガビットに達しました。その後、この氾濫の発生源は文字通り世界中の何十万もの実際のインターネットホストであることが判明しました。しかし、悪意のある分散型サービス拒否（DDoS）攻撃として始まったのではなく、根本原因は実際には、住宅用途を対象としたあるベンダーの何十万もの低コストインターネット製品の設計における深刻な欠陥でした。これらの製品の予期せぬ動作は、今後何年にもわたってウィスコンシン大学マディソン校に重大な運用上の問題をもたらします。この文書には、これらの製品の深刻な設計上の欠陥に関する最初の公開情報が含まれています。さらに、大学、製品メーカー、関連するインターネット標準（RFC）、および一般のインターネットサービスおよびユーザーコミュニティが関与する、解決に向けた継続的な多角的なアプローチについて論じます。 |
目次
欠陥のあるルーターがウィスコンシン大学のインターネット時刻サーバーを氾濫させる
Netgear、解決に向けて大学と協力
最初の氾濫
図1. 最初の氾濫
氾濫のブロック
背景：簡易ネットワーク時刻プロトコル（SNTP）
図2. SNTPリクエストパケット
図3. ユニキャストSNTP応答パケット
氾濫は続く
図4. 氾濫は続く：1ヶ月後
調査
送信元ネットワークへの連絡
図5. 提携機関へのメール通知
背景情報の収集
Netgearコードの検査
Netgearへの連絡
図6. Netgearサポートへのメール
図7. Netgearサポートからのメール
レビュープロセス
欠陥のあるSNTPクライアント
Netgear顧客への影響
影響を受けるNetgear製品のコードアップグレード
図8. 影響を受けるNetgear製品
欠陥製品の数
図8a. Netgear SNTPクライアント（日別）
提案される修正
最初の修正：「インスタント」コード
ネットワーク運用オプション：サービス提供か、切断か？
最終手段A：ウィスコンシン大学マディソン校 Netgear Anycast時刻サービス
図10. WiscNetのBGPベースAnycast時刻サービス
最終手段B：リクエストの抑制を試みる
図11. グローバルBGPルーティングテーブルを使用したリクエストの抑制
最終手段B：必要なIPリソース
図12. BGPベースの抑制に必要なIPリソース
インターネットコミュニティへの通知
インターネットのベストプラクティスとプロトコル標準の明確化
ステータス、2003年8月21日
図13. 最近の氾濫
後記
謝辞
分析ツール
参考文献 / 続きを読む
よくある質問
Netgearは、ネットワークへのサービス拒否（意図せずとも）を引き起こしたことに対して、どのような責任を負いますか？
Netgearクライアントに応答を返す偽のサーバーを設置し、ユーザーにアップグレードを促すことを検討しましたか？
これらの製品の予想寿命はどのくらいですか？
図13の「サメのひれ」のようなスパイクは、先週の電力網の障害（2003年ブラックアウト）とそれに続く「ローリング」復旧と関係がありますか？
言及されているもの以外に、ネットワークへの意図しない氾濫を引き起こす欠陥を持つデバイスはありますか？
この記事がSlashdotで取り上げられた影響は何でしたか？
従来のメーカーによるリコール/欠陥解決策が不可能なのはなぜですか？
私は[ITプレス]に所属していますが、お話しする時間はありますか？
この話はプレスでどのように取り上げられましたか？
最初の氾濫
図1は、2003年5月13日から15日（火曜日から木曜日）の48時間におけるキャンパスへのインバウンドトラフィックのグラフです。
グラフの前半は、キャンパスの通常のトラフィックレベルを示しており、ピーク時のパケットレートは約毎秒40,000パケットでした。しかし、ご覧のとおり、5月14日の午前8時頃（現地時間）から、主にコモディティインターネットサービスプロバイダーであるWiscNetからのインバウンドパケット/秒レートが劇的に増加しました。午前9時40分頃には、この追加トラフィックが測定インフラストラクチャと一部のレガシーキャンパス内ルーターに問題を引き起こし始めました。午前11時には、プロトコルとポート番号でインバウンド氾濫トラフィックを特定しました。それは公開時刻サーバー宛てであったため、WiscNetの境界ルーターで上流で受信トラフィックをブロックし、一時的に問題を緩和しました。これは、ネットワークオペレーターが悪意のあるサービス拒否氾濫攻撃に対応するためによく取る行動であり、我々もこれをその一つだと仮定しました。
氾濫のブロック
問題のトラフィックは、76バイトのIPパケットでUDPポート番号123（NTP）宛てであったため、ネットワーク時刻プロトコル（NTP）クエリであるように見えました。しかし、これらのパケットには珍しい特徴がありました。多くのソースから来ているように見えましたが、すべて同じソースポート番号：23457を持っていました。したがって、NTPサーバー宛てのポート123への特定のインバウンドクエリのサブセットのみをブロックするようにルーターを設定し、他の正当なリクエストを通常通りサービスし続けることが可能でした。我々は、ポート23457からソースされ、問題のNTPサーバーのポート123（NTP）宛てのすべてのUDPトラフィックをブロックしました。（数字の23457は、23456の次の数として、手作業で選ばれたようです。）この時点では、単に「攻撃者」のナイーブさのせいだと片付け、多くのランダムなソースアドレスを偽装していると仮定し、それ以上は追求せず、氾濫は「スクリプトキディ」が開始する氾濫攻撃がしばしばそうであるように、数時間以内に収まるだろうと推測しました。
背景：簡易ネットワーク時刻プロトコル（SNTP）
Dave MillsによるRFC2030からの抜粋：
簡易ネットワーク時刻プロトコル（SNTP）は、インターネット上のコンピュータクロックを同期するために使用されるネットワーク時刻プロトコル（NTP）の適応版です。これは、RFC-868で説明されているUDP/TIMEプロトコルと同等の精度と信頼性を期待できる、シンプルでステートレスなリモートプロシージャコール（RPC）システムです。SNTPは、完全なNTP実装の究極のパフォーマンスが必要ない場合に使用できます。
SNTPはNTPと同じパケットフォーマットを使用することに注意してください。これにより、SNTPクライアントは、完全なピアツーピアNTPプロトコルの複雑さを実装していなくても、NTPサーバーを利用できます。
SNTPの会話は通常、以下の手順に従います。
-
時刻を知りたいクライアントは、NTPサーバーのウェルノウンNTPポート番号123宛てのUDPパケット（SNTPリクエストを含む）を送信し、応答を待ちます。
図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 | | (some number: zero, or the time of request sent by client) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -
サーバーは、ウェルノウンNTPポート番号123からSNTPクライアントへのSNTP応答を含むUDPパケットで応答します。
図3. ユニキャストSNTP応答パケット
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |LI=| VN |Mode | Stratum | Poll | Precision | |0-2|=req.|= 4 | = 1 - 14 | (ignore) | (ignore) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Root Delay | | (ignore) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Root Dispersion | | (ignore) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reference Identifier | | (ignore) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Reference Timestamp (64 bits) | | (ignore) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Originate Timestamp (64 bits) | | (copied from request Transmit Timestamp) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Receive Timestamp (64 bits) | | (time request was received by server) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Transmit Timestamp (64 bits) | | (time of reply sent by server) | | = n | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -
応答を受信すると、クライアントはオプションで応答のOriginate Timestampを使用して応答を検証し、それが本当にこのクライアントのリクエストへの応答であることを確認しようとします。（応答が他のソースから偽装された場合、Originate Timestampに正しい値が含まれている可能性は低いです。）次に、「Transmit Timestamp」から値を取得し、推定されるエンドツーエンドの片道遅延を考慮してわずかに変更し、その結果をローカルクロックを設定するための現在時刻として使用します。
さて、私たちの物語に戻りましょう...
氾濫は続く
1ヶ月後、図4（問題のトラフィックに対する2003年6月初旬からのルーターの破棄パケットレートをプロット）が示すように、インバウンドNTPトラフィックの氾濫がさらに信じられないほど高いレートで続いていたことが判明しました。
図4では、次の点に注意してください：（1）レートにはわずかな日次変動があります（おそらく日中のユーザー行動によるもの）、（2）一般的に、レートは毎秒250,000パケット（および毎秒150メガビット）を超えて維持されており、（3）トラフィックレートは示されている期間中に増加しています。この図でのトラフィックレートの急激な低下は、氾濫が収まったためではなく、ネットワークメンテナンスと観測地点の上流での一時的なブロックによるものです。
この氾濫が継続し、レートが増加し続けていることがわかったため、さらに調査しました。一部のイングレスインターフェイスのブロックを注意深く解除することにより、サーバーへのトラフィックの小流を許可し、ペイロードを含むパケットをキャプチャしました。これらのパケットは、正当でよくフォーマットされた簡易ネットワーク時刻プロトコル（SNTP）バージョン1クエリであるように見えましたが、各クライアントホストからの理由は不明なほど高いレートでした。たとえば、あるトレース中、多くのクライアントが約1秒に1回のクエリを生成しました。これは、SNTPを使用するアプリケーションは、ホストが現在の時刻をある程度合理的に把握できるように、自身のクロックを比較的正確に設定することにのみ関心があるため、適切に構築されたSNTPクライアントにとっては非常に異常です。1秒に1回のクエリは馬鹿げており、NTPクライアントの動作としてはベストプラクティスから程遠いものです。
また、多くのIPアドレスがDNS名に解決可能であり、さらにIPアドレスはすべて、ブロックを解除した特定のイングレスインターフェイスの有効なソースであるように見えたことも発見しました。これは、ソースアドレスが偽装されたものではなく、非常に異常なSNTPクライアントを実行している実際のインターネットホストである可能性が非常に高いことを示唆していました。
残念ながら、クライアントソースホストのいずれも私たちのローカルキャンパスネットワーク内にはありませんでした。これは、調査を支援するためにリモートサイトのスタッフの協力を得る必要があることを意味しました。
調査
送信元ネットワークへの連絡
前述のパケットトレースからのトップトラフィック送信元IPアドレスの中から、私は、このようなインシデントに対応することに精通しているであろう才能あるネットワークスタッフを持つ他の大学の2つのクライアントホストを選択しました。
以下は、それらの機関のいずれかのインシデント対応チームに送信したメールです（ある程度の匿名性を維持するため、実際のSNTPクライアントのIPアドレスを10.42.69.10に置き換え、メールドメイン名も削除しました）。
図5. 提携機関へのメール通知
Date: Sat, 14 Jun 2003 04:34:11 -0500
From: Dave Plonka <plonka@localdomain>
To: abuse@[remotedomain]
Subject: sntp/ntp query flood from 10.42.69.10 to ntp1.cs.wisc.edu
[Organization] network abuse folks,
Since May 14, 2003 ~0800 central time, one of our campus' NTP
servers "ntp1.cs.wisc.edu" (128.105.39.11) has been the recipient of a
large-scale flood of Simple Network Time Protocol (SNTP) requests -
much more than it can service. This dramatic increase in inbound SNTP
requests inexplicably continues even now. To mitigate this flood we
are currently blocking over over 250K pkts/sec, exceeding 150
megabits/sec, and it has been continuing for weeks.
We are in the process of trying to determine if this flood is potentially
malicious or if it is an SNTP client misconfiguration or bug.
This traffic primarily consists of 76-byte UDP packets that are SNTP
version 1 queries from very many source host addresses directed to
ntp1.cs.wisc.edu port 123 (NTP). Unusually, these requests all have a
UDP source port of 23457. We have identified the host address
10.42.69.10 as just one of the sources. (However, there are at
least tens of thousands of source host addresses.)
I have attached a timestamped log of a packet capture from the
afternoon of June 13, 2003 (Friday) evidencing the SNTP query packets
from the host 10.42.69.10 at an unusually high rate of about one
per second. A packet decomposition (by tethereal) and hex dump of the
last packet (frame 998) in the log is included as well, which shows
them to be valid SNTP v1 queries as described in RFC 1361,
http://www.ietf.org/rfc/rfc1361.txt.
Could you assist us ASAP with this investigation by identifying that
host's operating system and what SNTP client code may be running on
that host? It would be interesting to know if a process on
10.42.69.10 currently has UDP port 23457 bound and what code that
process is running.
Thanks,
Dave
P.S. Our investigation so far has shown that Windows systems such as
2000 and XP have an "Internet Time" feature which is usually configured
to send SNTP requests to the Microsoft server "time.windows.com", but
this server can be changed. I have yet to identify any SNTP client
that regularly uses UDP port 23457 as its source port. (Note that
port number seems hand-picked, as the number subsequent to 23456.)
----------------------------------------------------------------------
1 2003-06-13 16:32:24.8808 10.42.69.10 -> 128.105.39.11 NTP NTP
7 2003-06-13 16:32:25.9611 10.42.69.10 -> 128.105.39.11 NTP NTP
14 2003-06-13 16:32:27.0412 10.42.69.10 -> 128.105.39.11 NTP NTP
21 2003-06-13 16:32:28.1215 10.42.69.10 -> 128.105.39.11 NTP NTP
27 2003-06-13 16:32:29.2020 10.42.69.10 -> 128.105.39.11 NTP NTP
33 2003-06-13 16:32:30.2821 10.42.69.10 -> 128.105.39.11 NTP NTP
39 2003-06-13 16:32:31.3624 10.42.69.10 -> 128.105.39.11 NTP NTP
45 2003-06-13 16:32:32.4427 10.42.69.10 -> 128.105.39.11 NTP NTP
51 2003-06-13 16:32:33.5232 10.42.69.10 -> 128.105.39.11 NTP NTP
56 2003-06-13 16:32:34.6049 10.42.69.10 -> 128.105.39.11 NTP NTP
68 2003-06-13 16:32:36.7638 10.42.69.10 -> 128.105.39.11 NTP NTP
74 2003-06-13 16:32:37.8441 10.42.69.10 -> 128.105.39.11 NTP NTP
78 2003-06-13 16:32:38.9242 10.42.69.10 -> 128.105.39.11 NTP NTP
84 2003-06-13 16:32:40.0050 10.42.69.10 -> 128.105.39.11 NTP NTP
90 2003-06-13 16:32:41.0846 10.42.69.10 -> 128.105.39.11 NTP NTP
96 2003-06-13 16:32:42.1647 10.42.69.10 -> 128.105.39.11 NTP NTP
<snip>
998 2003-06-13 16:35:13.3789 10.42.69.10 -> 128.105.39.11 NTP NTP
Frame 998 (90 on wire, 90 captured)
Arrival Time: Jun 13, 2003 16:35:13.378978000
Time delta from previous packet: 0.524605000 seconds
Time relative to first packet: 168.498125000 seconds
Frame Number: 998
Packet Length: 90 bytes
Capture Length: 90 bytes
Ethernet II
Destination: 00:0a:41:db:58:00 (00:0a:41:db:58:00)
Source: 00:0a:8b:bf:70:7c (00:0a:8b:bf:70:7c)
Type: IP (0x0800)
Internet Protocol, Src Addr: 10.42.69.10 (10.42.69.10), Dst Addr: 128.105.39.11 (128.105.39.11)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 76
Identification: 0x2cc7
Flags: 0x00
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 243
Protocol: UDP (0x11)
Header checksum: 0xb335 (correct)
Source: 10.42.69.10 (10.42.69.10)
Destination: 128.105.39.11 (128.105.39.11)
User Datagram Protocol, Src Port: 23457 (23457), Dst Port: 123 (123)
Source port: 23457 (23457)
Destination port: 123 (123)
Length: 56
Checksum: 0xb0bd (correct)
Network Time Protocol
Flags: 0x0b
00.. .... = Leap Indicator: no warning (0)
..00 1... = Version number: reserved (1)
.... .011 = Mode: client (3)
Peer Clock Stratum: unspecified or unavailable (0)
Peer Polling Interval: invalid (0)
Peer Clock Precision: 1.000000 sec
Root Delay: 0.0000 sec
Clock Dispersion: 0.0000 sec
Reference Clock ID: Unindentified reference source ''
Reference Clock Update Time: NULL
Originate Time Stamp: NULL
Receive Time Stamp: NULL
Transmit Time Stamp: NULL
0000 00 0a 41 db 58 00 00 0a 8b bf 70 7c 08 00 45 00
0010 00 4c 2c c7 00 00 f3 11 b3 35 0a 2a 45 0a 80 69
0020 27 0b 5b a1 00 7b 00 38 b0 bd 0b 00 00 00 00 00
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0050 00 00 00 00 00 00 00 00 00 00
私が報告した異常なSNTPクエリの送信元である2つのホストを調査するために、2つの大学のネットワークスタッフが調査を行いました。どちらも、トラフィックの送信元がNetgearブランドのルーターであると報告しました。（具体的には、1つはMR814モデルとして特定されました。）
これで少し理解が進みました。同じソースポート番号を使用している多くの送信元ホストは、ソースポート番号（23457）がハードコードされた組み込みSNTPクライアントによって説明できる可能性があります。
背景情報の収集
Netgear製品の評価されているNTPサポートに関する背景情報をウェブで検索していたところ、以下の引用を見つけました（ICSA Labs Firewall Lab Report on the NETGEAR FR114Pより）：
Netgear FR114Pは、内部バッテリーとクロックを持たないため、現在の年月日を設定するために個別のNTPベースのタイムソースに依存していました。この製品は、パブリックインターネットからアクセス可能な特定のNTPタイムソースがハードコードされています。製品を特定のNTPサーバーにアクセスするように設定した後でも、製品はハードコードされたNTPタイムソースにアクセスし続け、同時に指定されたタイムソースにもアクセスしていました。
結論
候補ファイアウォール製品は、ベースラインモジュールおよびレジデンシャルモジュール内のすべての基準要素を満たしており、したがってICSA Labs Firewall Certificationを取得しています。
Netgearは、FR114Pにはここで説明されている特定のSNTPの欠陥が含まれていないと報告しています。 私はそれを興味深いと感じました。なぜなら、ウェブ上で見つけたNTP関連の欠陥に関する情報はそれだけだったからです。
Netgearコードの検査
送信元SNTPクエリの氾濫がNetgear Platinumファミリー製品であるという仮説を検証し、この問題をベンダーに対して適切に特徴付けるために、多くのNetgear製品のコードがダウンロードされ、調査されました。
Unixの「strings」コマンドを使用するだけで、Netgearコードにはポート番号としてマジックナンバー23457が含まれていることが確認できました。
$ strings RP614_4_12.bin |grep 23457 on 23457 port. $ strings MR814_4_11.bin |grep 23457 on 23457 port.
同様の手法を使用して、RP614_4_12.binにASCII文字列として次のIPアドレスが埋め込まれていることがわかりました。
128.105.39.11 # ntp1.cs.wisc.edu (別名 "caesar.cs.wisc.edu") 192.168.1.101 66.37.215.43 12.234.94.14 192.168.0.1
（注：DNS名のコメントは明確化のために追加しました。これらの文字列はバイナリファイルには含まれていませんでした。）
同様に、これらのIPアドレスはMR814_4_11.binに埋め込まれていました。
0.0.0.0 12.234.94.142 66.37.215.43 192.168.0.102 128.105.39.11 # ntp1.cs.wisc.edu (別名 "caesar.cs.wisc.edu") 192.168.0.1 192.168.1.101
（グローバルにルーティング可能な3つのIPアドレスのうち、128.105.39.11のみがNTPサーバーとして使用されているようです。他の1つは、「dyndns.org」ダイナミックDNSネームサービスによって以前使用されていたIPアドレスでした。Netgearは、残りの埋め込まれたグローバルにルーティング可能なIPアドレスはもはや使用されておらず、開発者によるデバッグの残骸であるデッドコードの一部であると私たちに報告しました。）
Netgearへの連絡
2003年6月16日、Netgearサポートに以下のメールメッセージを送信しました。この問題は通常のカスタマーサポートの問い合わせよりも重要であるため、Netgearの従業員数名にも直接送信しました（彼らのメールアドレスはウェブから収集しました）。彼らに、適切なエンジニアリング担当者に連絡してもらうか、誰かに連絡してもらうように依頼しました。メールには「Return-Receipt-To」ヘッダーを含め、彼らのMail-eXchangerからすべて正常に配信されたという通知を受け取りました。そのメッセージの一部を以下に示します。
現時点では、この継続的なインシデントに関する完全なレポート、氾濫を証明するトラフィック測定統計、およびその根本原因の分析が公開準備完了となっています。
NETGEARが対話を開始したいのであれば、NETGEARの責任者から直ちに連絡を受ける必要があります。即時の解決策は期待していません。実際、完全な解決策はウィスコンシン大学マディソン校の関与なしには不可能だと確信しています。
6月19日（木曜日）、Netgearのサポートディレクターからボイスメールを受け取りました。彼は、コードに何らかの不具合があることを特定したことを確認しました。その後すぐに、彼とメールやボイスメールでのやり取りを開始しました。初期連絡が確立された後、以下のレビュープロセスに進みました。
Netgearのサポート組織は完全に無反応でした。奇妙なことに、6月16日に問題報告を送信してから23日後に、Netgearのメールベースのカスタマーサポートシステムから以下のメールメッセージを受け取りました。
図7. Netgearサポートからのメール
Date: Wed, 09 Jul 2003 09:35:46 +1000
From: support@esupport.netgear.com
Subject: RE:NETGEAR products abusing University of Wisconsin time server [#111678]
To: plonka@localdomain
Thank you for your email. We apologize for the delay in responding.
Due to an unexpected increase in email volume we have been unable to
respond in a timely manner. Your issue may have already been
resolved. Please reply to this email if you still require assistance
and we will respond as quickly as we can. If your issues is resolved
you do not need to reply and we will consider the case closed.
Again thank you for your patience and understanding.
Please help us serve you better by clicking here
mailto:support@netgear.com?subject=Feedback_us if you would like to
provide any other valuable feedback. (Note: this feedback is not sent
to an agent so you will not receive a reply.)
レビュープロセス
Netgearとの対話を開始 shortly after、解決策を議論するためのレビューチームの結成を提案しました。Netgearは同意し、約15名のメンバーからなるレビューチームが結成されました。メンバーは以下の3つの分野からそれぞれ約3分の1でした。
-
Netgearの従業員
-
大学の従業員
-
各分野の独立した専門家：
-
地域インターネットレジストリ
-
インターネット測定研究
-
ネットワーク時刻プロトコル
独立した専門家は、状況の詳細を事前に開示することなく参加することに同意しました。
レビュープロセス中に、いくつかの行動項目と方向性が開発されました。これらには以下が含まれます。
- SNTPクライアントの修正
- ネットワーク運用オプションの提案
- インターネットコミュニティへの通知
- インターネットのベストプラクティスとプロトコル標準の明確化
欠陥のあるSNTPクライアント
ウィスコンシン大学マディソン校に影響を与えている製品における欠陥のあるNetgear SNTPクライアント実装は、以下の特徴を持っています。
-
NTPサーバー128.104.39.11（ntp1.cs.wisc.edu）のIPアドレスがハードコードされています。
-
固定UDPソースポート番号23457を使用します。
これは、ウィスコンシン大学マディソン校がNetgearクライアントを識別し、カウントすることを可能にしたため、非常に有利でした。しかし、一部のNetgear製品の上流にあるネットワークアドレスポート変換（NAPT、またはNAT/PAT）の広範な使用により、SNTPリクエストソースポート番号は、リクエストパケットが宛先に到達する前に書き換えられることがあります。ネットワークオペレーターへの注意：ポート23457を含むUDPトラフィックや、当社のNTPサーバーのIPアドレス128.104.39.11を含むトラフィックをブロックしないでください。ご協力には感謝しますが、この問題の最善の解決策を妨げる可能性があります。
-
レスポンスを受信するまで1秒間隔でポーリングし、その後、製品モデルとファームウェアバージョンに応じて、1分、10分、2時間、または24時間のいずれかの長いポーリング間隔を使用します。
Netgear顧客への影響
現時点（2003年8月）で、大学はNetgearの時刻リクエストに対応するために最善を尽くしています。そのため、影響を受ける製品のユーザーは、この欠陥による問題に通常気づかないはずです。さらに、これまでの経験に基づくと、顧客のごく一部しかこれらの製品の時刻関連機能（ログ記録、ポリシー設定、電子メール通知など）を認識していないようです。
並行して、Netgearは前述の問題を示さないファームウェアを製造しており、開発を続けています。顧客は、Netgearのサポートサイトからダウンロード可能な新しいファームウェアバージョンにアップグレードできます。現時点（2003年8月）で、RP614v2、RP614、DG814、およびMR814モデルで利用可能な最新バージョンのファームウェアは、ウィスコンシン大学マディソン校のタイムサービスを使用せず、ポーリングも頻繁に行いません。
影響を受けるNetgear製品のコードアップグレード
Netgearから提供または確認された情報に基づき、以下の製品にこれらのSNTP設計上の欠陥が含まれていました。該当する場合は、修正が含まれる最も早いコードバージョンをラベル付けしました。
欠陥製品の数
1日で当社の時刻サーバーにクエリを送信したユニークなNetgearソースを500,000以上カウントしました。この測定値は、ソースIPアドレスとポート番号を変更するネットワークアドレスポート変換（NAPT）や、サービスが使用されていないときに一部のブロードバンド住宅サービスが顧客のリンクを切断することから、実際の数よりも少ない可能性があります。
2003年6月30日現在、Netgearは影響を受けた製品の総数707,147台を製造したと報告しました。簡単な計算：700,000個の不正なSNTPクライアントがあり、それぞれが毎秒1回のSNTPリクエストを当社の時刻サーバーに生成できるとすると、最悪の場合の総レートは約700,000パケット/秒になります。各SNTPパケットは76バイトのサイズなので、これはトラフィックで426メガビット/秒にもなります。
図8aは、ウィスコンシン大学マディソン校のネットワーク上のルーターによって観測された、NTP NetgearクライアントのユニークIPアドレスの1日あたりの実際の数を示しています。理論的には、クライアントのDHCPサーバーがクライアントIPアドレスを頻繁に変更する場合、この方法でクライアントをカウントすると数が過大評価される可能性があります。しかし、製造された製品の数に基づくと、これはかなり正確であると思われます。
提案される修正
レビュープロセス中に、SNTPクライアントのいくつかの改善が提案されました。これらには、SNTP実装が以下を行うべきということが含まれます。
- ポーリング間隔は、64秒から1024秒またはそれ以上の範囲内であるべきです。
- ローカルNTPサーバーまたはマルチキャストが利用可能な場合は、オペレーターによって設定されるか、RFC 2132のセクション8.3で定義されているDHCP「ネットワーク時刻プロトコルサーバーオプション」のような検出メカニズムによって検出されるように使用すべきです。
- NTPサーバーからの応答を受信できなかった場合に、ポーリング間隔の指数関数的バックオフ（前述の範囲内）を実行してもよいです。
- NTPサーバーからの応答を受信できなかった場合に、より短いポーリング間隔を使用してはなりません。
- クエリの有効/無効、およびクエリ可能な候補タイムサーバーに関する動作をオペレーターが設定できるようにする必要があります。
- 候補サーバーのIPアドレスを決定するためにDNSを使用し、NTPサーバーのゾーン管理者がクライアントの動作に影響を与えられるようにすべきです。
- 各ポーリング/クエリの前にDNSを介してサーバーIPアドレスを解決し、関連するDNSエントリのTime-To-Live値を尊重すべきです。
- 有効な
kiss-of-deathパケットを受信した場合、その状態を報告し、再初期化まで問題のサーバーへのクエリを中止することにより、既存のNTPアクセス制御メカニズムをサポートすべきです。 - 実装定義の固定ソースポート番号を使用してもよいです。
これらのうちいくつかは最初の修正で実装されましたが、他のいくつかはまだ検討中です。これらの提案が、今後のSNTP標準化の取り組みで評価されることを願っています。
最初の修正：「インスタント」コード
レビュープロセス中に、Netgearが大学に問題を引き起こしている欠陥について最初に通知する前に、RP614v2製品のSNTP関連のコード変更をすでに開発していたことがわかりました。
RP614v2のファームウェアv5.13 RC7に関して、Netgearはこの新しいコードを7月10日に私に提供しました。私のテストでは、変更されたSNTPクライアントは、彼らが説明したように、以下の特徴を持っていました。
- DNSサーバーが設定されている（またはDHCP経由で学習された）場合にのみ、SNTPクエリを生成するようになりました。
- コードは、応答がない場合に名前を交互に使用しながら、「time-a.netgear.com」と「time-b.netgear.com」のDNSクエリを10分間隔で実行します。CNAMEまたは複数のAレコードを持つ応答もサポートしていることを確認しました。
- DNS解決に成功した後、解決されたIPアドレスにNTPクエリを送信し、応答を待ちます。10分以内に応答がない場合、名前を再度解決し、再クエリします。5回の再試行後に諦めるようです。
- Webインターフェイスを介して設定変更が適用されるたびに、デバイスのクロックがゼロになり、NTPサーバーが再解決され、その後クエリが実行されます。
しかし、以下のバグも見つかりました。
- このコードのSNTPクライアントは、NTP応答パケットを検証しないようです。フラグが間違って設定されている場合（たとえば、サーバー応答ではなく別のクライアントクエリを示している場合）でも、ポート23457への任意のUDPパケットを有効な応答として受け入れます。
- SNTPクライアントが応答を待っている間（time-aまたはtime-bをクエリした後）、UDPパケットの送信元IPアドレスがクエリしたタイムサーバーのものでなくても、任意のUDP応答パケットを受け入れるようです。
このコードは、2003年7月11日頃にRP614v2のNetgearウェブサイトでダウンロード可能になりました。
NetgearはSNTPクライアントの改善を継続的に開発しており、レビューチームによって設計が検証されています。
ネットワーク運用オプション：サービス提供か、切断か？
これらの欠陥のあるデバイスは容易に再設定できません。Netgearとウィスコンシン大学マディソン校の両方の代表者は、不正なNetgear時刻リクエストに対処するために、Netgearの顧客が新しいファームウェア（最初のものは7月にリリースされました）にアップグレードすることに依存するのは実行可能なオプションではないと考えています。
私たちのレビューチームは、不正なNetgear時刻リクエストをどのように処理するかについて、いくつかの可能なオプションを検討しました。ここではすべての詳細を議論しませんが、私たちが焦点を当てた2つの主要な最終手段を以下に概説します。
最終手段A：ウィスコンシン大学マディソン校 Netgear Anycast時刻サービス
このオプションでは、WiscNetの境界に高信頼性、冗長なNTPサーバーを配置し、BGP anycastを使用して128.104.39.11宛てのインバウンドリクエストをそれらにルーティングします。（Anycastは、UDPに基づいたDNSやNTPのようなステートレスRPCサービスへのトラフィックをルーティングするためによく使用される技術です。）このオプションを実装するには、WiscNet内の3つの場所（ウィスコンシン大学マディソン校、ウィスコンシン大学ミルウォーキー校、ウィスコンシン大学オード・クレア校）にそれぞれラックマウントNTPサーバーのペアを設置することが含まれるでしょう。これらは3つの現在の境界インターネット交換ポイントに最も近く、したがってグローバルインターネットへの接続信頼性に対して最も多様なパスを提供します。
この構成の1つの明確な利点は、ウィスコンシン大学マディソン校が貴重なIPv4アドレス割り当てを可能な限り管理できることです。このBGP anycastデプロイメントはWiscNet内（単一の/32ホストアドレスルートを尊重します）にのみ存在するため、このオプションはウィスコンシン大学マディソン校のIPアドレス空間の使用を最小限に抑えます。Netgear時刻リクエストが向けられたアドレスのみです。
最終手段Aにはリスクがあります。サーバーの応答が要求クライアントホストに到達するかどうかは、大学の制御下には完全にはありません。したがって、ある程度の氾濫は続く可能性が高いです。サーバー障害以外の多くの理由で、SNTPクライアントが応答を受信できず、サーバーにリクエストを氾濫させ続けるエンドツーエンドパスの障害が発生する可能性があります。これらには、非対称ルーティングの問題、ファイアウォールポリシー、およびクライアントとサーバー間の任意のリンクに影響を与える災害が含まれます。実際、当社の時刻サーバーがすべてのNetgear SNTPリクエストに律儀に応答している間でも、数百のクライアントが氾濫し続けているのを定期的に観測しています。これらの「ゾンビ」は応答を受信していないようです。
複数のサーバーが同時にインターネットから孤立する可能性を制限するために、AS112プロジェクトが行っているような、さらに地理的に多様なデプロイメント場所を検討することもできます。これは、RFC1918関連のクエリによってインターネットのルートネームサーバーに引き起こされる損害を効果的に軽減します。
図10は、このサービスがどのように機能するかを示す図です。ウィスコンシン大学マディソン校に向かうNetgear SNTPリクエストは緑色で示されています。同じIPアドレスを持つ複数のNTPサーバーが複数の場所に配置されていることに注意してください。WiscNetの境界ルーターは、インバウンドSNTPリクエストを最も近いサーバーに転送します。サーバー応答は赤色で示されています。いずれかのサーバーが失敗した場合、トラフィックは同じアドレスを持つ残りのNTPサーバーのいずれかにルーティングされるはずです。
最終手段B：リクエストの抑制を試みる
Netgear時刻リクエストが当社のネットワークに転送されるのを防ぐには、ウィスコンシン大学マディソン校がntp1.cs.wisc.eduのIPアドレスを含むクラスBネットワーク内のIPアドレスブロックを犠牲にする必要があります。
インターネットのバックボーンルーティングの運用方法と、ルート数を管理可能に保つために、ネットワークルートは十分に大きい場合でないと尊重されないことがあります。今日のインターネットでは、ルートは2,048または4,096個の連続したアドレスを表さない限り、正当なものとは見なされない可能性があります。それぞれ、ネットワークオペレーターはそれらを/21または/20（「スラッシュ20」と発音）ブロックと呼びます。これは、21または20個の連続したビットのネットマスクを持つネットワークを表すためです。
図11は、この構成を示す図です。ウィスコンシン大学マディソン校の境界ルーターから発生するBGPアップデートは赤色で示されています。Netgear SNTPリクエストは緑色で示されています。インターネット全体でBGP対応の境界ルーターによってクライアントに返されるICMP到達不能メッセージは青色で示されています。これらは、NTPサーバーが存在するネットワークが到達不可能であることをクライアントに通知します。
最終手段B：必要なIPリソース
リクエストの転送を抑制しようとするこの最終手段は、大学に大きなコストをもたらします。欠陥のある製品の寿命の間、最大4,096個のIPアドレスを犠牲にする必要があるかもしれません。図12は、既存の128.105.0.0/16ネットワークをどのように分割でき、インターネットのグローバルBGPルーティングテーブルから除外される/20ブロックの1つのスライスを示すものです。
最終手段Bのリスクには、インターネットの一部の領域が、犠牲となる、広告されていないブロックの近くにある正当なキャンパスIPアドレスに到達できない可能性があることが含まれます。バックボーンネットワーク運用コミュニティからのインプットと実際の経験に基づいて、どのソリューションが大学とインターネットコミュニティ全体に最適かを判断する必要があります。
インターネットコミュニティへの通知
この文書の公開リリースは、この欠陥とそれによって引き起こされる氾濫についてインターネットコミュニティに情報を提供し、同様の間違いが他の場所で繰り返される可能性を最小限に抑えることを願う取り組みの一部です。Netgearは、公開開示の計画について、リリース前に数週間通知されていたことに注意してください。さらに、この文書の以前の改訂版はレビューのために提供されました。
世界中に分散した何十万もの不正なインターネットホストによる問題の範囲と、一部のネットワークリンクを完全に満たす可能性のある総レートでの氾濫の規模と予期せぬ性質のため、他の人に情報を提供し、専門家からアドバイスを求めたいと思いました。
この開示に続いて、この問題および類似の問題の危険性と潜在的な解決策をさらに提示し、レビューするための適切な場を見つけることを意図しています。
たとえば、レビュープロセス中に、オーストラリアのCommonwealth Scientific & Industrial Research Organisation（CSIRO）が、応答がない場合に毎分2回CSIRO時刻サーバーにポーリングする約85,000台のSMCブランドルーターで同様の問題に直面していることがわかりました。そのインシデントに関する記事、「Rogue routers cause havoc for CSIRO」、はここで見つけることができます。
http://australianit.news.com.au/articles/0,7204,6716567%5e15340%5e%5enbv%5e15306-15318,00.html
CSIROの問題の規模は桁違いに小さいですが、毎秒約2,800パケット、毎秒1.7メガビットの氾濫ですが、驚くほど似ており、その製造元の支援で責任を持って対処される可能性は低いかもしれません。
インターネットのベストプラクティスとプロトコル標準の明確化
また、レビュープロセス中に、レビューチームのメンバーがこの問題に関連するドキュメントを改善するためのインターネットドラフトの作成を開始しました。現在、少なくとも2つのそのような取り組みが初期段階にあります。
- 私は現在「Embedding Globally Routable Internet Addresses Considered Harmful」と題されたインターネットドラフトを準備中です。これは、ユニークでグローバルにルーティング可能なIPアドレスをインターネットホストに埋め込む慣行を非難し、結果として生じる問題の一部を説明し、選択された代替案を検討します。
- NTPコミュニティのメンバーは、SNTPを説明する既存のInformational RFC2030を改訂およびレビューしました。彼らの努力、およびおそらく他の関係者の努力により、NTPおよびSNTPをIETF内の標準トラックプロトコルとして再検討することが可能になるかもしれません。
ステータス、2003年8月21日
Netgearがこのプロセスの初期段階で協力してくれたことを嬉しく思います。そして、適切なソリューションを実装できる合意を形成しています。
当面の間、ウィスコンシン大学マディソン校は、Netgear製品からの時折の大規模なトラフィック氾濫を受けているにもかかわらず、Netgear SNTPリクエストに対応し続けています。最近のインシデントを図13に示します。右側のサメのひれのような異常は、毎秒約100,000パケットに増加してから収まったインバウンドNetgear時刻リクエストの氾濫です。
Netgearによって引き起こされたインシデントの規模と期間の両方が、ウィスコンシン大学マディソン校にとって深刻な運用上の問題であり続けています。現在、実質的にロシアンルーレットのような状況にありますが、ウィスコンシン大学マディソン校とインターネットオペレーターコミュニティの両方の専門知識を活用して、優れたソリューションを設計および実装できることを願っています。
後記
このケーススタディで思い浮かんだ、考察のための質問をいくつか紹介します。
- この意図しないサービス拒否氾濫は、一部のパブリックインターネットサービスの実行可能性について何を語っていますか？
- インターネットルーティングインフラストラクチャは、このような問題に対するより破壊性の低いソリューションを可能にするように改善できますか？
- このようなインシデントは、ユビキタスで低コスト、おそらく使い捨てのインターネットホストの可能性のある副作用ですか？
- 製造元、ベンダー、インターネット運用、およびユーザーコミュニティは、このような問題に対処するために協力する意思と能力がありますか？
謝辞
以下の人々が、データ収集、分析、および人脈形成において支援を提供しました。
- ウィスコンシン大学マディソン校：Jeff Bartig、Jim Gast、Michael Hare、Adam Kunen、Dave Thompson
- フロリダ大学：Robert Bird、Greg Goddard
- ハーバード大学：Greg Mazzu
- k claffy、Nevil Brownlee、George Michaelson
また、匿名希望者を含むレビューチームのメンバーにも感謝します。彼らの参加のおかげで、より良い解決策にたどり着けることは間違いありません。
分析ツール
この調査中に使用されたツールは以下のとおりです。
- MRTG
- RRDTOOL
- RRGrapher
- junipoll
- flow-tools
- Cflow
- FlowScan
- tcpdump
- ethereal (現 wireshark)
- sntp.pl
- strings ;^)
参考文献 / 続きを読む
- RFC2030: Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI (ステータス：Informational)
- RFC1305: Network Time Protocol (Version 3) Specification, Implementation and Analysis (ステータス：DRAFT STANDARD)
- ネットワーク時刻プロトコル（NTP）プロジェクトのホーム
- 公開NTPタイムサーバー
- 公開NTPセカンダリ（ストラタム2）タイムサーバー
- RFC2132: DHCP Options and BOOTP Vendor Extensions
- RFC1546: Host Anycasting Service
- http://www.networksorcery.com/enp/protocol/sntp.htm
- regeditを使用したWindowsの時刻サーバー設定の変更方法に関する記事
- Windows Time Serviceの基本操作
- http://www.microsoft.com/windows2000/docs/wintimeserv.doc
- 欠陥のあるルーターがウィスコンシン大学のインターネット時刻サーバーを氾濫させる（NANOG 29プレゼンテーション）
- インターネット病理学のケーススタディ：欠陥のあるルーターが大学のネットワークを氾濫させる（LISA '03トーク）
よくある質問
-
Netgearは、ネットワークへのサービス拒否（意図せずとも）を引き起こしたことに対して、どのような責任を負いますか？
私の職務は、そのような交渉に参加するようなものではありません。しかし、報告したように、合意が形成されつつあります。
他の方への注意：金銭的または法的な詳細については私に尋ねないでください。この文書は状況の技術的な概要であり、そのような詳細を伝えるための手段ではありません。
このニュース記事に興味があるかもしれません：http://www.doit.wisc.edu/news/story.asp?filename=322
-
Netgearクライアントに応答を返す偽のサーバーを設置し、ユーザーにアップグレードを促すことを検討しましたか？
はい、しかし長くは検討しませんでした。Netgearとレビューチームの他のメンバーは、影響を受ける製品の時刻関連機能に気づいている顧客のごく一部しかいないため、ほとんど効果がないだろうという点で一致しました。それに加えて、提案された「偽の」時刻サーバー（偽の時刻を報告する）は、現在当社の有名な信頼できる時刻サーバーのIPアドレスで運用される必要があります。パブリック時刻サービスの目的が正しい時刻を返すことであるため、突然信頼できなくなるのは非常に失礼です。大学は、それがどのように悪用されても、可能な限り最善のサービスを提供するつもりです。
-
これらの製品の予想寿命はどのくらいですか？
個人的には、それらの多くが5年から10年後まで使用される可能性が高いと考えています。推測ですが、おそらく半減期は5年で、その後は影響を受けた製品が350,000台未満使用されていると予想されます。
-
図13の「サメのひれ」のようなスパイクは、先週の電力網の障害（2003年ブラックアウト）とそれに続く「ローリング」復旧と関係がありますか？
いいえ、2003年8月に東海岸を襲ったブラックアウトとは一致しませんでした。しかし、Netgear SNTPトラフィックでブラックアウトの証拠を探したところ、停電中はわずかに減少しただけでした。インターネットのごく一部しか電力供給停止の影響を受けませんでした。初期の報告では、わずか数千のBGPプレフィックスが、わずか数百の自律システムからオフラインになったとのことです。オフラインになったものは双方向で到達不可能だったため、電力が復旧するまでそれらからのリクエストは受信しませんでした。ローリング復旧は、それらのNetgearクライアントがオンラインに戻るにつれて、当社のサーバーへの負荷を分散させるのに役立ちました。
-
言及されているもの以外に、ネットワークへの意図しない氾濫を引き起こす欠陥を持つデバイスはありますか？
多くのNetgearユーザーが、NetgearモデルRO318、ファームウェアバージョンV3.26も当社の時刻サーバーを使用しており、NTPエラーをセキュリティログに記録していると私に報告しました。この製品は評価していませんが、どのようなリトライ時間を使用しているかはわかりませんが、Netgearに報告します。
-
この記事がSlashdotで取り上げられた影響は何でしたか？
ウェブサーバーに大きな影響を与えましたが、全体としてはキャンパスにとって取るに足らないレベルのトラフィックでした。サーバーは一時的に毎秒30リクエストを処理しました。
このレポートがSlashdotで取り上げられた際の、ウェブサーバーのヒット/秒数とNetgear送信元SNTPリクエストフロー/秒数の数を比較したグラフを以下に示します。（注：この時点では、ほとんどのNetgearクライアントは当社のサーバーから応答を受信していたため、リクエストを氾濫させていませんでした。）
［画像］
-
従来のメーカーによるリコール/欠陥解決策が不可能なのはなぜですか？
Netgearとレビューチームの他のメンバーは、機能しているように見えるため、影響を受けたデバイスを返却する所有者のごく一部を除いて、すべてが返却される可能性は低いと考えていました。また、非常に少ない顧客がこれらの製品を製造元に登録しているため、彼らに連絡するのは非現実的です。
-
私は[ITプレス]に所属していますが、お話しする時間はありますか？
このレポートが最初に発表されたとき、鋭い聴衆のメンバーが、ITプレスは消費者がインターネット標準とベストプラクティスに準拠しているかどうかを評価する上で重要な役割を果たしていると提案しました。
それを踏まえて、もしあなたがITプレスに所属しており、あなたの出版物がインターネット製品のレビューを行ったり、「エディターズチョイス」賞を授与したりする場合、私はこのストーリーについて電子メールで連絡を取る用意があります。具体的には、インターネットコミュニティは、ITプレスのインターネット標準とベストプラクティスに関する知識と、製品を評価する能力の評価を探求することから利益を得るかもしれません。
このストーリーの報道をITプレスの製品評価および推奨機能と結びつけることで、コミュニティがこのような欠陥がこのような問題を引き起こす可能性を減らすことができると期待しています。それは単なるアイデアですが、どう思いますか。
-
この話はプレスでどのように取り上げられましたか？
包括的なリストではありませんが、報道のサンプルを以下に示します。
（一部の記事は詳細について誤解を招く、または不正確であることに注意してください。
そのうちのわずか数件だけが事実確認のために私に連絡しました。）-
Slashdot: Netgear Routers DoS UWisc Time Server
-
The Inquirer: Wisconsin Uni page describes Netgear
'flawed routers' -
Wisconsin Technology Network: Flawed Routers Flood UW Server
-
CNET News.com: NetGear flaw triggers accidental DoS attack
-
ZDNet Australia: UPDATE: Netgear routers attack university
-
Network World: Netgear router quirk perturbs college
（Network World誌の印刷版にも掲載） -
TECHWORLD: NetGear sets off denial of service attack
-
Network Computing: Industry Insights: Opportunity Knocks / Quality Counts
-
PC World: NetGear Routers Wage War on University
（PC World誌の2003年11月号にも掲載）
-
Copyright 2003, Dave Plonka.
$Id: index.wml,v 1.39 2006/07/19 15:20:28 plonka Exp $
$Log: index.wml,v $
Revision 1.39 2006/07/19 15:20:28 plonka
updated figure 8a
Revision 1.38 2005/04/28 16:13:02 plonka
updated figured 8a
added NANOG and LISA talks to references
added news story url to faq entry
fixed a typo
Revision 1.37 2004/09/28 18:37:16 plonka
fixed a typo
Revision 1.36 2004/05/19 22:54:31 plonka
updated figure 8a
Revision 1.35 2004/02/05 17:29:12 plonka
added figure 8a, Netgear SNTP Clients Per Day
Revision 1.34 2003/12/04 22:30:58 plonka
fixed a typo
Revision 1.33 2003/10/16 22:30:05 plonka
added a faq entry
Revision 1.32 2003/09/15 22:13:13 plonka
fixed some typos and reworded a couple sentences
Revision 1.31 2003/09/12 18:09:49 plonka
added info about code upgrade for HR314
Revision 1.30 2003/09/10 15:03:26 plonka
fixed a typo
Revision 1.29 2003/09/10 14:58:50 plonka
added using DHCP "Network Time Protocol Servers Option" to "Suggested Fixes"
Revision 1.28 2003/08/30 02:22:20 plonka
added faq entry
Revision 1.27 2003/08/27 18:42:42 plonka
added graph evidencing the flash crowd when this report was slashdotted
Revision 1.26 2003/08/25 23:54:09 plonka
fixed some typos and reworded a couple sentences
Revision 1.25 2003/08/25 23:54:09 plonka
added faq entries