要約

  • ディレクテッドブロードキャストは宛先プレフィックスまで通常に転送され、最終ホップのルーターだけがリンク層ブロードキャストへ変換した。
  • Smurf 攻撃は被害者の送信元アドレスを偽装し、要求を受けて応答したホストの返答を被害者へ向けた。
  • RFC 2644 は受信と転送を既定で遮断するよう変更した。BCP 38 は別の境界で送信元アドレスの偽装を抑える。

一つの宛先が集団を表した

ディレクテッドブロードキャストは宛先一覧ではない。ネットワークプレフィックスに、ローカル部をすべて一にした値を組み合わせる。経路上の多くのルーターにとっては普通の宛先であり、最後にそのプレフィックスへ接続するルーターが初めて「このリンクの全体へ渡す」という意味を実行に移す。

255.255.255.255 のリミテッドブロードキャストとは範囲が違う。後者は現在のリンクから出ない。前者は遠隔ネットワークまでルーティングでき、到着点で一対多の配信になる。アドレス一個に、遠方の集団を呼び出す命令が折り畳まれていた。

RFC 919 が 1984 年に示した用途は実際的だった。あらかじめサーバーを知ることなくサービスを探し、ゲートウェイの存在を知らせ、情報を持つ隣接ホストへ一度に問いかけられる。一方で、受信した全ホストが何らかの処理費用を負うとも警告した。

同じ管理領域のローカルリンクなら、その費用は参加者間の合意として扱える。遠隔から起動できるようになると、便利さを得る者と費用を負う者が離れる。

サブネット化が最終ホップへ判断を集めた

一つの IP ネットワーク番号の下に複数の物理ネットワークを置くと、ブロードキャストの範囲は単純ではなくなる。RFC 922 はサブネット環境へ規則を拡張し、遠隔のハードウェアネットワークまでは通常に転送し、直結するゲートウェイでリンク層ブロードキャストにする構造を保った。

ここが作用域の境界である。入力側では一個のデータグラムにすぎない。出力側では多数のローカルホストが受信対象になる。最後のルーターは配送だけでなく、要求の社会的な大きさを変更する。

CIDR では、どこまでがプレフィックスで、どこからがローカル部かは経路情報に依存する。RFC 1812 は、ユニキャストかネットワークプレフィックス向けブロードキャストかの判断は最終ホップでしかできないと説明した。分類の知識とファンアウトの実行権が同じ装置に置かれた。

しかし 1995 年の要件は許可を初期状態にした。転送を無効化する設定は必要だったものの、受信と転送の設定は許可が既定値だった。上書きする方針がなければ転送するのが正しい実装だった。

協調的な発見機能を前提にすれば理解できる設計である。送信元が他者のアドレスを名乗れると、その初期値は別の意味を持つ。

借り物の返信先が回路を完成させた

ルーターは宛先を見てパケットを進める。要求—応答型のプロトコルは、受け取った送信元へ返答する。IPv4 ヘッダーだけでは、そのアドレスの所有者が本当に要求を送ったとは証明できない。

攻撃者は送信元欄を被害者のアドレスにし、別のネットワークのディレクテッドブロードキャストを宛先にする。最終ルーターが要求をローカルへ一斉配信し、受信して応答を選んだホストは見かけ上の送信元、つまり被害者へ返す。

本当の送信者ではない相手へ返答するので反射となる。一つの要求が複数の応答者を招くので増幅となる。ただし倍率は固定ではない。稼働ホスト数、応答の実装、プロトコル、パケット長に左右される。重要なのは、攻撃者が各ホストへ個別に要求を送らなくてもよい構造だった。

RFC 2644 は、外部からのディレクテッドブロードキャストを許したネットワークを「Smurf Amplifiers」と呼んだ。各ホストの局所的な返答規則より、遠隔の一個の要求をローカルな多数の応答機会へ変えたルーター方針に焦点を当てた表現である。

個々には普通でも合計は第三者を襲った

ルーターは既知のプレフィックスを処理する。ホストはローカルブロードキャストを受ける。返信先は経路上で有効なアドレスである。それぞれの動作はありふれて見える。

ところが費用の集計先が違った。攻撃者は一つの要求を送り、増幅側ネットワークはホストと出口帯域を提供し、被害者は依頼していない返答の総量を受ける。設定を所有する組織が最大の損害を受けるとは限らない。

被害者側のレート制限は生存策になり得るが、権限配置を直さない。すでに一対多の変換が終わった後だからだ。入口の要求数が小さければ、増幅側の運用者にも深刻さが見えにくい。最も安価に止められる場所は、要求が集団作業へ変わる境界だった。

RFC 2644 は形式ではなく初期権限を変えた

1999 年 8 月の RFC 2644、BCP 34 は IPv4 ヘッダーを作り替えなかった。RFC 1812 の二つの既定値を反転した。

ルーターはディレクテッドブロードキャストを受信する設定を提供してもよいが、初期状態は無効でなければならず、エンドユーザーが明示的に設定しない限り受信しない。インターフェースごとの受信や転送設定も、どちらも遮断を既定値とする。

この変更で、誰が手を動かすかが逆になった。以前は運用者が古い機能を見つけて閉じる必要があった。以後は必要性を持つ者が、理由を伴って開けなければならない。新しい装置が放置だけで公開増幅器になる道を減らした。

機能自体を禁止しなかった点も重要である。限定された環境で必要なら明示的な例外を作れる。しかし、それは継承された偶然ではなく、責任を帰属できる管理行為になった。

ファンアウト遮断は送信者を証明しない

宛先側でディレクテッドブロードキャストを閉じれば、この増幅面は消える。だが、送信元アドレス一般の偽装が止まるわけではない。逆に、送信側でアドレスを厳格に検査しても、遠隔ネットワークが集団配信を受け入れる義務は生じない。

RFC 2827、BCP 38 は顧客ネットワークに近い入口で送信元を検査する。下流から来たパケットが、その顧客に正当に割り当てられたプレフィックス外を送信元として主張すれば拒否する。

限界も明記されている。有効なプレフィックスから来る攻撃は防げず、許可範囲内の別ホストを偽る場合も残る。これはトポロジー上の整合性と追跡可能性を高める仕組みであり、利用者本人の認証ではない。

二つの境界は別々の決定を守る。送信側はどの返信先を名乗ってよいかを決め、宛先の最終ホップは遠隔要求にローカル集団を動員させるかを決める。一方を閉じても、もう一方の統制が不要にはならない。

ローカルブロードキャストは残った

歴史を「ブロードキャストが危険なので廃止された」と要約すると範囲を誤る。リミテッドブロードキャストはリンク内の設定や発見に残り、そもそも転送されない。RFC 2644 が撤回したのは、遠隔の主体が他者のネットワーク内部へブロードキャストを持ち込む暗黙の資格だった。

反射・増幅攻撃全体が終わったわけでもない。偽装送信元に応答する別のサービスは存在し得る。達成したのは限定的だが強い変更である。危険な外部性が判明した機能を、ルーターの無条件な出荷時挙動から外した。

例外はルーター全体より小さく定義する

正当な用途が残るなら、単に「有効化」と記録するだけでは足りない。入口インターフェース、許可する送信元プレフィックス、宛先プレフィックス、出力インターフェース、プロトコル、期限、責任サービスを明示すべきである。ローカルな仕組みや選択的な発見で代替できない理由も必要になる。

観測では、既定で落とした数、例外で受け入れた数、実際にリンクへ送ったブロードキャスト、そこから生じた返答量を分ける。プレフィックス変更で対象集合が広がれば、例外も再審査する。

安全な既定値は運用方針そのものではない。ファンアウトを戻す前に、方針の所有者を呼び出す仕掛けである。

出典と証拠の限界

使用した閉じた資料集合は RFC 919、RFC 922、RFC 1812、RFC 2644、RFC 2827 である。ブロードキャスト機構、ルーター要件、既定値の反転、送信元フィルタリングを示すが、共通の増幅率、全ホストの挙動、現在の普及率、現在の攻撃頻度、ベンダーの準拠状況は測定していない。