[Top Page]
----------------------------------------------------------------------
BoF名   日本DNSオペレーターズグループ BoF
BoF開催団体名   日本DNSオペレーターズグループ
開催日時        2007年11月19日 17:30〜19:30
参加者数        約100名
BoFの概要

本BoFでは主にDNSのセキュリティ、パフォーマンス、運用上の課題についての
発表と議論が行われた。

 - DNS Rebinding Attackの概要について
   独立行政法人情報通信研究機構 力武健次氏

   DNS rebindingの仕組みと攻撃のシナリオ、各種実装での攻撃が成功するた
   めに必要な時間予測について紹介が行われ、その対策について議論が行わ
   れた。

 - 50万qpsを超えるDNS応答の測定方法について
   ネットエージェント株式会社 愛甲健二氏

   DNSの応答速度を改善する新しいキャッシュシステムについて、前回BoF時
   点からの性能の向上点が紹介され、適用できるネットワーク、測定のため
   に必要となる事柄について議論が行われた。

 - ライトニングトーク
   - j.gtld.biz A record is missing
     NeuStar, Inc. Ed Lewis氏

     .usのネームサーバj.gtld.bizをIPv6のみで運用している事例が紹介され、
     IPv6への移行方法などについて議論が行われた。

   - 昨年度のサイバー攻撃対応演習の報告
     ソフトバンクテレコム株式会社 工藤真吾氏

     重要なサイトが応答を返せなくなった場合の影響度、オペレータが連絡
     を取り合って対応するにあたっての課題が紹介され、連絡先の共有方法、
     連絡の取り方について議論が行われた。

   - ブロードバンドルータの DNS proxy の問題
     株式会社日本レジストリサービス 藤原和典氏

     ブロードバンドルータにEDNS0非対応の問題が紹介され、DNSOPS.JPで製
     品の調査を行い改善の取り組みを行うことが提案された。調査方法や技
     術的な調査項目について議論が行われた。

   - DNS DAY パネルディスカッションから
     株式会社日本レジストリサービス 米谷嘉朗氏

     パネルディスカッションで議論された運用管理の専門サービスの利用に
     ついて紹介され、DNSOPS.JPで正当に運営している運用者の評価を行うこ
     とが提案された。

----------------------------------------------------------------------
Internet Week 2007 の dnsops BoF で log を取った舩戸と申します。

事務局の一部の方と相談の上 BoF の log を ML に投稿いたします。
補足や誤解している部分についてのツッコミがあれば、お願いします。
# 特に Ed さんの英語での発表等


DNS rebinding attack by 力武さん

DNS rebinding とは何か?
- DNS の指すオブジェクトを変えること
- これが Java Script と一緒になると
  + 外部から内部を指して見に行くことができる
    o 同じホスト名で内部と外部にアクセスできるようになってしまう
      o Java Script same-origin Policy のため
      o ファイアウォール越えになってしまう
- Java Script same-origin Policy とは何か
  + 同じプロトコル、ホスト、ポートであれば同じアクセス範囲だとみなす
  + アクセス範囲をドメイン(ホスト名)で規定

代表的な攻撃シナリオ
1. 外部にスクリプトを仕込んだホスト A を用意
2. クライアントをホスト A のスクリプトにアクセスさせる
3. DNS を変更して同じホスト名で別のホスト B に変更
4. same-origin Policy に法ればクライアントからのホスト A 向けアクセスが
   ホスト B にいってしまう = ファイアウォールを越えてしまう

Java Script 以外の攻撃対象
- Java や Flash Player などのブラウザのプラグイン一般
  + やっかいなのは認証のスキームを全て独自で持っている
  + same-origin Policy を持っていれば攻撃の対象となる

95% の確率で攻撃するのに必要な時間
- Live Connect
  + JVM 持ってる場合は 60msec
- Flash
  + 0.2 秒
- ブラウザ
  + 1 秒あればじゅうぶん可能
    o Opera でも 4 秒あれば可能

攻撃への対策は手薄
- 例として DNS pinning
  + 一度DNSを引いたら一定時間保持
    o TTL をみないでアプリケーションで保持する
  + しかし無効手法の多くが既知
    o 別のポートでアクセスさせるとか
    o FlashPlayer では XML で SMF movie に Policy を書ける

ファイアウォール越え
- プライベートネット内の資源の探索
  + localhost をソースにした攻撃
    o localhost を信用している場合が多いため
- 内部のリソース利用
  + グローバルアドレスを持っている場合
- Source IP Address の不正利用
  + Spam とか

どれくらい攻撃に成功したか
- Web 上の広告を見てもらって踏んでもらった
  + 成功率約 91%
    o Flash Player, Live Connect, Java+Proxy の集合
- 試算したところ
  + 10 万個の IP Address を $100 以内でのっとれる計算になる
    o できあいの Botnet 借りるよりは安そう?

DNS的対策
- プライベートネットワークを使っている場合の対策
  + dnswall2 by google
    o CNAME 禁止
    o A/AAAA RR の応答を検査する
    o プライベートアドレスなら NXDOMAIN にする
- グローバルだったら
  + 個別に考えるしかない
    o 頑張るならリゾルバに入れる
    o 内部、外部の区別方法が別に必要
- 逆引きの認証を行う
  + auth というサブドメインにのっける
    o アドレスが本当にそのホストかどうかの判定
    o すでに Java で実装済みだが Flash Player などではまだらしい

DNS 的対策は実は難しい
- DNSSEC などの認証では解決不可
  + サインされていれば authoritative zone の中身は信じるしかない
- レジストラは何ができるか
  + 事後対策ぐらいしかできないだろう
  + あとは変動するアドレスは拒否するとか
- ソフトウェアは何ができるか
  + プライベートアドレスを無碍にできない
  + ACL に規定するのも難しい
- Web の本質的な問題がある
  + JavaScript で pinning を 1 行で無効にできる方法
    o document.domain = document.domain を書く
  + HTTP HOST ヘッダでは嘘をつけるからダメ
  + どうする?
    o JavaScript を許したのが問題?

参考文献
- Stanford の論文 ACM CCS 2007 で発表
  + http://crypto.stanford.edu/dns
- dnswall source by google
  + http://code.google.com/p/google-dnswall/
- 金床氏のメモ
  + http://wizardbible.org/33/33.txt

質問とか意見とか
- Java は対応した
  + IP Address が同じところしかアクセスしかできないはず
    o ホスト名ではなく IP Address で見ているため
- 逆引きしたものをもう一回正引きすればいいのでは
  + 正引きした結果の中に入っていなければダメと言えばいい
    o 昔からある話だと思う
    o hosts.ecuiv とか .rhosts とかに書くと問題があるという話と一緒
    o JavaScript だと影響がでかい
    o XSS 問題みたい
- 基本的にはブラウザの問題 ?
  + stanford のサイトに行くとチェックしてくれる
  + stanford はベンダーに結果を送った
    o こうするべきだということを書いて送った
- JavaScript を止めると大丈夫?
  + 大丈夫だが…
    o どう認証するかという問題は難しい
    o AJAX なところはダメになる
    o つまり Web を使うなと同義語
- ベンダーの反応は?
  + 直しつつあるということが stanford の Web に書いてある
    o どうするべきであるということも書いてある
- Web だけの問題でなく DNS とくっついているのでやっかい
  + same-origin Policy は他でも問題になっている
    o Cockie のアクセス許可範囲
  + DNS オペレータが言っていかないといけないと思う
- 悪意をもった authoritative zone があるとだめ
- オペレータとしての対応として
  + ISP のキャッシュサーバで落とすのが早いと思うがどうか?
    o そうだろう
    o dnswall の開発目的も同じだと思う

----------------------------------------------------------------------
DNSの応答速度を改善する新しいキャッシュシステム by 愛甲さん

DNS Accelerator
- コンテンツサーバの応答を手助けするシステム
  + サーバの前においてクエリをキャッシュしてサーバの代わりに応答させる

BIND の応答速度
- queryperf で 45000qps 投げると 45000qps を応答
- 自作ツールで 240000qps 投げると 34000qps を応答

DNS Accelerator
- キャッシュされているデータは 50000件
- 自作ツールにて
  + 360000qps 投げると 360000qps を応答
    o DNS サーバ側にはパケットは届いていない
  + 700000qps 投げると 530000qps を応答
- 10-15 倍の性能
  o キャッシュされた状態から計測を始めているので実際はもっと低くなる

前回からの改善点
- 応答速度の改善
  + 前回は 200000qps
- キャッシュ汚染によるメモリリークを防止
  + DNS サーバの IP Address や MAC Address を登録して汚染を防止
- DoS (DDoS) 攻撃を検知する機能を追加
  + 通常時に通過するクエリ数を記録して 10-100 倍以上の場合応答停止
  + 特定の条件下にて、サーバへ送るパケット量を制限する機能を追加
  + DoS 攻撃以外には効果なし
    o DNSamp, Cache Poisoning, Spoofing, rebinding attack など

有用なテスト方法の考察
- 市販品を使っているため
  + 要求クエリや応答クエリが双方に届かずに応答なしと判断されている
    可能性はないか?
  + CPU 以外の機器がボトルネックになっていないか
    o NIC やスイッチなど
  + CPUを速くすると応答が速くなる
    o MAX は 800000qps と推測している

問題点
- ハッキングされる可能性はないか
- 運用できるレベルの安定性を持っているか
- 他に必要なテストはないか
  + 協力いただける人を探している

質問とか意見とか
- クロスでつなぐとどうなるか
- NIC が受けきれないのではないか
  + short packet だと受けきれない
- ブロックした段階で DoS が成立するのではないか
  + accelerator が返答できるものは返答するが DNS サーバに投げない
  + L4 スイッチで rate limit で制限かければいいのでは
    o コンテンツの内容はわかっているのだから
    o L4 でもわからない DoS の検知方法が出てきたらいいと思う
- Intel の NIC のドライバのパラメータをいじるといいかもしれない
  + インタラプトモデレーションのパラメータ
    o 割り込みが抑えられるために NIC のバッファがあふれることがある
- ニーズだとか目的は
  + 500000qps を捌いている管理者ってそんなにいないのでは
    o 捌いているところは、それぞれ工夫していると思う
  + 営業的には 500000qps までは攻撃に対応しますというアピールをする
  + IDS モジュールとの差別化は?
    o IPS や rate control みたいな使い方があるのでは
    o TCP にフォールバックして応答がきたら DNS サーバだと思われるので
      応答してあげるとか
    o ロードバランサなどど比較して簡単に導入できると思う
- 情報処理学会の QAI 研究会に投稿してみては?
- M Root に使ってみてもらうとか?
- snort や tcpdump でやっているようなことの代わりになれば良いのでは?
- 700000qps 投げて 530000qps を応答になったのは
  + タイムアウトになったため
    o DoS 検知のためではない
- logging 機能はつけないよね?
  + つけないです
- 遅いPCでもできることを見せたらいいと思う

----------------------------------------------------------------------
ここから Lighting talk
----------------------------------------------------------------------
j.gtld.biz A record is missing by Ed Lewis

.US の NS が新しくなったが
- j.gtld.biz に A が無い
  + AAAA のみ
  + IANA にこれの意味はとたずねた
    o なにもいってこない
  + .US に聞いてみた
    o 問題はないといっている
  + 人によっては間違えではないのかと言っている

昔の .US は
- 全ての州をサブドメインで持っていた

使っている BIND
- ソフトウェアとしては古い
  + RFC は満たしているが
    o v6 のみでいいのか?

v6 only は
- 本当に問題ない?
- 実は v6 発展に貢献する?

質問とか意見とか
- この件についてどれくらい問い合わせがあったか
  + あまりない
    o google でも 3hit のみ
- どれくらいクエリがあるか
  + わからない
    o クエリが少ないから問い合わせが無いのか、多いのに問い合わせがない
      のかが、わからない
- j.gtld.biz ってどんなの
  + ブレードサーバでスタンバイがいる形
- v4 から v6 に移行するためには何が必要か
  + ユーザが移行できるようにすること
    o 文書をを用意すること
    o 教育が必要
  + ソフトウェアの対応について
    o DNS やネットワークはレディ
    o その他のソフトウェアはお金かけずにフリーソフトで

----------------------------------------------------------------------
サイバー攻撃対応演習の報告 by 工藤さん

サイバー攻撃対応演習って
- 総務省が実施したもののこと
  + 去年の横浜の BoF で「やるよ」と言っていたもの
  + 重要なサイト(yahoo)のコンテンツサーバが落ちたときに ISP の
    キャッシュがどうなるか
  + JP DNS が落ちた場合にどうなるか

結果は
- 高性能なサーバをキャッシュサーバに使っていたので
  + 15% 程度を占めるクエリが不能になっても影響はありませんでした
    o 40% 越えるとなんらかの対応をしないとまずい
  + BIND9 での調査
    o BIND8 だともっと影響が出たはず
- DNS を実際に運用している担当者同士が連絡を取り合おうと思っていよりも
  いろいろなことができた
  + ただし電話やメールをしている相手の認証を行う必要がある
    o ちゃんと whois の更新はしましょう
    o whois 引いても連絡つかないかもしれないけど

今回はユーザからの問い合わせという要員を省いたのだが
- 実際にはユーザからの問い合わせで大変なのでは
  + ユーザからはインターネットが使えないという申告にしかならない
    o そこから DNS に問題があると特定するのは大変

今年もやります
- DNS の参加組織は変化なし
  + オブザーバに IIJ 松崎さんを正式に追加
- シナリオを凝ったものにする
  + シナリオは今回非開示
    o ユーザ対応の分も考慮

何年後かは
- 今後は枠組みを広げている必要がある
  + いつか dnsops の参加者で大規模な演習を実施できるといいなぁという
    欲望もある

質問とか意見とか
- DNS が落ちてるとメールが使えないのでは
  + 演習時はそれぞれの携帯電話で連絡をとりあった
    o whois だと電話番号がマスクされていたり
    o あるいは代表番号だったり
    o 代表番号も夕方以降はつながらなかったり
    o FAX はしない
- 対策の有無の違いについて
  + 連絡のパスがある場合と無い場合でやった
    o 無い場合はなにもしない
    o ある場合は ISP が対策をとった
- 今後電話が NGN になった場合に電話で対応って大丈夫?
  + ENUM を使う場合
    o インフラの中の DNS を使うのでは?
- データセンタやホスティングをやっているところが置き去りなのでは
  + 依存関係を出しておくのは必要だと思う
- 演習をやって、わかりやすい対策のレポートってあと何回やればできるか?
  + 今回は DNS については、攻撃方法について、そこまで突っ込んでない
    o 各階層のオペレータの連絡体制を主にしたガイドラインを作る

----------------------------------------------------------------------
ブロードバンドルータの DNS proxy の問題 by 藤原さん

一般的なブロードバンドルータ
- ISP からフルリゾルバのサーバの情報を受け取る
- DHCP のオプションで PC に配布するはず
  + でも、どうも DNS Proxy になっている
    o 内部クライアントから検索要求を受け取りフルリゾルバに中継する
    o IP Address が変わったりするため

DNS Proxy への要求事項
- 問い合わせ・応答を正しく中継すること
  + 特に EDNS0 対応, TCP での問い合わせ, DNSSEC, v6 対応など

NIC-SE の発見した問題
- 実際に問題が起こった
  + EDNS0 非対応が見つかった
- TCP で問い合わせ不可
- DNSSEC 対応の検索の結果 DO Bit=1 を立てると誤動作
  + AD Bit=1 となるレスポンスで止まる
  + 大量のクエリを生成する
  + 中継に失敗する
  + 直接外へ問い合わせる

NIC-SE の提案
- テストしてベンダーに対応をお願いする
  + テスト項目
    o EDNS0
    o TCP での問い合わせ
    o trancation のフォールバック(巨大な応答)
    o AD=1 の応答の場合の動作
    o 直接外へ問い合わせる

提案
- dnsops.jpでも調査しませんか?
  + 日本でよく使われている製品の調査
  + 日本のベンダへの修正依頼
  + 日本での調査のフィードバック

質問とか意見とか
- RFC 1918 アドレスに関するクエリを投げないというのを追加してほしい
  + 投げないという仕様や提案があるのか、根拠は?
    o RFC 1918 に書いてある
    o ヘッダについては当然だが、ペイロードに関しても一緒だと思う
- EDNS0 の 512 bite 版があるので調査に注意すること
  + BIND ではフォールバックするコードが入っている
  + IETF で関係するところ
    o 先月の dns tech deployment WG で出た
- 調査は自動化できるのか
  + batch file で動かすとか
  + dig を用意する必要がある
- JPRS や JPCERT で出してみるとか
  + JPCERT でベンダとのやりとりはしているのでサポートはできると思う
- 中継になってしまうのはアドレスが書き変わるためというのは
  + マルチセッションのせいではないか
    o 日本は特に対応したほうがいいかも
- ブロードバンドルータの config 書き換えをやっているところに協力が依頼
  できるのでは
  + 任意に書き換えるツールというのを NTT 東西にある
    o これを作っているところにはルータがたくさんあるだろう
- IP flagmentation は大丈夫かってのも入れてほしい
- キャリアが出しているルータとかも調査したほうがいい

----------------------------------------------------------------------
DNS DAY パネルディスカッションから by 米谷さん

運用管理のあり方
- 負担増が課題であるとの認識の下
  + 軽減する方法として専門サービスの利用はありえるか議論を展開
- 結論は
  + 単体の専門サービスというより基本部分としてならやれる
    o 単体で買うのは難しい

会場からの意見
- 今の DNS
  + 交通ルールや道路標識を知らなくとも車を運転できるようなもの
    o 新しいことを知らない人に情報を伝える仕組みがいるのでは
- データの正統性をどうやって保証するか
  + クローラをまわしたら
    o DNSSEC が来たら今の階層構造のゆるい管理は崩壊できる
- しっかりやってあたりまえ
  + 何かあったら怒られる
  + 正当にやってるところを評価してみたらどうか

DNSOPS.JP で評価出来ないか
- 正当に評価し誇りをもってもらおうということ

質問とか意見とか
- うまくいかなかったことを情報共有できれば底上げできるのではないか
  + 評価も必要だが
    o ネガティブではなくポジティブリストを作る方法でやってみたい
  + やっちゃったリストを作ることを提案したい
- ICANN とかの情報を流すようにすることも必要だと思う
- こういうことはガバナンスの仕組みに取り込めないか
- オペレータコミュニティ以外にリサーチャコミュニティとポリシーメーカの
  押し付けあいになってるのでは
  + 誇りを持つためには活動が必要だと思う
- 年中行事として
  + config list を集める
  + フリーソフトウェアアワードみたいな感じ
- 中立性を損なわないように、やりかたを気をつけよう
  + 幹事と会社は独立で
- WIDE もダメなドメインを出そうとしている
- 定量的でない評価も必要
  + ユーザの意見など
    o ユーザからは見えないものではあるが
  + lameを追っ払うのは重要なので、定量的に見るべきだと思う

----------------------------------------------------------------------
お知らせ

JPRS からのサーバ等を独立させる
- みなさんに手伝ってもらいたい
  + 12 月から作業をはじめる予定
    o やっちゃったリストの Wiki とかを考えたい

次回
- 半年後くらい
  + 新しいサーバへの移行期限として
  + どこかは未定
    o JANOG 21 とか?
----------------------------------------------------------------------