トップ 追記

インターノット崩壊論者の独り言


EPIC2014
Google Public DNS (8.8.8.8, 8.8.4.4) 経由では本サイトにアクセスできないよう措置させて頂いております。

2021-03-31 DNS キャッシュサーバでのアクセス制限だけでは不十分

隠れオープンリゾルバのスキャナを作ってみた

Bernhard Müller が "IMPROVED DNS SPOOFING USING NODE RE-DELEGATION" という論文を発表し、カミンスキーが新たなキャッシュポイズニング手法を編み出したと称して間違った解説を行い世界を騒がせたのが 2008 年のことでした。

そしてキャッシュポイズニング対策として DNS キャッシュサーバのポートランダマイズが世界的に進められる中で、残存する未対策のサーバを発見し注意喚起するために私が Port Randomize Tester を作ったのは 10 年前 (2011年) でした。

また 2008 年当時は DNS 権威サーバの 8 割がオープンリゾルバという状況でしたが、JPCERT/CC などの活動でその対策も進み、その数は急激に減少しました。

しかし、このたびふと思い立ち、海外の某所から送信元を詐称したクエリを投げて調査を行ってみたところ想像以上に多くの隠れオープンリゾルバが残存していることがわかりました。調査対象としたのは私が管理している DNS コンテンツサーバ (この e-ontap.com や reflection.co.jp など 20 ドメインほどの権威サーバ) へのクエリログから抽出した約 100,000 の IP アドレスです。

スキャン総数は 104,979 アドレス、普通のオープンリゾルバ (A) が 4511 (4.3%)、詐称クエリに対してオープンなリゾルバ (B) が 8103 (7.7%)、B + (A - (A ∩ B)) は 10739 (10.2%) でした。

そしてその約 1 万件のうち PTR レコードが JP を指しているものが以下のように見つかりました。

JP全体: 707
AD.JP: 255
NE.JP: 177
CO.JP: 93
AC.JP: 44
OR.JP: 33
GO.JP: 13
ED.JP: 2
LG.JP: 1
PREF.*.JP: 1

想像以上の数でした。大手 ISP (AD.JP/NE.JP) や政府機関 (GO.JP) などにも隠れオープンリゾルバが多く見つかったため、これらのデータは JPCERT/CC へ 3/8 に報告してあります。

JPCERT/CC さんにも注意喚起を頑張って欲しいのですが、私も何か出来ないかと思って、調査に使ったスキャナを Port Randomize Tester から呼び出して訪問者のリゾルバがオープンかどうかを検査をできる機能を付け加えました。 Port Randomize Tester を訪問すると連携している海外某所のサーバからブラウザが使用しているリゾルバへ詐称クエリが飛び、そのリゾルバからのクエリを Port Randomize Tester で動いている権威サーバが検出して判定を行う仕組みです。

このページを訪問して、もし "openresolver for the world" だとか "openresolver against spoofing" とか赤い字で表示されたら、そのサーバはオープンでありリフレクション攻撃の踏み台やキャッシュポイズニングあるいは実装の脆弱性を突く攻撃に弱い可能性がありますから、当該サーバのネットワーク管理者に改善を促してください。

どういう詐称パケットを投げているかは詳しく説明しないほうがよいと思いますが、多くは Ingress Filtering つまり自組織の IP アドレスが外部から流入しない (また自組織の IP アドレス以外が外部に出ていかない) ようにするという基本的な対策が境界ルータ(あるいはファイアウォール)で行われていないことが原因です。適切に対策されていれば詐称パケットはそもそも組織のネットワークへ流入しません。DNS キャッシュサーバでのアクセス制限だけでは不十分だということを理解しましょう。

p.s: 対策状況の観察をこちらでつづけています。

本日のツッコミ(全5件) [ツッコミを入れる]

Before...

tss [攻撃者はこんなまだるっこしいサイトを利用してターゲットを探したりしませんよ。]

tss [なお、サーバを公開する予定はありません。JPドメイン(名)が公開対象です。]

だめじゃん [脆弱性をお伝えしてシステム管理者に修正をお願いして全然対応してくれないので、公開したくなる気持ちはわかります。攻撃し..]


2021-03-15 まあよくあること

損保ジャパンDC証券株式会社のドメインを預かっていました

場合によっては乗っ取りとも言われるかもしれませんが、穏便に言えば、彼らの使用しているドメイン名のネームサーバの一つを保護していたというのが良いでしょう。

SJDC.CO.JP がそのドメイン名ですが qmail.jp の前野年紀氏から危険な状態なので保護して欲しいと頼まれた後の経緯を以下に記します。

  • 2021.03.09 14:08 前野さんより awsdas-61.com の保護依頼
  • 2021.03.09 14:39 awsdas-61.com 登録
  • 2021.03.09 15:45 私から JPCERT/CC へ報告、対応依頼
  • 2021.03.09 17:20 JPCERT/CC から受領の自動応答
  • 2021.03.09 19:03 JPCERT/CC から対応の必要はない旨の回答
  • 2021.03.10 11:36 JPCERT/CC へその認識は間違っている旨を返答
  • 2021.03.10 14:30 JPCERT/CC から確認し適宜対応する旨の回答
  • 2021.03.10 14:44 ネームサーバ変更 (whois で確認)

JPCERT/CC さん、初動は勘違いなのか遅れたものの迅速な対応ありがとうございました。

問題はネームサーバの一つ ns-491.awsdns-61.com を間違って ns-491.awsdas-61.com として jp に登録していたことでした。awsdas-61.com を私が登録して保護していました。なお sjdc.co.jp のゾーンは作成せず無応答にしていましたので害は及ぼしておりません。せっかくの機会なので研究目的でクエリのログは観察させてもらいましたが「浸透おそい」なんていう現象はありませんでした :-)

ちなみに翌日に www.rk.sjdc.co.jp の CNAME の先で DNSSEC 検証失敗のトラブルはあったようですが本件とは関係ありませんね。

参考: whois

Before
 Domain Information: [ドメイン情報]
a. [ドメイン名]                 SJDC.CO.JP
e. [そしきめい]                 そんぽじゃぱんでぃーしーしょうけん かぶしきがいしゃ
f. [組織名]                     損保ジャパンDC証券株式会社
g. [Organization]               Sompo Japan DC Securities Inc.
k. [組織種別]                   株式会社
l. [Organization Type]          Company
m. [登録担当者]                 AT13583JP
n. [技術連絡担当者]             AT13583JP
p. [ネームサーバ]               ns-1273.awsdns-31.org
p. [ネームサーバ]               ns-579.awsdns-08.net
p. [ネームサーバ]               ns-491.awsdas-61.com
p. [ネームサーバ]               ns-1788.awsdns-31.co.uk
s. [署名鍵]                     
[状態]                          Connected (2021/06/30)
[登録年月日]                    2019/06/13
[接続年月日]                    2019/07/30
[最終更新]                      2020/10/20 17:20:54 (JST)
After
Domain Information: [ドメイン情報]
a. [ドメイン名]                 SJDC.CO.JP
e. [そしきめい]                 そんぽじゃぱんでぃーしーしょうけん かぶしきがいしゃ
f. [組織名]                     損保ジャパンDC証券株式会社
g. [Organization]               Sompo Japan DC Securities Inc.
k. [組織種別]                   株式会社
l. [Organization Type]          Company
m. [登録担当者]                 AT13583JP
n. [技術連絡担当者]             AT13583JP
p. [ネームサーバ]               ns-1273.awsdns-31.org
p. [ネームサーバ]               ns-579.awsdns-08.net
p. [ネームサーバ]               ns-491.awsdns-61.com
p. [ネームサーバ]               ns-1788.awsdns-31.co.uk
s. [署名鍵]                     
[状態]                          Connected (2021/06/30)
[登録年月日]                    2019/06/13
[接続年月日]                    2019/07/30
[最終更新]                      2021/03/10 14:44:48 (JST)
本日のツッコミ(全1件) [ツッコミを入れる]

tm [VISAドメイン問題解説 https:// www.e-ontap.com/summary/fornondns..]


2021-02-05 なぜいつまでも直せないのか?

JP サーバの不良と EDNS0 バッファサイズ

私から JPRS への一週間前の質問に回答が昨日来ていました。

JPRS が伝聞の形ながらようやく EDNS0 バッファサイズの推奨値を回答したのが画期的です。 (これまでは回答を拒んでいた)

要するに、、、

  1. JP サーバが問題のある動作をするのは既知の問題で RFC のせい
    JPRS が待っているのはたぶんこの I-D の RFC 化。RFC 1034 にたったこの一文
    "If glue RRs do not fit set TC=1 in the header."
    が加わらないと直せないということのようです。(言いたいことはあるけれどとりあえずノーコメント)
  2. DO bit が ON であれば少なくとも 1220 オクテットにしないといけない (RFC 4035 により MUST)
    (私は質問のためにあえて 565 オクテットにしていたので違反 / DO bit は off にして 512 にするのが私の推奨 / DNSSSEC は害)
  3. DNS Flag Day 2020ではフルサービスリゾルバーにおける EDNS バッファサイズとして 1,232バイトが推奨されている
  4. JP サーバーにおける DNS Flag Day 2020 で推奨される EDNS バッファサイズへの変更は現在検討中
ということですね。

From: info@jprs.jp
To: "T.Suzuki" <tss@e-ontap.com>
Cc: info@jprs.jp
Subject: Re: [JPRS info 410313] ends-buffer-size
Date: Thu, 04 Feb 2021 15:46:50 +0900
X-Mailer: Cybozu MailWise 5.1.3
 
鈴木 様
                                        株式会社日本レジストリサービス
													                                                     お客様サポート係
 
お問い合わせいただきましてありがとうございます。
 
> 1. 必要な glue がつかないのに TC フラグが立たない JP サーバは欠陥では
> ないでしょうか?
 
当該動作はDNSプロトコル上の問題である旨が指摘されており、問題を解決す
るためのプロトコルの修正が、インターネットドラフトとして提案されており
ます。
 
当社としては、標準化の動向を踏まえて対応を進める予定です。
 
> 2. edns-buffer-size: 565 がいけないということであれば、適切なサイズは
> いくつですか?
 
ご質問のdigコマンドにおいてUnboundから送出される問い合わせにはDO bitが
セットされており、RFC 4033における「security-aware resolver」として取
り扱われると承知しております。
 
その場合、EDNSバッファサイズには、RFC 4035 Section 4.1の記述が適用され
ると承知しております。ご参考までに、以下に引用いたします。
 
また、DNS Flag Day 2020ではフルサービスリゾルバーにおけるEDNSバッファ
サイズとして、1,232バイトが推奨されていると存じます。
 
>  A security-aware resolver MUST support a message size of at least
>  1220 octets, SHOULD support a message size of 4000 octets, and MUST
>  use the "sender's UDP payload size" field in the EDNS OPT pseudo-RR
>  to advertise the message size that it is willing to accept.  A
>  security-aware resolver's IP layer MUST handle fragmented UDP packets
>  correctly regardless of whether any such fragmented packets were
>  received via IPv4 or IPv6.  Please see [RFC1122], [RFC2460], and
>  [RFC3226] for discussion of these requirements.
 
> 3. 現在 JP サーバは ; EDNS: version: 0, flags: do; udp: 4096 という応答をし
>   てきますが、4096 というサイズは DNS flag day 2020 に対応していない危険なサイズ
>   ではないでしょうか? DNS flag day 2020 への対応予定を教えてください。
 
JP DNSサーバーにおける、DNS Flag Day 2020で推奨されるEDNSバッファサイ
ズへの変更につきましては、現在検討中です。
 
何かございましたらお手数ですが、以下の窓口までお問い合わせください。

ちなみに私の質問のメールは以下

From: "T.Suzuki" <tss@e-ontap.com>
To: info@jprs.jp
Subject: ends-buffer-size
Date: Thu, 28 Jan 2021 12:09:55 +0900
Organization: E-ONTAP
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.1)
 
お世話になっております。JP ドメイン利用者の鈴木と申します。
 
一部のドメイン名が Unbound (1.13.0) で引けない現象がおきています。
 
% dig www.chukyo-uac.jp
 
; <<>> DiG 9.9.5 <<>> www.chukyo-uac.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 33801
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 565
;; QUESTION SECTION:
;www.chukyo-uac.jp.		IN	A
 
;; Query time: 1481 msec
;; SERVER: 127.0.0.2#53(127.0.0.2)
;; WHEN: Thu Jan 28 11:50:17 JST 2021
;; MSG SIZE  rcvd: 46
 
% dig www.internat.jp
 
; <<>> DiG 9.9.5 <<>> www.internat.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 49684
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 565
;; QUESTION SECTION:
;www.internat.jp.		IN	A
 
;; Query time: 243 msec
;; SERVER: 127.0.0.2#53(127.0.0.2)
;; WHEN: Thu Jan 28 11:50:29 JST 2021
;; MSG SIZE  rcvd: 44
 
unbound.conf は以下のようになっています。
 
server:
	verbosity: 5
	interface: 127.0.0.2
	prefer-ip4: yes
	outgoing-num-tcp: 50
	edns-buffer-size: 565
	do-ip6: no
	logfile: "unbound.log"
	use-syslog: no
	harden-referral-path: no
	qname-minimisation: yes
	aggressive-nsec: no
	use-caps-for-id: no
	minimal-responses: no
	module-config: "iterator"
	auto-trust-anchor-file: "/usr/local/etc/unbound/root.key"
 
原因は edns-buffer-size: 565 なのに対して、以下のように glue も TC フラグも
立っていない応答が返ってきていることだと思います。
 
~% dig -t a www.internat.jp @a.dns.jp +dnssec +notcp +ignore +norec +qr +bufsize=565
 
; <<>> DiG 9.9.5 <<>> -t a www.internat.jp @a.dns.jp +dnssec +notcp +ignore +norec +qr +bufsize=565
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8815
;; flags: ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 565
;; QUESTION SECTION:
;www.internat.jp.		IN	A
 
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8815
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 1
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.internat.jp.		IN	A
 
;; AUTHORITY SECTION:
internat.jp.	86400	IN	NS	ns.internat.jp.
D4R30L9CETC680EV8UASC74TLJJOK5H2.jp. 900 IN NSEC3 1 1 8 80722445BE D4TOBSLK5IS3M3551DVTF68MN0O8J8S7 NS SOA RRSIG DNSKEY NSEC3PARAM
D4R30L9CETC680EV8UASC74TLJJOK5H2.jp. 900 IN RRSIG NSEC3 8 2 900 20210222174503 20210123174503 39945 jp. HP6LnfaNAar4I90csxRO8GEMvbfmLdNIcpwSxQnC7wtiaklHilryuH/j XGqkGGfSKuyQ1cKC/TyrV+v3IujaQj3j+osGcJCuyWs8l0zR9uxoEoPg z+yKKKm7pG28ZR/JOSappIJnrlm/Qrlv8zNcFMPvnoy0u8VhrGpawMMF w98=
41KTTL2MNI5RKK32378RH6QOPQLV3EQF.jp. 900 IN NSEC3 1 1 8 80722445BE 42Q5A65HN8KPQSFCTTJ2K946MUAF2P1N TXT RRSIG
41KTTL2MNI5RKK32378RH6QOPQLV3EQF.jp. 900 IN RRSIG NSEC3 8 2 900 20210222174503 20210123174503 39945 jp. mCQskVHnKp1UiF3phtcyW1uRu8W1s+unUOrBcL4PVBlcjIyGNCUxeR/G z6iR2Y5ooeaMfl7dtNFR9idggyUT46v8pAVcM9uqi/0/OZmxNSpGMKKQ kBSv+Pl1miIUnKk6nlIwuOkZjDuMJKJAuk24de3ZxN12aEJ/a4sJ5LdC +7Q=
 
;; Query time: 26 msec
;; SERVER: 203.119.1.1#53(203.119.1.1)
;; WHEN: Thu Jan 28 12:01:26 JST 2021
;; MSG SIZE  rcvd: 554
 
そこで質問です。
 
1. 必要な glue がつかないのに TC フラグが立たない JP サーバは欠陥ではないでしょうか?
 
2. edns-buffer-size: 565 がいけないということであれば、適切なサイズはいくつですか?
 
3. 現在 JP サーバは ; EDNS: version: 0, flags: do; udp: 4096 という応答をし
  てきますが、4096 というサイズは DNS flag day 2020 に対応していない危険なサイズ
  ではないでしょうか? DNS flag day 2020 への対応予定を教えてください。
 
--
------------------------------------------------------------------------------
T.Suzuki / E.F.シューマッハーとI.イリイチを読もう
『コンヴィヴィアリティのための道具』が文庫本になりました
本日のツッコミ(全1件) [ツッコミを入れる]

tss [ちなみに com は TC bit を立ててくる。RFC を待たないと直せないというのは理由にならないと思いますね。..]


2020-08-27 1.1.1.1 は大丈夫か?

Knot Resolver の危険なモード

Knot Resolver の permissive mode (寛容モード) は非常に危険なので、もしこれを普段使いしている人がいれば、即刻利用をやめることをお勧めします。

permissive mode は委譲を追いかける際に NS の A レコードが additional に付加されていたら、それをすべてノーチェックで信用することにより、検索を速くしようという趣旨のもののようです。

ふと悪い予感がしてある実験をしてみたところ、このモードが恐ろしく危険であることがわかりました。

以下はその実験の説明です。brau.jp へ毒入れを試みます。(すべて私が登録しているドメイン名です)

  1. 偽 brau.jp サーバへの誘導用ドメイン internat.jp を用意
    ~% dig @ns.internat.jp -t txt brau.internat.jp +norec
     
    ; <<>> DiG 9.9.5 <<>> @ns.internat.jp -t txt brau.internat.jp +norec
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53242
    ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
     
    ;; QUESTION SECTION:
    ;brau.internat.jp.	IN TXT
     
    ;; AUTHORITY SECTION:
    brau.internat.jp.	300 IN NS ns.brau.jp.
     
    ;; ADDITIONAL SECTION:
    ns.brau.jp.		300 IN A 150.42.6.9
    
    これは internat.jp から brau.internat.jp の委譲応答ですが、同居ゾーンを用いて Additional Section に ns.brau.jp の偽の A レコードを加えてあります。これは glue ではないので安全に考慮した実装であれば無視すべきものです。本物の ns.brau.jp は 150.42.6.4 です。

  2. Knot Resolver で brau.internat.jp の TXT レコードを検索
    ~% dig @127.0.0.3 -t txt brau.internat.jp 
     
    ; <<>> DiG 9.9.5 <<>> @127.0.0.3 -t txt brau.internat.jp
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8904
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
     
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;brau.internat.jp.	IN TXT
     
    ;; ANSWER SECTION:
    brau.internat.jp.	60 IN TXT "brau.internat.jp"
     
    本物の ns.brau.jp = 150.42.6.4 に brau.internat.jp ゾーンはありません。この TXT は 偽 ns.brau.jp = 150.42.6.9 に用意した brau.internat.jp ゾーンが応答したものです。minimal response なので分かり辛いのですがこの時点で 偽 ns.brau.jp = 150.42.6.9 がキャッシュされ、それに誘導されたものと考えられます。

  3. Knot Resolver で brau.jp の SOA レコードもしくは NS レコードを検索
    ~% dig @127.0.0.3 -t soa brau.jp
    (snip)
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
     
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;brau.jp.		IN SOA
     
    ;; ANSWER SECTION:
    brau.jp.		120 IN SOA ns.brau.jp. tss.e-ontap.com. (
    				2020082501 ; serial
    				3600       ; refresh (1 hour)
    				600        ; retry (10 minutes)
    				86400      ; expire (1 day)
    				60         ; minimum (1 minute)
    				)
    
    これは brau.jp の NS をキャッシュに入れるためです。NS を直接問い合わせてもよいです。Answer Section の SOA は本物の ns.brau.jp 由来のものです。Minimal response で分かり辛いですが、Authority Section から brau.jp IN NS ns.brau.jp. が、Additional Section から ns.brau.jp IN A 150.42.6.4 が返ってきているはずです。(パケットダンプで確認済)
    しかし、権威あるサーバからの 150.42.6.4 はすでにキャッシュにある 150.42.6.9 を上書きしないようです。ここが問題。

  4. Knot Resolver で brau.jp の TXT レコードを検索
    ~% dig @127.0.0.3 -t txt brau.jp
    (snip)
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
     
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;brau.jp.		IN TXT
     
    ;; ANSWER SECTION:
    brau.jp.		60 IN TXT "NG"
    
    この Answer Section の TXT "NG" は偽 ns.brau.jp 由来のものです。ステップ 2 で注入された偽 A レコードで誘導された結果だと考えられます。

以上からわかることは permissive mode の Knot Resolver には任意のドメインのキャッシュポイズニングが可能だということです。

そこで、開発元の NIC.CZ に問い合わせたところ以下の返事がありました。

Documentation for version 5.1.1 (at https://knot-resolver.readthedocs.io/en/v5.1.1/config-dnssec.html#mode) describes that "permissive mode" accepts all glue records without checks. This is definition of cache-poisoning security hole, so we can conclude that the permissive mode works as intended - and that's why it is not enabled by default.

要約すると「permissive mode はすべてのグルーレコードをノーチェックで受け入れる。これはキャッシュポイズニング脆弱性を意味している。貴方の指摘はその仕様どおりだと言える。我々がこのモードをデフォルトにしていない理由でもある」という回答です。

私はそんなことは承知で質問したのです。設計の趣旨はあくまで委譲を追いかけるための情報として referral に付随する A レコード (これを彼らは glue と読んでいますがそれは定義の間違い) を効率よく利用するためであり、もしその A レコードが悪意あるものだった場合に被害を受けるのは問い合わせ対象のドメインに限定されているはずだと考えていました。

ところが私の実験では特定条件下に置かれたドメインだけでなく、任意のドメインにキャッシュポイズニングができてしまいました。これは彼らの意図 (intended) から外れているのではないでしょうか。

まあ本当のところを追求すのは面倒なのでやめておきますが、permissive mode が危険なことは彼らも認めているわけなので、実験目的以外に使用するのは止めましょう。改めて文書を見るとこう書いてあります。

Knot Resolver uses secure configuration by default, and this configuration should not be changed unless absolutely necessary

なお、nic.cz からのメールの最後にはこうありました。(1.1.1.1 は?)

On the other hand we have not seen anyone relying on permissive mode for along time, so we might just remove it in next releases.

p.s.

ところでこの件は DNS 温泉常連の大塚さんのこのツイートに端を発しています。

これは 1.1.1.1 で私の実験のステップ 2 と同じ現象が起きていることを意味しているものです。1.1.1.1 は Knot Resolver を使用していると言われているのですが、これだけ見ても危険ではないかと疑われます。(どういう攻撃が可能であるかは解説を控えておきます)

そして私のゼミの M2 の太田くんから permissive mode で大塚さんの事例が再現できたという報告を受けたのが今回の実験の発端でした。

私の実験通りのことが 1.1.1.1 でも起きるとすれば大変なことなのですが、今のところ再現はできていません。さすがに permissive mode をそのまま運用しているわけではないでしょうが一抹の不安が残るところです。

labs.nic.cz からのメール

labs.nic.cz にブログの翻訳を送って意見を求めたところ以下の返信がありましたので転載しておきます。(転載は彼らも歓迎とのことです)

私の記事はあくまで permissive mode が危険なことを確認したまでであり、normal mode までが危険だという主張はしていないことをここに記しておきます。彼らの文書からはどれほど危険なのかが読み取れなかったので実験を行い、このモードに関する注意喚起の意味でブログを書いたまでです。

From: Petr Špaček <petr.spacek @ nic.cz>
To: "T.Suzuki" <tss @ e-ontap.com>
Cc: knot-resolver @ labs.nic.cz, Masato OTSUKA , Kenya Ohta 
Subject: Re: [knot-resolver@labs] a vulnerability of permissive mode
Date: Fri, 28 Aug 2020 09:22:35 +0200
Organization: CZ.NIC
  
Hello,
 
and thank you for sharing link to translation!
 
Unfortunatelly nobody in our team speaks Japanese so we are not able to write an explanatory article with reaction. For that reason I ask you to amend the article so it starts with information that _default is secure_ and that _only an explicit configuration can make it insecure_.
 
 
Rationale for this request:
 
Translation of the current version seems unnecessairly alarmist to me. From my perspective the current text says:
- Step 1: Explicitly configure Knot Resolver into insecure mode (which is documented).
- Step 2: Test that the explicit configuration is really insecure.
 
What is the purpose? I'm really confused, and I believe some readers might be confused as well.
 
The only explanation I could see is that documentation might be unclear in some aspect. If it is that case please be constructive and point out what exactly what is unclear/confusing so we can fix it. Articles with statements like "it's too much trouble to pursue the truths" do not help to improve software or documentation quality.
 
 
In similar spirit there could be an article saying "we disabled DNSSEC validation, and then our tests shown that this is insecure configuration, so do not use this configuration". It is exactly the same logic as the article above.
 
 
Also your article seems to imply that 1.1.1.1 should behave exactly the same as Knot Resolver, which is incorrect assumption. Cloudflare is heavily customising our code so they can provide features unique to 1.1.1.1. This naturally causes divergence in behavior.
 
In other words 1.1.1.1 is not equal to latest publicly available release of Knot Resolver. I would appreciate if you article clarified that aspect as well.
 
I ask you to amend the article as indicated above and thank you for your time.
Petr Špaček  @  CZ.NIC

2020-07-04 遠隔授業用に

DNS の仕組みを解説するスライドを作成した

私は大学で「コンピュータネットワーク」という授業を担当していたりします。例年だと教室の大きなホワイトボード全面を使って DNS の仕組みを解説しているのですが、今年は遠隔授業のため書画カメラを使って行おうとしたのですがうまくいきませんでした。

やむなく縦横無尽に図を描きながら講義する楽しみは諦めて、Keynote のスライドで講義することにしました。

ということで、せっかく苦手なパソコンを駆使して作成したスライドをここに公開しておきます。なお解説音声は公開しませんので悪しからず。(画像クリックでスライドへ)

DNS mechanism
本日のツッコミ(全1件) [ツッコミを入れる]

tss [forwarder は意味が混乱しているので注意が必要です。 http://www.e-ontap.com/dns..]


2020-06-23 ちょいとポイズニング

Sibling domain の glue に毒を入れる模擬実験

黒塗りの DNS の論文に書いた話のわかりやすい裏付けとして、sibling domain (兄弟ドメイン) の glue キャッシュの上書きを模擬的に実験しました。

以下は実験用のゾーンです。TLD として nom、悪意ある SLD として wine.nom、そして偽 nom を用意します。wine.nom には nom の NS である a.nic.nom を NS に加えておきます。

;172.18.1.1
;nom zone (before)
;
nom.                    86000   IN      NS      a.nic.nom.
a.nic.nom.              86400   IN      A       172.18.1.1
;
wine.nom.               86400   IN      NS      ns.wine.nom.
wine.nom.               86400   IN      NS      a.nic.nom.
ns.wine.nom.            86400   IN      A       172.18.1.2
 
;172.18.1.2
;fake nom zone
;
nom.	300	IN	NS	ns.fake.nom.
*.nom.	300	IN	A	172.18.1.2

まず、キャッシュサーバ (今回は Unbound 1.10) から wine.nom とは別の beer.nom に関する問い合わせを行っておきます。

root@server_unbound1:/ # dnsqr a www.beer.nom
1 www.beer.nom:
46 bytes, 1+1+0+0 records, response, noerror
query: 1 www.beer.nom
answer: www.beer.nom 60 A 172.18.1.2

beer.nom を名前解決する過程でキャッシュには root から nom への委譲で得られる a.nic.nom の A レコード 172.18.1.1 が入ります。これは RFC 2181 のキャッシュ優先度ランキングにおいて最下位のキャッシュです。

root@server_unbound1:/ # unbound-control dump_cache
START_RRSET_CACHE
;rrset 86388 1 0 1 0
a.nic.nom.	86388	IN	A	172.18.1.1
(snip)

次に偽応答を模擬するために nom zone を書き換えます。

;nom zone (after)
;
nom.                    86000   IN      NS      a.nic.nom.
a.nic.nom.              86400   IN      A       172.18.1.2

そして wine.nom の名前解決をキャッシュサーバに要求します。

root@server_unbound1:/ # dnsqr a www.wine.nom
1 www.wine.nom:
46 bytes, 1+1+0+0 records, response, noerror
query: 1 www.wine.nom
answer: www.wine.nom 10 A 172.18.1.2

このとき nom ゾーンはお節介にも wine.nom への委譲応答に含まれる a.nic.nom について偽の a.nic.nom の A レコードを Additional Section で返します。(本物ですが偽応答と差し替えることができるので模擬的に偽応答と同等と考えられます)

この A レコードは nic.nom のグルーではありますが、wine.nom のグルーではないので、ここで現れるべきものではないのです。(ちなみに実装は NSD を用いています)

root@server_unbound1:/ # dnsq a www.wine.nom 172.18.1.1
1 www.wine.nom:
99 bytes, 1+0+2+2 records, response, noerror
query: 1 www.wine.nom
authority: wine.nom 86400 NS ns.wine.nom
authority: wine.nom 86400 NS a.nic.nom
additional: ns.wine.nom 86400 A 172.18.1.2
additional: a.nic.nom 86400 A 172.18.1.2

さてお立ち会い。ここでキャッシュをダンプしてみると、172.18.1.1 だった a.nic.nom のキャッシュが TTL が切れてもいなかったのに上書きされています。

root@server_unbound1:/ # unbound-control dump_cache
START_RRSET_CACHE
;rrset 296 1 0 3 0
ns2.wine.nom.	296	IN	A	172.18.5.2
;rrset 86396 1 0 1 0
a.nic.nom.	86396	IN	A	172.18.1.2
(snip)

そして念押しで存在しないはずの名前を問い合わせてみると、キャッシュサーバは偽 nom ゾーンに問い合わせてその答えを返してきます。

root@server_unbound1:/ # dnsqr a nonexistent.nom
1 nonexistent.nom:
49 bytes, 1+1+0+0 records, response, noerror
query: 1 nonexistent.nom
answer: nonexistent.nom 300 A 172.18.1.2

結論: 委譲応答に余計についてくる sibling domain の A レコードを受け入れるキャッシュサーバは危険です。真のグルー以外を受け入れてはいけません。(残念ながらメジャーな実装たちはこの危険な A レコードを受け入れます。)


2020-05-27 JPDIRECT への返信

ホスト情報取扱いの改善のお願いをしてみた

「無駄で危険なホスト情報の話 (とりいそぎ)」の続きです。JPDIRECT へ以下の返信をしました。

お世話になっております。
 
以下、了解しました。ありがとうございます。
 
jp ドメインは net/com/org よりは綺麗だと認識していますので、彼らに対して改善のイニシャティブをとって頂けると嬉しいです。
 
com/net/org の運用が jp よりなぜ危険かは私から説明するまでもないでしょう。
jp はそのために掃除がなされてきたのですから。
 
ただ、EPP についてはその解釈の危険性の認識が jp (JPRS さん) の運用を含めて認識が不十分で危険だと思いますので、変更の働きかけについてご検討をお願いしたいと思います。
 
参考: Sibling glue は DNS 第一フラグメント便乗攻撃に脆弱
   http://www.e-ontap.com/dns/csec87/#(23)
   (論文 http://www.e-ontap.com/dns/csec87/paper.html)

続きはまた

5/29 追記: JPDIRECTからの返信

ご指摘の事象を確認の上、適切な場での紹介など、対応を検討するよう
申し添えた上で、社内共有いたします。
 
なお、ご指摘の事象は他レジストリが管理するTLDの仕様によるものであり、
他レジストリにおける仕様変更はJPRSからはお約束しかねる旨、ご理解くだ
さいますようよろしくお願いいたします。
 
今後ともよろしくお願い申し上げます。

2020-05-22 良いのかこれで?

無駄で危険なホスト情報の話 (とりいそぎ)

無駄で危険なホスト情報の話をしたいのですが、まずは JPDIRECT (JPRS) に質問していた件に対して回答があったので掲載しておきます。どういう話なのかは追ってここに詳しく書きたいと思います。

私から JPDIRECT への質問 (JPDIRECT のウェブフォームより)

tkix.net のネームサーバに b.ns.spam18.net を付け加えようとしたところ、エラーが出て登録できませんでした。エラーが不親切 (注:使用できない文字が含まれているか、未登録の情報を入力しているため、申請できません) で理由がわかりませんでしたが、超能力を駆使して b.ns.spam18.net のホスト情報を登録してみました。たまたま spam18.net も私が管理者で御社をレジストラとしていたのでホスト情報の登録は出来ました。この状態で上記のネームサーバ変更を行ったところ、なぜか無事に変更完了しました。

質問です。
なぜ、glue でも sibling glue でもない不要な b.ns.spam18.net のホスト情報登録が必要なのでしょうか。そしてなぜ net がこれを受け入れ、委任応答 (referral の additional) にまで (sibling glue) でもないのに出してくるのでしょうか

JPDIRECT からの回答

                                      株式会社日本レジストリサービス
                                            JPDirectお客様サポート係 
 
JPDirectをご利用いただき、誠にありがとうございます。
 
お問い合わせいただいておりました、ホスト情報の登録について、回答
いたします。
 
「.net」は米国Verisign社がレジストリとして管理しているドメイン名ですが、
レジストリより.netドメイン名に対して.netのネームサーバーを登録する
際には、事前にホスト情報を登録するように要求されているため、
レジストラであるJPRS、またその指定事業者であるJPDirectでもその仕様に
従ってホストの情報登録をお願いしているものです。
(なお、.comでも同様の仕様となっております)
 
  ※本件についてレジストリ(Verisign)の定めている仕様や規程でご確認
    いただける資料がないか、JPRSのgTLDレジストラ部門にも確認いたしま
    したが、レジストリから一般向けに公開されている資料がないとの回答
    がございました。
  
なお、ほとんどのgTLDドメイン名は、レジストリ・レジストラ間通信のための 
プロトコルとしてEPPを利用しています。 
EPP上でのホスト情報の取り扱いについては、以下のRFCで規定されています。 
 
  Extensible Provisioning Protocol (EPP) Domain Name Mapping 
   <https://tools.ietf.org/html/rfc5731>
 
この仕様にのっとり、gTLDの場合、 
    内部(internal)ホスト:ドメイン名と同じTLDを用いたホスト名 
    外部(external)ホスト:ドメイン名とは異なるTLDを用いたホスト名 
という定義をしており、TLDが同じ場合はすべて内部ホストとして扱い、
「内部ホストはホスト情報の登録が必要」という仕様となっている
レジストリが多いようです。 
 
以上、ご確認の程よろしくお願いいたします。

EPP に問題があるかも。そして内部名の定義の問題。話の続きはまた今度。

本日のツッコミ(全1件) [ツッコミを入れる]

tm [JP レジストリとしてのJPRSはここに書かれたcom/netとは異なる運用になっています。 そのことについて..]


2020-03-27 憶測ばかりしていないで

感染シミュレーションしてみよう

以前、浸透シミュレーションというのをやってみましたが、それに用いたマルチエージェントシミュレータ artisoc の開発元である構造計画研究所さんが「流行伝搬モデル」を公開してくださっています。

これでウイルス感染の簡易なシミュレーションを行うことが出来ます。詳しい説明は構造計画研究所さんにお任せして以下結果だけ紹介しておきます。尚、これが今話題のウイルスの特性を表しているわけではありませんのでご注意ください。あくまで一般的なモデルによるものです。



シミュレーションの動き

左上が人 (エージェント) の動きです。緑が感受性者(Susceptible) =まだ病気に感染していなくて感染の可能性のある状態の人、赤が感染者(Infectious) =病気に感染して、感染させる能力のある状態の人、青が除去者(Removed) =病気から回復して免疫保持した状態、あるいは物理的制度的に隔離されて感染させる能力を封じられた状態、あるいは病気により死亡した状態の人です。

左下は基本再生産数 (一人の感染者が平均何人の感染者を生むか)、右のグラフは左上のエージェントたちの数を表しています。



I. 再感染しない場合 (SIRモデル) のシミュレーション

(1) 基準として移動速度 0.5 の SIR モデルを動かしてみた。

人がシミュレーション 2 ターンに 1 マス動く場合です。他のパラメータは図を参照ください。



(2) 移動速度を落とした場合のシミュレーション (移動速度 0.1)

爆発的感染は防げますが、だらだらと感染が続くのがわかります。



II. 再感染する場合 (SIRSモデル) のシミュレーション

(1) 免疫がすぐ消える場合どうなるんだという質問に答えてみた。
まずは免疫期間 20 ターン



(2) 免疫期間を延ばしてみたシミュレーション (免疫期間 180)

180ターンまで延ばしてみた。



(3) 免疫期間を延ばしてみたシミュレーション (免疫期間 500)

500ターンまで延ばしてみた。


2020-02-24 検疫所がドメインを検疫される事態に

厚生労働省検疫所が DNSSEC の運用に失敗

厚生労働省検疫所のドメイン forth.go.jp の DNSSEC 署名が 2 月 23 日 0 時 10 分に署名の期限が切れて現在 (2/24 22:35) も署名検証に失敗する状態になっています。新型コロナウイルス COVID-19 の影響でしょうか。 (追記: 20200225084916 UTC に再署名で復活)

DNSSEC の署名を検証している DNS キャッシュサーバ (1.1.1.1 とか 8.8.8.8 とか IIJ とか) をお使いの方々はアクセスできないと思います。必要なときに貴重な情報にアクセスできないのは困りますね。


drill によるトレース

~% drill -t -S forth.go.jp soa
;; Number of trusted keys: 1
;; Chasing: forth.go.jp. SOA
 
DNSSEC Trust tree:
forth.go.jp. (SOA)
|---DNSSEC signature has expired:
forth.go.jp.	600	IN	RRSIG	SOA 8 3 600 20200223001003 20190228001003 64740 forth.go.jp. aSMXSVJX6QLDYlz2YWtFKTnHJU6OEpqGa9h+EC31MFN2kdgC72rVzI034VIetNDHtyoNMdYMLppf8LpFs3ZvF9ZFPUIINQ6kUL1LaFmvEiIgHe6bWS72Uhzdh/3tFqsAAKppj6GBZvyZ8T612uDbqetikYCgduGZcNf7C/h/CEk=
For RRset:
forth.go.jp.	600	IN	SOA	a1-134.akam.net. root.forth.go.jp. 2019030101 3600 7200 1209600 600
With key:
forth.go.jp.	600	IN	DNSKEY	256 3 8 AwEAAcCn8faiJWlroR4GIGmag7BwoehMKjHMgfXZPDPX3rkZkYVtVzxyUQeLNdCeaNuooORh+iviTzkYNTcR8V+VHiSdW/J7u0hodauBEc4VPtoXz81eeslvx1jwe+hJYivq4lPHuxqh4Id/scTBDTU+KqmmTdYhHTUANC9KiaVMvehZ ;{id = 64740 (zsk), size = 1024b}
|---forth.go.jp. (DNSKEY keytag: 64740 alg: 8 flags: 256)
    |---DNSSEC signature has expired:
forth.go.jp.	600	IN	RRSIG	DNSKEY 8 3 600 20200223001003 20190228001003 49357 forth.go.jp. NRCHOA15fTkxlW3G09DN/qv/6frRq8LBxT2nRwaLwpFnLiyj91KGwH19qyZfPpczObjjDV9MOcxgAEh6cI6xfq2DYBvQMXgP3R3F5YHISup5ZCgt5xiqURM9XSLinye8+xpeBY6WWF8TGDP1X8MnPrg0thjv8XTvd8345ZXCwwO/XEelhviaNdcm3IfoMxcAAZ18+2XJ71evy+JpmUlHDn9AQh51DcGxJUrUOP7OXQBNfzZ2XNujvCBPedFQ/hqNMXBMJ34ypfk7GkSkh2d+hxsrjpHt0FsmC9LMHGdL6j5RFa6aGvd2F/6hSnawd5eojqMUMqZIFfCivYxHdiKZpQ==
For RRset:
forth.go.jp.	600	IN	DNSKEY	256 3 8 AwEAAcCn8faiJWlroR4GIGmag7BwoehMKjHMgfXZPDPX3rkZkYVtVzxyUQeLNdCeaNuooORh+iviTzkYNTcR8V+VHiSdW/J7u0hodauBEc4VPtoXz81eeslvx1jwe+hJYivq4lPHuxqh4Id/scTBDTU+KqmmTdYhHTUANC9KiaVMvehZ ;{id = 64740 (zsk), size = 1024b}
forth.go.jp.	600	IN	DNSKEY	257 3 8 AwEAAey5c0+CPF4gPQpB0jo4nW8UkTxbNa5avUcaVCkCXuASxV+Y28wTwcM5L4oAjft5B/Vq105eDC9FCJnm4Rq/F2wrV//zhD9w1bvTUuQ4ecYCLoOvMULJXxB4BPjN9HSTAzobKsD74Sd3Q5ruW1wZiD3sixxKMpccermXJaOfHBPWid/sL1iFIjGXWbr3MF8zXHc5AdSwVVdU4b74mJ5SWgDplJq81uMikzmMxWI3gFej+sn4t1MABLfL2n1W/e8oAfStqGLcbpsbaMFCrTUVwSe/KnyEPhRQVaDaAb8q6j6xnMD3+/YiSWJ3U25s63T/UUd7ExgO77eIi+/okmysb80= ;{id = 49357 (ksk), size = 2048b}
With key:
forth.go.jp.	600	IN	DNSKEY	257 3 8 AwEAAey5c0+CPF4gPQpB0jo4nW8UkTxbNa5avUcaVCkCXuASxV+Y28wTwcM5L4oAjft5B/Vq105eDC9FCJnm4Rq/F2wrV//zhD9w1bvTUuQ4ecYCLoOvMULJXxB4BPjN9HSTAzobKsD74Sd3Q5ruW1wZiD3sixxKMpccermXJaOfHBPWid/sL1iFIjGXWbr3MF8zXHc5AdSwVVdU4b74mJ5SWgDplJq81uMikzmMxWI3gFej+sn4t1MABLfL2n1W/e8oAfStqGLcbpsbaMFCrTUVwSe/KnyEPhRQVaDaAb8q6j6xnMD3+/YiSWJ3U25s63T/UUd7ExgO77eIi+/okmysb80= ;{id = 49357 (ksk), size = 2048b}
    |---forth.go.jp. (DNSKEY keytag: 49357 alg: 8 flags: 257)
    |---forth.go.jp. (DS keytag: 49357 digest type: 2)
        |---jp. (DNSKEY keytag: 2661 alg: 8 flags: 256)
            |---jp. (DNSKEY keytag: 39595 alg: 8 flags: 257)
            |---jp. (DS keytag: 39595 digest type: 2)
                |---. (DNSKEY keytag: 33853 alg: 8 flags: 256)
                    |---. (DNSKEY keytag: 20326 alg: 8 flags: 257)
No trusted keys found in tree: first error was: DNSSEC signature has expired
;; Chase failed.

1.1.1.1 の応答

~% drill -D www.forth.go.jp @1.1.1.1
;; ->>HEADER<<- opcode: QUERY, rcode: SERVFAIL, id: 15363
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; www.forth.go.jp.	IN	A
 
;; ANSWER SECTION:
 
;; AUTHORITY SECTION:
 
;; ADDITIONAL SECTION:
 
;; Query time: 13 msec
;; SERVER: 1.1.1.1
;; WHEN: Mon Feb 24 22:36:48 2020
;; MSG SIZE  rcvd: 33

DNSViz

DNSSEC署名検証しているか確認するページを作りました

ふと IIJ が DNSSEC 署名検証を始めたことを思い出して、IIJ Public DNSサービスFirefox の DoH (DNS over HTTPS) サーバとして設定し、上記の www.forth.go.jp をブラウザで見たところ閲覧できてしまいした。

これはおかしい、ひょっとして IIJ が (中の人はそういうことはしないつもりだとおっしゃっていましたが) RPZ で検証から除外しているのかと思い、署名検証失敗を確認できるサイトを作りました。以下をお試しください。署名検証が適切になされていれば見られないはずです。

http://dnssec-failed.mufj.jp

しかし、このサイトもやはり IIJ の DoH を設定した Firefox で見えてしまいました。署名検証しているはずなのに検証失敗するはずのサイトが見えてはいけないだろうと調べたところ、原因は DoH を有効にしたときのデフォルトが network.trr.mode = 2 となっていたことでした。2 では DNS Over HTTPS を優先するが、失敗すると DoH から OS に設定されたリゾルバにフォールバックするとのこと。私が普段使用しているのは DNSSEC を無効にした Unbound だったので名前解決できてしまっていたわけです。これでは DNSSEC 対応している DoH を使う意味がありませんね。

network.trr.mode = 3 とすると無事?に http://dnssec-failed.mufj.jpforth.go.jp も見られなくなったのですが、暫くするとあらゆるサイトが見られなくなりました。これは network.trr.bootstrapAddress を設定していなかったのが原因でした。network.trr.uri に設定された URI のドメイン名が DoH で引けなくなっていたのですね。(なお bootstrapAddress は Firefox 74 で設定不要になるとのこと)


参考:


最近の日記

2008|04|05|06|07|08|10|11|
2009|02|03|04|06|07|09|10|11|
2010|01|03|06|09|10|11|12|
2011|01|02|03|05|06|07|10|11|
2012|03|06|07|10|11|12|
2013|02|03|04|05|06|08|09|10|11|
2014|01|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|07|08|09|10|11|12|
2016|01|06|08|12|
2017|03|07|08|09|12|
2018|04|08|10|11|
2019|01|02|07|11|12|
2020|01|02|03|05|06|07|08|
2021|02|03|

リンク

Copyright by T.Suzuki