【Apache】オープンソース版とRHEL版の違いについて

Question

###前提・実現したいこと
RHEL7 apacheの脆弱性対策を考えています。
構成は以下になります。

使用サーバ：RHEL7
使用アプリ：httpd-2.4.6-40.el7_2.4.src.rpm

上記のバージョンでは以下のCVEが該当します。

<Affected> 2017-7679 2017-7668 ...etc <Will not Fix> 2014-8109

いずれもFixしているのはオープンソース版の2.4.26以上か2.2.34のみです。

---

■すべてFixさせる場合

RHEL7の最新版でもFixされていないため、
すべてFixさせる場合はオープンソース版の最新版にする必要があると思いますが、
RHEL7版とオープンソース版は全く別物になりますでしょうか。
仮にオープンソース版へのアップデートを考えたときに、
どんな影響や弊害を考える必要があるのか分かりません。

現行システムの仕様と比較して影響範囲などを確認したり検証したりする必要があるのか、
はたまた普通に切り替えてしまって問題ないのか、
影響が大きいなら切り替えは行わずRHEL7の最新版にアップデートして待ったほうがよいのか、
など判別がついていません。

オープンソース版とRHEL版の違いや、考え方の指針についてご教示いただけますでしょうか。

###発生している問題・エラーメッセージ

###該当のソースコード

ここにご自身が実行したソースコードを書いてください

###試したこと
課題に対してアプローチしたことを記載してください

###補足情報(言語/FW/ツール等のバージョンなど)
より詳細な情報

Answer 1

いくつかの質問が混ざっているので、それぞれ答えていきます。

###パッケージ版とOSS版の一番の違いはサポートの有無

一番の違いはサポートの有無です。

パッケージ版はRed Hat社がその動作を商用サポートしており、問題があったときはRed Hat社へ問い合わせをする事ができます。Red Hat社は最後まで責任を持って、問題の解決に向けてサポートしてくれます。RHELのサブスクリプション費用が高いのも、このサポートがあるからです。

OSS版はそのような責任があるサポートはしてくれません。メーリングリスト等でApacheのコミュニティーに質問することはできますが、答えてくれるとは限りませんし、その答えに責任を持ってくれることもありません。うまくいかないときに、開発元のApache財団へ文句を言うのは筋違いです。Apacheのライセンスに「私達は一切の責任を持ちません」とはっきり明記してあり、それに同意しなければ、そもそも使用してはいけません。

このサポートの違いは小さくありません。そもそもサポートが不要であれば、RHELではなくCentOSで十分だったはずです。

###パッケージ版とOSS版を入れ替えるときの注意事項

現実的に入れ変える必要がでてきたとして、その違いや注意事項を述べていきます。

1. OSS版ではコンパイル環境を整える必要があります。GCC等のコンパイラはもちろんですが、openssl-develと言ったヘッダ等が含まれる開発パッケージもいくつか入れておく必要があります。(必要になる開発パッケージは、コンパイルするモジュールによって異なります。)
2. パッケージ版はモジュールを個別にインストールすることができますが、OSS版はコンパイル時にモジュールを選んでおく必要があります。(OSS版でも後からモジュールを追加することはできますが、いささか面倒です。)
3. Apache HTTP Serverに含まれないモジュールもパッケージとして提供されている場合があります。それらのモジュールは、Apache HTTP Serverとは別に、同じくコンパイルして入れる必要があります。例えば、PHPのmod_php等がそうであり、phpパッケージのmod_phpを使用せずに、PHPのコンパイルから始める必要があります。(もしかしたら動く可能性はありますが、推奨はしません)
4. OSS版ではsystemd関係の設定ファイルは一切用意しません。パッケージに含まれるhttpd.serviceを参考にしながら、自分で用意する必要があります。パッケージ版のファイルを上書きした場合、アップデート等でさらに上書きされて予期せぬ動作になりますので、絶対にやめて下さい。サービス自体を別にして、パッケージ版のサービスを落とし、OSS版のサービスを起動するようにしてください。
5. OSS版ではSELinux関係の設定は一切行いません。パッケージのSELinux設定を参考にしながら、自分で設定する必要があります。
6. パッケージ版とOSS版ではコンフィグファイルの構成が異なります。モジュールファイルへのパスなども異なるため、そのまま使用することはできません。よく理解した上で、設定の書き換えや設定ファイル、モジュールファイルの配置を手動で行う必要があります。
7. OSS版をパッケージ版があった場所にバイナリを上書きするようなことはやめてください。パッケージは単なるバイナリファイルの集合ではありません。多くの設定からの集合体であり、パッケージで入れたバイナリであることを前提にしています。上書きしただけで動くこともありますが、それは偶然に過ぎません。
8. OSS版で入れた場合、パッケージの管理外になります。パッケージのバージョン等を一元管理している場合は、その対象から外れます。脆弱性情報などは自分で集め、自分で対象バージョンか確認する必要があります。
9. OSS版では最新版が使用できるため、新機能が使えます。OSS版で新機能を使った場合、パッケージ版へ戻すことはできません。(ディストリビューションのメジャーバージョンが変わらない限り、パッケージ版に新機能が追加されることは原則ありません。)
10. OSS版はコンパイル時に柔軟な選択が可能です。不要な設定を初めからオフにしたり、モジュールを組み込みにしたりできます。ただし、よく理解した上で選択しないと、パッケージ版と同じにはなりません。

なお、新バージョン用のSRPM(ソースから入れるRPM)を作ると言う方法もあります。ただ、httpdパッケージ以外の多くのパッケージも用意する必要があるため、それなりの知識がないと難しいです。

大昔に、どうしてもApache HTTP Serverの新機能が使いたくて、最新のOSS版に入れ替えと言うことをした事がありますが、新規でOSS版のApache HTTP Serverを入れることとほぼ同じぐらいの工数になりました。つまり、さくっと入れ替えると言うことはできません。新たにサーバーを一つ作って(ただし、OSの初期設定だけ済んでいる)、そこにコンテンツを移行するぐらいのとおなじぐらいの物だと思ってください。

なお、いざOSS版で運用するとなった場合、OSS版のアップデートはコンパイルから始まりますので、それなりの工数がかかります。夜間にアップデートを走らせておくなんて事も(スクリプトなどを組めばできないことはありませんが)基本的にはできないと思ってください。

###RHELはなぜFixしないのか？

最後に、なぜRHELはこれらをすぐにFixしないのかです。と言っても、私はRed Hat社の社員では無いので、以下は推測になることを予めご了承ください。

別にReh Hat社がサボっているわけではありません。緊急度が高い脆弱性が出た場合は、1～2日後には大抵パッチを出すようにしています。しかし、今回は緊急度が低い脆弱性であったと言うことです。

一言で脆弱性と言っても緊急度の高さが異なります。CEV 2017-7679の情報について見てみましょう。

CVE-2017-7679 - Red Hat Customer Portal

CVSS v3 metricsが緊急度の高さの目安であり、深刻度という評価では3.7です。このCVSS v3の見方はIPAが資料を出してくれているので、下記を参考にしてください。

共通脆弱性評価システムCVSS v3概説：IPA 独立行政法人 情報処理推進機構

ぶっちゃけていうと、放置してもそれほど問題が出ない脆弱性と言うことです。Reh Hat社の方針としては、多くの顧客で安定して稼働することを第一としています。深刻度が非常に高い、例えばCVE-2014-6271(ShellShockの一つ、深刻度は9.8)のような脆弱性は、なりふり構っていられませんので、すぐに対応します。しかし、

• デフォルトでは無効のマイナーな設定を有効にしないと攻撃を受けない。
• 攻撃の成功には運の要素が絡み、確率が非常に少ない。
• 攻撃が成功しても、DOSや一部の情報漏洩(絶対に機密にしなければならない部分では無い)のみで、深刻な影響を受けない。

と言った場合、パッチを当てることによって不安定になるリスクを背負うことよりも、安定して稼働し続ける方を選択します。そのため、すぐにパッチを用意しない、または、全く用意しない場合もあります。また、会社としてのリソースも無限ではありませんので、緊急性が低い物は後回しにするというのもあります。

脆弱性は何でもかんでも単に対応すれば良いという物ではありません。脆弱性の対応というのは、パッチを作る側にもそれなりの工数が必要であり、また、そのパッチによって不安定になったり別の脆弱性が産まれるリスクが常につきまとう物です。それらを考慮して、バランス良く対応する必要があると言うことです。

Comments

[pumiea]

CVSS的に緊急ではないものの、そこそこのレベルの対処の考え方が分からず困っていました。
オープンソースとRHELの違いと実際に入れ替えるときの問題点など、とても分かりやすい説明をしていただきありがとうございます。
周囲にはこれらのリスクや懸念があることを説明し、理解や賛同をいただいた上で対応の方向性を決めたいと思います。

Answer 2

通常の対応は、

• 設定レベルで行える軽減策があるなら適用する
• 軽減策がなく攻撃経路が存在するならサービスを止める
• あとはパッケージが更新されるのを待つ

です。

環境の都合で対策が取れずパッケージの更新も待てない場合は自力で対策することになります。

Apacheに限らず、RHELで提供されているパッケージは、オリジナルのものにセキュリティ修正をバックポートしたソースから作られています。

これをオリジナルのものに入れ替える場合、次の問題があります

• 他のパッケージとの依存関係が崩れる
• 設定ファイルの非互換
• 公式パッケージには含まれない機能拡張による非互換

間違いなくすんなりとはいきませんが、Redhatのサポートは受けられませんのでこれらは自力で解決する必要があります。

もう一つの方法として、Redhatの代わりにバグ修正だけを自力でバックポートする方法もあります。SRPMと、オリジナルのソースコードからセキュリティ修正に関する部分の差分を入手し、展開したSRPMにそれを反映して、RPMを作り直します。Redhatのサポートは受けられないことにかわりはありませんが、上記の問題は軽減されます。

いずれにせよそれなりの知識が要求されます。

Comments

[pumiea]

サポートを受けられないことや非互換であることなど、容易に変更できるものではないことが分かりました。
業務上何かしらの対策をとらねばならない場合は、サポートを受けつつ暫定策での対処を考えます。
ありがとうございました。