web-dev-qa-db-ja.com

同じ外部IPアドレスを持つユーザーを一意に識別する方法は？

ウェブサイトにログインモジュールを作成しました。ユーザー名/メールに基づいてユーザーを識別し、ユーザーアカウントごとの失敗したログイン試行に基づいてログインを調整できるため、単純なブルートフォース攻撃に対処することができました。

しかし、ユーザーが列挙したブルートフォース攻撃（別名、逆ブルートフォース攻撃）に関しては、ユーザーの特定はかなり困難になります。 IPアドレスごとの失敗した試行に基づいてログインを調整すると、同じ外部IPアドレスが割り当てられるため、ローカルネットワーク経由でインターネットに接続しているユーザーがうまく機能せず、他の誰かが試行に失敗したために調整に直面する可能性があるため、煩わしいネットワーク。

そのようなユーザーを一意に識別する方法はありますか？

authenticationip
29
ashu

同じ外部IPアドレスを持つユーザーを一意に識別する方法は？そのようなユーザーを一意に識別する方法はありますか？

はい、たくさんの方法があります：

  • クッキー
  • Evercookies （Flash Cookie、さまざまなHTML5ストレージオプション、アクセスしたブラウザーのリンク履歴など、さまざまな手法を使用して識別情報を保存するJavaScriptコード）
  • デバイスのフィンガープリント：HTTPヘッダーを使用します（主にユーザーエージェントですが、他のヘッダーとその順序も役立ちます）。
  • JavaScriptを使用したデバイスフィンガープリント：JavaScriptを使用すると、画面の解像度、タイムゾーン、プラグイン、システムフォントなど、多くの情報を取得できます。
  • 動作：ユーザーがフォームに入力する速度、ボタンのどこをクリックするかなど。

しかし、これらのほとんどはブルートフォース攻撃からの防御には役立ちません。これは、それらを実行するプログラムがCookieを受け入れたり、JavaScriptを実行したりしないためです。

あなたの場合、あなたは試すかもしれません：

  • HTTPヘッダー：これらは、実際には同じIPアドレスを使用するユーザーを区別するのに十分である可能性があります（もちろん、攻撃者はランダムにそれらを切り替えることができますが、ほとんどの場合そうではないと思います）。
  • 軽いスロットル：IPアドレスをブロックする必要はありません。IPアドレスのログインプロセスを遅くするだけで済みます。そうすれば、ブルートフォースはあまり実行できなくなりますが、同じIPアドレスを使用する実際のユーザーは引き続きログインできます。
  • CAPTCHAs ：これらは正当なユーザーを困らせますが、ブルートフォース攻撃の発信元であるIPアドレスを実際に使用しているユーザーが多すぎないことを願います（もちろん、CAPTCHAを自動的に解決するツールがありますが、 CAPTCHAなし）。
  • ログインを許可する前に、ユーザーにCookieを受け入れ、さまざまな識別情報（画面の解像度、タイムゾーンなど）を送信するよう要求することができます。もちろん、攻撃者もこれを行うことができますが、現在存在するブルートフォースツールでこれを行うことはできないので、カスタムスクリプトを作成する必要があります。しかし、これは正当なユーザーを困らせるかもしれません。
37
tim

HTML5＆ WebRTC を使用すると、インターネットからでもユーザーの内部IPアドレスを取得できます。詳細については、記事 HTML5 WebRTCを使用したローカルIP検出：セキュリティとプライバシーのリスク？ を確認して試してみてください。 http://net.ipcalf.com/ 。

記事を掲載しているウェブサイトは現在ダウンしているようです。ただし、この記事 WebRTC Founding Leaking Local IP Adresses もいくつかの情報を提供できると思います。

21
Batuhan

私の知る限り、なりすまし方法はありません。すでに最大試行回数を1分間のタイムアウトで1分あたり8回に制限している場合。 1分のタイムアウトは、ユーザーに十分な情報を提供する限り、一般的に迷惑とは見なされません。

誰があなたをブルートフォースにしようとしているのかを調査するのは興味深いかもしれないので、IPアドレスからブルートフォースが疑われる場所でこれらの発生を積極的に確認してください。

5
Lucas Kauffman

ここで説明する他のほとんどの方法は、簡単に無効にされたり、パフォーマンスが大幅に低下したりします。

これが、Webアプリケーションファイアウォール（WAF）がそれらに依存しない理由です。

2つの信頼できる方法は次のとおりです。

  • IPヘッダーのパケットシーケンスを分析します：ほとんどのTCP/IPは番号パケットを順番にスタックするため、番号がランダムである場合、クライアントはおそらく遅れています= NAT（他のクライアントとの共有インターネット接続）。いくつかのRAM前のパケットIDを記憶するためのオーバーヘッドがありますが、セッションCookieに相当します。これは攻撃者はパケットを低レベルで書き換える必要があるため、なりすましは困難ですが、不可能ではないため、レート制限と組み合わせる必要があります。NAT処理されたパブリックIPでより多くのヒット/秒を許可します。
  • 暗号認証を使用したセッションCookie：通常のセッションCookieは十分ではありません。それらはHTTPで暗号化されておらず、HTTPSでさえ暗号化されていないため、HTTPS暗号化ペイロードの一部ではない可能性があり、したがって認証もされていません。 http://blog.teamtreehouse.com/how-to-create-totally-secure-cookies 正しく実行してください。 暗号化されているだけでなく、認証済み/「署名済み」であることを確認してください。http://spring.io/blog/2014/01/ 20/exploiting-encrypted-cookies-for-fun-and-profit Webアプリのコードにのみアクセスできる場合は、これがより良いオプションです。明らかにCookieが無効になっている場合は、ブラウザとボットを区別するクライアント側JavaScriptを実行します（ボットがサポートしない画面解像度などを要求し、スクリプトが失敗した場合はボットのステータスを返します）。 これを、認証済みセッションCookieによるレート制限と組み合わせるか、Cookieが無効になっている場合は、IPベースのレート制限（「スロットリング」）またはブロックと組み合わせます。ブルートフォース攻撃者は何千回も再試行する可能性があるため、これはIP/HTTPパーサーのルーチンの早い段階で要求を受け入れ/拒否し、将来のCPUサイクルを節約します。 DHCP/PPPoE /新しいセッションCookieにより、禁止は数分後に期限切れになります。 GoogleやBaiduなどの検索エンジンクローラーの偽装されていないIPをホワイトリストに登録する必要があることに注意してください。そうしないと、検索ランキングが低下する可能性があります。

ソリューションをレート制限と組み合わせる場合、正しいレート制限は、ページあたりのURL数の1〜2倍にする必要があります。たとえば、login.phpに2つのCSSファイル、4つのJavaScriptファイル、10の画像と1つのページ自体が含まれている場合、クライアントセッションCookieごとに1秒あたり少なくとも合計17ヒットを許可する必要があります。それ以外の場合は、通常のリクエストをブロック/制限している可能性があります。

持続的な攻撃の場合は、上流のルートをブロックまたはブラックホール化するようにISPに依頼する必要があります。

他のソリューションを使用しないのはなぜですか？

「User-Agent：」はなりすましに非常に簡単です。

wget -O index.html --user-agent="My Fake Browser"

セッションCookie、「X-Forwarded-For：」HTTPヘッダー、およびその他のヘッダーも、盗む/偽造するのは簡単です。 Googleの「Firesheep」、「Cookies Manager +」、「Modify Headersプラグイン」、「LiveHeadersプラグイン」など。

ステルス攻撃はリクエスト間のランダム化または待機時間の増加を引き起こすため、レート制限だけでは十分ではありません。

wget --limit-rate=10 http://example.com/index.php

通常、ブルートフォースが唯一の問題ではありません。https://www.owasp.org/index.php/Top_10_2013-Top_1 =効果的な保護のコーディングとテストにも時間がかかります。 Webサーバーの時間やCPUサイクルを節約するには（サーバーファームがある場合は何倍にもなる無駄です）、Webホストは、これが構成されたフロントエンドWAFを提供する必要があります。これが最善の解決策です。サーバー側で実行しないでください。上流で行います。

4
Courtney Schwartz

一意の識別は難しいかもしれませんが、ユーザーエージェントなどのサーバー変数やCookieなどのローカル変数を追加する可能性があります（どちらも偽装や回避される可能性がありますが、少なくともIPアドレスと一緒にいくつかのバリエーションを追加します）。 JavaScriptがオプションの場合、次のことを試すことができます ブラウザフィンガープリント （JavaScriptまたはHTML5 Canvas）

3
Alasjo