Defensive Research

Оборонительное исследование угроз: посещение подозрительных URL через изоляцию прокси

3 min read Published Updated 654 words

Посещение подозрительного URL напрямую с вашей исследовательской рабочей станции — безрассудство: более 70% вредоносных целевых страниц проверяют IP-адрес подключения и либо показывают безобидную страницу, либо полностью блокируют запрос. Изоляция через прокси — не опция, а база для любого достоверного сбора данных об угрозах. Без неё вы передаёте злоумышленникам сетевой блок вашей инфраструктуры, и они в течение нескольких минут переключатся на атаку ваших внутренних сервисов.

Почему прямой просмотр не подходит для сбора данных об угрозах

Современные эксплойт-киты и фишинговые наборы проверяют REMOTE_ADDR по блок-листам threat-intel, базам геолокации и даже обратным DNS-запросам. Прямое соединение с известного исследовательского ASN вызывает перенаправление на чистую страницу или 404. Хуже того, многие наборы используют JavaScript для перечисления локального IP клиента через утечки WebRTC (RFC 8834) — раскрывая вашу реальную сеть даже за VPN. Изоляция через прокси разрывает эту цепочку, завершая соединение на удалённом посреднике, который не имеет репутации вашей инфраструктуры. Сам прокси должен быть одноразовым: облачный инстанс для одного использования или ротируемый пул резидентных прокси. Статические прокси от одного провайдера «сгорают» за несколько дней.

Многоуровневая изоляция: прокси + ВМ или контейнер

Одного прокси недостаточно, если браузер утекает данные через DNS, временные побочные каналы или браузерный отпечаток. Объедините прокси со специально созданной ВМ или контейнером без постоянного хранилища, без монтирования файловой системы хоста и с урезанным профилем браузера. Используйте iptables в контейнере, чтобы принудительно направить весь исходящий трафик через прокси и заблокировать весь трафик на адреса RFC 1918. Например, Docker-контейнер с --network none и SOCKS5-туннелем через ssh -D 1080 на одноразовый jump box. Это не даёт браузеру обойти прокси через WebSocket или WebRTC — частый сбой при использовании только прокси на уровне браузера. ВМ или контейнер следует уничтожать после каждого сеанса; снимки допустимы только при очистке всех cookie, кеша и localStorage.

Инструменты: Burp Suite с цепочкой прокси и headless-браузеры

Для ручного анализа настройте Burp Suite через SOCKS5-прокси (RFC 1928), задав User options > Connections > SOCKS Proxy равным 127.0.0.1:1080 и включив Do DNS resolution via SOCKS proxy. Это принудительно направляет все DNS-запросы через прокси, предотвращая DNS-утечки. Для автоматического сбора данных стандартом являются фермы headless-браузеров на Puppeteer или Playwright. Ниже приведён минимальный скрипт Puppeteer, который направляет весь трафик через SOCKS5-прокси и отключает WebRTC:

const puppeteer = require('puppeteer');
const proxy = 'socks5://127.0.0.1:1080';

const browser = await puppeteer.launch({
  args: [
    `--proxy-server=${proxy}`,
    '--disable-webrtc',
    '--no-sandbox',
    '--disable-setuid-sandbox'
  ]
});
const page = await browser.newPage();
await page.authenticate({ username: 'user', password: 'pass' });
await page.goto('http://malicious.example', { waitUntil: 'networkidle0' });
// Capture screenshot, HAR, DOM snapshot
await page.screenshot({ path: 'screenshot.png' });
await browser.close();

Этот подход работает, но будьте осторожны: многие headless-браузеры обнаруживаются через navigator.webdriver и отсутствие chrome.runtime. Используйте puppeteer-extra-plugin-stealth или встроенные stealth-патчи Playwright для уменьшения отпечатка. Даже тогда сложные наборы обнаруживают headless Chrome по отсутствию свойств window.chrome или аномальной длине navigator.plugins. Единственная надёжная контрмера — запускать полноценный браузер (не headless) в ВМ с реальным драйвером дисплея — но это плохо масштабируется.

Альтернативы urlscan.io для самостоятельного анализа

urlscan.io удобен, но делится метаданными ваших сканирований с сообществом и логирует ваш IP. Для чувствительных расследований разверните собственную платформу захвата. PhantomJS мёртв; используйте Playwright с собственным HAR-логгером и локальным экземпляром mitmproxy. mitmproxy (--mode socks5 --listen-port 8080) записывает все пары запрос/ответ и позволяет изменять заголовки или ответы на лету. Дополните его wireshark для анализа PCAP. Другой вариант — ThreatPinch Lookup (расширение Chrome, запрашивающее локальные фиды threat-intel), но это не полноценное решение для изоляции. Для массового сканирования разверните PhishingKitTracker или собственный Python-скрипт с requests и ротируемым списком прокси из proxybroker. Компромисс: самостоятельные системы требуют обслуживания пулов прокси и профилей браузеров, но дают полный контроль над хранением данных и исключают утечку целей вашего расследования третьим сторонам.