エラーログに、さまざまな管理ページにアクセスしようとするおせっかいな訪問者が表示される
404ページで非常に多くのヒットが発生した後、Webサイトのエラーログの監視を開始しました。そこに私は一日中、私が存在しない私のウェブサイト上の管理フォルダとエディタにアクセスするいくつかの試みがあることがわかりました。たとえば、Word Pressとfckeditorの管理フォルダーにアクセスしようとしていますが、私はどちらも持っていません。
これらの試みについて私がすべきこと、およびそれらが心配の原因であるかどうかについての考えはありますか？
私のエラーログからの例：
[Mon Jun 23 16:17:17 2014] [error] [client 120.37.236.236] File does not exist: /home/[snipped]/public_html/admin, referer: [snipped].com/admin/editors/fckeditor/editor/filemanager/upload/test.html
[Mon Jun 23 16:16:39 2014] [error] [client 178.158.214.36] File does not exist: /home/[snipped]/public_html/administrator
[Mon Jun 23 16:16:39 2014] [error] [client 178.158.214.36] File does not exist: /home/[snipped]/public_html/wp-login.php
[Mon Jun 23 10:39:13 2014] [error] [client 120.37.236.217] File does not exist: /home/[snipped]/public_html/admin
[Mon Jun 23 08:31:49 2014] [error] [client 27.153.217.87] File does not exist: /home/[snipped]/public_html/fckeditor
[Mon Jun 23 05:34:19 2014] [error] [client 115.29.14.241] File does not exist: /home/[snipped]/public_html/editor
[Mon Jun 23 05:34:17 2014] [error] [client 115.29.14.241] File does not exist: /home/[snipped]/public_html/admin
[Mon Jun 23 05:34:16 2014] [error] [client 115.29.14.241] File does not exist: /home/[snipped]/public_html/FCKeditor
[Mon Jun 23 05:34:12 2014] [error] [client 115.29.14.241] File does not exist: /home/[snipped]/public_html/editor
[Mon Jun 23 05:34:10 2014] [error] [client 115.29.14.241] File does not exist: /home/[snipped]/public_html/admin
[Mon Jun 23 05:34:06 2014] [error] [client 115.29.14.241] File does not exist: /home/[snipped]/public_html/Fckeditor
最後に、cPanel Xのエラーログで報告されたエラーに関する詳細情報をどこで入手できるか、誰にもわかりますか？たとえば、私は多くのエントリを持っています
ファイルが存在しません：405.shtml
しかし、どのページまたはリンクがそれらを生成したのかわからないので、問題の原因を修正するためにどこに行けばいいのかわかりません。
これは「訪問者」（本当の人）である可能性は低いですが、Webサイトで実行されるソフトウェアの脆弱性に対する自動ソフトウェアテストである可能性があります。私はこの種のリクエストを何年も見てきました。私のサーバーで最も一般的なのは、WordPress管理ページとMicrosoft FrontPage拡張機能のリクエストです。
ソフトウェアを実行していない場合、これらのリクエストはWebサイトにほとんど影響を与えません。
ソフトウェアを安全に保つための標準的なアドバイスは、Webソフトウェアにも当てはまります。ソフトウェアを最新の状態に保ちます。コンテンツ管理システムのセキュリティ脆弱性は頻繁に発見されます。私のWebホストは、新しいバージョンがリリースされたときにWordPressを自動的にアップグレードすることも提案しています。
残念ながら、一般的なWebサイトのセキュリティは、この「Pro Webmasters Stackexchange」形式には広すぎます。これをどのように処理するかは、会社の規模と何を保護しようとしているかに完全に依存します。
機密データのないシンプルなWebサイトの場合は、それらを無視して、コントロールパネルが見つけにくいか、IPが制限されていることを確認してください。
例：
- 管理パネルをwebsite.com/adminからwebsite.com/schwpzhashkeyに変更します
- 特定のIPアドレスへのコントロールパネルアクセスのみを許可するには、Webサーバー構成にIP制限を設定します。
おそらく何もしていません。ハッカーの世界へようこそ。
これは私が研究していることです。
Webサイトをランドスケープおよびハッキングするために設計されたソフトウェアパッケージが多数あります。 admin、wordpressなどへのアクセスは、少なくとも、使用しているシステムとサイトに存在する脆弱性を把握するための造園の試みです。一部のアクセスは、実際のハッキングの試みである可能性があります。
指定したログスニペットを見ると、これらは造園の試みです。彼らは、さまざまな脆弱なPHPソフトウェアにアクセスしようとしています。この時点で、彼らはインストールされているものを把握しようとしているので、私は可能だと言います。それはステップ1です。ステップ2では、インストールしたソフトウェアのバージョンをプローブし、脆弱性データベースと比較して、次に試みることができる脆弱性を判断します。ステップ3は、成功したかどうかにかかわらず、実際のハックの試みです。
ほとんどの場合、これらは侵害されたシステムからのトロイの木馬ソフトウェアです。ハッカーは匿名プロキシを使用して、これらのトロイの木馬システムにハックコマンド/コードを提供しています。
ログファイルを監視し、ドメイン名とIPアドレスのブロックをすぐに開始することを強くお勧めします。
更新：早く逃げなければならなかった-請負業者の1人が早く現れた。
セキュリティツールはいくつかありますが、Webサーバーの場合、 https://www.modsecurity.org/ にあるmod_securityが最適です。すぐにこれに戻ります。
ソフトウェアを更新するためのアドバイスは、常に良いものとは限りません。新規インストールは、新しい脆弱性を開く可能性があります。皮肉なことに、より安全なインストールは古いものである可能性があります。ハートブリードの脆弱性は最近の更新によるものでしたが、すぐに更新していなければ脆弱性はありませんでした。別の例は、Apache 1.2を備えたRedHat 6.2の古いインストールで、新しいインストールのように侵害されていないようです。ケースバイケースでこれを取る必要があります。ブランケットソフトウェアの更新は、危険なアドバイスになる可能性があります。ハッカーはほとんどの場合、最近の脆弱性、またはまだインストールされている可能性が高い脆弱性を探しています。セキュリティの移動ウィンドウスタイルのビューがあります。ソフトウェアの新しいバージョンがリリースされると、古いバージョンがハッキングされる可能性は低くなります。
それでも、ソフトウェアの更新を念頭に置き、更新をインストールする前にシステムに脆弱性が存在するかどうかを確認することをお勧めします。セキュリティまたは機能の観点から修正するものがない場合は、更新を延期することが賢明です。アップデートや脆弱性をチェックする習慣をつけてください。これを行う最善の方法は、 http://web.nvd.nist.gov/view/vuln/search?execution=e2s1 を時々（実際には頻繁に）確認して、問題。私が見つけようとしている電子メールリストがどこかにあります。電子メールリストはすぐにあなたを最新の状態に保ちますWebアドレスを使用すると、そこにあるすべての既知の詳細を見つけることができます。繰り返しますが、脆弱なまたは必要なアップデートのみをインストールしてください。
Mod_securityに戻ります。 mod_securityは、WWWファイアウォールのようなものです。すべてではありませんが、ほとんどのハック試行をブロックできますが、それを維持する必要があります。このようなソフトウェアをインストールして、攻撃の試みがWebサーバーに到達するのを防ぐのが賢明です。ファイアウォールがある場合は、ファイアウォールでHTTPフィルターを使用することもできます。正規表現に精通している場合、これは非常に強力なオプションです。ポイントは、ハッキングがWebサーバー、PHP、PHPアプリケーションに到達してはならないということです。 Mod_securityは、いくつかのPHPアプリケーション、PHPを更新するよりもはるかに強力なオプションです。実際、PHPは教科書であり、安全なソフトウェアプラットフォームを作成する際にすべきではありません。
覚えておいてください-これは私が生計を立てており、すべての主要な通信と国のインフラストラクチャのセキュリティプロトコルの研究のために長い間持っていることです。週に数回、毎日ではないにしてもセキュリティに注意を払い、可能な場合はアナウンスのアラートを設定します。
同じ問題があるため、要求されたURLを解析するカスタム404ページを作成し、（ログファイルから）選択したパターンに基づいて、標準の404ページを表示するか、以前にチェックしたファイルにIPアドレスを追加しますいずれかのページが表示されます。次回、私のサイトの任意のページにアクセスしようとすると、自分のIPにリダイレクトされます。これは迅速で汚い修正ですが、数千回ではなく1〜2回試行しただけで、システムがこれ以上見えないようにします。
「wp-login.php」のような攻撃ページをセキュリティページにリダイレクトします。
私は私のサイトでこれらの多くを取得します。 PHPからファイアウォールのIPをその場で簡単にブロックできるシステムが既に用意されているため、これらのURLのいずれかにヒットする人のブロックを7日間開始しました。
このようなシステムを作成できない、または作成したくない場合は、使用する帯域幅を減らすためのさまざまな手法を試すこともできます。もちろん、これらのヒットを1日に数千件取得している場合にのみ、これを気にする必要があります。 「不正なURL」のリストを保持し、404ページで、実際に要求されたURLがブラックリストに載っているかどうかを確認できます。もしそうなら、「出口;」データを送信せずにすぐに。これは、1日あたりのヒット数が少ない場合はほとんど意味がありませんが、数千を取得している場合のひどい考えではありません。
私はすでにmysqlにブラックリストを持っているので、未知の404の2番目のテーブルを作成しました。 404であり、ブラックリストにないリクエストされたURLは、このリストに追加されます。このようにして、リクエストされているURLとその頻度を監視できます。何かが多くのヒットを取得している場合は、ブラックリストに追加して、さようなら。