要約

  • RRLは、偽装されたUDP問い合わせが反射増幅に使われる状況で、権威サーバーからの似た応答の反復を減らす。
  • Paul Vixieの役割は大きいが単独ではない。ISCは同氏との防御戦略会合に触れ、BINDの開発記録にはVernon Schryverも記されている。
  • RRLは応答の種類とクライアントのアドレス範囲をまとめて流量を制御する。認証、攻撃者の特定、意図の判定ではない。

応答が攻撃のペイロードになる

DNS反射攻撃では、攻撃者が権威サーバーへ問い合わせを送り、送信元を被害者のアドレスに偽装する。サーバーの応答は被害者へ届く。応答が問い合わせより大きければ、攻撃者は自分の送信量以上のトラフィックをサーバーに送らせたことになる。

ISCの2014年発表は具体例として、isc.orgへの36バイトのANY問い合わせが3,576バイトの応答を生む場合を示した。反射が魅力的な理由を示す一例であり、あらゆるDNS通信に当てはまる倍率ではない。サイズは問い合わせ、ゾーンの内容、DNSSEC、トランスポート、実際の応答で変わる。運用上の問いはもっと限定的だ。似た問い合わせが続くとき、権威サーバーは似た応答をどこまで送り続けるべきか。

ISCは、Paul Vixieと社内で行った防御戦略の議論がRRLにつながったと説明する。BINDの開発チケットは、BIND 9向けパッチの作成者としてVixieとVernon Schryverの両名を挙げる。公開資料から確認できるのはVixieの大きな関与であり、単独発明者という説明ではない。RRLは運用上の課題をチームが実装し、その後も調整した成果だ。

Internet Hall of Fameの紹介は、この経緯をより広いDNSの仕事の中に位置付ける。Vixieは1988年、Digital Equipment Corporationに在籍しながらBIND 4の保守を始め、その後BIND 8の主たる作者、技術アーキテクトとなった。MAPS、PAIX、Internet Software Consortiumも設立し、Keio UniversityではDNSとDNSSECに関する博士研究を行った。こうした実績は仕事の広がりを示すが、Schryverも記されているRRLパッチの共同クレジットを変えるものではない。

BIND 9.9.4ではRRLは任意のビルド機能として導入された。ISCの「BIND 9.10 Significant Changes」では、その後RRLが標準のビルド構成に含まれたと説明されている。これはBINDで機能が利用可能になった経緯を示す。すべての権威DNS運用者が有効にしたことや、他のDNS製品も同じ動作をすることまでは示さない。

トークンバケットが測るのは類似性であって身元ではない

現行のBIND 9.20.29管理者マニュアルでは、RRLは類似した応答とDNSクライアントを単位にトークンまたはクレジットのバケットを作る。応答ごとにクレジットを使い、設定したレートと時間窓で補充する。空でない応答、NODATA、NXDOMAIN、委任、エラー、すべてのUDP応答など、クラスごとに制限できる。上限を超えると、BINDは応答を破棄するか内容を変える。

「クライアント」という単位には運用方針が含まれる。BINDの現行資料で示される既定値はIPv4の/24、IPv6の/56での集約で、同じ範囲のアドレスはまとめて数えられる。再帰リゾルバー、企業、大学、アクセス事業者の背後には無関係な利用者が多数いるかもしれない。そのうち一者がバケットの枠を使い切れば、同じ範囲の別の利用者にも遅延、切り詰め、または応答の欠落が及び得る。

だからといって、プレフィックス単位の集約が常に誤りというわけではない。問い合わせを多数のアドレスに分散すれば、アドレス単位の制限は回避される可能性がある。攻撃時にはサーバーが限られた送信容量を配分しなければならない。集約幅、応答クラス、レートには可用性上の費用が伴う。これらは明示的な運用方針であり、クライアントの「本当の身元」を中立に観察する設定ではない。

BINDのslip設定はトレードオフを見えやすくする。マニュアルの既定値slip=2では、有効なサーバークッキーを持たない制限対象の問い合わせに対し、2回に1回、小さな応答を返す。クッキーを提示した場合はBADCOOKIE、そうでなければ切り詰めビットを付け、リゾルバーにTCPでの再試行を促す。一部のエラーは切り詰められず、slipの頻度で送られる。slip=1は制限された応答をすべて切り詰めて返し、反射の抑制より応答の完全性と配達を優先する。slip=0は制限対象をすべて破棄する。再試行経路も防御の設計に含まれる。

サービスの役割によって導入範囲は変わる

ISCは権威サーバーでのRRL利用を推奨する一方、再帰サーバーへの適用は誤検知を生み、同じ名前を何度も尋ねる利用者を遅らせることがあると注意している。オープンリゾルバーを閉じることが先決だ。同じ機能でも、公開権威サービスと利用者向け再帰サービスでは負担が異なる。

BINDには、強制前に候補設定の影響を観察するlog-onlyモードがある。RateDropped、QryDropped、RateSlipped、RespTruncatedなどのカウンターは設定された機構の動作を示すが、攻撃者の身元を明かすものではない。観測された送信元アドレスは偽装されている可能性があり、同じバケットに属することは攻撃の帰属証明にならない。

Heng LuのNote 65は、ここでは実装が実際に何を制御しているかを稼働時の挙動で見る、という編集上の視点としてのみ使う。Vixieの経歴を裏付ける史料でも、RRLの技術仕様でもない。評価すべきなのは稼働中のBINDの版、設定、各バケットのカウンター、クライアントの再試行挙動であり、文書にRRLの記載があることだけではない。

証拠が支える結論は限定的だ。RRLは権威サーバーが反射トラフィックへ加える類似応答を減らし得る。同時に、正規利用者を同じグループにまとめ、配達と抑制の間に選択を迫ることもある。問い合わせ元の認証、動機の判定、普及率の測定、被害者への反射トラフィック消失の保証はできない。Vixieの意義は、運用上の防御を、運用者が限界を検証できる設定可能な実装へつなげた役割にある。

出典