NHKのDNSレコードが飛んだことを踏まえて色々と考えてみる

NHKのDNSレコードが飛んだことを踏まえて色々と考えてみる ニュース
スポンサーリンク

NHKのDNSレコードが飛んだことを踏まえて色々と考えてみる

2019年11月13日に発生した、NHKのDNSレコードが飛んだ話ですが、今のところ原因については発表がないので、DNSレコード操作を行う際の話を書きまとめてみます。

DNSレコードが飛ぶ原因は何か

そもそもDNSレコードが飛ぶ原因に何が上げられるかですが、僕としては以下が主な要因と考えます(可能性が高い順に並べてみます)

  • ついうっかりやってしまった、ヒューマンエラー
  • ハードウェアトラブル
  • 攻撃

ヒューマンエラーについて

NHKのDNSレコードが飛んだことを踏まえて色々と考えてみる
DNSレコードが飛ぶ主な原因として考えているのがヒューマンエラー(作業ミス)。

メンテナンス作業時についうっかり違うところをクリックしてしまっただとか、ゾーン情報を修正時に誤りがあった、ゾーン情報を誤って削除したなど、人の作業純度とは決して高くないのです。

僕も今までしょうも無いヒューマンエラーを起こしてサーバが止まってしまっただとか、WEBサイトにアクセスできなくなった、DBを吹き飛ばしてしまったなど数多く経験してきました。

しょぼんブログの前身である、エイサー×acerが吹き飛んだのもAzure上でのヒューマンエラーが原因だったので・・・

ヒューマンエラーを無くすにはどうすれば良いか、という話ですが一番効果的な物は「ヒューマン要素を無くす」ことですが、流石にこれは全ての作業に適用する事は非現実的。

であれば何をすべきかというと、作業前に作業手順書の作成と作業チェックリストを作り、入念に内部レビューを行い、作業時には一人で作業せず必ずチェック用の人員を立てる事(ダブルチェックを行う)が現実的かつ、効果の大きな対策となるでしょう。

NHKのDNSレコードが飛んだことを踏まえて色々と考えてみる

作業前の準備とダブルチェックは回数が経てば経つほど、定常的な作業ほど慢心して徐々に疎かになっていくところなので、定期的な作業フローの見直しや、作業員への啓蒙が大事。

こんなこと偉そうにかけるほどキチンとしていませんが、エイサー×acerを吹き飛ばしてからは、仕事以外での作業時も設定変更による影響の確認と、作業ミスしたときにおこるリスクの把握、リカバリー手順などをきちんと確立してから作業を行うようにしています。

ハードウェアトラブル

NHKのDNSレコードが飛んだことを踏まえて色々と考えてみる
こちらは人為的な要因ではなく、突発的におこる事なのでどうしようも無いじゃないか、と思考停止するのではなく、定期的なメンテナンスやサービスレベルに基づいた保守契約、障害発生時のフロー確立、監視体制の構築を行う事で、できる限りリスクを防ぐ、または影響度をいくらか小さくすることができます。

特に監視と保守契約が見落とされがちといいますか、軽視されがち。

冗長構成を取っているから監視はそこまでしなくてよい”だろう”、サービスレベルは高いけど初期コストが高いし、この構成であれば障害が発生してもサービスに影響が出る事は無い”だろう”、これらの慢心やサービスレベルに合っていない過小な投資を行うことで、あとでえらい目にあうパターンですね。

こんなこと書いてるとイヤな思い出がフラッシュバックしてきますね・・・

攻撃

NHKのDNSレコードが飛んだことを踏まえて色々と考えてみる
可能性は他2つと比べて少ない物の、社会インフラや有名企業、有名サービスを運営しているのであれば、攻撃が原因となることも十分あり得ます。

DNSサーバへの主な攻撃の種類は下記4種類と考えています。

  • DNSキャッシュポイズニング
  • ゾーン転送要求による攻撃
  • カミンスキー攻撃
  • のっとり
  • 脆弱性を突いた攻撃

キャッシュポイズニングとカミンスキー攻撃

NHKのDNSレコードが飛んだことを踏まえて色々と考えてみる
キャッシュポイズニングは攻撃者がキャッシュサーバに偽の情報を送り込む事で、攻撃者が用意した不正なサーバにアクセスさせたり、キャッシュサーバを停止させてしまうものですね。

DNSキャッシュポイズニングの対策は、TTLを十分に長く設定しておけば良い

はずだったのですが、Dan Kaminsky氏が発表した新たな攻撃にはTTLの長さに関係無く攻撃できる可能性があるとして、従来の定説がひっくり返りました。

  • 攻撃者がキャッシュサーバに対し、乗っ取りたいドメイン名と同じドメイン内で、存在しないドメイン名を問い合わせする
  • キャッシュにないため、キャッシュサーバが権威サーバに問い合わせを行う
  • 攻撃者は偽の応答として参照先を示したパケットをターゲットのキャッシュサーバに送り込む

カミンスキー攻撃を含めたDNSキャッシュポイズニングの対策としては、TTLを長くするのではなく、以下のような対策を取る必要があります。

  • キャッシュサーバに問い合わせできるクライアントを限定する
  • ソースアドレスが偽装されたパケットをフィルタリングする
  • 問い合わせに使用していないIDの応答があったり、県債サーバからの応答が問い合わせた回数以上に大量にある等の異常なDNSパケットを検知して防御する

上記以外にDNSSECを利用する方法もあるのですが、DNSSECを利用するには、権威サーバ、キャッシュサーバがDNSSECに対応していること、電子署名に必要な鍵の管理や配布方法の確立、ルートやTLDの署名が必要になるなど、課題が大変に多く普及にまではまだ時間がかかりそうです。

ゾーン転送要求による攻撃

NHKのDNSレコードが飛んだことを踏まえて色々と考えてみる
あとは負荷分散のために同じゾーン内に複数台のDNSサーバが存在している際に、ゾーン内でDNS情報を同期する際に発行される、ゾーン転送要求を悪用した「ゾーン転送要求による攻撃」が上げられます。

こちらについては、必要の無いIPアドレスからのゾーン転送要求を制限することで対策できます。

例えば、以下のような構成をJPCERTが提唱していたりします。

  • プライマリサーバでは、セカンダリサーバの IP アドレスからのゾーン転送要求のみを受けつけるよう設定する
  • セカンダリサーバでは、すべての IP アドレスからのゾーン転送の要求を拒否する

のっとり

NHKのDNSレコードが飛んだことを踏まえて色々と考えてみる
こちらはテレビアニメ「ラブライブ!」の公式サイトが乗っ取られたことで結構有名になった攻撃手法ですが、こちらはドメイン移管を悪用した手法でした。

例えば、ほげほげ.jpなどの「.jp」ドメイン、汎用JPドメインでは、本来レジストラから別のレジストラへ移管する仕組みとして用意されている、移管手続きを行うと、移行先レジストラからドメイン登録者へ確認を行い、10日以内に返事が無い場合は、移管をする意思があると扱われ、別レジストラへの移管が成立します。

もちろん「誤って」承諾しても移管が成立してしまいます。

ラブライブ!の際は、悪意ある第三者がラブライブ!所有の汎用JPドメインの移管申請を行い、ドメイン管理者が返事をしなかったか、誤って承諾の返事をしたことが原因で悪意ある第三者にドメインが移管されたことによるものでした。

汎用JPドメインは差戻もできるとのことですが、もちろんその差戻が承認されるまでいくつかのリードタイムが発生するので、その間ドメインが乗っ取られたままになります。

こちらは長期休暇等のタイミングで実行されてしまうと、休日対応体制を敷かない限り防ぐ事ができないので、レジストラが提供してるレジストリロックサービスを利用することが肝要と言えるでしょう。

脆弱性を突いた攻撃

NHKのDNSレコードが飛んだことを踏まえて色々と考えてみる
こちらはDNSサーバに限った話ではないのですが、ソフトウェアにバグや脆弱性が絶対に無い、ということはなく何かしらのバグや脆弱性が発見される物です。

ソフトウェア開発者はこれらの情報に対して即時に対応してアップデートやワークアラウンドを提供し、バグや脆弱性を悪用されることを防ぐようにしているのですが、肝心のユーザがソフトウェアアップデートや、ワークアラウンドを実施しなければどうにもなりません。

日本の状況しか分かっていないので、あえて日本のみに言及しますが、ソフトウェアアップデートには大変大きな稼働がかかるため、後回しにされがちなんですよね。

そして、バグや脆弱性に対応したアップデートが公開されているにもかかわらず、攻撃を受けてしまうという悲劇が起こっているのです。

なので、ソフトウェアアップデートは非常に、非常に重要であることを再認識し、ソフトウェアアップデートに対してもっとコストを多く振り分けなければいけません。

これは現場サイドだけでなく、経営陣も大変に大きな経営リスクである事を自覚しなければなりません。

対策について思うことをつらつらと語ってみました。

長文となって大変恐縮ですが、DNSサーバを運用するに当たって必要なリスクへの対策についてつらつらと語ってみました。

DNSサーバをはじめとしたサーバや、各サービスを運用している方は、今回の様なケースを対岸の火事として見るのでは無く、いつか内でも発生するかもしれない、という意識を持って頂き、今一度兜の緒を締めるきっかけとして頂ければ幸いです。

【復旧済み】NHKのサイトに繋がらないと思ったら結構とんでもないことになっている・・・?

先ほどNHKのサイトにアクセスしようとしたところ、名前解決ができずにアクセスできないことが分かりました。

サイトアクセス復旧しました!

以下は過去ログとしてご覧ください。

当初はこちら側のDNSサーバの問題かなと思ったら、Aレコードが引けない状態になっていました。

NHK編成センターのTwitterアカウントで本事象についてツイートされています。

syobon@tatsuta:~$ dig nhk.or.jp ns

; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> nhk.or.jp ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52046
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
; COOKIE: 74575d81d116e41f (echoed)
;; QUESTION SECTION:
;nhk.or.jp.                     IN      NS

;; ANSWER SECTION:
nhk.or.jp.              86331   IN      NS      ns.nhk.or.jp.
nhk.or.jp.              86331   IN      NS      ns10.nhk.or.jp.

;; ADDITIONAL SECTION:
ns.nhk.or.jp.           86126   IN      A       133.127.64.240
ns10.nhk.or.jp.         86126   IN      A       133.127.255.71

;; Query time: 0 msec
;; SERVER: 10.0.20.60#53(10.0.20.60)
;; WHEN: Wed Nov 13 00:02:47 JST 2019
;; MSG SIZE  rcvd: 118

NSレコードは勿論応答あり。

syobon@tatsuta:~$ dig www.nhk.or.jp a

; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> www.nhk.or.jp a
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 59933
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
; COOKIE: e1b18a9f84e40178 (echoed)
;; QUESTION SECTION:
;www.nhk.or.jp.                 IN      A

;; Query time: 2234 msec
;; SERVER: 10.0.20.60#53(10.0.20.60)
;; WHEN: Wed Nov 13 00:04:20 JST 2019
;; MSG SIZE  rcvd: 54

しかしAレコードは応答無し。

syobon@tatsuta:~$ dig pid.nhk.or.jp

; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> pid.nhk.or.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23329
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
; COOKIE: 0d56d934e2f2a439 (echoed)
;; QUESTION SECTION:
;pid.nhk.or.jp.                 IN      A

;; ANSWER SECTION:
pid.nhk.or.jp.          10045   IN      A       202.247.104.234

;; Query time: 0 msec
;; SERVER: 10.0.20.60#53(10.0.20.60)
;; WHEN: Wed Nov 13 00:05:35 JST 2019
;; MSG SIZE  rcvd: 70

2019年11月30日にサービスが終了されるNHKネットクラブのAレコードは引ける物の、

NHKのサイトに繋がらないと思ったら結構とんでもないことになっている・・・?

ページの表示にかかる時間は22,537ミリ秒と異常値を示しています。

syobon@tatsuta:~$ dig nhk.or.jp mx

; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> nhk.or.jp mx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46551
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
; COOKIE: 0a9cae7b6f11fd7c (echoed)
;; QUESTION SECTION:
;nhk.or.jp.                     IN      MX

;; Query time: 895 msec
;; SERVER: 10.0.20.60#53(10.0.20.60)
;; WHEN: Wed Nov 13 00:10:38 JST 2019
;; MSG SIZE  rcvd: 50

NHKに勤めている方のメールアドレスが分からないので、これは予測の上で確認していますが、nhk.or.jpのMXレコードも存在せず。

syobon@tatsuta:~$ dig www1.nhk.or.jp

; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> www1.nhk.or.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 35321
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
; COOKIE: bdf541173791e999 (echoed)
;; QUESTION SECTION:
;www1.nhk.or.jp.                        IN      A

;; Query time: 1512 msec
;; SERVER: 10.0.20.60#53(10.0.20.60)
;; WHEN: Wed Nov 13 00:12:02 JST 2019
;; MSG SIZE  rcvd: 55

NHKあさイチのメール投稿フォームサイトもAレコードの応答が空なので

NHKのサイトに繋がらないと思ったら結構とんでもないことになっている・・・?

ページへのアクセスももちろんできません。

特に詳細な情報が出次第おって追記しようと思います。

Source: ITトレンド | JPCERT | JPNIC | ITMedia

コメント

タイトルとURLをコピーしました