トップ 最新 追記

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


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

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)
本日のツッコミ(全2件) [ツッコミを入れる]

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

tm [損保ジャパンDC証券からの連絡はあったのでしょうか。]


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 あらため Hidden Open Resolver Tester を訪問すると連携している海外某所のサーバからブラウザが使用しているリゾルバへ詐称クエリが飛び、そのリゾルバからのクエリを Hidden Open Resolver Tester で動いている権威サーバが検出して判定を行う仕組みです。

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

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

p.s: 対策状況の観察をこちらでつづけています。2021/9/7 リスト公開しました。

NGK2022S の LT で使用した解説スライドを公開しました。


最近の日記

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|09|12|
2022|02|03|05|06|
2024|02|

リンク

Copyright by T.Suzuki