1つのセッションで1つのWebサイトで複数のIPアドレスを許可する必要があるのはなぜですか?


18

私の質問がこのサイトの範囲と一致することを願っています。

私はCMSを開発しています。現在、ログインしているユーザーはセッションのIPアドレスにロックされています。残念ながら、ユーザーベースのごく一部が、2つ以上のIPアドレス間を常にジャンプしています。それらのほとんどは、おそらくロードバランサーを使用します。技術的には、ユーザーセッションを1つのIPアドレスにロックする必要はありません。クライアントが私のWebサイトの1ページのリクエストで複数のIPアドレスを切り替えることは期待していませんでした。

クライアントがページリクエストのIPアドレス間を絶えずジャンプできるようにするリスクは何でしょうか(たとえば、CSSファイルはxxx.xxx.xxx.xxxによって要求され、JavaScriptファイルはyyy.yyy.yyyによって要求されます)。 yyy)?通常、それを許可または禁止する必要がありますか?


39
IPを飛び回るのにロードバランサーさえ必要ありません。地下鉄で携帯電話に接続すると、列車の走行中に数分ごとに異なるIPを取得し、その後、目的地で携帯電話がWiFiに切り替わると再びIPを取得する場合があります。
whatsisname

13
また、場所間を移動するラップトップ(ホーム>仕事>スターバックスなど)の場合も同様です。また、IPv6ランダムアドレス(IPv6 SLAACプライバシー拡張)。
marcelm

直感的には、異なるソースIpsを飛び回るクライアントが「ときどき」以外の問題を引き起こすと予想します。
トムH

1
制御するネットワークにインストールされるwebappを開発している場合、または知識がある場合、セキュリティのためにこれを行うことを決定することができます。 WSからこれにアクセスし、ロードバランサーなど、IPを変更する可能性のあるものはありません」...数か月に1回しか変更されない可能性があります)
バクリウ

1
@TomHいいえ、大多数のWebアプリはIPアドレスを気にしません。新しいTCP接続を介したHTTPリクエストで同じCookieを受け入れます。認知度が低く、デザインが悪いがらくただけが、セッションをIPまたは接続にロックします。
ナビン

回答:


35

ユーザーベースのごく一部が、2つ以上のIPアドレス間を常にジャンプしています。

原因

ユーザーが匿名サービスを使用して実際のIPアドレスを積極的に隠そうとしていないと仮定すると...:

私が見たほとんどの企業の例は、大企業といくつかのISPがプロキシサーバーのクラスターを使用しており、それぞれが異なる外部IPアドレスを持ち、ユーザー要求がそのクラスターで負荷分散されることによって発生します。

デュアルスタックユーザーがIPv4とIPv6の両方でリクエストを作成し、後続のリクエストで2つのプロトコルRFC 8305を切り替えることがあります。

もう1つのシナリオは、Wi-Fiアクセスポイントの極端な範囲にいて、デバイスがWi-Fiとセルラーデータを「ランダムに」切り替える場合です。

解決策

最初のシナリオでは、最初の3オクテットのみを考慮することで、セッションでそのようなIPアドレスの「セキュリティ」を維持することで妥協する場合があります。

2番目と3番目のシナリオでは、無関係なプロバイダーからであっても、まったく異なるクライアントIPアドレスが表示されます。

特定のIPアドレスにセッションを結び付けないでください。これにより、実際のセキュリティが向上するよりも、ユーザーエクスペリエンスが損なわれる可能性が高くなります。


27
まさにこれらの理由から、セッションをIPアドレスに結び付ける人はもういません。
マイケルハンプトン

33
セッションをIPアドレスに決して結び付けないでください、80年代は終わりました!私のISPは完全な/ 64ネットワークを携帯電話に提供しており、そこではブラウザが狂ったように飛び回っています。
bjoster

6
すべてに加えて、マルチパスTCPはますます一般的になっています。
ことができますポイラゾウル

3
テクニカルユーザー向けにCMSを作成する場合、ログインページに「このセッションをIP(xxx.yyy.zzz.iii)のみに制限する」チェックボックスを置くことができます
Ferrybig

6
@bjosterは、IPv6プライバシー拡張機能により、アドレスを切り替え続けるため、WebサイトがIPのみで追跡できないためです(複数の人が同じアドレスの背後にいるため、これはIPv4の問題ではありません)
Ferrybig

9

クライアントがページリクエストのIPアドレス間を絶えずジャンプできるようにするリスクは何でしょうか(たとえば、CSSファイルはxxx.xxx.xxx.xxxによって要求され、JavaScriptファイルはyyy.yyy.yyyによって要求されます)。 yyy)?通常、それを許可または禁止する必要がありますか?

主なリスクは、悪意のあるユーザーがセッションをハイジャックすることです。1つまたは少数のIPアドレスにロックダウンできる場合、まったく異なるIPアドレスからのユーザーがセッションを乗っ取ることをブロックできます。

問題は、一部のユーザーがこれを正当に行うことです。負荷分散プロキシを使用している場合でも、2つのワイヤレスアクセスポイント(またはその他)の近くにいる場合でも、複数のIPアドレスを使用します。そのため、それらのユーザーに許可する必要があります。また、複数のIPアドレスから要求する場合を除き、どのユーザーが複数のIPアドレスを必要とするかを判断するのは困難です。

この影響を軽減する1つの方法は、HTTPSを使用することです。その場合、悪意のある攻撃者は、セッションCookieと同様にセキュリティで保護されたレイヤーを侵害する方法を持っている必要があります。安全でない接続では、悪意のある攻撃者はネットワーク検査を使用してセッションCookieを侵害する可能性があります。しかし、HTTPS経由では、同じ悪意のあるアクターが会話のいずれかの端にアクセスする必要があります。悪意のある攻撃者がそれを持っている場合、別のIPを使用する必要はありません。

TL; DR:通常、同じユーザーに対して異なるIPアドレスからのリクエストを許可する必要があります。これが起こる正当な理由があります。代わりにHTTPSを使用して、そのクラスのエクスプロイトから保護します。


4

クライアントがページリクエストのIPアドレス間を常にジャンプできるようにするリスクは何ですか

セキュリティの観点から-リスクはゼロ。

今、実用的な観点から。つまり、セキュリティまたはDoS保護のために特定の種類のアルゴリズムを使用することはできません。

ユーザー要求を調整する簡単な方法は、IPアドレスで追跡することです。これはアプリケーションサーバーとやり取りする必要がないため、低レベルのサービスを使用してこれを行うことができます。Apacheのmod_evasiveのようなソフトウェアがこれを行います。これらの手法は引き続き使用できますが、ユーザーがIPアドレスを変更すると、効果が低下します。繰り返しになりますが、ユーザーはいずれにせよIPアドレスを切り替えるため、これらの手法は実際には効果的ではありませんでした。

関連するが、異なるユースケースは、失敗したログイン試行を抑制することです。これは、総当たりパスワードの推測を防ぐためです。ただし、ユーザーがIPアドレスを変更しても、とにかくできることは何もありません。真面目なハッカーは自分のマシンさえ使用しないでしょう。彼はボットネットで時間を購入し(または以前に感染したボットネットを使用して)、10,000人の他のPC(IPアドレス)を介してサービスに接続しました。これは、事前ログインであるため、ユーザーのIPアドレスの制限とは実際には関係ありませんが、留意する必要があります。


1

ユーザーが新しいIPアドレスにジャンプする理由はいくつかあります。

  1. IPv6プライバシー拡張機能、多くのIPv6クライアントは現在、LANの/ 64内を飛び回っています。
  2. 負荷分散プロキシ。クライアント要求は、それぞれが個別のIPを持ついくつかのプロキシのいずれかにルーティングされます。
  3. NATプールでは、ボーダーNATは複数のIPアドレスで構成され、プールから任意のIP /ポートの組み合わせを任意のクライアントTCP接続に割り当てます。
  4. ユーザーは、最近の電話で一般的な、異なるネットワークまたはネットワークの一部の間を移動します。
  5. デュアルスタックユーザーは、IPv4とIPv6の間をホップできます。

私は今、私のクライアントがページリクエストのためにIP間を絶えずジャンプできるようにするリスクは何ですか?

クライアントセソインをIPにロックすることの利点は、セッションを盗む攻撃が難しくなることです。攻撃者がクライアントCookieを盗むことができるが、クライアントIPアドレスからサーバーへの接続を許可しないメカニズムを持っている場合、IPロックはセッションを盗むことをブロックします。

マイナス面は、明確な理由がないためにセッションが無効になった一部のユーザーに破損を引き起こすということです。

最近のほとんどのサイトは、このようなロックの利点よりも破損の方が大きいと考えているようです。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.