Один IP на всех: как обнаружить CGNAT и избежать проблем

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

Но структура Интернета изменилась, и эти предположения больше не могут считаться верными. Сегодня один IPv4-адрес может представлять сотни или даже тысячи пользователей из-за широкого использования Carrier-Grade Network Address Translation (CGNAT), VPN и прокси- промежуточных устройств. Такая концентрация трафика может привести к значительному побочному ущербу – особенно для пользователей в развивающихся регионах мира – когда механизмы безопасности применяются без учета многопользовательской природы IP-адресов.

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

Наша работа изначально была мотивирована простым наблюдением: CGNAT является вероятным незаметным источником предвзятости в Интернете. Эта предвзятость была бы более выраженной там, где больше пользователей и меньше адресов, например, в развивающихся регионах. И эти предубеждения могут иметь глубокие последствия для пользовательского опыта, сетевых операций и цифрового равенства.

Причины понятны по многим причинам, не в последнюю очередь из-за необходимости. Страны развивающегося мира часто имеют значительно меньше доступных IP-адресов и больше пользователей. Это неравенство является историческим артефактом того, как развивался Интернет: самые большие блоки IPv4-адресов были распределены десятилетия назад в основном организациям в Северной Америке и Европе, оставив гораздо меньший пул для регионов, где внедрение Интернета расширилось позже. 

Чтобы визуализировать разрыв в распределении IPv4, мы построили график соотношения пользователей к IP-адресам на уровне стран на рисунке ниже. Мы берем оценки онлайн-пользователей от Группы Всемирного банка и количество IP-адресов в стране из записей Региональных интернет-регистраторов (RIR). Получившаяся цветовая карта показывает, что использование каждого IP-адреса более сконцентрировано в регионах, которые обычно имеют плохое проникновение Интернета. Например, большие части Африки и Южной Азии отображаются с самыми высокими соотношениями пользователей к IP. И наоборот, самые низкие соотношения пользователей к IP наблюдаются в Австралии, Канаде, Европе и США — именно в тех странах, которые в остальном имеют самые высокие показатели проникновения Интернета среди пользователей.

Нехватка адресного пространства IPv4 означает, что региональные различия могут только ухудшаться по мере роста уровня проникновения Интернета. Естественным следствием увеличения спроса в развивающихся регионах является то, что интернет-провайдеры будут еще больше полагаться на CGNAT, и это усугубляется тем фактом, что CGNAT распространен в мобильных сетях, от которых так сильно зависят пользователи в развивающихся регионах. Все это означает, что действия, известные как основанные на репутации IP или поведении, будут непропорционально сильно затрагивать развивающиеся экономики. 

Cloudflare — это глобальная сеть в глобальном Интернете. Мы делимся нашей методологией, чтобы другие могли извлечь выгоду из нашего опыта и помочь смягчить непреднамеренные последствия. Сначала давайте лучше поймем CGNAT.

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

Отдельно другая форма крупномасштабного совместного использования IP-адресов часто остается незамеченной пользователями: Carrier-Grade NAT (CGNAT). Один из способов объяснить CGNAT — начать с гораздо меньшей версии преобразования сетевых адресов (NAT), которая, скорее всего, существует в вашем домашнем широкополосном маршрутизаторе, формально называемом оборудованием клиентских помещений (CPE), которое преобразует невидимые частные адреса в доме в видимые и маршрутизируемые адреса у интернет-провайдера. Как только трафик покидает дом, интернет-провайдер может добавить дополнительное преобразование адресов на корпоративном уровне, в результате чего многие домохозяйства или несвязанные устройства оказываются за одним IP-адресом.

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

Основным драйвером этой технологии, что понятно, является исчерпание адресного пространства IPv4. 32-битная архитектура IPv4 поддерживает только 4,3 миллиарда уникальных адресов — емкость, которая когда-то казалась огромной, но была полностью превзойдена взрывным ростом Интернета. К началу 2010-х годов Региональные интернет-регистраторы (RIR) исчерпали свои пулы нераспределенных IPv4-адресов. Это оставило интернет-провайдеров неспособными легко приобрести новые блоки адресов, вынуждая их максимально использовать свои существующие выделения.

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

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

Это не новая или нишевая проблема. Она признавалась годами Инженерным советом Интернета (IETF), организацией, которая разрабатывает основные технические стандарты для Интернета. Эти стандарты, известные как Запросы комментариев (RFC), действуют как официальные чертежи того, как должен работать Интернет. RFC 6269, например, обсуждает проблемы совместного использования IP-адресов, в то время как RFC 7021 рассматривает влияние CGNAT на сетевые приложения. Оба объясняют, что традиционные методы предотвращения злоупотреблений, такие как черные списки или ограничение частоты запросов, предполагают взаимно-однозначное соотношение между IP-адресами и пользователями: когда обнаруживается вредоносная деятельность, нарушающий IP-адрес может быть заблокирован для предотвращения дальнейших злоупотреблений.

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

Хотя надеялись, что CGNAT является лишь временным решением до eventual перехода на IPv6, как гласит старая пословица, нет ничего более постоянного, чем временное решение. В то время как развертывание IPv6 продолжает отставать, развертывания CGNAT становятся все более распространенными, как и связанные с ними проблемы. 

Чтобы обеспечить более справедливое отношение к пользователям за CGNAT IP с помощью методов безопасности, которые полагаются на репутацию IP, наша цель — идентифицировать крупномасштабное совместное использование IP. Это позволяет лучше калибровать фильтрацию трафика и минимизировать побочный ущерб. Кроме того, мы хотим отличать CGNAT IP от других технологий IP с крупномасштабным совместным использованием (LSS), таких как VPN и прокси, потому что нам может потребоваться применять разные подходы к разным видам технологий совместного использования IP.

Для этого мы решили воспользоваться обширным обзором Cloudflare активных IP-клиентов и построить контролируемый классификатор обучения, который будет отличать CGNAT и VPN/прокси IP от IP, выделенных одному абоненту (не-LSS IP), на основе поведенческих характеристик. На рисунке ниже представлен обзор нашего контролируемого классификатора: 

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

Обнаружение начинается с создания начального набора данных IP-адресов, которые, как предполагается, связаны с CGNAT. У Cloudflare есть обширные логи HTTP и трафика. К сожалению, в любом запросе нет сигнала или метки, указывающей, что является или не является CGNAT.

Чтобы создать обширный размеченный набор данных для обучения нашего ML-классификатора, мы используем комбинацию методов сетевых измерений, как описано ниже. Мы полагаемся на публичные источники данных, чтобы помочь разграничить начальный набор крупномасштабных общих IP-адресов от других в логах Cloudflare.

Наличие клиента за CGNAT часто можно вывести с помощью анализа трассировки маршрута. CGNAT требует от интернет-провайдеров вставки шага NAT, который обычно использует Общее Адресное Пространство (RFC 6598) после абонентского оборудования (CPE). Запуская трассировку маршрута от клиента к его собственному публичному IP и исследуя последовательность прыжков, появление адреса в диапазоне 100.64.0.0/10 между первым приватным прыжком (например, 192.168.1.1) и публичным IP является сильным индикатором CGNAT.

Трассировка маршрута также может выявить многоуровневый NAT, который требует CGNAT, как показано на диаграмме ниже. Если интернет-провайдер назначает CPE приватный адрес RFC 1918, который появляется сразу после локального прыжка, это указывает как минимум на два уровня NAT. Хотя интернет-провайдеры иногда используют приватные адреса внутри сети без CGNAT, наблюдение приватных или общих диапазонов непосредственно ниже по потоку в сочетании с множественными прыжками до публичного IP сильно suggests CGNAT или эквивалентный многослойный NAT.

Хотя точность трассировки маршрута зависит от конфигураций маршрутизаторов, обнаружение приватных и общих диапазонов IP является надёжным способом идентификации крупномасштабного совместного использования IP. Мы применяем этот метод к распределённым трассировкам маршрута от более чем 9000 зондов RIPE Atlas, чтобы классифицировать хосты как находящиеся за CGNAT, однослойным NAT или без NAT.

Многие операторы кодируют метаданные о своих IP в соответствующей обратной DNS-записи указателя (PTR), которая может сигнализировать об административных атрибутах и географической информации. Мы сначала запрашиваем DNS для PTR-записей всего пространства IPv4, а затем фильтруем набор известных ключевых слов из ответов, которые указывают на развёртывание CGNAT. Например, каждая из следующих трёх записей соответствует ключевому слову (cgnat, cgn или lsn), используемому для обнаружения адресного пространства CGNAT:

node-lsn.pool-1-0.dynamic.totinternet.net 103-246-52-9.gw1-cgnat.mobile.ufone.nz cgn.gsw2.as64098.net

Записи WHOIS и Internet Routing Registry (IRR) также могут содержать названия организаций, примечания или детали распределения, которые раскрывают, используется ли блок для пулов CGNAT или резидентных назначений.

Учитывая, что как PTR, так и WHOIS записи могут поддерживаться вручную и поэтому могут быть устаревшими, мы пытаемся очистить извлечённые данные, проверяя факт, что соответствующие интернет-провайдеры действительно используют CGNAT на основе отчётов клиентов и рынка.

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

Комбинируя вышеуказанные техники, мы накопили набор данных размеченных IP-адресов для более чем 200K IP CGNAT, 180K VPN & прокси и почти 900K выделенных IP, которые не являются LSS IP. Это были отправные точки для моделирования с помощью машинного обучения.

Наша гипотеза заключалась в том, что агрегированная активность от IP CGNAT отличается от активности, генерируемой другими IP-адресами, не являющимися CGNAT. Наше извлечение признаков - это оценка этой гипотезы - поскольку сети не раскрывают CGNAT и другое использование IP, качество нашего вывода строго зависит от нашей уверенности в тренировочных данных. Мы утверждаем, что ключевым дискриминатором является разнообразие, а не только объём. Например, сканеры, размещённые на ВМ, могут генерировать большое количество запросов, но с низким разнообразием информации. Аналогично, глобально маршрутизируемые CPE могут иметь индивидуально уникальные характеристики, но с объёмами, которые с меньшей вероятностью будут пойманы при более низких частотах дискретизации.

В нашем извлечении признаков мы анализируем 1% выборки логов HTTP-запросов на предмет отличительных признаков IP, скомпилированных в нашем справочном наборе, и те же признаки для соответствующего префикса /24 (а именно IP с общими первыми 24 битами). Мы анализируем признаки для каждого из VPN, прокси, CGNAT или не LSS IP. Мы обнаружили, что признаки из следующих широких категорий являются ключевыми дискриминаторами для различных типов IP в нашем тренировочном наборе данных:

• Сигналы на стороне клиента: Мы анализируем агрегированные свойства клиентов, подключающихся с IP. Большая, разнообразная пользовательская база (как в CGNAT) естественно представляет гораздо более широкое статистическое разнообразие клиентских поведений и параметров соединения, чем сервер с одним арендатором или прокси малого бизнеса.

• Сетевое и транспортное поведение: Мы исследуем трафик на сетевом и транспортном уровнях. То, как крупномасштабное сетевое устройство (как CGNAT) управляет и маршрутизирует соединения, часто оставляет subtle, измеримые артефакты в его шаблонах трафика, такие как в распределении портов и наблюдаемом сетевом времени.

• Объём трафика и разнообразие назначений: Мы также моделируем объём и "форму" трафика. IP, представляющий тысячи независимых пользователей, в среднем будет генерировать более высокий объём запросов и нацеливаться на гораздо более широкий, менее коррелированный набор назначений, чем IP, представляющий одного пользователя.

Ключевым моментом является то, что для различения CGNAT от VPN и прокси (что абсолютно необходимо для калиброванной фильтрации безопасности), нам пришлось агрегировать эти признаки в двух разных областях: на IP и на префиксы /24. IP CGNAT обычно выделяются большими блоками IP, тогда как IP VPN более разбросаны по разным IP-префиксам.

Мы вычисляем вышеуказанные признаки из HTTP-логов за 24-часовые интервалы, чтобы увеличить объём данных и уменьшить шум из-за перераспределения IP по DHCP. Набор данных разделён на 70% тренировочный и 30% тестовый наборы с непересекающимися префиксами /24, а метки VPN и прокси объединены из-за их схожести и меньшей операционной важности по сравнению с обнаружением CGNAT.

Затем мы обучаем многоклассовую модель XGBoost с взвешиванием классов для решения дисбаланса, назначая каждый IP классу с наивысшей предсказанной вероятностью. XGBoost хорошо подходит для этой задачи, потому что он эффективно обрабатывает большие наборы признаков, предлагает сильную регуляризацию для предотвращения переобучения и обеспечивает высокую точность с ограниченной настройкой параметров. Классификатор достигает точности 0.98, взвешенной F1 0.97 и лог-потерь 0.04. На рисунке ниже показана матрица ошибок классификации.

Наша модель точна для всех трёх меток. Наблюдаемые ошибки в основном представляют собой ошибочную классификацию IP VPN/прокси как CGNAT, в основном для IP VPN/прокси, которые находятся внутри префикса /24, который также используется широкополосными пользователями вне прокси-сервиса. Мы также оцениваем точность предсказания с использованием k-кратной перекрёстной проверки, которая обеспечивает более надёжную оценку производительности путём обучения и проверки на множественных разделениях данных, уменьшая дисперсию и переобучение по сравнению с единичным разделением на обучение-тест. Мы выбираем 10 фолдов и оцениваем Площадь под ROC-кривой (AUC) и многоклассовые лог-потери. Мы достигаем макро-среднего AUC 0.9946 (σ=0.0069) и лог-потерь 0.0429 (σ=0.0115). Признаки на уровне префикса являются наиболее важными вкладами в производительность классификации.

На рисунке ниже показано ежедневное количество выводов об IP CGNAT, сгенерированных нашей службой обнаружения, развёрнутой в CDN, между 17 декабря 2024 года и 9 января 2025 года. Количество выводов остаётся в значительной степени стабильным, с заметными провалами в выходные и праздничные дни, такие как Рождество и Новый год. Эта картина отражает ожидаемые сезонные вариации, поскольку более низкие объёмы трафика в эти периоды приводят к меньшему количеству активных диапазонов IP и снижению активности запросов.

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

Мы анализируем метки ботов, изучая, насколько часто запросы с CGNAT и не-CGNAT IP-адресов помечаются как боты. Cloudflare присваивает оценку бота каждому HTTP-запросу с использованием моделей CatBoost, обученных на различных характеристиках запроса, и эти оценки затем предоставляются через Межсетевой экран веб-приложений (WAF), позволяя клиентам применять правила фильтрации. Медианный показатель ботов практически идентичен для CGNAT (4,8%) и не-CGNAT (4,7%) IP-адресов. Однако средний показатель ботов заметно ниже для CGNAT (7%), чем для не-CGNAT (13,1%), что указывает на различные базовые распределения. Не-CGNAT IP-адреса демонстрируют гораздо более широкий разброс, причем некоторые достигают 100% уровня ботов, в то время как CGNAT IP-адреса в основном группируются ниже 15%. Это говорит о том, что не-CGNAT IP-адреса, как правило, dominated либо человеческой, либо бот-активностью, тогда как CGNAT IP-адреса отражают смешанное поведение множества конечных пользователей, с преобладанием человеческого трафика.

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

Это говорит нам о том, что пользователи за CGNAT IP-адресами действительно подвержены побочным эффектам, и идентификация этих IP-адресов позволяет нам настраивать стратегии противодействия для быстрого пресечения вредоносного трафика, одновременно снижая побочное воздействие на добросовестных пользователей за тем же адресом.

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

На карте ниже показана доля выявленных CGNAT IP-адресов страны от общего числа IP-адресов, наблюдаемых в стране. Регионы с большей зависимостью от CGNAT отображаются на карте более темным цветом. Этот вид подчеркивает георазнообразие значимости CGNAT; например, большая часть Африки, Центральной и Юго-Восточной Азии полагается на CGNAT.

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

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

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

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

В Cloudflare мы не ограничиваемся использованием этих данных только для оценки политик и практик. Мы используем системы обнаружения для улучшения наших систем во всем наборе функций безопасности приложений и работаем с клиентами, чтобы понять, как они могут использовать эти данные для улучшения настраиваемых ими защитных мер.