回答:
まず、Apacheのスクリプト機能（php、cgi、ruby、...）は、スクリプトを実行しているユーザーの特権を持つシェルアカウントに相当する可能性があることに注意してください。
サーバーが複数のユーザーで共有されている場合、すべてのスクリプトが同じapacheユーザーとして実行されるわけではないため、 suexec（-またはITK MPM - David Schmittにより提案）の使用を検討する必要があります。
apacheを仮想化またはchrootします。これにより、セキュリティの追加レイヤーに少なくとも多少の妥協が含まれます。apacheをchrootすると、ライブラリをjailなどに移動することになり、メンテナンスが難しくなる可能性があることに注意してください。FreeBSDを使用している場合は、代わりにjailを使用できます。ポートから、portauditをその中から実行します。ライブラリの依存関係や手動でファイルを移動することを心配する必要はありません。これは常にい混乱になります。BSDの刑務所では、パッケージ管理システム（ポート）を使い続けることができます。（GNU / Linuxでは、仮想化にVServerを使用することもできます。- David Schmittが推奨します）
（明らかに）Apacheだけでなく、PHP、ruby、perlなどの更新プログラムとパッチについても把握してください。すべての更新プログラムを提供するためにOSを信頼するだけではありません。一部のディストリビューションはパッチが非常に遅いです。露出時間を可能な限り0日間の脆弱性に制限します。スティックmilw0rmのあなたのRSSリーダーにフィードを購読insecure.orgメーリングリスト、等...だけでなく、それはあなたのOSの前にあなたは脆弱性について学ぶのを助けるパッチをリリースするの周りを取得、あなたはまた、特定のPHPの脆弱性について学びますたとえば、OSによって管理もパッチも適用されないcmsアプリケーション。
ファイルシステムの変更を追跡するには、tripwire / aide、audit、mtree（BSD）などを使用します。これは本当に重要です。変更を定期的にメールで送信し、毎日手動で確認します。変更してはならないファイルの変更がある場合は、その理由を調査します。何らかの悪意のあるJavaScriptが何らかの方法でページに何らかの形で挿入された場合、この方法でキャッチします。これにより、サーバーが保存されるだけでなく、ユーザーも保存されます。これは、独自のWebページが悪用されて訪問者が感染する可能性があるためです。（これは非常に一般的な戦術です。攻撃者はサーバーを気にかけないこともよくあります。発見されるまでできるだけ多くの訪問者に感染したいだけです。これらの攻撃者は通常、トラックを隠すことさえしません。このような妥協点をできる限り早くキャッチすることは非常に重要です。）
スホシンのようなものを使用してphpを保護すると役立ちます。しかし、それを理解することも学び、アプリケーションの期待されるパラメーターの構成を調整してください。
PaXなどのカーネルパッチを使用すると、多くのバッファオーバーフローの脆弱性から保護するのに役立つ場合があります。ソフトウェアが脆弱であっても。（これはあなたを無敵にするわけではありません、それはまだ別のマイナーなレイヤーです。）
いくつかのセキュリティツールを使用するときに、自信過剰にならないでください。使用するツールを理解し、常識を使用してください。読む、学ぶ、できる限り追いつく。
必須のアクセス制御（例：SELinux）の使用を検討してください。これにより、アプリケーションごとに、許可することを詳細に指定できます。アクセスできるファイル。カーネルが呼び出すものは、作成などが許可されています。これは非常に複雑なプロセスであり、多くの理解が必要です。一部のディストリビューションでは、パッケージに対して事前に作成されたSELinuxポリシーを提供しています（例：Gentoo）。この提案は、以下の提案とは矛盾していますが、それでもなお有効です。
物事をシンプルにしてください。複雑なセキュリティ戦略があなたに反するかもしれません。
Apacheで、非常に制限の厳しいデフォルトルール（オプションなし、すべてから拒否など）を設定し、特定のVirtualHostsの必要に応じてオーバーライドします。
すべてのドットファイルへのアクセスを拒否します（すぐに.htaccessファイルもカバーします）
あらゆる種類のパスワード認証がある場所では常にhttpsを使用します。
ファイアウォールはデフォルトで拒否するポリシーにする必要があります。ファイアウォールで特定のルールを作成して、特定のトラフィックを記録します。
ログ解析スクリプトを設定して、ログの異常をスキャンします。（プレリュードIDSスイートでこれを行うことができますが、正直なところ、時間をかけて独自のスクリプトを作成することをお勧めします。これにより、独自のツールとルールをよりよく理解できるようになります。）
サーバーに、最後にログインしたユーザー、アクティブな接続、使用された帯域幅などに関する毎日のレポートをメールで送信します。
suidバイナリ、世界中の書き込み可能なファイル、およびそのようなものをcronスキャンして、それらを郵送してください。
メールを受け取るように設定したものについては、時間の経過とともに例外のリストを作成する必要があります。（ファイルシステムの変更を無視するフォルダー、許可する777ファイル、許可するsuidバイナリー）。起こるべきでないことだけを通知することが重要です。些細なもので毎日メールを受け取ると、それらを無視し始め、それらは無意味になります。
しっかりした階層化された冗長バックアップ戦略を立ててください。そして、すべてのもののイメージまたはコピーを作成するだけでうまくいくと仮定しないでください。たとえば、バックアップ中にMySQLがテーブルへの書き込みを行っている場合、バックアップを復元するとMySQLバイナリファイルが破損する可能性があります。したがって、mysqldumpが通常のイメージ、夜間のtarball、バージョン管理、またはその他の設定を行っているデータベースの上にあるcronが必要になります。バックアップ戦略について考えてください。つまり、本当に考えてみてください。
セキュリティのためにこのようなリストに依存しないでください:)真剣に！インターネット上でこれらの多くを見つけ、それらすべてを読み、すべての提案を調査し、常識と経験を使って自分の心を決めます。最後に、経験と常識があなたを救う唯一のものです。リストもツールもありません。読んでください、しかし理解せずにただコピーしないでください。
SANのLinux Security Checklistをお勧めします。それに加えて、別の社内手順を使用します。チェックリストは少し時代遅れかもしれませんが、キーポイントの多くは真実です。
チェックする無数の許可、無数のチェックリストが常にあり、新しいバグ/脆弱性の発見を終わらせません。セキュリティは、あなたがオンまたはオフにするものだとは思わないでしょう、それはあなたが絶えずすることです。
ソフトウェアの「避けられない失敗」を考えると、SELinuxはいくつかの心配事を解決するのに役立ちます（セキュリティに対する特効薬はありません）。ユーザースペースアプリケーションが危険にさらされていると仮定すると、正しいSELinuxポリシーは、通常の（つまり、SELinuxが無効または許容されている場合）特権で動作することを防ぎます。もちろん、これには、監査ログを監視し、インストールされたポリシーを分析し、必要に応じてアプリケーションを機能させるためにそれを変更する必要があります。
デフォルトのポリシーが役に立たないということはありませんが、私は個人的にそれが許可するものを知りたいです。