強烈なDNSキャッシュポイズニング手法が公開される:Geekなぺーじ
本日、JPRSが緊急の注意喚起を公表しました。 緊急）キャッシュポイズニング攻撃の危険性増加に伴うDNSサーバーの設定再確認について（2014年4月15日公開）- 問い合わせUDPポートのランダム化の速やかな確認・対応を強く推奨 それに対して、2月中旬に脆弱性を発見してJPRSへと報告していた鈴木氏(脆弱性は前野氏との共同発見)が、JPRSの注意喚起では「危険性をよく理解して対策をとるにあたって十分な情報が含まれているとはいえません」として、以下の情報を公開しています。 開いたパンドラの箱 - 長年放置されてきたDNSの恐るべき欠陥が明らかに キャッシュポイズニングの開いたパンドラの箱 キャッシュポイズニングの開いたパンドラの箱 - 2 - 本来であれば、より上位からの正規の回答が優先されなければならないはずなのに、下位側が優先される仕様になっているので、偽装されたデータが優先されてしまう
インターノット崩壊論者の独り言 - 開いたパンドラの箱 - 長年放置されてきた DNS の恐るべき欠陥が明らかに
EPIC2014 Google Public DNS (8.8.8.8, 8.8.4.4) および Cloudflare (1.1.1.1, 1.0.0.1) 経由では本サイトにアクセスできないよう措置させて頂いております。 本日、JPRS がようやく重い腰をあげて注意喚起を発してくれましたが、その内容は危険性をよく理解して対策をとるにあたって十分な情報が含まれているとはいえません。 一方で注意深い攻撃者が探せば、ネット上にはすでに深刻な攻撃を行うのに必要な情報は十分に流れています。特に、JPRS が3月に慌てて co.jp などにこっそり入れた署名付き TXT レコードは大きなヒントに見えます。 DNS に詳しい攻撃者であれば、攻撃手法に辿りつくのは時間の問題でしょう。(すでに攻撃は行われているかも知れません) 長く秘密にしておくことは得策ではないと判断し、防御する側の心構えと手助けにし
キャッシュポイズニングの開いたパンドラの箱 -2-
キャッシュポイズニングの開いたパンドラの箱 -2- Opened Pandora's box of Cache Poisoning -2- 鈴木常彦 2014.04.15 (Concept by 前野年紀 2014.02) 移転インジェクション攻撃: RFC2181 5.4.1 "Ranking data" の欠陥 今回、委任インジェクション攻撃に加え、さらに RFC2181 の欠陥を突いた攻撃が可能であることを確認した。 委譲元から得た最低ランクの NS キャッシュを、偽権威の Answer に付随する Authority Section の NS で上書きして毒入れすることができ、そのゾーンを自由にできる。 これにより、現状では別途示した 1, 2, 3 の条件に関係なく容易に毒入れすることが可能である。 攻撃者は以下のようにターゲットのゾーンの NS を偽権威に向けることができる。
キャッシュポイズニングの開いたパンドラの箱
キャッシュポイズニングの開いたパンドラの箱 Opened Pandora's box of Cache Poisoning 鈴木常彦 2014.04.15 (Concept by 前野年紀 2014.02) / English version 背景 Kaminsky 2008年、Dan Kaminsky 氏が TTL に影響されない毒入れ手法を発表した。 しかし、偽応答のAdditional Section で毒が入るとされたのは誤りだったことを2011年に鈴木が明かにした。 http://www.e-ontap.com/dns/bindmatrix.html Müller Bernhard Müller の "IMPROVED DNS SPOOFING USING NODE RE-DELEGATION", 2008.7.14 https://www.sec-consult.c
Root Server Technical Operations Association
As of 2024-09-30T13:15:47Z, the root server system consists of 1917 instances operated by the 12 independent root server operators. The 13 root name servers are operated by 12 independent organisations. You can find more information about each of these organisations by visiting their homepage as found in the 'Operator' field below. Technical questions about the Root Server System as a whole can be
XName site - Free DNS Hosting Service
This Free DNS hosting service is provided to help people that don't want to lose time and money with providers not always reactive to DNS changes. We can provide you primary and secondary name server for free (but if you like this service, please contribute !) All zones hosted as primary or secondary on our main server - ns0.xname.org, are automatically replicated on our secondary servers, ns1.xna
named.conf の設定
### /etc/named.conf root:root 644 ### acl "internal-acl" { 127/8; 192.168.0/24; }; include "/etc/rndc.key"; controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { rndc-key; }; }; include "/etc/host1.key"; logging { channel "default_syslog" { syslog daemon; severity info; }; channel "default_debug" { file "named.run"; severity dynamic; }; channel "null" { null; }; category "unmatched" { "nu
IPv4アドレス移転履歴 - JPNIC
この履歴はJPNICが定めるIPv4アドレス移転申請手続きに基づき公開するものです。 JPNICでは下記の移転履歴に関するお問い合わせには応じられませんので、 あらかじめご了承ください。
DNSSEC のこと調べようと思ったら for 文で RSA を decrypto したの巻 - してみんとて
今年に入ってレジストリの JPRS さんが DNSSEC に対応なさいました (JPドメイン名におけるDNSSEC運用ステートメント（JP DPS）) 。その関係で DNSSEC のこと少しくらいお勉強しないとなぁと思ったわけですが、「要するに RSA で署名しちゃうわけなんでしょ〜」って理解だけだと何なので一応手を動かしてみることにしました。 DNSSEC は、各ゾーン毎で各レコードセットに署名をしてレコード情報の改竄が検知できるようにします (RRSIG レコード)。運用の簡便化の為に公開鍵は 2 つ用意されてます (DNSKEY レコードの ZSK と KSK)。KSK のハッシュなどを上位ドメインに登録してもらうことで「上位ドメインが信じれれば当該ドメインも信じれる」という信頼のチェーンを作ります (DS レコード)。詳しくは、ググってね。 つわけで、ターゲットは www.dnss
DNSSEC 関連情報 ～DNSSEC資料集～ / JPRS
DNSSECとは[PDF:748KB]（2011/01/14公開） BIND 9.7の新機能を利用した権威DNSサーバの運用[PDF:119KB]（2011/01/18更新） ルートゾーンにおけるKSKの管理方法（2010/07/13公開） JPドメイン名におけるDNSSEC運用ステートメント（JP DPS）v1.4（2015/10/01実施） [参考訳（英語）]（2015/10/01実施） DNSSEC機能確認手順書v1.2[PDF:1,272KB]（2010/07/21公開） DNSSEC性能確認手順書v1.2[PDF:309KB]（2010/07/21公開） DNSSEC技術実験報告書 機能・性能確認編[PDF:1,103KB]（2010/09/07公開）英語版[PDF:1,110KB]（2011/11/28公開） DNSSEC技術実験報告書 運用設計編[PDF:521KB]（201
次世代のセキュリティ拡張DNSSECをBIND 9で実現
次世代のセキュリティ拡張DNSSECをBIND 9で実現：実用 BIND 9で作るDNSサーバ（13）（1/3 ページ） 現在、標準化作業が進行中のDNSSEC。その仕組みとBIND 9での実現方法を解説する。後半では、スプリットDNSの設定方法を紹介。（編集局） 今回は、DNSのセキュリティ拡張である「DNSSEC」とスプリットDNSを実現する「VIEW」について解説します。DNSSECは、まだ標準化の議論が活発に行われている最中です。そのためBIND 9では実装が不完全なものもあります。 ゾーン情報の信頼性を保証するDNSSEC 第9回で、ゾーン情報が改ざんされる危険を回避する手段としてDNSSEC（DNS Security Extension：DNSセキュリティ拡張）を紹介しました。現在、DNSSECはIETFのDNSEXT（DNS Extensions）ワーキンググループで標準化の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DNS/毒盛/Kaminsky手法/対策はある - moin.qmail.jp
http://jprs.jp/tech/material/rfc/RFC5155-ja.txt
Preventing DNS cache poisoning when reusing source ports
DNS/毒盛/Mueller手法 - moin.qmail.jp
intoDNS: checks DNS and mail servers health
http://www.zonecheck.fr/
DNSの設定チェック
http://jprs.jp/tech/material/id/draft-ietf-dnsop-rfc4641bis-04-ja.txt
Unboundの紹介