Internet Week 2015 DNSOPS-JP BoF

2015/11/19(木) 19:00 - 20:30 於 富士ソフトアキバプラザ

====

「DNS可視化と対策」 テリロジー籠谷さん

- サーバ運用に必要なこと(攻撃の対策において)

・可視化
 概要把握
 特異点特定
 通信特定分析
 生データ
・攻撃対策 
 脅威対応

  可視化の部分が大きい。

- DNSトラフィック可視化の既存ツールは?

  Munin、Cacti等・・・サーバ監視ツール
  DSC・・・DNSのトラフィックを見えるが、まだ見れることが限定される
 どれも足りない。掘り下げられるツールがほしい。

- 実現したいこと

・長期傾向から特異点を特定
・任意の時間帯で状況把握
・いろいろな切り口で表示
・特定の時間帯をじっくり解析

- 可視化ツールをつくってみた:momentum DNS viewer

・http://tapas.terilogy.com/projects/dns_viewer
・過去4週間のトラフィック傾向を一望して特異点を探せる
 毎日のトラフィックグラフがカレンダー形式で表示
・特異点を見つけたら、見たい時間帯をズームイン
 最小で1秒単位でトラフィック量を把握可能。スパイクも見れる。
・切り口を切替え
 時系列・TOP10などで表示
・じっくり解析
  当該時刻のPCAPファイルをクエリドメイン名などでフィルタした上で取得
・ツールの利用シーン
 普段は、傾向を把握し早期の兆候把握。個別対応のための細かい情報を取得可能。

- デモ
可視化のデモ
・インターフェイス毎のトラフィックグラフから時間帯を指定して表示
 →その時間帯を別の切り口で表示(レスポンスタイム、RCODE別等)
・長期ビューで過去4週間分を表示して異常を発見
 →異常がありそうな時間帯を指定し、より細かい時間軸でのグラフへ

・水責め攻撃検出
 ドメイン毎にランダムクエリ数を集計。クエリ数が多いドメインで
 絞り込み、PCAPダウンロードしてWiresharkで閲覧。

====

「JP DNSで見た最近の変化」 JPRS 藤原さん 

- JPRSはa.dns.jpのクエリログを過去11年分、a.dns.jp以外は
 50時間分を取得している。

- JP DNSで観測できるIPアドレス数の変化
 1日160万アドレス。a.dns.jpだけで80万から100万。微増傾向。
  ちなみにRootだと1000万アドレスくらい。

- IPv6クエリ割合
  AAAA クエリ、IPv6クエリいずれも増加傾向

- DNSSEC関係
  JP DNSKEYクエリ数、DSクエリ数の集計
  増えたり減ったりしている。大規模なISPのDNSキャッシュサーバが
  DNSSEC検証を開始したりやめたりしているからではないか。

- DSレコードクエリが増加
  JPゾーンのNegative cache TTLを900秒に短くしたらDSクエリが増えた。
 DSレコードのクエリでJP DNSが溢れる懸念があり、それに関するI-D
  (draft-fujiwara-dnsop-ds-query-increase) を書いたがその後減ったので放置。
 みなさんDNSSEC検証をオンにしてDSクエリを送ってください。
  DSクエリが増えて溢れるくらいが嬉しい。

- ソースポートランダム化しているリゾルバの数
  リゾルバのIPアドレス毎に、1日毎のポート番号の数を見る。
  ・unknown(クエリが少なすぎてランダム化しているか不明) が多い、40%くらい。
  ・(Kaminsky attackの) 2008年より前からランダム化してる
    リゾルバがあった。おそらくdjbdns。
  ・ランダム化していないリゾルバは順調に減っているが、
    まだまだ残っている。


====

「DNSデータ・サイエンス」Nominum/Bruce Van Niceさん

- Nominumとは
 Paul Mockapetris (RFC1034の著者)
  Nominumの製品は40カ国で使用されている。
  4億加入者にサービス。1.8兆トランザクション/日。
  BIND9も開発した。

- 既存の脅威分析は不十分
・DDoSやマルウェアがカバーされてない
・既存フィードの限界
  偽陽性率が高い。通信事業者としては使えない。

  ダメなものを複数組み合わせても使えない。BAD+BAD ≠ GOOD。

・パターンと関係の発見
 3.5TB/dayのデータ。3%はISPからのもの。
 データはプライバシ保護のために匿名化。

・関連付けの技術
 機械学習を利用して類似性検出し、似通った振る舞いの
 ドメインのグループを視覚化。
 関連付け技術でマルウェアを早期発見。ドメイン間の関係を検出。

例:新しいコアドメイン
 ほぼリアルタイムで1日350万。多くがDGA(アルゴリズム生成)で有害なもの。
 解決できない名前も多い

例:検出された群
  有害なドメインの寿命はほぼ3日以内。

例:ブラウザハイジャック
  ネットワークにより感染率は変わる 1%〜20%。

例:アドトラッカー
 既知のアドトラッカーのドメインをシードとして、
 さらにそれと関係するドメインを検出。

例:ボットネットクラスタ

例:DNSトンネリング
 DNSトンネリングを検出するアルゴリズム。

まとめ:
・DNSデータを解析することで、多くのことがわかる。
・DDoS、ボット、マルウェア、アドウェア、
  トンネル・・・もっと多くの発見があるでしょう。

====

「DNS backscatter」  NII福田さん

・センサーをインターネットに置く活動してる
・悪意がある活動を見つける。ポートスキャン、攻撃、スパム

・DNS逆引きを使って悪い人を同定して攻撃を検出

 SMTPサーバへの攻撃・・・スパマーのホスト名
 ファイアウォールへの攻撃・・・ ポートスキャナのホスト名
 Webサーバ・・・Webクローラのホスト名

   を利用して悪意がある振る舞いを検出。

例:スパムを送信されると、権威サーバへ逆引きクエリが来る
    それを解析して悪意ある活動を検出
・クエリの特徴でメールとスパムは分離できる。機械学習を使って認識可能。

・M-rootのデータを利用して実験
 heartbreed検出
 スパマーを検出

・いいところ
  逆引きだけなのでデータが多くない。
  逆引きのトラフィックを解析するため、プライバシフレンドリ。
  デプロイ可能
  正確

====

「顧客向け参照用DNS管理者の憂鬱
 〜無償だと思っていたDNSBLが有償だったら〜」 IIJ島村さん

- IIJでは共用のDNSキャッシュサーバを運用中
  (小規模法人顧客、FTTHユーザ、ホスティングユーザ向け)

- ある日DNSBL事業者(の日本代理店)から料金請求メール。
  DNSBLへクエリを行っているソースIPアドレスとして上記のDNSサーバが記載。
  IIJのメールサービスではそのDNSBLは使ってない。なんで?

- tcpdumpしてみた
  ホスティングサービスやトランジットサービスの顧客がそのDNSBLを参照していた。
 1顧客で最大20qps。全体で200qps程度。
 そのDNSBLの利用条件の無償利用の条件を超えている・・・

- DNSBL事業者(の日本代理店) との会話
 曰く、
 ・大量クエリを出してるところに契約のお願いしてる。IIJだけでなく他ISPにも。
 ・有償契約をしてもらえない場合はクエリを遮断する。

  (どんな方法で遮断するのか?)
 ・どの範囲で、どういう手段で遮断するかは未定(よくわかっていない)。
 ・10月から遮断する。

- IIJの対応
 有償契約はしない。大量クエリを送ってる顧客には個別で対応依頼
  (自前で参照用DNSを立てるなど)。
 その結果、クエリは結構減った。

- X-Day 10/1
 特に問題なし。問題のDNSBLはちゃんと引けている。対応してクエリ減ったから?

- 他のISP担当者に聞いてみた
 同じ通知が来たISPは何社かあるが、やはり遮断されてない模様。

- いったい何だったのか。みなさんもお気をつけください。

==== 

「nginxを利用したDNS over TLS対応」 滝澤さん

- DNSプライバシのためスタブリゾルバとフルリゾルバ間をTLSで暗号化。
・Unbound自体にDNS over TLS機能あり。
 スタブ(フォワーダ)、フルリゾルバサービス側どちらにもなれる。

- UnboundのTLS機能ではなく、nginxのTLSプロクシ機能で
  DNS over TLSやってみよう
・nginxのstreamモジュールでTCPおよびTLSプロクシが可能。
・サーバ(フルリゾルバ)側のnginxで、クライアント(スタブリゾルバ)
  からのTLSコネクションを受けてUnboundの53/tcpへフォワード。

- ベンチマークしてみた

 Unbound - Unbound UDPクエリ:             82,000qps
  Unbound - Unbound TCPクエリ:             71,000qps
  TLS Unbound - TLS Unbound (nginx未使用):  1,000qps
 TLS offのnginx経由のUnbound同士:         69,000qps
  片方をTLS onのnginx経由のUnbound、もう片方をTLS Unbound:
                                            2,100qps
  両方をTLSオンnginx:                      15,000qps
  TLSセッション再利用をオンなnginx:        44,000qps

Unbound自身のTLS周りの性能はよくない。nginx経由でTLSすると性能向上。
TLSセッション再利用するとさらに性能向上(TLSハンドシェイクは重い)。

====

「APRICOT 2106参加支援プログラム」  高田さん

APRICOT2016  2016/2/15〜 NZで開催
参加する若者に旅費・宿泊料を支援。
資格: 応募締切(12/8) 時点で 18歳以上30歳以下。
資格がある方はぜひ。職場の若者にも声かけてみて!

====