BINDの脆弱性対応手順マニュアル

以前自身のブログでまとめたものを、いただいたリプライや後から知った情報を含め
かきなおしたものです。すでに日常的に脆弱性対応されている方というよりは、「なんかしらんけどDNSサーバの管理者になっていた。とりあえずBINDというソフトウェアで動いていることは知っている」という方向けだと思います。

#１．BINDの脆弱性の発表をキャッチする
BINDの脆弱性について、世の中で一番早く発信するのはBINDの開発・保守を行っているISC（Internet Systems Consortium）です。そこからの情報をキャッチする主な手段としては以下があげられます。

・ISCが提供しているメーリングリストへの登録
・ISCが提供しているRSSを利用する
・ISC公式twitterをチェックする(@ISCdotORG)

ISCはBIND Subsprictionという有料サポートを提供していて、それに加入していると５日～３日早く脆弱性情報が提供されるそうですが・・・とてもお高いそうなので加入を選択肢に入れることはないでしょう(；´Д｀)
そのほかにも問い合わせに早く回答してくれたり、トレーニングを実施してくれたりという恩恵があるそうなので気になる方はのぞいてみてください。
BIND Support, Insurance for your DNS

英語なのでパッと見わかりにくいですし、個人的にはISC本家について必ずしもびんびんにアンテナを張っていなくてもいいんじゃないかなと思います。理由は後述します。

BINDの脆弱性について、次に発信してくれるのはJPRSです。日本の.jpドメインの管理をしている会社です。緊急性の高いBINDの脆弱性が発表されると迅速にアナウンスを出してくれます。
上司や客先に説明するときに、JPRSのアナウンスを印刷して持って行くと説明がしやすいです。JPRSはBIND以外のDNSのソフトウェアについてもアナウンスを出しています。

JPRS DNS関連技術情報
その他JPCERT/CCが出すアナウンスもあります。JPCERT/CCはDNS関係だけではなく脆弱性全般について取り扱っているので、普段からチェックしておいて損はないと思います。
Japan Vulnerability Notes

ISC本家について必ずしもビンビンにアンテナを張っている必要はない、と言ったのは、このJPRSやJPCERT/CCのアナウンスがあるからです。

#２．対応するかどうかを決める
これは、環境によって異なるのでなんとも言えないのですが、私の場合はJPRSが反応しているものは即、対応の対象にすると決めています。JPRSからのアナウンスでは、緊急性の高いものはタイトルに（緊急）とついています。

あとは以下の観点から判断しています。

・対象のサーバが外に出ているかどうか
→FWで守られているかどうか。外に出ているものであれば、一刻も早く対処しないといけないです。(ただし、FWの内側にいても、外部に自由に名前解決できる状態で攻撃を受ける例もあるそうで…そのへんは分かったら追記しますね。）リモートで攻撃可能な脆弱性だといつ攻撃を受けるかわかりません。脆弱性が公表された後すぐに攻撃ツールが出回ることもあります。過去の脆弱性には「BINDコロリ」と称されるものも・・・。

攻撃ツールが出回ったことが追記されたJPRSからのアナウンスの例
BINDコロリだった例
参考：BINDコロリの定義

・脆弱性によって受ける影響が大きいかどうか
→JPRSのアナウンスを読むと、どのような条件でどのような影響を受けるかがわかります。サービス停止だと、会社の業務が停止する可能性もあると思います。（DNSに限って言えば個人情報漏洩などはあんまり考えられないですけど・・・ゾーンがまるまる取られることがあると、動作しているサービスが予測されるのでやはり良くないですね）
基本的には脆弱性にはすべて対応すべきだと思っています。ただし、実際に対応するか、いつまでに対応するかどうかは実際の環境や、対応にかかる工数とリスクを天秤にかけて、上司や客先と相談して判断すべきだと思います。

#3.対応作業を実施する
私はlinux系のOSでしかDNSサーバを運用したことがないので、linux系に限って書きます。

・BINDをソースでインストールした場合
ISCが提供している修正版のソースを落としてきて、configure→make→make installのいつもの流れで修正版をインストールします。make installをする前に、named.confなどの設定ファイルのバックアップをとっておく、修正版のソースを展開したあとに、修正版のnamed-checkconfを使って動作中のBINDのnamed.confのコンフィグチェックを実施するとより安心です。
私自身BINDの脆弱性対応で、make installしたあとに、BINDを起動させたら、全然起動してこなくてすごーく焦った経験があります。バージョンアップにより動作が変わり、新バージョンでは今まで使用していたnamed.confの設定を受け付けなくなったことが原因でした。

・BINDをパッケージでインストールした場合
ディストリビューションが修正版をリリースするまで待つことになります。リリースされたらパッケージのアップデートをすればOKだと思います。ただし、念のために、named.confなどの設定ファイルとかはバックアップをとっておいたほうがいいかもしれません。

twitterのフォロワーさんであるまこぴさんがRHEL互換OS向けの書いてくださっています。
つまづくポイントしっかり書いていらしてすばらしいです。
https://twitter.com/makopicut/status/690936951642279936

長くなりましたが、私はこんな感じで脆弱性対応をしています。
って、年に5～6回こんなことをするのも面倒なので・・・・BIND以外のソフトウェアにシフトしていきたいですね(；´Д｀)