侵害の検出のためにデータベース内の偽のユーザー
自分のデータベースに偽のユーザーを追加し、その使用状況を監視しているサイト*を読みました。これらの偽のユーザーの1人が使用されているか、ログインが試行された場合、データベースの侵害などを意味する可能性があります。
これは、問題が発生した後でそれを検出するための良いアイデアのように思えます。私はこれを自分で行う予定です。しかし、それは実際には良い考えですか？
偽のユーザーのパスワードハッシュと電子メールアドレス、および場合によってはコードベース内の一意の文字列について、Googleアラートなどを使用してWebをスキャンすると便利でしょうか？
*申し訳ありませんが、どこにいるのか思い出せません。おそらくリノード。
編集：明確にするために、「ユーザー」とはWebサイトにログインするユーザーのことです。 [email protected]のようなユーザーを辞書タイプのパスワードで追加できます。そのユーザーがログインしている場合は、すべてのユーザーパスワードなどを調査してリセットします。それがログイン試行のみの場合は、さらに調査する必要があることを示すフラグですが、たぶん幸運なヒットです。
Web監視に関しては、Pastebinなどを監視して、それらのユーザーのパスワードハッシュまたはコード/ dbの別の場所にある一意の文字列を探すことができます。実際のハッシュ（低レベルの管理者アカウントなど）を監視するだけなので、これは偽のユーザーのアイデアとは無関係である可能性があります。
ハニーポットを作成することは、情報セキュリティにおいて一般的に使用されている手法ですが、本番環境では最良のアイデアとは言えません。アプリケーションに潜在的に新しいリスクを追加するという事実は別として、そのようなトラップの必要性はあまりないかもしれません。
ログインの失敗は、ほとんどのアプリケーション（またはサーバーデーモン）で監視でき、アプリケーションを危険にさらすことなく、十分な洞察を得ることができます。
明白なことを述べるために;ブルートフォース攻撃は（残念ながら）一般的な現象であり、いずれにしてもアプリケーションに影響を与える可能性があります。
質問のゲームには少し遅れますが、これまでのところ、他の回答にはほとんど同意できないため、新しい質問を提示しています。
他の答えと私が同意しない主なものは次のとおりです。
ユーザーをDBに追加することは、ハニーポットを作成することと同じではありません。 （ハニーポットの定義を取り、それをハニーポットと見なすことができるような方法で解釈することはおそらく可能ですが、それは一続きだと思います。）QAチームがテストに使用するためだけに10人のユーザーを追加するとします。これらのユーザーのいずれかが通常のテスト時間外に、または予期しないIPからログインしていることに気付いた場合は、同じことを行っていることになります。これらのQAユーザーをハニーポットと呼ぶことはありません。
システムにユーザーを追加しても、システムが脆弱になるわけではありません。それが本当なら、新しいユーザーがアカウントを作成するたびに、システムはより脆弱になります。それが本当ならそれはかなり悲しいでしょう！
システムにユーザーを追加することが役立つかどうかに関しては、答えはアプリケーションが実際に何をするかによって異なります。ユーザーデータベースが危険にさらされている場合、攻撃者はデータベースに含まれている情報（ユーザー名/パスワード/電子メールアドレスなど）を持っているのでしょうか、それともWebサイトにアクセスできるのでしょうか。考慮してください：
- サイトがバンキングを処理している場合、攻撃者は多くのアカウントでログインしてお金を移動したり、アカウント情報を収集したりする可能性があります。 （この場合、「追加」ユーザーはログインを試行する可能性があります。）
- サイトが単なる無料のフォーラムである場合、攻撃者はおそらくログインを気にせず、代わりに電子メールアドレスの販売を検討するか、銀行やeコマースサイトのパスワードを推測するためにパスワードハッシュを総当たり的に試みます。 （これは最もありそうなシナリオかもしれません。）
- 攻撃者が望んでいる興味深い有料コンテンツがサイトにある場合、攻撃者は1人のユーザーを選択してログインする可能性があります。 （「追加」ユーザーの1人になる可能性は低いです。）
したがって、最初のケースでは、「余分な」ユーザーを監視することは多少役立つかもしれませんが、ほとんどの場合それはおそらく役に立たないでしょう。
とはいえ、それでも試したい場合は、おそらく最も効果的なアプローチは次のとおりです。
- 推測が非常に難しいアドレスと非常に難しいパスワードを持つ2つの新しいメールアカウントを作成し、頻繁に確認するメインのメールアカウントに転送するように設定します。
- あなたのサイトで、それらのメールアドレスそれぞれを使って新しいユーザーを作成します。どちらも推測が非常に難しいsernamesです。
- 1人のユーザーに非常に難しいパスワードを与え、もう1人のユーザーには簡単なパスワードを与えます。
これで2つのことが完了しました。これらのユーザーのいずれかがログインした場合（簡単なパスワードを持つユーザーである可能性が高い）、DBが侵害されている可能性があります。または、これらのアカウントのメールアドレスのいずれかにメールを受信した場合は、DBが侵害されている可能性があり、メールアドレスはおそらく販売されていました。
最終的な考え：上記で最も可能性の高いシナリオ（攻撃者が他のサイトで使用するためにユーザー/電子メール/パスワードを収集しようとする）について述べた場合、その場合、彼らは決してログインしたり、電子メールアドレスを販売またはスパム送信したりすることはできません。 DBサーバーへのすべてのアクセスを監視する以外に、これを検出することはかなり困難です。
これは、認定された脆弱性の評価に役立つ可能性がありますが、プロダクション側の観点では、アプリケーションを危険にさらしています。これは、攻撃者にとって可能な攻撃ベクトルである可能性があります。
攻撃者はこれらのアカウントへのアクセスを取得し、管理者権限または特権昇格を悪用して取得する方法を見つける可能性があります。
あなたが言おうとしていた概念はハニーポット（攻撃者ができることを監視する）ですが、ハニーポットは危険にさらされるように設計されています。アプリケーションが危険にさらされないようにしてください。
Application Hardeningの1つのルールは、不要なアカウント/デフォルトアカウント/ゲストアカウント/共有アカウントを無効にすることです。
私には良い考えのように見えますが、注意点があります。それによって、システムがより脆弱にならないようにする必要があります。別のユーザーアカウントは別の方法であるため、これは技術的に不可能であることを理解していますが、これを実装する場合は、次のことをお勧めします。
- Adminなどの一般的なユーザー名は使用しないでください。これは、スキャンするだけのパッシブマルチホスト攻撃に見舞われる可能性があります。
- アカウントを使用する意図がないので、パスワードをめちゃくちゃにして、実際には長くて複雑に見えるようにすることもできます。
- attemptedアクセスと成功を監視しますが、成功した場合はより大きな問題が発生します。
- 最後に、これらの大きな問題の1つ：パスワードをハッシュ化してください!!!これは常識であるはずですが、びっくりします。パスワードがハッシュされていない場合、データベースの侵害[〜＃〜] will [〜＃〜]はすべてのアカウントへのアクセスを許可します。
最後の注意：他のユーザーは、成功したアクセスではなく試行に進むことが非常に重要である理由を述べています：特権のエスカレーションは たぶんほぼ確実に彼らが入ることができれば可能です。