おはこんばんにちは。ナツヨです。
いつか、脆弱性対応についての記事を書こうと思っていたら、BINDさんがまた
脆弱性を発表してくれました。（CVE-2015-8704,CVE-2015-8705)
前回の発表から１ヶ月も立っていないのに、流石BINDさんだなぁと思いました。（遠い目）
今日は、BINDに焦点をあてて、脆弱性対応とはどういうことが必要なのかまとめていこうと思います。すでに日常的に脆弱性対応されている方というよりは、「なんかしらんけどDNSサーバの管理者になっていた。とりあえずBINDというソフトウェアで動いていることは知っている」という方向けだと思います。
１．BINDの脆弱性の発表をキャッチする
BINDの脆弱性について、世の中で一番早く発信するのはBINDのサポートを行っているISC本家（BIND | Internet Systems Consortium）だと思います。情報をキャッチする主な手段としては以下があげられます。
・ISCが提供しているメーリングリストへの登録
・ISCが提供しているRSSを利用する
・ISC公式twitterをチェックする
英語なのでパッと見わかりにくいですし、個人的にはISC本家について必ずしもびんびんにアンテナを張っていなくてもいいんじゃないかなと思います。理由は後述します。
BINDの脆弱性について、次に発信してくれるのはJPRSです。日本の.jpドメインの管理をしている会社です。緊急性の高いBINDの脆弱性が発表されると迅速にアナウンスを出してくれます。
CVE-2015-8704,CVE-2015-8705の時は、ISCからの発表が１９日の11:54（日本時間との時差は１７時間であり、日本時間に直すと20日の4:54)だったのに対し（
CVE-2015-8704: Specific APL data could trigger an INSIST in apl_42.c | Internet Systems Consortium Knowledge Base）
JPRSからのアナウンス(（緊急）BIND 9.xの脆弱性（DNSサービスの停止）について（CVE-2015-8704）)が２０日の11:00でした。大体６時間で、わかりやすくまとまった日本語でアナウンスしてくださるのでとてもありがたい限りです。上司や客先に説明するときに、JPRSのアナウンスを印刷して持って行くと説明がしやすいです。JPRSはBIND以外のDNSのソフトウェアについてもアナウンスを出しています。
その他JPCERT/CCが出すアナウンスもあります。JPCERT/CCはDNS関係だけではなく脆弱性全般について取り扱っているので、普段からチェックしておいて損はないと思います。
ISC本家について必ずしもビンビンにアンテナを張っている必要はない、と言ったのは、このJPRSのアナウンスがあるからです。
２．対応するかどうかを決める
これは、環境によって異なるのでなんとも言えないのですが、私の場合はJPRSが反応しているものは即、対応の対象にすると決めています。緊急性の高いものはタイトルに（緊急）とついています。
あとは以下の観点から判断しています。
・対象のサーバが外に出ているかどうか
→FWで守られているかどうか。外に出ているものであれば、一刻も早く対処しないといけないです。リモートで攻撃可能な脆弱性だといつ攻撃を受けるかわかりませんし。
・脆弱性によって受ける影響が大きいかどうか
→JPRSのアナウンスを読むと、どのような条件でどのような影響を受けるかがわかります。サービス停止などだと、会社のサービスの継続に関わるので即対処しないと行けないと思っています。（BINDに限って言えば個人情報漏洩などはあんまり考えられないですけど・・・ゾーンがまるまる取られることがあると、動作しているサービスが予測されるので良くないですね）
基本的には脆弱性にはすべて対応すべきだと思っています。ただし、実際に対応するかどうかは実際の環境や、対応にかかる工数とリスクを天秤にかけて、上司や客先と相談して判断しています。
3.対応作業を実施する
私はlinux系のOSでしかDNSサーバを運用したことがないので、linux系に限って書きます。
BINDをソースでインストールした場合、ISCが提供している修正版のソースを落としてきて、configure→make→make installのいつもの流れで修正版をインストールします。make installをする前に、named.confなどの設定ファイルのバックアップをとっておく、修正版のソースを展開したあとに、修正版のnamed-checkconfを使って動作中のBINDのnamed.confのコンフィグチェックを実施するとより安心です。
蛇足なんですが、この修正版のnamed-checkconfを使う方法は先輩から教わりました。聞いた時は頭いいな〜と思いました(ヽ'ω`)
以前の脆弱性対応で、make installしたあとに、BINDが起動してこなくて焦った経験があります。その場で前バージョンのソースをmake installしなおして復活するまで汗がだらだらでした。バージョンアップにより動作が変わり、新バージョンでは今まで使用していたnamed.confの設定を受け付けなくなったことが原因でした。先輩にnamed.confを修正してもらって、バージョンアップを実施しました(｀；ω；´)
BINDをパッケージでインストールした場合、ディストリビューションが修正版をリリースするまで待つことになります。リリースされたらパッケージのアップデートをすればOKだと思います。ただし、ねんのために、named.confなどの設定ファイルとかはバックアップをとっておいたほうがいいかもしれません。
（パッケージのアップデートでも、修正版ソースのnamed-checkconfを実行するのって有効なんでしょうか。そのへんはやったことないので不明です・・・(゜_゜)）
修正版ソースを展開してnamed-checkconfを実行する以外に、パッケージ版ならではのコンフィグチェックをするもっと良い方法があれば教えていただきたいです。
ながくなりましたが、私はこんな感じでBINDの脆弱性対応をしています。
世の中にいるDNSサーバ管理者１年生の方の役に経てばとっても嬉しいです。
間違った点などありましたら、@infragirl755 まで知らせてくださるとたすかります。
それではおやすみなさいませ (´-ω-｀)
以下、追記
・JPCERTの正式名称はJPCERTコーディネーションセンターだと指摘をいただき、記載をJPCERT/CCに修正しました。
・BINDパッケージ版のアップデートのくだりについて、少し日本語がわかりにくいので修正しました。
・ISC発表からJPRSのアナウンスまでの時差について修正しました。（日本時間のわけがないのに痛恨のミス）
・RHEL向けの手順を作成された方がいらっしゃいました！
まこぴ(@makopicut)さん、ありがとうございます。
・そもそもパッケージ版とソースどちらを用いるかという話についてツイートされていたので引用させていただきました。ソース版だと手がかかるんですよね・・・。
鳥海ゆえ(@sarvant_yue)さん、ありがとうございました。
あとは・・・ISCの第一報からJPRSのアナウンスが出るまでの時間差の話は「現地時間ではないか？」と突っ込まれているのをTLで眺めていました。あー恥ずかしい(・_・;)
今後も気になることがあれば追記しようと思います。
