Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
195 lines (169 sloc) 11.4 KB

ssmjp 2019/04 DNSの話を聞く会

日時:2019/4/23 19:30-21:30
場所:株式会社インターネットイニシアティブさん

19:30-19:40 @tigerszkさん 前枠/会場諸注意

ゆるふわ街角勉強会です
インフラ運用がメインです
「アウトプットしないのは知的な便秘」が
普段は60から100人
今回はスペシャル会です
LTの練習場的な位置づけでやってます

※会場でとったメモになります、誤っている可能性がありますのでご容赦ください


1. 19:40-20:00 @sischkgさん 「BINDのメモリリーク脆弱性とRoot KSK Rollover」

当日資料

  • 2019/2/22に発表されたBINDの脆弱性について
    Root KSK Rollover
    Key Tag Optionを使ったパケットを送るとメモリリークする
    Ubuntu18.04LTSが対象です
    ソースコードからコンパイルしていると対象
  • 運用環境では発生していない、Fuzzing環境(Sumeer Daysで報告)で発見した
    数個のDNSクエリでサーバ上のメモリを使い切ることはない
    パケット1個でとまるものではない
    バージョンアップのみ対応
  • Key Tag Optionについて
    Root KEK RooloverでSignaling Trust Anchor Knowledgeが定義された
    Root ZoneのKSKを更新するためにする作業
    Signaling Trust Anchor KnowledgeとはTrsut Anchorに付けるKey Tag
    BINDのメモリリークは受信したKey Tagをログへ記録する機能とともに追加
    一個目のタグのポインタのところに、見えなくなったポインタへ二個目のタグを入れてしまうため発生
    年末に発見して報告したが年越しでシステム更新できない組織もあるため公開は1月上旬以降に
    他の脆弱性の対応も重なって1月後半に、結局2/22に公開に
  • Signaling Trust Anchor Knowledgeの実装状況から
    すべてQNAMEを使っていてKey Tag Optionを使う必要性があったか疑問
  • 観測結果からはまったく何もいえなかった、という報告だった
    新しい実装だったため観測対象が偏っている
    署名検証しない設定でも送信している実装
  • Key Tag Optionを実装しなければ避けられた脆弱性
    対応はあまりよくなかった
  • @buta_sanのシグネチャになっているキノコのぬいぐるみ
    1匹300から500円で1200ロット

Q:実害は観測されていますか
A:今のところ聞いていませんが、named止めると異常起きるので受けたか判断はできます
Q:きのこのぬいぐるみは1色1200ロットですか
A:そうです


2.20:00-20:20 @fj_twtさん 「DNS BOM-BA-YE!! 〜DNSを止めろな!〜」

当日資料
ISPのDNS運用やってました、今はセキュリティの仕事をしているふり(?)をしてます

  • 今日は通信事業者とDNSについてのお話です

  • DNSを止めるな、DNSで止めるな、DNSで止めろ、DNSを止めろ
    ISPのDNSを止めると電気通信事故
    2時間以上3万人以上になると重大事故→1時間58分で復旧しがち(?)
    BINDについて、頻繁に公表される脆弱性、予測しよう
    BIND開発元に課金すれば教えてもらえる?

  • 脆弱性が公開される予兆を掴む
    ftpサーバの特定ディレクトリ(private)が更新される→5営業日経過後公開?
    Shodanでまだ見ぬBINDを探せる、現行バージョンではない次の先行配布されているバージョンが検索できる

  • 海賊版サイトブロッキング 緊急避難として....?→実際実施されなかった
    もう少し丁寧に対応を検討

  • 実際に止めている事例

    • 児童ポルノブロッキング ホットラインセンターからインターネットコンテンツセーフティ協会で判定 民間でやっている 経緯は警察庁、総務省から2008年ごろから検討開始 2009-2011検討を重ねて実運用に

    • DNSマルウェアフィルタリング マルウェア感染端末に攻撃指示を配信するC2サーバの名前解決を遮断 攻撃を未然に防ぐ 感染拡大を抑える

  • ブロッキングとフィルタリング

    • ブロッキング
      利用者の同意を得ずに
    • フィルタリング
      同意あり
  • ISP以外のDNSキャッシュの利用を止める
    OP53B→ISPではやりません→企業や学校などはやることもある
    DNSだけでファイル送信できてしまう
    NIST SP800-81-2 Check Item39
    企業は外向きのDNSトラフィックを指定されたリゾルバへ向けたほうがいい
    と書かれている

Q:8.8.8.8についてはフィルタリングされているか(?)
A:各事業者ポリシーで確認したほうがいいと思います(?)
Q:自宅のキャッシュサーバではなにを採用していますか
A:BIND使ってます、慣れているため


3. 20:20-20:25 DNS Summer Dayのおしらせ

2019/6/28(金) 10:00-18:00
会場:フクラシア東京ステーション
テーマ:DNSホットトピック、運用関連ネタ、etc..
URL:https://bit.ly/dnssummerday2019


20:25-20:35 休憩


4. 20:35-21:35 @tss_ontapさん 「黒塗りの DNS (萎縮編)」

当日資料

  • 某大学のURLが中華料理屋のURLになっていた
    レンタルサーバ返した後、Aレコード削除申請がなかった→そのまま中華料理屋に貸した
    危険な忘れ物 Floating Donainname
    借りたサーバIPアドレスにリソースレコードを向けたまま解約してはいけない
    Subdomain takeover Attack
    放置されたCNAMEの先は狙って再登録されうる、、、
    参考:The Principles of a Subdomain takeover
    https://blog.sweepatic.com/subdomain-takeover-Principles

  • まずはDNSの基礎知識から
    超短縮版DNS温泉です

    • ゾーンとは
      ドメイン名は管理の都合のためにゾーンカットでゾーンに区切られる
      管理の都合のためにゾーンに区切られる→RFC2181
      Delegationとは(委譲、委任)
  • 委譲の危ない話(lame delegationの乗っ取りリスク)
    とある会社が管理していたDNSサーバがかなり前から応答なし(2003年ごろから)
    委任を向けているのに応答がない(lame delegation)
    2005・5・18 NXDOMAINになっていた...
    whoisからもなくなっていた→買えてしまう
    夜道で迷子を見つけたら保護しますよね?ということで。。。

  • 属性ドメインなら?
    ac.jpなら問題ないと思っていたらそうでもなかった。。。

  • 共用サーバでのlame delegationの乗っ取り(実験)
    とあるレジストラに登録されたドメインに登録者に協力してもらい実験を行った
    ドメイン引越しをしてもらったときに引越し元と先を同時に設定していた最中に
    別アカウントで乗っ取れてしまった

  • 親子ゾーンの同居
    サービス運用上の問題に起因するドメインハイジャックの危険性について

  • 共用権威サーバにおけるゾーン乗っ取り(リスク)の要点
    誰でもゾーンが作れる共用権威サーバが危ない
    :
    (公開資料参照)
    :
    CNAMEを向けられていることはサービス運用者にはなかなかわからない
    そもそもの話、他人のドメイン名を借りること自体が危ない
    さらにいうと中古ドメイン名は危ない(中古を使うのも中古にするのも)

  • 本題
    同じ■■サーバから送信されたメールが■■■■■■■■■■■される
    問題は権利確認していないこと、対策は権利確認してもらうこと
    権利は移動するので常に確認が必要

  • Route■■では
    親子同居による乗っ取りできない
    lame delegationの乗っ取りは可能(公開情報)
    ゾーン削除のときに警告文が出てくるようになった

Q:レンタルサーバ作ったら勝手に委任先が決まってしまうのはすべての業者が確認してもらえそうですか?
A:事業者ごとに違うのでヒアリングしたほうがいい
コメント:権利関係を確認するまでに時間がかかるため、確認が完了しないことがある。
Q:メールサーバの■■■■■■はユーザ側で解決できるか。
A:事業者の協力なしではできない


感想:

DNSっぽい話ではありませんが、、、
24/365動いているプログラムを作る際、メモリリークのパフォーマンスチェックをします、
その際可能な限り負荷をかけ、長時間モニタリングを試験環境で行うことがあります。
OSSを使う場合どのように実運用しているのかと気になっていたことだったのですが、
同じように試験されていることを今回知りました。
またfuzzing試験について以前講習を受けたことがあったのですが、
その際、脆弱性のあるhttpサーバプログラムにリクエストを送る実演でCPU負荷が100%になっていたことを
見たことがあります。こうした試験で確認することは大事だな、と思いました。

DNSのブロッキングとフィルタリングという言葉を聞いたことがあるのですが、
これまで違いについて意識したことがなかったため、今回その違いと実際の取り組みについて
知ることができました。
またこの会があったのは4/23でした、その際にBINDのprivateフォルダが作成されていて、
ほぼ5営業日あとのタイミングで新しいバージョンが公開されていたのは、
予見が当たっていてすごいな、と。

わたしも個人でVPSを借りてWEBサイトを運用しています(これを書いている時点で)が、
DNSのサービスを利用しています。
次は共用のVPSサーバでメールサーバを構築してみようかと思い、一度検討したこともあったのですが、
今回その設計でのリスクを聞くことができてよかったと思いました。
あと資料にあった中華屋さんは点心がおいしいので、おすすめです。

<会場風景>

result
result

You can’t perform that action at this time.