_ 先週 InternetWeek がありまして、DNS DAY では今年も登壇してみました。あとハンズオンとか。去年までは発表者であっても他のセッションを聞くには金払え、だったけど、今年は一部セッションはご自由にどうぞという太っ腹な方針に転換したので、特権をありがたく亨受して、通常業務を放棄して4日間入り浸ってみた。
_ 発表資料 (*1)にもあるんだけど「情報収集 → 影響度調査 → テスト → パッチ適用」のサイクルをまわすのめんどくさいんだよね。そのうちの情報収集と影響度調査の部分は vuls で自動化できるぜやったね、という話なんで試してみる。
_ が、うーん。ちょっと期待してたのとは違うなぁ。CVE のリストを拾ってきて(情報収集)、ホストにインストールされてるものに該当してるものが存在してるかどうかチェックする(影響度調査)、というのが vuls のお仕事らしい。だけど、こちらが期待するのは、というかふだんやっているのは、ホストに何をインストールしてるかは把握済みなのがまず前提の上で、それらに脆弱性が出ているかどうか調べて(情報収集)、自分の使い方で実害があるのかどうか検討する(影響度調査)ってことであって、そういう意味では vuls がやってくれるのは情報収集だけで影響度調査は一切やってくれない。
_ たとえば、うちの自宅サーバを vuls でスキャンすると BIND の脆弱性を報告してくれるんだけど、こんなんどうでもいいんだよ。だって named 起動してないもん。うちでは BIND は named-checkzone やら dnssec-signzone やらのコマンドラインツールを使うためにインストールしてるのであってサーバとして使うことはないので、細工されたクエリで落ちるというようなよくある脆弱性の影響を受けることはなく、対応せず放置でも何ら問題ない。このように、インストールされているバージョンに脆弱性があるかどうかにとどまらず、その脆弱性が実際の運用において影響があるのか、影響ありなら即刻修正しなきゃマズいものなのか、急がなくても後日ほかのメンテ作業のついででやれば十分なものなのか、そういったリスク評価こそが影響度調査だと思うんだけど、vuls はそこに踏み込んでくれない。
_ まあ、どんな脆弱性があるかはデータベースにあっても、どんな使い方してるかなんてそうそう簡単に判定できっこないのは当たり前なんだけどね。そういうツールじゃないのに勝手に誤解したこっちが悪いということで。でも 影響度調査までやるって宣伝されたら期待するじゃんやっぱり。
_ そんなわけで、vuls は情報収集専用ツールです(断言)。
_ 情報収集ツールだとしても、うーん。デフォでは OS ベンダによるパッケージのリストを精査してるだけで、野良ビルドしたものは無視なのね。いちいち追加設定を書けば拾ってくれるけど、バージョン番号込みで書かないと使えないってのがちょっと。いや、バージョンなしでも拾ってくれないわけじゃないんだけど、試しに apache をバージョン指定なしで設定に書いてみたら、インストールされてるのは 2.4 なのに 1.3.x の脆弱性まで大量に報告されてノイズばっかり。どうやら設定ファイルに書かれたものを CVE のリストから探してるだけで、実ホスト内にインストールされてるもののバージョンを調べるようなことは一切しない模様。1回実行するだけだったらバージョン番号込みで設定するのもまあアリかもしれんけど、日々の運用ということを考えるとアップデートするたびに vuls の設定ファイルを更新するとか手間以外のナニモノでもなく、野良ビルドしたもののバージョンを自動で識別する仕組みがぜひとも欲しいところ。バージョン番号を返すコマンドを設定に書くぐらいの労は別にかまわないので、そのかわりに1回設定を書いたらホスト側をアップデートしても追従してほしい。
_ いろいろ dis ってみたけどもちろん悪いところばかりではない。hoge というアプリを使ってるという意識はあっても、それが利用している fuga というライブラリへの意識はどうしても低くなりがちで情報収集はおろそかになる。とくにパッケージの依存関係で自動インストールされたものだとナニソレ聞いたことねーよ、ってのもたくさんある。そういうのも漏れなく検出してくれるのはたいへんありがたい。そういうツールだとわかった上で使うのであれば非常に有用だと思う。