手の込んだハッキングの試みが検出されました-今何ですか？
私はphp/mysqlベースのWebアプリケーションを開発中です。私は複雑なルートをとり、フレームワークや何かを使用するのではなく、アプリの基盤全体をゼロから構築しました。これまで、実際にコードを書く方法を学びました（ほとんど知りませんでしたが、今はかなり進んでいます。しかし、専門家または専門家からの反響はあると思います...）
私は自分でカスタム404エラーページを作成しました。このページには、ユーザーが表示しようとしたURL、それらのURL、およびコンテキストでアクティブなすべての変数（IPアドレスを含む）が記録されています。これは私のサイトのエラーを追跡し、ハッキングの試みを検出するためのものです。
5か月前のようにサイトのベータ版を公開して以来、wp-login.phpにアクセスしようとするボットがいくつか（3未満）やって来ました。通常は5以下でした。リクエストがどれだけ速く行われたかにより、ボットからリクエストが行われたことは確かです。
それらはあまり気になりませんでした（名前が表示されたため、IPをgodaddyに報告しましたが）。 wordpressを使用していないので、侵入を試みたディレクトリは存在しません。
しかし今日、スペインにあるIPアドレスは私のサイトで20分を費やし、次のようなURLに60以上のリクエストを行いました
- / base/captcha/index /
- /参加する
- /signup.php
- /register.php%22%3E%3Cspan
- /？page = login＆cmd = register
- /sign_up.html
- / action/sign_up
- /modules.php?app=user_reg
- /index.php?app=home&mod=public&act=register
- /index.php?app=home&mod=Public&act=isEmailAvailable
- /reg.asp?reg=reg
- /ucp.php?mode=register&change_lang=en
- / member/register
- /includes/captcha.php
- /login.php?part=register&action=person
- /User/Register.aspx
リストはどんどん続きます...
これが自動化された攻撃なのか、実際に各URLを試行している人がいたのかはわかりません 1分あたり約3リクエストしかないためです。
幸い、これらの要求はいずれも結果をもたらしませんでした。それらのほとんどは既存のディレクトリを対象としていないため、GET変数を渡そうとしたものは効果がありませんでした。これらの変数はスクリプトで使用されなかったためです。
だから私は少し誇りに思っていますが、そのような手の込んだ攻撃は何もしていません。つまり、コードベースが非常に堅固で、簡単に侵入できないことを示していますが、少し不安に感じています。ちょっと変わったディレクトリとファイル名を使って幸運になりました...アプリケーションをプログラミングするときはセキュリティに非常に注意していましたが、自分の経歴があるためにとても弱いと感じました...
またハッカーの目的はこれらすべてのURLを試すことだったのかと思います。自分のサイトにアカウントを登録するのは無料です...？！そして、私のサイトのエクスプロイトは現在非常に低いです...私のDBにある最も価値のあるものについては、約100のメールアドレスだけです。
私の起業家は私の競争相手が私のサイトに侵入しようとしたと考えています... :-D
強調表示された間接的な質問に加えて、私の主な質問は次のとおりです。
今日入手した情報をどうすればよいですか？
特定の時間内に特定の数の失敗したページリクエストの後、IPを単にブロックするメカニズムを導入する必要がありますか？
この特定の攻撃に詳しい人はいますか？
ワイルドワイルドインターウェブへようこそ。
あなたが説明した攻撃はどちらも、何らかのツールを介して行われた自動スキャンのようです。一部のツールでは、IDSによる検出を回避するために要求を調整することもできるので、これが、あなたが言及したスキャンの要求レートが遅い原因である可能性があります。
あなたが言及したこの特定のスキャンは、あなたのWebサイトにフォーラムソフトウェアが存在するかどうかを盗聴しているようです。 （例えば、ucp.phpはphpBBフォーラムファイルです）。
ハッカーの目的はこれらすべてのURLを試すことだったのでしょうか
ここでの攻撃者の目標は、このドメインで実行されているフレームワーク/スクリプト言語/ソフトウェアを特定することです。
今日入手した情報をどうすればよいですか？
これらの攻撃の背後にある意図について詳しく知りたい場合は、GoogleでIPアドレスを検索し、このIPからの攻撃の既知のインスタンスがないかどうかを確認できます。
たとえば、過去1時間にサーバーログでこのような自動スキャンを確認したところ、このIPからの広範なスキャンが確認されました88.190.60.68。これをグーグルで検索すると、すぐに このレポート と このページ が表示され、このルージュIPとそのアクティビティの詳細がわかります。したがって、少なくともこれは標的型攻撃ではなかったので安心できます（ほとんどは対象外です）。
さらにステップを進めたい場合は、 fail2ban のようなソフトウェアをインストールして、そのようなスキャンを自動的に検出し、指定された期間IPアドレスをブラックリストに登録するように構成できます。
この特定の攻撃を知っている人はいますか？
サイト（ドメイン）が人気/古くなるにつれて、このようなスキャンがさらに表示される可能性があります。さまざまな意図のあるスクリプトがたくさんあります。リンクスパムを投稿できるコメント/フィードバックページを見つけようとする人もいます。他の人はいくつかの非常に特定の脆弱性を探しているかもしれません。
これは、脆弱性のある既知のスクリプトを探す自動スキャンであると言っても、かなり安全でしょう。正直なところ、これはコーディングの能力とは関係ありませんが、欠陥のあるWebサイトを探すスクリプトキディの怠惰です。
ベストプラクティスに従って特定のヘッダー属性をブロックした場合、攻撃者はサーバー上で実行されているスクリプト、フレームワーク、アプリ、サービスを知ることができません。彼らは、既知のすべてのフレームワークディレクトリ構造とキーファイル（wp-config.phpなど）を試し、HTTPサーバーからの200 OK応答を期待して推測する必要があります。 200が返された場合、スクリプトがアクティブであることを知っているため、既知のセキュリティ上の欠陥を絞り込み始めることができます。たとえば、wp-config.phpを見つけた場合は、リモートインクルードを試して変数を取得し、 wp-ajax.phpを見つけて、サイトのバックドアやウォーターホールなどを見つけてください。
ほとんどの場合、攻撃から学んだことを取り入れて、それをコード化します。頻繁にスキャンされるファイルやディレクトリを含むファイルやルートには名前を付けないでください。水面下に留まることで、コードを少しだけ安全に保つことができます。
この特定の攻撃を知っている人はいますか？リクエストを見ると、あなたが登録ボットにアクセスされたと言えるでしょう。
今日入手した情報をどうすればよいですか？はい、この情報を使用してサーバーを管理/保護する方法はいくつかありますが、それははるかに長い会話であり、ネットワーク、セキュリティのニーズ、およびクライアント/顧客をサポートする必要性に大きく依存します。
情報に基づいて処理する（IPなどによるautoban/autoblockなど）ので、少なくとも、何が起こっているのかを監視できます。これも長い会話であり、上記と同じ主要な側面（ネットワーク、セキュリティ、およびサポート）に依存する無数のアプローチです。
Webサイト全体で何らかのanalyticsパッケージをまだ使用していない場合は、それが最も有用であり、実行できることです。これは、正当なユーザーのレポートメカニズムとしても機能します。歓迎されない訪問者として。