DNS AMP Check
ネームサーバ診断 「DNSの再帰的な問合せを使ったDDoS攻撃」の踏み台になる可能性に関する診断です。 好ましくない設定(キャッシュを応答する)のサーバは毒入れに対しても脆弱となります。 放っておくと、大変なことになりますよ。 あなたのお使いの機器をチェックします。(IPv6未対応 mOm) 調べたいドメインがあればどうぞ (サブドメインも可ですが一部手抜きで診断できないかもしれません)。 その権威サーバが問題のある設定でキャッシュサーバを兼ねているとNGとなります。 ドメイン名 (診断に時間のかかる場合があります) 大量のドメインのチェックを行うとアクセス制限をさせて頂くかもしれません。ご利用は控えめに ;-) Lame Delegation など総合的な診断はDNS健全性チェッカーをどうぞ 参考: DNS の再帰的な問合せを使った DDoS 攻撃に関する注意喚起 DNS の再帰的な問合
（緊急）複数のDNSソフトウェアにおける脆弱性（システム資源の過度な消費）について（2014年12月25日更新）
--------------------------------------------------------------------- ■（緊急）複数のDNSソフトウェアにおける脆弱性（システム資源の過度な消費） について（2014年12月9日公開） - BIND 9では権威DNSサーバーにも限定的に影響、バージョンアップを強く推奨 - 株式会社日本レジストリサービス（JPRS） 初版作成 2014/12/09（Tue） 最終更新 2014/12/25（Thu） （米国The CERT Divisionの注意喚起・Vendor Informationへのリンクを追加） --------------------------------------------------------------------- ▼概要 BIND 9・Unbound・PowerDNS Recursorを含む複
複数の国内サイトがドメイン名ハイジャックされた件をまとめてみた - piyolog
2014年11月5日にJPCERT/CC、JPRSがドメイン名ハイジャックに関する注意喚起を公開しました。また同日日本経済新聞社が同社サイトがこの攻撃を受けていたことを速報で報じました。*1 ここでは関連情報をまとめます。 注意喚起・対策 JPCERT/CC 登録情報の不正書き換えによるドメイン名ハイジャックに関する注意喚起 JPRS （緊急）登録情報の不正書き換えによるドメイン名ハイジャックとその対策について（2014年11月5日公開） JPRS (PDF) 補足資料：登録情報の不正書き換えによるドメイン名ハイジャックとその対策について JPNIC IPアドレス・AS番号/ドメイン名に関する登録情報の不正書き換えに関する注意喚起 タイムライン 日付 出来事 9月第1週 Volexityが日経で不正なサイトへの接続を確認。 10月9日 VolexityがBlog記事を公開。 10月15日
DNSの「開いたパンドラの箱」を理解するために - 権威DNSサーバが返す5種類の応答とその意味 -:Geekなぺーじ
前回からかなり時間が経過してしまいましたが、やっと新書を書き終わったので、「DNSキャッシュポイズニングの基本と重要な対策」の続きです。 まだまだ先は長いのですが、今回は権威DNSサーバがキャッシュDNSサーバに返す5種類の応答とその意味について解説します。 権威DNSサーバからの5種類の応答 ユーザからの名前解決要求を受け取ったキャッシュDNSサーバは、ルートサーバを起点とするDNSの階層構造をたどって、名前解決を実行します。名前解決の際、キャッシュDNSサーバはユーザから問い合わせがあった「名前」と「型」を、権威DNSサーバにそのまま問い合わせます。そして、キャッシュDNSサーバはそれぞれの権威DNSサーバから返される応答を解釈しながら、名前解決を進めていきます。 名前解決において、キャッシュDNSサーバがそれぞれの権威DNSサーバから受け取る応答は、以下の5種類に分類できます。この5
キャッシュポイズニング攻撃対策
Copyright © 2014 株式会社日本レジストリサービス 1 キャッシュポイズニング攻撃対策： キャッシュDNSサーバー運用者向け―基本対策編 初版作成：2014年4月30日 最終更新：2014年4月30日 株式会社日本レジストリサービス（JPRS） 本資料の位置づけ • 本資料は以下の四部構成の資料の一部 – 対象者ごとに、キャッシュDNSサーバー運用者向けと 権威DNSサーバー運用者向けに大別 – それぞれを、基本対策編と応用対策編の二部で構成 Copyright © 2014 株式会社日本レジストリサービス 2 基本対策編（本資料） 応用対策編 基本対策編 応用対策編 キャッシュDNSサーバー運用者向け 権威DNSサーバー運用者向け 本資料の内容（基本対策編） • 本資料ではキャッシュDNSサーバー運用者向け の基本対策編として、以下の項目について解説 – おさらい（1）：キ
強烈なDNSキャッシュポイズニング手法が公開される:Geekなぺーじ
本日、JPRSが緊急の注意喚起を公表しました。 緊急）キャッシュポイズニング攻撃の危険性増加に伴うDNSサーバーの設定再確認について（2014年4月15日公開）- 問い合わせUDPポートのランダム化の速やかな確認・対応を強く推奨 それに対して、2月中旬に脆弱性を発見してJPRSへと報告していた鈴木氏(脆弱性は前野氏との共同発見)が、JPRSの注意喚起では「危険性をよく理解して対策をとるにあたって十分な情報が含まれているとはいえません」として、以下の情報を公開しています。 開いたパンドラの箱 - 長年放置されてきたDNSの恐るべき欠陥が明らかに キャッシュポイズニングの開いたパンドラの箱 キャッシュポイズニングの開いたパンドラの箱 - 2 - 本来であれば、より上位からの正規の回答が優先されなければならないはずなのに、下位側が優先される仕様になっているので、偽装されたデータが優先されてしまう
新たなDNSキャッシュポイズニング手法、第一フラグメント便乗攻撃について - 仙豆のレシピ
以前IPv6 summitに参加したときに聞いたお話の中にあった、昨年(2013年）8月に発表された新たなDNSキャッシュポイズニング手法「第一フラグメント便乗攻撃」について興味がわいたのでいろいろ調べたり実際にできるのかを試したりしてみました。（もちろん自分の管理するクローズドな環境で） 第一フラグメント便乗攻撃をグーグルで検索しても個人のブログ等が出てこないのでこれが第一「第一フラグメント便乗攻撃」便乗エントリです（別にうまくない） 攻撃コード等ありますが、けっして自分の管理する環境以外に使用しないでください 第一フラグメント便乗攻撃とは 第一フラグメント便乗攻撃とは、DNS応答がフラグメントされた場合DNS応答の同定に使える要素（UDPポート番号、問い合わせID、問い合わせ名）が一つ目のフラグメントにしかないことを利用し、二つ目のフラグメントを偽装することによって毒入れをするというD
8.8.8.8に対するBGPハイジャックの話:Geekなぺーじ
一昨日書いた記事に対する補足です。 まず、最初にBGPハイジャックそのものは、世界各所で毎月のように発生しており、別に珍しくもない話です。 そのほとんどが、意図的にトラフィックを乗っ取る目的で行われたものではなく、単なるオペレーションミスであると言われています。 BGPハイジャックで有名なのが、2008年にYouTubeへのトラフィックをパキスタンのISPが吸い込んでしまった事件(参考：RIPE-NCC: YouTube Hijacking: A RIPE NCC RIS case study)ですが、これも意図的にやったのではなく、パキスタン国内向けのネット検閲設定が外部に漏れてしまったというオペレーションミスだったと思われます。 オペレーションミスは、漏らしてしまった側だけではない可能性もあります。 そもそも、/32などのプレフィックス長を持つ経路はフィルタされていることが多いので、普
[PDF]中国でGreatだよ
中国でGreatだよ Matsuzaki ‘maz’ Yoshinobu <maz@iij.ad.jp> 2013/08 @ APNIC36 network maz@iij.ad.jp 1 何だかアクセスできないよ Twitter Facebook YouTube ERR_TIMED_OUT ERR_TIMED_OUT ERR_NAME_RESOLUTIN_FAILED maz@iij.ad.jp 2 APNICが用意したネットワークだよ • AS# – 24555 • IPアドレス – 220.247.144.0/20 - transited by AS7497 – 2001:df9::/32 - transited by AS4837 • キャッシュDNS – BIND9 – 同じネットワーク内でIPv4/IPv6 dual stack だよ maz@iij.ad.jp 3 Twitt
設定ガイド：オープンリゾルバー機能を停止するには【BIND編】
--------------------------------------------------------------------- ■設定ガイド：オープンリゾルバー機能を停止するには【BIND編】 株式会社日本レジストリサービス（JPRS） 初版作成 2013/04/18（Thu） --------------------------------------------------------------------- ▼はじめに 本資料は、オープンリゾルバーとして動作しているBINDを使ったDNSサーバー の設定を、簡単なステップで修正する事を目的としています。 オープンリゾルバーについての技術的な解説は本資料では行いません。手順 に沿った操作で設定を変更し、読者が運用するDNSサーバーがオープンリゾル バーではなくなることを目指しています。 オープンリゾルバーおよびそれを利用し
Home | DNS-OARC
The DNS Operations, Analysis, and Research Center (DNS-OARC) brings together key operators, implementors, and researchers on a trusted platform so they can coordinate responses to attacks and other concerns, share information and learn together. DNS-OARC has five key functions: Information Sharing. DNS-OARC provides a trusted, shared platform to allow the DNS operations community to share informat
技術解説：「DNS Reflector Attacks（DNSリフレクター攻撃）」について
--------------------------------------------------------------------- ■技術解説：「DNS Reflector Attacks（DNSリフレクター攻撃）」について 株式会社日本レジストリサービス（JPRS） 初版作成 2013/04/18（Thu） --------------------------------------------------------------------- ▼はじめに 2013年3月16日（協定世界時）[CISCO2013]から3月下旬にかけ、迷惑メール 対策の活動を進めている国際組織The Spamhaus Projectに対する攻撃に端を 発する、大規模かつ長期間にわたる分散サービス不能（DDoS）攻撃が発生し ました。 今回の攻撃ではこれまでで最大規模となる300Gbps以上のトラフィ
Truth of Kaminsky Bug
実験目的 Kaminsky が示した毒入れ手法は DNSプロトコルの欠陥によるものであり、非常に危険なものであるという論を根拠に DNSSEC が推進されている。しかし、BlackHat USA 2008 における Kaminsky の講演のスライドに示されている方法にはいろいろな点で疑義がある(Finchなど)。qmail.jp の前野氏からあれで毒が入ると思うかとの指摘を受けたこともあり、散々考えたが、私には Kaminsky のスライドどおりに毒が入ることがどうしても納得いかなかった。そして、Kaminskyが間違っている(あるいは嘘をついている)、あるいは、BIND には毒が入るバグがあって Kaminsky の攻撃手法が成功するというのではないかという仮説が引き出せる。これは前野氏が当初から洞察していたことであった。この仮説に基づくと、Kaminsky の発表から3年経った今、そ
当社DNSに関するお知らせ | さくらインターネット
お客様各位 さくらインターネット株式会社 平素よりさくらインターネットに格別のご愛顧を賜り、誠にありがとうございます。 さくらインターネットでは、レンタルサーバサービスやVPSサービスなどのサービスと 併せて、DNSサーバ機能をレンタルするネームサーバサービスを提供しております。 ネームサーバサービスにおいては、当社で取得頂いたドメインのほか、他のレジスト ラで取得されたドメイン名を、当社の管理する広域分散されたネームサーバに登録する ことができます。 その登録において、当社ではドメインの所有者確認を行っておりませんでしたが、 その影響について外部からの指摘や、社内調査によって判明した問題を鑑み順次仕様 変更等を行っております。 その問題点と対処内容、当社方針等についてご報告いたします。なお、本件は当社 のみならず大半の事業者においても同様のケースが報告されております。従いまして、 啓蒙も
「DNS浸透問題」は脆弱性だった！「幽霊ドメイン名脆弱性」:Geekなぺーじ
「浸透いうな！」という掛け声が一部界隈で有名な「DNS浸透問題（もしくは、DNS浸透いうな問題）」ですが、今年2月にDNS浸透問題の原因の一つとなっている現象と同じものに起因する新たな脆弱性が発表されました。 その名は「幽霊ドメイン名脆弱性(ghost domain names)」です。 一見、DNS浸透問題とは全く別の問題のように思える「幽霊ドメイン名脆弱性」ですが、それが発生する原因と状況をよく見ると、「あ！これってDNS浸透問題で言ってた話と同じ原因だよね！？」とわかります。 実際、後述する通り、幽霊ドメイン名脆弱性の発想をDNS浸透問題と組み合わせることで、他人のDNS引っ越しを妨害するDoS攻撃も可能になります。 そう考えると、問題発生原因を調べずに「DNSの浸透をお待ち下さい」で済ませてしまうのは脆弱性の放置であるという考え方もできそうです(*1)。 ここでは、幽霊ドメイン名脆
BIND 9.6.1でDNSSEC対応してみた - Soukaku's HENA-CHOKO Blog
ここの内容を参考にして、ウチのサーバでDNSSEC対応にしてみた。 DNS Security Extensions（略称DNSSEC）は、DNSにおける応答の正当性を保証するための拡張仕様である。サーバとクライアントの双方がこの拡張に対応し、かつ拡張機能を使った形式で該当ドメイン情報が登録されていれば、DNS応答の偽造や改竄を検出することができる。 DNS Security Extensions - Wikipedia 日本でもJPRSが.jpドメインでのDNSSEC対応を2010年から始めると言う状況だし、対応が出来ていないレジストラも多いようなので、"DNSSEC Look-aside Validation Registry"サービスを利用するのが、現時点ではベターなようです。 JPRSが正式にサービスを開始したら、.jpドメインの方はJPRSに合わせた対応にする事になると思うんだけ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
