web-dev-qa-db-ja.com

RHEL 6.3OpenSSHとApacheのアップグレード

PCIコンプライアンスのためにサーバーの1つ（RHEL 6.3 x86_64）に対して403Labsから外部セキュリティスキャンを実行したところ、スキャンに合格するためにアップグレードする必要のあるアプリケーションが手元にあることが主に示されました。

そうは言っても、私が直面している問題は、パッケージマネージャー（yum）とレミリポジトリの使用に、ApacheとOpenSSHに必要なバージョンがないことです。私はすでに以下を実行しました：

yum update
yum --enablerepo=remi,remi-test install httpd mysql mysql-server php php-common

これにより、重大でリスクの高い結果は解決されましたが、中レベルの結果では、次のパッケージをさらにアップグレードする必要があることが示されています。

必要なアップグレードは次のとおりです。

   Current            Required
Apache 2.2.15 to >= Apache 2.2.23
OpenSSH 5.3   to >= 5.7

それで、パッケージマネージャーは私にそれらのバージョンへのアップグレードを許可することができないので、これをどのように行う必要がありますか？私は現在、ソースからインストールする必要があるという前提の下にあります。より良い代替案がある場合は、それを示してください。

また、ソースからインストールする以外に選択肢がない場合、OSに正しいバージョンをインストールしていることがわかるように、誰かが適切なソースパッケージを特定するのを手伝ってくれませんか？

助けてくれてありがとう。

linuxapache-2.2redhatyumrhel6
5
Skittles

それをしないでください！

OSベンダーのサポート構造の外に出る前に、これが正しいことであることを確認する必要があります。

一部のPCIコンプライアンステストでは、報告されたバージョン番号が低すぎるため、アプリケーションに脆弱性があることが報告されます。これは、多くのベンダーが採用しているセキュリティとバグ修正の バックポート を考慮していません。

たとえば（古いNessusスキャンから）、バージョンが2.2.14未満の場合、CentOSによって提供されるApacheが脆弱であると宣言します。脆弱性について詳しく調べると、 CVE-2009-3095 、 CVE-2009-3094 などが見つかります。

それらを調べると、Apacheサプライの現在のバージョンで修正されていることがわかります。RH、したがってCentOSを購入します。

8
user9517

プッシュバック...

Red Hat EnterpriseLinuxはそのようには機能しません。監査要件を満たすためにソースからインストールすると、追加のセキュリティ問題とより多くの管理オーバーヘッドが発生します。

Red Hatがエンタープライズオペレーティングシステムに対して採用しているアプローチは、OSのサポートライフサイクル全体を通じて一貫したターゲットを作成することです。大企業やエンタープライズアプリケーションは、これらのオペレーティングシステムがサポートされている7年以上にわたってバイナリ互換性を保証する必要があります。 Red Hatはパッケージのマイナーバージョン番号を変更しませんが、代わりに変更とセキュリティパッチを新しいバージョンから古いパッケージにバックポートします。

たとえば、RHEL5ではApache2.2.23は表示されませんが、新しいバージョンのApacheから2.2.3に移植された関連するセキュリティパッチ（および一部の機能）は表示されます。

私が監査人やセキュリティに焦点を当てている人々に対処するとき、私は彼らがパッケージの変更ログを読んで、彼らの特定の懸念が既存のセキュリティ修正またはバグ修正によってカバーされているかどうかを確認することを主張します...

これが EL Apache changelog です。

CVE-*番号を CERT/National Vulnerability Database と相互参照します。たとえば、 CVE-2011-3368 は、2.2.21より前のApacheバージョンに影響を与える脆弱性を示しています。明らかに、RHELのメジャーバージョンは2.2.3しかないため、セキュリティ修正プログラムが開発され、テストされ、古いバージョンに移植されました。

12
ewwhite

上記のパッチのバックポーティングについては知っていましたが、PCIコンプライアンスの実装でもこれに遭遇しました。 Apacheを使用したソリューションは、/ etc/httpd/conf/httpd.confでServerTokensを「Prod」に設定し、ServerSignatureを「Off」に設定することでした。この賢明な設定は、Apacheにバージョン番号を報告せず、使用しているすべてのモジュールを吐き出すように指示します。その後、スキャンに合格しました。

SSHの場合、理想的な設定は、アクセスをファイアウォールでオフにして、オフィスだけがポートに接続できるようにすることです。このように、スキャンはそれを拾いません。

それが不可能な場合、PCI監査人は、パッチが適用されていることを証明し（通常、画面共有ユーティリティを介して、「yum update」に利用可能な更新がないことを示します）、定期的なテストの手順が整っていれば、安全であると確信できます。 。 RedHatのセキュリティメーリングリストに登録していることと、使用しているコンポーネントに脆弱性がある場合はすぐに更新をスケジュールすることを示しました。

それを除けば、あなたはアピールして適切な侵入テストを受けることができるはずです。

6
chylarides