Резидентные прокси обходят блокировку по IP: что работает

Примерно четверть узлов выхода резидентных прокси, которые продают крупные провайдеры, работает на устройствах, владельцы которых понятия не имеют, что они входят в чью-то инфраструктуру. Эта оценка основана на многолетних академических исследованиях таких сетей, и она многое объясняет — в том числе то, как недавно одна компания по безопасности обнаружила выходы резидентных прокси в IP-диапазоне, выделенном Администрации президента США. Когда исследователи заметили этот трафик, половина его приходилась на промежуток с 17:00 до полуночи по восточному времени, и интернет отреагировал так, как он обычно реагирует. Но за шутками стоит реальный урок для всех остальных: резидентные прокси — самый эффективный способ обойти защиты на основе IP, и если ваша модель угроз всё ещё считает «резидентный IP» признаком доверия, вы отстали на целое поколение.

Четыре года я занимался детекцией в средней SaaS-компании, и сдвиг был виден на наших дашбордах в реальном времени. Примерно в тот момент, когда группы, занимающиеся credential stuffing, перешли с датацентровых прокси на резидентные выходы, наши блоклисты по IP с отлова 80% атакующего трафика упали почти до нуля. Те же атаки, тот же инструментарий, другой последний хоп. Эта статья о том, почему так происходит и что реально работает, когда репутация IP перестаёт работать.

Как на самом деле устроены резидентные прокси

Резидентный прокси — это просто узел выхода, работающий на потребительском устройстве: телефоне, смарт-ТВ, медиаприставке, домашнем роутере. Клиент прокси-сети платит за трафик, который выходит с этих устройств, а задача провайдера — держать миллионы таких узлов в каждом регионе. Источники предложения можно выстроить в порядке убывания респектабельности из трёх.

1. Opt-in SDK. Бесплатные приложения — VPN, виджеты погоды, мобильные игры, приложения «зарабатывайте, делясь трафиком» — встраивают прокси-SDK. Согласие спрятано в пользовательском соглашении, которое никто не читает, но формально оно есть. Именно на эту модель крупные провайдеры ссылаются, когда говорят об этике.
2. Скомпрометированная прошивка и малварь. Ботнеты уже много лет зарабатывают на перепродаже прокси. Дешёвая Android-приставка с подозрительной прошивкой, залитой на заводе, становится прокси-узлом в тот момент, когда подключается к сети. Владелец думает, что купил медиаплеер.
3. Прямая аренда ботнета. Нижний сегмент рынка даже не притворяется. Если провайдер предлагает пятьдесят миллионов ротируемых IP без заявленной политики происхождения, можно самим посчитать.

Самое важное — как это выглядит со стороны защитника. Трафик приходит из резидентного ASN Comcast, BT или Deutsche Telekom. IP геолоцируется в правдоподобный город. Обратный DNS возвращает что-то вроде pool-96-225-14-7.nycmny.fios.verizon.net. Каждая эвристика, которую мы строили в 2010-х, говорит: это человек дома. Это не так. Это ретранслятор за 3 доллара за гигабайт, а человек дома даже не знает, что он существует.

На этом моменте стоит сделать акцент, потому что именно эта часть истории должна тревожить вас, даже если вы никогда не покупаете и не сражаетесь с прокси. SDK, который ретранслирует трафик, — это софт под чужим удалённым управлением, работающий внутри вашего сетевого периметра. Сегодня он продаёт полосу пропускания. Ничто архитектурно не мешает оператору — или тому, кто взломает оператора, — поставить эти узлы на что-то более серьёзное. Прокси-SDK на устройстве внутри чувствительной сети — это не проблема полосы пропускания. Это плацдарм с отделом биллинга.

Почему защиты на основе IP мертвы

Репутация IP имела смысл, когда злоупотребления шли оттуда, откуда они и должны были выглядеть: из bulletproof-хостингов, захваченных датацентровых диапазонов, открытых прокси на забытых VPS. Можно было перечислить плохие районы. Резидентные прокси положили конец этой эре, перенеся плохой трафик в хорошие районы — по одной взломанной гостиной за раз.

Экономика делает всё хуже. Пространство датацентровых IP ограничено и находится под плотным мониторингом: сожгите /24, и через день он окажется во всех блоклистах. Резидентные узлы выхода практически бесконечны и самовосстанавливаются. Одна кампания credential stuffing может ротировать через десятки тысяч отдельных домашних IP, каждый из которых делает два-три запроса и никогда не упирается в лимиты запросов на IP. Ваш WAF видит десять тысяч разных «пользователей». Блокировка отдельного IP ничего не даёт; блокировка всего ASN означает блокировку ваших реальных клиентов.

Поэтому утверждение «трафик пришёл из Белого дома» нуждается в оговорке, и скептики в любой дискуссии по этой истории правы, что её поднимают. Владение IP-пространством не означает, что каждое объявление о нём соответствует одной физической точке. Крупные организации анонсируют диапазоны из множества площадок, держат гостевые сети, лаборатории и carrier NAT-оверлеи. Выходной IP в диапазоне организации говорит вам, на кого зарегистрировано это пространство, а не за чьим столом прошли пакеты. Когда вы проводите такой анализ в собственной сети — а вам стоит это делать, — относитесь к атрибуции как к гипотезе, которую нужно проверить по внутренним логам потоков, а не как к выводу.

Сигналы детекции, которые всё ещё работают

Репутация IP мертва, но трафик не невидим. У выходов прокси есть отпечатки. Ни один из этих сигналов сам по себе недостаточен — у каждого есть легитимные объяснения, — но в совокупности они удивительно эффективны. Это стандартный приём современной инженерии детекции: перестать искать дымящийся пистолет и начать строить скоринг из слабых сигналов. Та же философия есть в поведенческом фингерпринтинге обфусцированных скриптов — не нужно читать код, если можно охарактеризовать его поведение.

Анализ ASN и формы соединений

Начните с ASN, но не останавливайтесь на вопросе «резидентный ли он». Полезный вопрос — соответствует ли ASN заявленному клиенту. Запрос с user agent десктопного Chrome, пришедший из потребительского диапазона мобильного оператора 5G, подозрителен. Так же подозрителен трафик с потребительского ISP ASN, бьющий в ваш API с concurrency, характерной для датацентра. Отдельные прокси-узлы — это настоящие дома, а у настоящих домов есть реальные ограничения: потребительская скорость загрузки, таблицы NAT, общий адрес carrier-grade NAT. Выходной IP, который за час обслуживает сорок разных клиентов прокси, создаёт паттерны соединений, которые не порождает ни одно домохозяйство.

TLS- и TCP-фингерпринты

Здесь ловятся неаккуратные операторы. Большинство клиентов прокси пропускают трафик через клиентский софт провайдера или через стандартные HTTP-библиотеки — Python requests, Go net/http, Node. У каждой есть свой TLS ClientHello: порядок cipher suite, списки расширений, поддерживаемые группы. Хэши JA3 и JA4 позволяют сравнить то, что TLS-рукопожатие говорит о клиенте, с тем, что заявляет user agent. «Chrome 126 на Windows», который отправляет TLS-фингерпринт Go, — это бот в костюме. Некоторые продвинутые прокси-сети делают полный TLS passthrough с машины клиента, что сохраняет обман, но многие этого не делают, а даже хорошие протекают на уровне TCP. Заявленный клиент Windows с TTL и размером окна, указывающими на Linux, — это ещё один балл в скоринге.

Задержки и временные паттерны

Каждый резидентный прокси добавляет хоп через потребительское железо и потребительские каналы. У этого хопа есть цена. Если ваш сервис также видит истинную задержку клиента через WebRTC, измерение на граничном узле CDN или даже распределение таймингов запросов внутри сессии, вы можете сравнить сетевой RTT с заявленной геграфией. «Пользователь из Денвера» с RTT 4 мс до вашего датацентра в Вирджинии не в Денвере. Тайминги внутри сессий тоже важны: у человека при просмотре есть паузы на чтение, движения мыши, неравномерный ритм. Трафик, проброшенный через прокси из автоматизированного скрипта, имеет метрономический характер — стабильные интервалы между запросами, отсутствие дрейфа простоя, мгновенная отправка форм. Даже когда атакующие добавляют джиттер, это джиттер из распределения, которое человек никогда бы не выдал.

Поведенческие эвристики

Самый сильный сигнал — то, что делает клиент, а не то, чем он является. Реальные пользователи блуждают. Боты выполняют план. Сессия, которая логинится, сразу переходит на страницу настроек по URL, к которому не ведёт ни один путь в интерфейсе, меняет email и отправляет запрос на выплату за девяносто секунд, — не человек, что бы ни говорил её IP. Отслеживайте энтропию последовательности: ходят ли сессии по вашему приложению так, как его реально ведёт ваш фронтенд, или же они бьют в эндпоинты в порядке, который мог бы выбрать только тот, кто читал вашу API-документацию? Агрегация между сессиями — здесь главная фишка. Один резидентный IP, делающий три запроса, выглядит невинно. Триста резидентных IP, каждый из которых делает по три запроса с одинаковыми TLS-фингерпринтами, одинаковым разрешением экрана и одной и той же последовательностью эндпоинтов, — это одна операция в трёхстах костюмах.

Поиск прокси-SDK в собственной сети

Входящей проблеме уделяют больше внимания, но история, с которой всё началось, на самом деле про исходящий трафик: устройство в сети, которая должна была бы знать лучше, ретранслировало чужой трафик. С этим можно реально что-то сделать, потому что вы контролируете периметр. Допустите, что какой-то пользователь рано или поздно воткнёт взломанную приставку или установит «бесплатный VPN» на рабочий телефон. Ваша задача — сделать это событие громким.

Логика детекции простая, потому что у прокси-SDK характерная картина поведения. Узел существует, чтобы получать инструкции и ретранслировать трафик, а значит:

• Постоянные управляющие соединения. Долгоживущие TLS-сессии к незнакомым доменам или IP, часто с крошечными периодическими пакетами. Снимите базовую линию исходящих направлений; клиентское устройство с шестичасовым соединением к хосту в стране, где ни один из ваших поставщиков ПО не работает, заслуживает внимания.
• Высокий fan-out соединений с клиентского устройства. Рабочая станция, которая устанавливает исходящие соединения с сотнями разных внешних IP в час, ведёт себя как инфраструктура, а не как человек. Ноутбуки просматривают страницы; ретрансляторы ретранслируют.
• Входящие потоки к клиентским подсетям. Многие прокси-фреймворки пробивают входящие туннели или используют NAT traversal в духе STUN. Если устройство в вашем гостевом или IoT VLAN принимает соединения из интернета, с сегментацией что-то очень не так — найдите это.
• Асимметричные паттерны загрузки. Телефон или ТВ-приставка, у которых объём отдачи приближается к объёму приёма, раздают контент или ретранслируют трафик. Ни то ни другое не нормально для потребительских устройств.
• Базовые линии по времени суток. Исследователи, которые обнаружили выходы в правительственной сети, опирались именно на это: активность, сконцентрированная в вечерние часы, указывала на устройство в личной, а не гостевой сети. Ваша версия проще — поднимайте тревогу, когда характер трафика устройства меняется, а не только объём.

Ничего из этого не требует глубокой инспекции пакетов, а это важно, если вам нужна сеть, которой можно доверять. Метаданные потоков — NetFlow, Zeek conn logs, VPC flow logs — несут все перечисленные выше сигналы. Если вы ещё не сохраняете и не строите базовые линии по данным исходящих потоков, закройте этот пробел до того, как что-то покупать. Слепые зоны здесь созвучны тем, что есть в логировании аутентификации в облаке: данные есть, но на них никто не смотрит, пока не случится инцидент.

# Quick-and-dirty hunt: client devices acting like relays
# Feed this Zeek-style conn logs; flag RFC1918 sources with
# high distinct-destination fan-out and heavy upload ratios.
awk -F'\t' '
$3 ~ /^(10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01]))/ {
src=$3; dst=$5
up[src]+=$10; down[src]+=$12
seen[src SUBSEP dst]=1
}
END {
for (k in seen) { split(k,a,SUBSEP); fanout[a[1]]++ }
for (s in fanout)
if (fanout[s] > 200 && up[s] > down[s] * 0.5)
printf "%s dsts=%d up=%d down=%d\n", s, fanout[s], up[s], down[s]
}' conn.log | sort -t= -k2 -nr | head -20

Это первый проход, а не готовый продукт: подстройте порог fan-out под ваши базовые линии и ждите ложных срабатываний от медиасерверов и агентов бэкапа, пока не добавите их в белый список. Суть в том, что охота недорога. Пара вечеров анализа логов находит то, что найдёт и шестизначный аппаратный комплекс.

Сегментация — настоящее решение

У меня твёрдое мнение, сложившееся трудным путём: вы никогда не выиграете гонку детекции у взломанных потребительских устройств. Их слишком много, а вендоры, поставляющие небезопасную прошивку, никак не отвечают за последствия. Что можно сделать — сделать скомпрометированное устройство скучным. Заражённая приставка в правильно сегментированном IoT VLAN может продавать свою полосу пропускания прокси-сети — неприятно и потенциально стыдно, если ваш IP-диапазон чувствителен, — но она не может достучаться до ваших файловых шар, внутренних API или чего-то, что превратило бы стыд в утечку.

В разборах инцидентов картина всегда одна и та же. У организации была плоская сеть, либо «гостевая», которая могла дотянуться до внутреннего DNS и интерфейсов управления, либо политика BYOD, которую ничто не обеспечивало, кроме галочки в соглашении. Потом к сети подключалась дешёвая Android-приставка или телефон со встроенным SDK, и выходной IP организации начинал появляться в инвентарях прокси-провайдеров. Исправление задним числом — это то, что нужно было сделать заранее: клиентская изоляция в гостевых сетях, IoT-устройства в VLAN с доступом только на выход и запретом назначений RFC1918, личные устройства — подальше от зон доверия продакшена. Эшелонированная защита не выглядит эффектно, но, как мы уже писали в контексте многоуровневой защиты против одного сильного контроля, спасают именно слои, когда отказывает любой из контролей — а какой-нибудь всегда отказывает.

Есть ещё и политический разговор, который стоит провести внутри компании. Именно через «бесплатные» приложения эти SDK и попадают на устройства. Если сотрудники могут ставить произвольный софт на устройства, которые касаются вашей сети, вы передали свой периметр компаниям из мобильного ad-tech. Некоторые организации отвечают MDM и списками разрешённых приложений; большинству же сегментация сети даёт ту же изоляцию при меньших политических издержках.

Что на самом деле говорит эта история

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

Если вынесете одно: проверьте, не встречаются ли выходные IP вашей организации в инвентарях резидентных прокси. Некоторые сервисы это покажут, а ваш фид threat intel, возможно, уже содержит эти данные. То, что ваш диапазон там есть, — не доказательство компрометации: carrier-grade NAT и общее адресное пространство размывают картину, — но это дешёвая и информативная отправная точка для охоты. Затем посмотрите на fan-out исходящего трафика, долгоживущие соединения и дизайн ваших VLAN.

Атакующие переселились в хорошие районы несколько лет назад. Защитники, которые это заметили, — те, кто перестал проверять адреса и начал следить за поведением.