web-dev-qa-db-ja.com

ApacheをBash Shellshockの脆弱性からどのように保護しますか？

私はApacheウェブサーバーを実行していますが、bashに対するShellsockエクスプロイトの最近のニュースで、自分のウェブサーバーが脆弱かどうか疑問に思いました。そうは思いませんが、間違いないようにしたいです。

私はサーバーでbash CGIを意図的に使用していません。mod_phpとPHP WSGIサイトを使用してPythonを実行しています。しかし、サーバー上で実行されているソフトウェアが、予期せずにCGIを使用していないことを確認したいと思います。

Webサーバーに脆弱性がないことを確認するにはどうすればよいですか？

apacheshellshockbash
43
user56147

CGIとは別に、見落とされているshの使用は、ほとんどのLinuxシステムでのexec()呼び出し、またはsystem()とpopen()の使用によるものです。これはbashを意味します。 exec()ファミリの呼び出しは "/bin/sh -c"と共によく使用され、シェルのリダイレクト、パイプライン、またはプロセスを呼び出すときの引数の拡張などのさまざまな機能を提供します。

Apacheはこれを正確に使用します（APRを介して、パイプされたログを使用する場合、およびその他の状況で Shell_PATH の apr/threadproc/unix/proc.c の使用を参照）。外部出力フィルターとして（ExtFilterDefineを介して）、および #exec cmd SSIの処理が含まれます。この動作はほぼ確実に多くのサードパーティモジュールにも当てはまります。

Webサーバーを保護するための最善の手順：

  • bashパッケージをパッチまたはアップグレードします（これを自分で行う場合は、shインスタンスが浮遊していないことを確認し、sh手動で設定したchrootsでも）

  • chrootでApacheを実行し、必要な場合にのみ、最小限の/bin/shを使用します。

    • apache httpd 2.2では、「|」から「||」への切り替えが piped logs で行われるため、/bin/shが不要になります（Apache 2.2.12以降で使用可能） ）
    • apache httpd 2.4では、 piped logs で "|$"を使用していないことを確認してください。これは、httpd.2.2の動作に戻ります。 2.4は|と||をサポートしますが、どちらも/bin/shを使用しません

  • デフォルトのCGIスクリプトが無効になっていることを確認します。最上位のOptionsから再確認します（例：<Directory />でExecCGI

  • まだ使用していない場合は mod_security を検討してください。 Red Hatは KB記事12123 で環境をログに記録してクリーンアップするために使用できるいくつかのルールを提供しています。

スクリプトで "#!/bin/sh -p"を使用することも検討できます。これにより、bashが privileged mode に強制されます。これにより、環境から関数をインポートできなくなります（他の変更）。これは、システムに脆弱なCGIスクリプトがあり、パッチやコンパイラがない場合に役立ちます。これは Debianおよび派生システムでは機能しない可能性があります なので、慎重に確認してください。

（また、/bin/shがbashの場合は、無条件に他のものに置き換えないでください。起動スクリプトに影響する可能性があります。）

CGI（bashスクリプト以外）を介して、またはApacheモジュール（PythonおよびPHPの場合））で実行されるアプリケーションコードも再生できますこの一部です。攻撃者が変数を十分に制御できる場合（URIエンコードが難しい場合があります）、アプリケーションがプロセスの呼び出し時に/bin/shを使用し、それらの変数が保持されている場合は、問題があるかもしれません。

最新のLinuxシステムを実行しているが、Apache用のchrootまたはその他のコンテナーをセットアップしていない場合、Apacheの起動時にunshareおよびバインドマウントを使用して/bin/shを置き換えることができるはずです。 （またはその他のサービス）。

unshare -m -- sh -c "mount --bind /usr/local/bin/bash /bin/sh && 
    /usr/local/Apache2/bin/apachectl start"

これの利点は

  • bashを選択的に置換できるため、物を壊すリスクが少ない
  • より簡単にshを呼び出す試みをログに記録して監査できます

（これで簡単にできないことは、疑わしい変数を検査してログに記録するラッパーとしてbashスクリプトを書くことです。もちろん、他の何かを使用する必要があります...）

Linuxでauditdを実行している場合、/bin/shにいくつかのルールを追加してリロードすることで、audit.rulesの使用を簡単に監視できます。

-w /bin/sh                -p x
-w /bin/bash              -p x

（shはbashへのシンボリックリンクなので、両方が必要です）

Red Hatは、LD_PRELOADで使用できるランタイムの「修正」という別のアプローチを公開しています。これは アドバイザリ にあります。これは、必要に応じて、疑わしい変数をログに記録するように調整することもできます。これまでのところパッチの完全性について現在疑問があることを考えると、このソリューションはおそらく少なくともApacheの短期的な修正としては良いでしょう。

より一般的なApache強化のヒントについては、こちらもご覧ください。 Apache Server Hardening

28
mr.spuratic

Redhatアドバイザリによると：

mod_php、mod_Perl、およびmod_pythonは環境変数を使用しないため、影響を受けないと考えられます。

それについてもっと読む： https://access.redhat.com/node/120022

9
shaomoon

Bashを保護し、ボックスを固定しました。ほとんどのディストリビューションにはパッチが用意されていますが、まだパッチが適用されていないディストリビューションを実行する場合は、自分でコンパイルしてパッチを適用できます。

1
Andrew

不明な場合は、cgiモジュールSudo a2dismod mod_cgiを無効にするか、httpd.confのLoadModuleを削除してください。 shaomoon がmod_phpに言及したように、mod_Perlとmod_pythonは影響を受けません。

とにかく、単純にパッチをインストールする必要があります。 bashが脆弱でない場合、Apacheもこの攻撃から保護されます。

1
PiTheNumber