DNSの完全性を守るためにすべきこと：IIJ DNSプラットフォームサービスのスゴいところ(第3回)
2020年04月23日 木曜日
CONTENTS
はじめに
IIJ DNSプラットフォームサービスのスゴいところを紹介するシリーズの第3回です。バックナンバーはこちら。
セキュリティの3要素はCIAといわれます。すなわち、機密性(Confidentiality)、完全性(Integrity)、可用性(Availability)です。このうち可用性については前回の記事で説明しました。また、機密性については触れません。なぜなら、DNSは機密性を保護するための仕組みがそもそも存在しないからです。最近ちょくちょく話題になるDoH/DoTはまさに機密性のためのプロトコルですが、あれはユーザとフルリゾルバ(キャッシュDNS)の間の機密性を保護するものであって、権威DNSサーバへの通信の機密性を保護するものではありません。もし将来ADoT(権威サーバへのDoT)が標準化されることがあれば対応を検討するかも、ぐらいですかね。
ということで、今回のテーマはCIAのI、完全性です。
完全性とはつまり「情報が改竄されないこと」で、DNSではDNSSECが代表的なものです。でも、みなさんDNSSECにはアレルギーがあるみたいで説明しても読んでもらえなさそうなので、記事の後半にまわします。まずはDNSSEC以外の話から。
認証と認可
昨年はじめ、DNS設定の改竄事案が多数発生しているとして、アメリカ国土安全保障省の情報セキュリティ部門から緊急指令が発せられました。DNSで改竄といえばキャッシュポイズニングがまず思い浮かびますが、この件はそうではなく、権威DNSサーバやレジストリの登録情報そのものを不正に書き換える手口が中心だったようです。書き換える手段が不正だったとしても、書き換えた結果の整合性が取れていればそれを検知することはできません。たとえDNSSEC署名していたとしても、秘密鍵にアクセスされてしまえば改竄されたレコードに正当な署名を付与されてしまいますし、レジストリに登録されたDSレコードが削除されれば署名検証が無効化されてしまいます。DNSの改竄を防ぐのにもっとも重要なのは登録情報そのものが不正に書き換えられないよう守ることです。DNSSECはその後です。
ではどうやって不正に改竄されたのでしょうか。この緊急指令ではその具体的な方法についての言及はありませんが、記載された対策内容から推測するに、権威DNSサーバやレジストラにログインするためのアカウント情報を不正に窃取するなどの手法が取られたものと思われます。この件では「お前のところは大丈夫なのか」というお問い合わせもたくさんいただきましたが、「うちでできることはちゃんとやってる。それ以上に、お客様自身がアカウント/パスワードの管理をしっかりやってね、二要素認証やアクセス元制限できるからその設定をしてね」という回答をさしあげました。
しかし、これまではアカウントを「認証」しかしていませんでした。認証が通りさえすれば、そのあとは何でもできてしまいます。「認可」の概念がなかったのです。
用語の整理をしておきます。認証は「正当なユーザかどうか判断すること」、認可(承認ともいう)は「ユーザに権限があるかどうか判断すること」です。新幹線の切符を持っていれば改札を通れます。切符という所有物により「認証」されたわけですね。しかし、大阪まで行けるのか名古屋までなのか、グリーン席なのか指定席なのか自由席なのか、あるいはどこにも行けず席もない入場のみなのかは切符により異なります。どこまで行けるか、どの席に座れるか、これが「認可」です。
IIJ DNSプラットフォームサービスでは、認可権限を細かく設定できるようになりました。アカウントごと、ゾーンごとに編集と参照の権限を別々に設定できます。これにより、万が一認証情報が漏曳して第三者に不正にアクセスされてしまったとしても、契約全体が不正に操作されるようなことはなく、被害は漏曳したアカウントが持っていた権限までに抑えられます。また、たとえば同一組織で複数のゾーンを運用するけれどそれぞれのゾーンの運用部署は異なるようなケースで、自部署が運用するゾーンを意図せずあるいは故意で他部署に書き換えられる事故を防止できます。
また、認証部分も強化されました。認証の強化というと、複雑なパスワードが強制されたり、二段階認証が強制されたり、安全かもしれないけどめんどくさくなる方向を想像するかもしれません。しかし、たとえば社外からのアクセスは多要素認証を必須とするけど社内からのアクセスならパスワード認証だけでもいい、とか、お客様社内のAD (ActiveDirectory)ドメインにログイン済みであれば統合Windows認証でIIJ DNSプラットフォームサービスには自動ログインできるようにする、といったように、むしろ利便性を向上させる方向にカスタマイズすることもできます。
ただし、これらはIIJ IDサービスにより提供される機能になります。利用するには、IIJ IDサービスもあわせて契約し、IIJ DNSプラットフォームサービスと連携しておく必要があります。IIJ IDサービスと連携せず、IIJ DNSプラットフォームサービス単体でご利用の場合はこれら強化された認証・認可機能は使えず、IIJの他のサービスと同等になります。それでもTOTPを利用した二要素認証やアクセス元IPアドレスの制限などは可能です。二要素認証もアクセス元制限も、お客様自身で設定しないと有効にはなりませんので、積極的に利用していただくようお願いします。
TSIG認証
TSIG (Transaction SIGnature)はDNSメッセージへの署名や送受信者の認証に使われるもので、RFC2845で定義されています。公開鍵暗号を使うDNSSECとは異なり、TSIGは共通鍵を使います。共通鍵なので不特定の相手とのやりとりはできませんが、プライマリとセカンダリサーバ間のゾーン転送やNOTIFYのアクセス制限など、特定の相手とだけやりとりできればいい局面で利用されます。IIJ DNSプラットフォームサービスでも新たにサポートしました。
わりと古くから存在するTSIGなんですが、対応してる権威DNSサービスってあんまりないんですよね。旧DNSセカンダリサービスでも対応してませんでしたし。DNSSECよりはずっとお手軽に使えるので、自前サーバとDNSプラットフォームサービスとの間でプライマリ/セカンダリ構成を組みたい場合はぜひご利用ください。
そして、DNSSEC
2018年にMyEtherWalletが乗っ取られ、仮想通貨が盗まれた事件を覚えているでしょうか。
何者かがBGP経路ハイジャックでAWS Route53のトラフィックを乗っ取り、そのうちmyetherwallet.comへのDNS問い合わせに対する応答を偽造して偽サーバに誘導し、この偽サーバにアクセスしてきたユーザが保有していた仮想通貨を盗んだ事件です。この事件では、オレオレ証明書だったのにブラウザの警告を無視してアクセスしてしまったうかつなユーザが被害に遭ったようです。
DNSを乗っ取られるということはそのドメインのコントロールを奪われるということであり、乗っ取った側はオレオレでない正規の証明書の発行を受けることができます。Let’s Encryptなら経路ハイジャックに成功して3分あれば証明書の入手には十分でしょう。時間がかかってもよければLet’s Encrypt以外でも取得できます。MyEtherWallet事件は犯人側がその手間を惜しまなければ警告の出ない正規の証明書を持った偽サイトにトラフィックを誘導できたはずでした。「ブラウザの警告を無視しなければ被害を防げたのに」で済ますことはできません(※)。
※経路ハイジャックで取得できる証明書はDV証明書までであり、OV証明書や、MyEtherWalletが本来使っていたEV証明書は取得できません。MyEtherWallet事件の起きたころ、EV証明書はブラウザのアドレスバーが緑になって組織名が表示されていましたが、現在はChromeでもFirefoxでも緑色表示をやめており、当時よりも違いがわかりにくくなっています。
ではこの事件はどうすれば防げたかというと、以下の方法がありました。
- RPKIで経路ハイジャックそのものを防ぐ
- DNSSECでDNSの乗っ取りを防ぐ
RPKI (Resource PKI)はIPアドレス情報の割り当てを証明するためのPKI基盤であり、誤った経路情報を検出することができます。しかし、これは回線事業者が実施するものであり、Webサイトを運用する立場では手を出せません。
DNSSECはDNSの情報に署名を付与し、それを検証することでDNSの改竄を防ぐものです。経路ハイジャックに成功しても、偽DNSサーバは正規の署名を付与できないためDNSの乗っ取りを検知できます。ドメイン所有者の立場でできる対策となると現状ではDNSSECが唯一の策といえるでしょう。myetherwallet.comも事件後に対策としてDNSSEC署名を開始しました。
DNSの改竄というと、キャッシュサーバに対するポイズニングを思い浮かべる人が多いかと思います。キャッシュポイズニングは、DNSが信頼性の低いUDPを利用したプロトコルであることが原因の大きな部分を占めており、そのためUDPをやめてTCPに変えればいいのでは、という意見をときおり目にします。しかし、TCPに変えても経路ハイジャックによるDNS改竄は防げません。DoH/DoTはそもそも権威サーバを対象にしていませんが、仮に権威サーバでDoH/DoTに対応したとしても、前述のとおり正規のTLS証明書を入手できてしまう経路ハイジャックには役に立ちません。経路ハイジャックなんてそうめったに起きない？ これを見てもそう言えますか？
なお、ホームルータのDNS設定を外部から書き換えるような攻撃に対してはDNSSECでも(通常は)防げません。利用しているキャッシュサーバがDNSSEC検証していても、検証しないサーバを使うように設定を改竄されてしまうからです。検証をキャッシュサーバに任せるのではなく、個々のクライアントが自力でDNSSEC検証すればこのケースも対策できます。Linuxのsystemd-resolvedやFreeBSDのlocal-unbound、OpenBSDのunwindなどのローカルリゾルバで実現できますので、興味のある人は試してみてください。
IIJ DNSプラットフォームサービスでDNSSEC
IIJ DNSプラットフォームサービスにおけるDNSSEC機能については詳しく書いたんですけど、ただの宣伝になっちゃっておもしろくないので、書いたものはばっさり捨てて、ここでは主な機能を箇条書きで列挙するだけにとどめます。
まずはDNSSECの基本機能から。旧サービス（DNSアウトソースサービス）の時代から対応していましたが、それを引き継ぎ、強化しました。
- 鍵の作成・更新(ロールオーバー)はほぼ自動
- ZSK(ゾーン署名鍵)の管理は完全自動
- KSK(鍵署名鍵)はDSレコード(鍵ハッシュ)の登録だけお客様の手作業、それ以外は完全自動
- ご利用のドメインレジストラにDS登録を申請してください
- レジストラとしてIIJ ドメイン管理サービスを利用していれば、DS登録も自動
- ゾーン編集後の署名、署名有効期間更新の署名は完全自動
- 署名の存在を意識する必要がない
- すべてのゾーンでデフォルトでDNSSEC署名する
- なんらかのポリシーでDNSSECを使いたくない場合や、レジストラがDSレコードを取り次いでくれなくて有効にできない場合は署名しないようにすることも可能
- 署名アルゴリズムは楕円曲線暗号(ECDSAP256SHA256)
- RFC8624の推奨アルゴリズム
- 署名サイズが小さくなり、応答パケットがフラグメントしたり、DNS ampの踏み台に使われづらくなった
- ちなみに旧DNSアウトソースサービスでは
- ドメイン管理サービスと連携している場合のみ有効にできるオプションだった
- アルゴリズムはRSASHA256(署名サイズ大)
要は、ほぼ自動だから楽ちんだよ、ということです。DNSSECは運用に手間がかかるからやらない、という言い訳は通用しません。
続いて、先進的な機能。
- セカンダリ署名に対応
- お客様プライマリサーバから未署名ゾーンを転送し、セカンダリのDNSプラットフォームサービスで署名する
- セカンダリ署名したゾーンをさらに別サーバに転送する3段構成も可
- CDS (Child DS)レコードに対応
- CDSレコード = DSレコードの登録を自動化するための仕組み
- 署名したゾーンにはCDSレコードを登録
- CDSに対応したレジストリ、レジストラを利用していれば、DSレコード登録も自動化できる
- こちらで把握してるかぎりでは.cz (チェコのccTLD)ぐらいしか対応してないけど…
- IIJ DNSプラットフォームサービスで契約しているゾーンの子ゾーンをお客様が自前運用している場合、子ゾーンにCDSレコードを登録すればIIJ DNSプラットフォームサービスの親ゾーンに自動でDSレコードを登録する
- IIJドメイン管理サービスを利用している場合、IIJ DNSプラットフォームサービスをご利用でなくても、お客様ゾーンにCDSレコードを登録すると自動でDSレコード登録をおこなう
ゾーンの管理はWebUIを使わず手元のサーバでこれまでどおりおこないたい、でもDNSSECはめんどくさいから自前で運用したくない、という場合、セカンダリ署名で幸せになれます。また、DNSSECの運用で唯一手作業が必要だったDSレコードの登録を自動化できるようにする仕組みがCDSレコードです。レジストリ/レジストラの方でも対応する必要があるので現状ではほぼ機能しないと予想してますが、JPRSさんや他社レジストラさん、対応よろしくお願いします。
図1:セカンダリ署名
やってみよう
第1回の記事にも書いたとおり、この記事はIIJ DNSプラットフォームサービスのスゴいところを紹介するためのものですが、このサービスを導入しなくてもいいからどんどん参考にしてください、他社さんも真似してください、という趣旨でもあります。なので、サービスを導入せず、自前でDNSSEC運用する方法についてももちろん解説します。が、この解説だけでかなりの分量になってしまうので、記事を分けます。もうちょっと待ってね。
権威DNSサービスを提供する同業他社さんや、構築を請け負うSIerさん、ぜひDNSSECへの対応をよろしくお願いします。NISCによる政府機関向けセキュリティガイドラインでも「導入が望ましい」とされており、実際に財務省、厚労省、法務省、外務省など、中央省庁を中心にDNSSEC署名済みのgo.jpドメインがぽつぽつ増えてきています(NISC自身はDNSSEC署名してないけど…)。政府調達案件ではDNSSECに対応できた方が今後受注に有利になりそうな気配ですよ。
ドメインレジストラ、jpドメイン指定事業者の各社さんにもお願いがあります。DSレコードの取り次ぎに対応してください。ドメイン所有者がDNSSEC対応しようと思っても、レジストラ(指定事業者)がDSレコードを取り次いでくれなければ有効にできません。DNSSEC署名するかどうか最終的に判断するのはドメイン所有者であるべきです。レジストラがその判断を妨げるべきではありません。
とくに、地方公共団体用のlg.jpドメインは、他の属性jpドメインと異なり民間事業者の参入が認められておらず、地方公共団体情報システム機構(J-LIS)が独占しています。そのJ-LISがどうやらDSレコードを取り次ぎしていないようです。lg.jp以外のjpドメインであれば、どうしても必要ならDS取り次ぎに対応した事業者にドメインを移管することで対応できますが、J-LISが独占しているlg.jpは移管もできません。lg.jpは非常に公共性が高く、取り扱う情報の真正性には多大な注意が払われるべきだと思います。しかし、DNSSEC対応ドメインが増えつつあるgo.jpとは対照的に、現時点ではlg.jpドメインはDNSSECに対応したくてもできない状況にあります。J-LISはDSレコードを取り次いでください。
[2020/05/08 追記]「J-LISはlg.jpドメインのDSレコード取り次ぎをおこなっており、地方公共団体向けの専用ページに申請方法を載せている」との指摘をJPRSさんよりいただきました。
誤った情報を記載してしまいたいへん申し訳ありませんでした。お詫びの上訂正します。
つづく
ということで、IIJ DNSプラットフォームのDNSSECや認証まわりの機能強化について説明しました。
自前でDNSSEC運用する話が残っていますが、それはいったん置いておいて、次回はここまでで取り上げなかった細かい機能について説明します。
