長らくブログを放置してますが、ちょっと琴線に触れたので。いい意味でね。
はてブのホッテントリから流れてきて、いい感じに意識が高くて素晴らしいんだが、いくつか細かいツッコミどころもあるので、俺流としてまとめなおしてみる試み。なお、対象はOpenSSLには限りません。
OpenSSL脆弱性対応手順まとめ – infragirl’s blog
0.パッケージ管理方針を決める
そのサーバ・そのサービスでのパッケージ管理をどうするかはあらかじめ決めてしまって、それを変える時は大幅なシステム変更、例えばサーバそのもののリプレイスやOSのアップグレードをする場合に限ってしまいます。
んで、管理方針を決めると言ってもほぼ2択で、ソースからコンパイルしてインストールするか、ディストリビューションの管理方法に従うかです。前者をもうちょっと細かく言うと、サービスにクリティカルなパッケージのみをソースからインストールするかディストリビューション付属のものを使うかを決めてしまい、この方針は原則として変えません。
個人的にはディストリビューションの方針に従った方が楽だからそれでいいじゃんというクチですが、いくつかの理由によりソースからのインストールを選択するシチュエーションも考えられます。
・ディストリビューション提供のものより新しいバージョンを使いたい
これはわりとあります。例えばディストリビューションからはhttpd 2.2が提供されてるけど2.4を使いたいとかPostgreSQL 9.1が提供されてるけど9.4を使いたいとか。CentOSなんかだとRedHat準拠ということもあり、最新メジャーバージョンの追随は遅い方です。DebianもCentOSほどではありませんが、少し前のバージョンということもあります。機能や性能に対するニーズが薄ければ、有り物を使う方が手軽ですが、そうも行かない状況もありますので、この辺りはケースバイケースで柔軟に設計・対応したいですね。
ちなみにこのサーバの場合、ほとんどのパッケージはディストリビューションのものをそのまま使っていますが、WordPressだけは自前でインストールしてますね。だってDebianのWordPressがちょっと古いんだもん……。
・コンパイルオプションを細かく指定したい
これも機能的な要件などによります。ディストリビューションによっては追加のパッケージなどでうまく対応できたり、Gentooみたいな方向性もありますが、提供されているパッケージに自力で追加の機能を有効にするのが面倒なので、だったら自前でコンパイルした方がよいという考え方ですね。
・せめてサービスに直接関わるものはディストリビューションの方針ではなく、自分でバージョンコントロールしたい
若干、宗教的な理由ですが、情報をキャッチアップして対応するやる気がある場合は十分な理由になります。極論していくとGoogleのような「自家用ディストリビューションを作る」という野心的な方向性になりますが、さすがにそれは難しいのでせめて重要なパッケージは自前で管理したいというニーズはなんとなく理解できます。
1.脆弱性情報をキャッチアップする
がんばって主要なサイトのRSSやメーリングリストを読んで、いち早くキャッチできるようにしたいものです。便利なご時世で、意識が高いエンジニアの方のTwitterをフォローしておくと早く情報を入手できたりとか、それこそはてブのホッテントリとかでもいいんじゃないかという気はしますが。
JVNとかJPCERT/CCはまあまあ信頼はできるんですが、スピード感が微妙なこともある印象。あとはその手の話題が得意なニュースサイトもありますが、得てして雑な翻訳だけだったりして影響度とか深刻さが伝わらないことが多いんだよねぇ。
ひとつ気をつけておきたいのは、どんな話題であっても必ず一次情報を当たって、それが英語であっても頑張って読むことです。「影響は深刻だけど、脆弱性の成立要件がめちゃくちゃ厳しい」とか「自分の使い方ではその脆弱性が成立する余地がない」みたいなこともあるので、そういうところをちゃんと評価できるようにはなりたいですね。
2.使っているバージョンを確認して、影響有無を評価する
まずここで影響バージョンの読み方を間違えないようにしないといけません。
例えば2016年9月に発見されたOpenSSLのCVE-2016-6304などの場合、本家の情報としては影響バージョンが「1.0.1t以前」で修正バージョンが「1.0.1u」です。ところがDebian Jessieのパッケージとしては影響バージョンが「1.0.1t-1+deb8u3」で修正バージョンが「1.0.1t-1+deb8u5」となっています。これはDebian側での互換性の問題からベースバージョンを上げずに最低限のパッチのみをバックポートした独自のパッケージを作成してるということですね。なので杓子定規に「1.0.1uが提供されねぇじゃん」と慌てると無駄な労力を強いられることになります。
言い方を変えると、ディストリビューション提供のパッケージ管理に従う場合、そのOSのサポート期限内である限りは、原則としてこういったタイプのセキュリティフィックスは提供され続けられます。OpenSSL 1.0.1系はサポート終了予定が2016年12月31日に迫っていますが、Debian Jessieのサポート期限は2018年5月まであるので、仮に来年以降OpenSSLのセキュリティアップデートが発生した場合はDebian側でのバックポートが行われるかベースバージョン自体のアップデートが行われると思われます。
さらに別の言い方をすると、ディストリビューションの流儀に従えば、雑にaptitudeなりyumなりをしておけば、ちゃんと対応はされると思っていいんじゃないかなと。Gentooなんかだとたまにやんちゃにメジャーバージョンを上げてきますが、少なくともDebianやRedHatの場合はメジャーバージョンが原則として固定されるので、致命的に何かが動かなくなるリスクは低いと考えています。まあサーバのクリティカルさとかによってはちゃんと検証環境を用意してからやった方がいいですけど。
3.アップデートするかどうかを決める
これはもう状況によりけりで、「アップデートしないリスク」と「アップデート作業に伴う変更リスク」をどう評価して天秤にかけるかです。
カーネルの脆弱性でローカルユーザが権限昇格できるみたいなタイプだと、そもそもローカルユーザを許可しない構成になっていれば優先度は下げられますし、逆にカーネルのアップデートはOS再起動を伴うのでダウンタイムが発生して、慌てて実施するよりは何かの折にやるという方針もありかなとは思います。
4.アップデートする
ということでアップデートを実施しましょう。万が一、OSがサポート切れになっていて修正パッケージが提供されない場合は、他にもいろんな問題が発生する可能性があるので万死に値します。すぐにOSのアップデート計画を立てましょう。
まとめ
OSのサポート期限内だったら、そのディストリビューションの流儀（Debianだったらapt、CentOSだったらyum）に任せておけば、手軽だし適度なスピード感で対応できるしいいじゃんと思ってたり。構成要件が複雑なシステムだと必ずしもそうは行かないけどね。
コメント