Я надеюсь, что мой вопрос соответствует сфере действия этого сайта.
Я разрабатываю CMS . В настоящее время мои вошедшие в систему пользователи заблокированы на их IP-адрес для сеанса. К сожалению, небольшая часть моей пользовательской базы постоянно перепрыгивает между двумя или более IP-адресами. Большинство из них, вероятно, используют балансировщики нагрузки. Технически нет необходимости блокировать сеансы пользователей на один IP-адрес. Я не ожидал, что клиенты будут переключаться между несколькими IP-адресами для одного запроса страницы на моем веб-сайте.
Теперь мне интересно, каковы риски, позволяющие моим клиентам постоянно переходить между IP-адресами для запроса страницы (например, файлы CSS запрашиваются с помощью xxx.xxx.xxx.xxx, а файлы JavaScript - с помощью yyy.yyy.yyy. ууу)? Должен ли я вообще разрешить или запретить это?
Ответы:
причины
Предполагая, что ваши пользователи не пытаются активно скрывать свои реальные IP-адреса с помощью службы анонимности ...:
Большинство корпоративных примеров, которые я видел, вызваны тем, что крупные компании и некоторые интернет-провайдеры используют кластер прокси-серверов, каждый из которых имеет свой внешний IP-адрес, причем запросы пользователей балансируют нагрузку в этом кластере.
Вы можете увидеть пользователей с двумя стеками, которые делают запросы как по IPv4, так и по IPv6 и переключаются между двумя протоколами RFC 8305. для последующих запросов.
Другой сценарий - когда я нахожусь в экстремальном диапазоне точки доступа Wi-Fi, и мое устройство «случайным образом» переключается между Wi-Fi и сотовой передачей данных.
Решения
В первом сценарии вы можете пойти на компромисс в сохранении такого IP-адреса «безопасности» в своих сеансах, рассматривая только первые три октета, поскольку обычно такой кластер прокси-серверов находится в небольшой подсети и будет иметь соседние IP-адреса.
Во втором и третьем сценарии вы увидите совершенно разные клиентские IP-адреса, даже от несвязанных провайдеров.
Не привязывайте свои сеансы к определенному IP-адресу, это скорее нарушит работу пользователя, чем обеспечит реальную улучшенную безопасность.
источник
Основной риск - злонамеренный пользователь, взломавший сеанс. Если бы вы могли ограничиться одним или небольшим набором IP-адресов, вы могли бы блокировать пользователей с совершенно разных IP-адресов от перехвата сеанса.
Проблема в том, что некоторые пользователи делают это законно. Независимо от того, используют ли они прокси-сервер с балансировкой нагрузки или находятся на полях двух точек беспроводного доступа (или чего-либо другого), они используют несколько IP-адресов. Таким образом, вы в значительной степени должны разрешить это для этих пользователей. И трудно сказать, каким пользователям требуется несколько IP-адресов, кроме случаев, когда они запрашивают несколько IP-адресов.
Одним из способов уменьшить влияние этого является использование HTTPS. Тогда у злоумышленника должен быть способ скомпрометировать защищенный уровень, а также файл cookie сеанса. По небезопасному соединению злоумышленник может просто использовать проверку сети, чтобы скомпрометировать cookie-файл сеанса. Но через HTTPS один и тот же злоумышленник должен иметь доступ к одному из концов разговора. И если злоумышленник имеет это, то нет необходимости использовать другой IP.
TL; DR : вам следует разрешать запросы с разных IP-адресов одному и тому же пользователю. Есть законные причины, по которым это может произойти. Вместо этого используйте HTTPS для защиты от этого класса эксплойтов.
источник
С точки зрения безопасности - ноль рисков.
Теперь с практической точки зрения. Это означает, что вы не можете использовать определенные типы алгоритмов ни для безопасности, ни для DoS .
Простой способ регулирования пользовательских запросов - отслеживание по IP-адресу. Поскольку это не требует взаимодействия с вашим сервером приложений, вы можете использовать сервисы на более низких уровнях для этого. Такие программы, как Apache mod_evasive, делают это. Вы все еще можете использовать эти методы, но изменение пользователем IP-адресов снизит их эффективность. С другой стороны, пользователи все равно будут переключать IP-адреса, поэтому эти методы никогда не были эффективными.
Связанный, но другой, вариант использования регулирует неудачные попытки входа в систему. Это сделано для предотвращения подбора пароля методом перебора. Но опять же, вы ничего не можете сделать, если пользователи меняют IP-адреса. Действительно серьезный хакер даже не использовал бы свои машины. Он просто покупал некоторое время в ботнете (или использовал свой ранее зараженный ботнет) и подключался к вашему сервису через 10 000 компьютеров (IP-адресов) других людей. Это на самом деле не связано с ограничением IP-адреса пользователя, потому что это предварительный вход в систему, но об этом следует помнить.
источник
Существует несколько причин, по которым пользователь может перейти на новый IP-адрес.
Преимущество привязки клиентских sessoins к IP-адресам заключается в том, что они усложняют атаки кражи сеансов. Если у злоумышленника есть механизм, который позволяет им красть файлы cookie клиентов, но не позволяет им устанавливать подключения к вашему серверу с IP-адреса клиентов, тогда блокировка IP-адресов не позволит им украсть сеанс.
Недостатком является то, как вы говорите, это приведет к поломке для некоторых пользователей, которые считают, что их сеанс признан недействительным без видимой причины.
В настоящее время большинство сайтов считают, что поломка перевешивает преимущества такой блокировки.
источник