Как настроить PolarProxy для анализа трафика без SNI: подробный гайд

Если вы работаете с анализом вредоносного трафика, наверняка сталкивались с ситуацией, когда PolarProxy не может определить сервер для перенаправления из-за отсутствия SNI (Server Name Indication). Это особенно раздражает, когда приложение напрямую обращается по IP-адресу, минуя DNS. К счастью, проблема решается через настройку правил – ниже расскажу, как это сделать.

Настройка PolarProxy для работы без SNI

Основная ошибка возникает из-за флага --nosni в старых версиях PolarProxy (до 1.0.2). Если у вас версия 1.0.0 или 1.0.1, вместо ручных параметров лучше использовать правила (ruleset). Вот как это работает:

1. Создайте JSON-файл tls-termination.json со следующим содержимым:

{
    "name": "TLS termination/offloading for local www",
    "version": "1.0.1",
    "rules": [
        {
            "active": true,
            "match": { "type": "nontls" },
            "action": { "type": "block" },
            "description": "Block non-TLS traffic"
        }
    ],
    "default": {
        "action": { "type": "terminate", "target": "ВАШ_IP_FAKENET:80" },
        "description": "Terminate TLS and forward to local www"
    }
}

Замените ВАШ_IP_FAKENET:80 на IP и порт вашего FakeNet-сервера. Например, "target": "192.168.1.50:80".

2. Запустите PolarProxy с параметром --ruleset:

./PolarProxy -v -p 10443,80,80 --pcapoverip 57012 -o . --ruleset tls-termination.json

Этот метод не требует флагов --terminate или --connect, что упрощает конфигурацию.

Кстати, если вы используете Ubuntu VM, не забудьте настроить iptables для перенаправления трафика:

sudo iptables -t nat -A PREROUTING -i enp0s8 -p tcp --dport 443 -j REDIRECT --to 10443

(где enp0s8 – имя сетевого интерфейса вашей виртуальной машины).

Типичные ошибки и их решение

Если после настройки вы видите сообщения вроде Cannot determine the frame size или Name or service not known, проверьте:

• Совместимость версии PolarProxy. Для работы с правилами нужна версия 1.0.0 или выше. Если у вас старая сборка – обновитесь до 1.0.2 (там баг с --nosni исправлен).
• Правильность IP в JSON-файле. Опечатка в адресе FakeNet – частая причина ошибок.
• Настройки сети между VM. Например, в VMware иногда требуется отключить Promiscuous Mode в настройках виртуального адаптера.

Для тестирования используйте команды:

curl.exe --insecure --resolve hello.com:443:IP_PolarProxy https://hello.com  # с SNI  
curl.exe --insecure https://IP_PolarProxy  # без SNI

Второй запрос должен теперь обрабатываться корректно.

Важно: Если FakeNet работает на другом порту (не 80), укажите его в JSON. Например, "target": "192.168.1.50:8080".

Если сеть «падает» при изменении шлюза на Windows VM (такое бывает в VMware), попробуйте вручную прописать маршрут через PolarProxy:

route add 0.0.0.0 mask 0.0.0.0 IP_PolarProxy -p

Но это уже тема для отдельного разговора – возможно, как-нибудь разберем детальнее.

Короче, суть в том, что правила (ruleset) дают больше контроля над трафиком, чем флаги командной строки. Этот подход не только решает проблему с SNI, но и позволяет гибко настраивать фильтрацию – например, блокировать нешифрованные соединения, что полезно при анализе современных угроз.

P.S. Если что-то не работает, посмотрите логи PolarProxy. Там часто прячутся подсказки – например, «Failed to connect to target» укажет на недоступность FakeNet. Не стесняйтесь экспериментировать с параметрами. Иногда пара лишних пробелов в JSON ломает всю конфигурацию, так что внимательность тут ключевая (ну или почти).