Я надеюсь, что мой вопрос соответствует сфере действия этого сайта.

Я разрабатываю CMS . В настоящее время мои вошедшие в систему пользователи заблокированы на их IP-адрес для сеанса. К сожалению, небольшая часть моей пользовательской базы постоянно перепрыгивает между двумя или более IP-адресами. Большинство из них, вероятно, используют балансировщики нагрузки. Технически нет необходимости блокировать сеансы пользователей на один IP-адрес. Я не ожидал, что клиенты будут переключаться между несколькими IP-адресами для одного запроса страницы на моем веб-сайте.

Теперь мне интересно, каковы риски, позволяющие моим клиентам постоянно переходить между IP-адресами для запроса страницы (например, файлы CSS запрашиваются с помощью xxx.xxx.xxx.xxx, а файлы JavaScript - с помощью yyy.yyy.yyy. ууу)? Должен ли я вообще разрешить или запретить это?

небольшая часть моей пользовательской базы постоянно перепрыгивает между двумя или более IP-адресами.

причины

Предполагая, что ваши пользователи не пытаются активно скрывать свои реальные IP-адреса с помощью службы анонимности ...:

Большинство корпоративных примеров, которые я видел, вызваны тем, что крупные компании и некоторые интернет-провайдеры используют кластер прокси-серверов, каждый из которых имеет свой внешний IP-адрес, причем запросы пользователей балансируют нагрузку в этом кластере.

Вы можете увидеть пользователей с двумя стеками, которые делают запросы как по IPv4, так и по IPv6 и переключаются между двумя протоколами RFC 8305. для последующих запросов.

Другой сценарий - когда я нахожусь в экстремальном диапазоне точки доступа Wi-Fi, и мое устройство «случайным образом» переключается между Wi-Fi и сотовой передачей данных.

Решения

В первом сценарии вы можете пойти на компромисс в сохранении такого IP-адреса «безопасности» в своих сеансах, рассматривая только первые три октета, поскольку обычно такой кластер прокси-серверов находится в небольшой подсети и будет иметь соседние IP-адреса.

Во втором и третьем сценарии вы увидите совершенно разные клиентские IP-адреса, даже от несвязанных провайдеров.

Не привязывайте свои сеансы к определенному IP-адресу, это скорее нарушит работу пользователя, чем обеспечит реальную улучшенную безопасность.

Теперь мне интересно, каковы риски, позволяющие моим клиентам постоянно переходить между IP-адресами для запроса страницы (например, файлы CSS запрашиваются с помощью xxx.xxx.xxx.xxx, а файлы JavaScript - с помощью yyy.yyy.yyy. ууу)? Должен ли я вообще разрешить или запретить это?

Основной риск - злонамеренный пользователь, взломавший сеанс. Если бы вы могли ограничиться одним или небольшим набором IP-адресов, вы могли бы блокировать пользователей с совершенно разных IP-адресов от перехвата сеанса.

Проблема в том, что некоторые пользователи делают это законно. Независимо от того, используют ли они прокси-сервер с балансировкой нагрузки или находятся на полях двух точек беспроводного доступа (или чего-либо другого), они используют несколько IP-адресов. Таким образом, вы в значительной степени должны разрешить это для этих пользователей. И трудно сказать, каким пользователям требуется несколько IP-адресов, кроме случаев, когда они запрашивают несколько IP-адресов.

Одним из способов уменьшить влияние этого является использование HTTPS. Тогда у злоумышленника должен быть способ скомпрометировать защищенный уровень, а также файл cookie сеанса. По небезопасному соединению злоумышленник может просто использовать проверку сети, чтобы скомпрометировать cookie-файл сеанса. Но через HTTPS один и тот же злоумышленник должен иметь доступ к одному из концов разговора. И если злоумышленник имеет это, то нет необходимости использовать другой IP.

TL; DR : вам следует разрешать запросы с разных IP-адресов одному и тому же пользователю. Есть законные причины, по которым это может произойти. Вместо этого используйте HTTPS для защиты от этого класса эксплойтов.

Каковы риски, позволяющие моим клиентам постоянно переходить между IP-адресами для запроса страницы

С точки зрения безопасности - ноль рисков.

Теперь с практической точки зрения. Это означает, что вы не можете использовать определенные типы алгоритмов ни для безопасности, ни для DoS .

Простой способ регулирования пользовательских запросов - отслеживание по IP-адресу. Поскольку это не требует взаимодействия с вашим сервером приложений, вы можете использовать сервисы на более низких уровнях для этого. Такие программы, как Apache mod_evasive, делают это. Вы все еще можете использовать эти методы, но изменение пользователем IP-адресов снизит их эффективность. С другой стороны, пользователи все равно будут переключать IP-адреса, поэтому эти методы никогда не были эффективными.

Связанный, но другой, вариант использования регулирует неудачные попытки входа в систему. Это сделано для предотвращения подбора пароля методом перебора. Но опять же, вы ничего не можете сделать, если пользователи меняют IP-адреса. Действительно серьезный хакер даже не использовал бы свои машины. Он просто покупал некоторое время в ботнете (или использовал свой ранее зараженный ботнет) и подключался к вашему сервису через 10 000 компьютеров (IP-адресов) других людей. Это на самом деле не связано с ограничением IP-адреса пользователя, потому что это предварительный вход в систему, но об этом следует помнить.

Существует несколько причин, по которым пользователь может перейти на новый IP-адрес.

1. Расширения конфиденциальности IPv6, многие клиенты IPv6 в настоящее время будут переходить в / 64 по локальной сети.
2. Прокси-серверы с балансировкой нагрузки, запрос клиента направляется на один из нескольких прокси-серверов, каждый с отдельным IP.
3. Пулы NAT, граница nat настроена с несколькими IP-адресами и назначает комбинации IP / порт из пула произвольно для клиентских TCP-соединений.
4. Пользователь перемещается между различными сетями или частями сети, что в настоящее время характерно для телефонов.
5. Пользователи с двумя стеками могут переключаться между IPv4 и IPv6.

Теперь мне интересно, каковы риски, позволяющие моим клиентам постоянно переходить между IP-адресами для запроса страницы

Преимущество привязки клиентских sessoins к IP-адресам заключается в том, что они усложняют атаки кражи сеансов. Если у злоумышленника есть механизм, который позволяет им красть файлы cookie клиентов, но не позволяет им устанавливать подключения к вашему серверу с IP-адреса клиентов, тогда блокировка IP-адресов не позволит им украсть сеанс.

Недостатком является то, как вы говорите, это приведет к поломке для некоторых пользователей, которые считают, что их сеанс признан недействительным без видимой причины.

В настоящее время большинство сайтов считают, что поломка перевешивает преимущества такой блокировки.