내 질문이이 사이트의 범위와 일치하기를 바랍니다.

CMS를 개발 중 입니다. 현재 로그인 한 사용자가 세션의 IP 주소에 잠겨 있습니다. 불행히도 내 사용자 데이터베이스의 작은 부분이 지속적으로 두 개 이상의 IP 주소 사이를 이동합니다. 대부분은 아마도로드 밸런서를 사용합니다. 기술적으로 사용자 세션을 하나의 IP 주소로 잠글 필요는 없습니다. 내 웹 사이트에서 단일 페이지 요청에 대해 클라이언트가 여러 IP 주소를 전환 할 것으로 기대하지 않았습니다.

이제 클라이언트가 페이지 요청을 위해 IP 주소간에 끊임없이 이동할 수있는 위험이 무엇인지 궁금합니다 (예 : CSS 파일은 xxx.xxx.xxx.xxx에 의해 요청되고 JavaScript 파일은 yyy.yyy.yyy에 의해 요청 됨). yyy)? 일반적으로 허용 또는 금지해야합니까?

내 사용자층의 작은 부분이 두 개 이상의 IP 주소 사이를 끊임없이 이동합니다.

원인

사용자가 익명 서비스를 사용하여 실제 IP 주소를 적극적으로 숨기려고하지 않는다고 가정하면 ... :

내가 본 대부분의 기업 사례는 대기업과 일부 ISP가 서로 다른 외부 IP 주소를 가진 프록시 서버 클러스터를 사용하고 사용자 요청이 해당 클러스터에서로드 밸런싱되기 때문에 발생합니다.

듀얼 스택 사용자가 IPv4 및 IPv6을 통해 요청을 하고 후속 요청을 위해 두 프로토콜 RFC 8305 간에 전환하는 것을 볼 수 있습니다 .

다른 시나리오는 Wi-Fi 액세스 포인트의 극단적 인 범위에 있고 내 장치가 Wi-Fi와 셀룰러 데이터를 "무작위로"전환하는 경우입니다.

솔루션

첫 번째 시나리오에서는 일반적으로 프록시 서버 클러스터가 모두 작은 서브넷 내에 있고 인접한 IP 주소를 가지므로 처음 세 옥텟 만 고려하여 세션에서 이러한 IP 주소 "보안"을 유지하는 데 문제가있을 수 있습니다.

두 번째 및 세 번째 시나리오에서는 관련없는 공급자와 완전히 다른 클라이언트 IP 주소가 표시됩니다.

세션을 특정 IP 주소에 연결하지 마십시오. 실제로 개선 된 보안을 제공하는 것보다 사용자 경험이 손상 될 수 있습니다.

이제 클라이언트가 페이지 요청을 위해 IP 주소간에 끊임없이 이동할 수있는 위험이 무엇인지 궁금합니다 (예 : CSS 파일은 xxx.xxx.xxx.xxx에 의해 요청되고 JavaScript 파일은 yyy.yyy.yyy에 의해 요청 됨). yyy)? 일반적으로 허용 또는 금지해야합니까?

주요 위험은 악의적 인 사용자가 세션을 가로채는 것입니다. 하나 또는 작은 IP 주소 집합으로 잠글 수있는 경우 완전히 다른 IP 주소의 사용자가 세션을 가로 채지 못하게 차단할 수 있습니다.

문제는 일부 사용자가 합법적으로이 작업을 수행한다는 것입니다. 로드 밸런싱 프록시를 사용하든 두 개의 무선 액세스 포인트 (또는 기타)의 여백에 관계없이 여러 IP 주소를 사용합니다. 따라서 해당 사용자에게 거의 허용해야합니다. 그리고 여러 사용자가 여러 IP 주소에서 요청할 때를 제외하고 여러 사용자가 여러 IP 주소를 필요로하는 것을 말하기는 어렵습니다.

이로 인한 영향을 줄이는 한 가지 방법은 HTTPS를 사용하는 것입니다. 그런 다음 악의적 인 행위자가 세션 쿠키뿐만 아니라 보안 계층을 손상시킬 수있는 방법이 있어야합니다. 안전하지 않은 연결을 통해 악의적 인 행위자는 네트워크 검사를 사용하여 세션 쿠키를 손상시킬 수 있습니다. 그러나 HTTPS를 통해 동일한 악의적 인 행위자가 대화 끝 중 하나에 액세스해야합니다. 악의적 인 행위자가 가지고 있다면 다른 IP를 사용할 필요는 없습니다.

TL; DR : 일반적으로 동일한 사용자에 대해 다른 IP 주소의 요청을 허용해야합니다. 이것이 일어날 수있는 합법적 인 이유가 있습니다. 해당 익스플로잇으로부터 보호하려면 HTTPS를 사용하십시오.

클라이언트가 페이지 요청을 위해 IP 주소 사이를 지속적으로 이동할 수있게하는 위험은 무엇입니까?

보안 관점에서 볼 때 위험이 없습니다.

이제 실용적인 관점에서. 즉, 보안 또는 DoS 보호에 특정 유형의 알고리즘을 사용할 수 없습니다 .

사용자 요청을 조절하는 간단한 방법은 IP 주소로 추적하는 것입니다. 응용 프로그램 서버와 상호 작용할 필요가 없으므로 낮은 수준의 서비스를 사용하여이를 수행 할 수 있습니다. Apache의 mod_evasive와 같은 소프트웨어가이를 수행합니다. 이러한 기술을 계속 사용할 수 있지만 사용자가 IP 주소를 변경하면 효율성이 떨어집니다. 그런 다음 사용자는 어쨌든 IP 주소를 전환하므로 이러한 기술은 실제로 효과적이지 않습니다.

관련이 있지만 다른 유스 케이스는 실패한 로그인 시도를 제한하는 것입니다. 이는 무차별 암호 추측을 방지하기위한 것입니다. 그러나 사용자가 IP 주소를 변경하면 어쨌든 할 수있는 일은 없습니다. 정말로 심각한 해커는 자신의 컴퓨터를 사용하지 않을 것입니다. 그는 봇넷에서 시간을 벌거나 (또는 ​​이전에 감염된 자신의 봇넷을 사용하여) 10,000 명의 다른 사람의 PC (IP 주소)를 통해 서비스에 연결합니다. 사전 로그인이므로 사용자의 IP 주소를 제한하는 것과는 관련이 없지만 명심해야합니다.

사용자가 새로운 IP 주소로 이동할 수있는 몇 가지 이유가 있습니다.

1. IPv6 개인 정보 확장, 요즘 많은 IPv6 클라이언트가 LAN의 / 64 내에서 이동합니다.
2. 로드 밸런싱 프록시, 클라이언트 요청은 각각 별도의 IP를 가진 여러 프록시 중 하나로 라우팅됩니다.
3. NAT 풀, 경계 nat는 여러 개의 IP 주소로 구성되며 풀 임의의 IP 주소에서 클라이언트 TCP 연결로 IP / 포트 조합을 할당합니다.
4. 사용자는 오늘날 전화와 공통으로 다른 네트워크 또는 네트워크의 일부 사이를 이동합니다.
5. 이중 스택 사용자는 IPv4와 IPv6 사이를 이동할 수 있습니다.

내 고객이 페이지 요청을 위해 IP간에 끊임없이 이동할 수있게하는 위험이 무엇인지 궁금합니다.

클라이언트 sessoins를 IP에 잠그면 얻을 수있는 이점으로 세션 도용 공격이 더 어려워집니다. 공격자가 클라이언트 쿠키를 훔칠 수 있지만 클라이언트 IP 주소에서 서버에 연결하지 못하게하는 메커니즘이있는 경우 IP 잠금은 세션을 훔치는 것을 차단합니다.

단점은 명백한 이유없이 세션이 무효화 된 일부 사용자에게 파손을 일으킬 것이라고 말합니다.

오늘날 대부분의 사이트는 파손이 그러한 잠금의 이점보다 중요하다고 생각합니다.