Я сподіваюся, що моє запитання відповідає обсягу цього веб-сайту.

Я розробляю CMS . Наразі мої зареєстровані користувачі заблоковані на їх IP-адресу для сеансу. На жаль, невелика частина моєї бази даних постійно переходить між двома або більше IP-адресами. Більшість із них, ймовірно, використовують балансири навантаження. Технічно не потрібно блокувати сеанси користувачів однією IP-адресою. Я не очікував, що клієнти переключаться між декількома IP-адресами для запиту однієї сторінки на моєму веб-сайті.

Мені зараз цікаво, які ризики дозволяють моїм клієнтам постійно переходити між IP-адресами для запиту сторінки (наприклад, CSS-файли запитуються xxx.xxx.xxx.xxx, а файли JavaScript запитують yyy.yyy.yyy. yyy)? Чи потрібно взагалі дозволити чи заборонити це?

невелика частина моєї бази даних постійно переходить між двома або більше IP-адресами.

Причини

Якщо припустити, що ваші користувачі активно не намагаються приховати свої реальні IP-адреси за допомогою сервісу анонімізації ...:

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

Ви можете бачити користувачів Dual Stack, які роблять запити як через 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. Тоді зловмисний актор повинен мати спосіб скомпрометувати захищений шар, а також файли cookie сеансу. Через незахищений зв’язок, злісний актор може просто використовувати перевірку мережі для компрометації файлів cookie сеансу. Але над HTTPS той самий злісний актор повинен мати доступ до одного з кінців розмови. І якщо злісний актор має це, то використовувати інший IP не потрібно.

TL; DR : зазвичай ви можете дозволити запити з різних IP-адрес для одного і того ж користувача. Є законні причини, що це може статися. Замість цього використовуйте HTTPS для захисту від цього класу подвигів.

які ризики дозволяють моїм клієнтам постійно переходити між IP-адресами для запиту сторінки

З точки зору безпеки - нульові ризики.

Тепер, з практичної точки зору. Це означає, що ви не можете використовувати певні типи алгоритмів ні для захисту, ні для захисту DoS .

Простий спосіб заглушити запити користувачів - це відстеження за IP-адресою. Оскільки для цього не потрібно взаємодіяти з вашим сервером додатків, для цього ви можете використовувати сервіси нижчих рівнів. Програмне забезпечення на зразок mod_evasive Apache робить це. Ви все ще можете використовувати ці методи, але зміна 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-адресами на запит на сторінку

Перевага блокування сеансів клієнта до IP-адрес полягає в тому, що він ускладнює атаку з крадіжки сеансу. Якщо зловмисник має механізм, який дозволяє їм викрадати файли cookie клієнтів, але не дає їм з’єднатися з вашим сервером з IP-адреси клієнтів, тоді IP-блокування заблокує їх вкрасти сеанс.

Мінус, як ви говорите, може призвести до поломки деяких користувачів, які вважають свою сесію недійсною без очевидних причин.

На сьогоднішній день більшість сайтів, здається, вважають, що поломка переважає переваги такого блокування.