web-dev-qa-db-ja.com

スクリプトの1つが脆弱であるとわかったら、どのような対策を講じる必要がありますか？

私は、LAMPサーバーで小規模企業向けのPHPベースのWebサイトをいくつか管理しています。スクリプトには、JoomlaやWordpressなどのCMS、SilverStripeおよびDrupalインストールが含まれます。

一週間前、私はサイトが危険にさらされていることを発見しました。問題の実際の唯一の原因は、攻撃ですべての.phpファイルが削除されたことです。それらをバックアップから復元すると、すべてが通常の状態に戻ります。

もちろん、セキュリティホールはまだどこかに存在しています。攻撃直後に私がしたことは次のとおりです。

  • サイトはすべて/var/wwwに保存され、すべてに使用されるファイルとフォルダーはwww-userに属します。すべてのサイトにユーザーを作成しました。 drupal、およびDrupalフォルダーでchown -R drupal:www-data .を実行しました。

  • ファイルがu=rwx,g=rx,o=、ディレクトリがu=rw,g=r,o=になるように許可を確認しました。これにより、PHPを介した攻撃が実際にファイルを削除したり、何らかの方法でファイルを変更したりすることが不可能になると思います。

今私の質問：

  • 許可に関するこれらの仮定は正しいですか、少なくとも差し迫った攻撃から私を救うでしょうか？

  • スクリプトを最新バージョンにアップグレードし、バックアップが正常に機能することを確認する以外に、他にどのような予防策を講じることができますか？

phpsecurityapache2chmod
5
slhck

各サイトに追加のユーザーを作成したという事実は、誰かがハッキング/悪用された場合、残りは影響を受けない可能性が高いため、さらに一歩進めることができるので素晴らしいです。

ホームフォルダー内のホスト

ホストを実際にホームフォルダに移動して、いわば投獄されるようにすることができます。これにより、セキュリティが少し強化されます。たとえば、パスが/ home/drupal/public_htmlにあるようにvhostsをセットアップし、各ユーザーが他のユーザーのホームに入らないようにセットアップできます。

Chmod

すでにこれを行っていると思いますが、セキュリティに関して頭を悩ませているようですが、ほとんどのエクスプロイトで注入されるキーファイルは、テンプレートファイル、インデックスファイル、構成ファイル、および.htaccessファイルです。したがって、これらのファイルをCHMODすることは非常に重要です。

CHMODを設定することが重要ですが、サイトを保護できる他の重要な要素もいくつかあります。

SQLインジェクション

SQLインジェクションは今でも非常に人気があり、適切なセキュリティ対策を講じることでこれを防ぐことができます。php.iniファイルのerror_reportingなどをオフにすると、安全な.htaccessを設定して追加のレイヤーを追加できます。ただし、SQLへのデータの配置がサニタイズされているかどうかを常に確認する必要があります。使用しているプラ​​グインがmysql_real_escape_stringまたはpg_escape_string（PHPを使用している場合）を使用しているか、変数を使用するすべてのクエリで準備済みステートメントを使用していることを確認することが重要ですPOSTまたはGETから。これはSQLインジェクションに役立ちます。これは正確な方法をリストするためのかなりのローンですが、Googleを検索してSQLインジェクションを完全に防ぐためにSQLインジェクションについてもう少し学ぶ必要があります。

PHPセキュリティ

ホームディレクトリ内の各サイトでphp.iniを使用することを検討してください。そうすれば、サイトを操作する必要がないものを無効にできます。無効にするものが多いほど、サイトに対して使用するハッカーが少なくなります。

これらを無効にすることを検討しますが、サイトによっては、更新を行うためにfopenなどが必要になる場合があります。手動で行うと、ほとんどの場合無効にできます。

allow_url_fopen = Off
display_errors = Off
display_startup_errors = Off
log_errors = On
error_reporting = E_ALL
error_log = /home/yourUserID/public_html/phperr.txt
expose_php = Off
magic_quotes_gpc = Off
magic_quotes_sybase = Off
register_globals = Off

Robots.txt

ロボットは、検索エンジンがプラグインフォルダーにアクセスできないようにすることで、サイトに若干のセキュリティを追加できます。多くのセキュリティ問題は、古くて悪用可能なプラグインが原因であり、ほとんどの場合、ハッカーはGoogleを使用してこれらのサイトを見つけます。ブロッキングプラグインがサイトで見つけられないようにしてください。

3
Simon Hayter

攻撃者がどのように侵入したかを特定する必要があります。Webサーバー経由の場合、実際には比較的簡単です。

  1. ファイルが消えたときを判別します。すでにファイルを戻しているので、ディレクトリの変更時間を確認することはできません。代わりに、これらのファイルからの404エラーがないかWebサーバーログを調べてください。
  2. ファイルが消える直前にどのリクエストがウェブサーバーに届いたかを判断します。 Webサーバーのログを調べてください... GETまたはHEADリクエストを介したものである場合、ログには非常に明らかなものがあります。 GET/HEAD＆POST以外のものを探します。それでも何も見つからない場合、それはPOSTであり、mod_securityを実行するか、アドホックデバッグ出力を吐き出さない限り、それらが実際に行ったログはありません。異常な要求を行っていると思われるIPアドレスを探すか、エラーログをチェックして、そこに手がかりがあるかどうかを確認します。

すでに述べたように、本当にeveryパスワードを変更する必要があります。また、webserverディレクトリの所有権を変更して、webserverを実行するユーザーがnotファイルを変更する権限を持つようにすることをお勧めします。ファイルのアップロードまたはその他のユーザー派生コンテンツを行う場合は、書き込み可能なサブディレクトリを指定しますが、not最上位レベルを指定します。 （また、問題のサブディレクトリにCGI、PHP、または静的ファイル以外の方法で提供されるものを含めることはできません）。 Webサーバーのエラーログを見て、より寛容なアクセス許可を必要とする（必要な）ものがあるかどうかを確認し、それらのアクセス許可を与えるか、動作を変更します。

さらに高いレベルのセキュリティが必要な場合、リソースヒットを受け入れて2台目のサーバーを使用する場合は、すべてのファイルを完全に異なるサーバーに保存し、NFSをWebサーバーに読み取り専用でマウントします。これは、脆弱性がある場合（いつ？）、永続的な被害をもたらすためにもっと一生懸命働く必要があることを意味します。

また、サーバーを強化するためのガイドである ApacheのCISベンチマーク にも目を通す必要があります（OSおよびデータベースのガイドもあります）-ただし、各ステップをよく理解する必要があることに注意してください特に古いブラウザを使用しているクライアントの場合、それらを盲目的に適用すると、既存のサイトが破損します。これは、変更を行ってから1週間ほどエラーログを見る必要がある場合のもう1つの例です。

4
Joe