У меня есть хитрое приложение, за которым мне нужно следить. Это файл Java .jnlp. Используя Process Monitor, я смог идентифицировать его (его экземпляр javaw), выходящего на другие серверы в моей сети; однако при запуске Fiddler он вообще не проявляет активности. Я знаю, что трафик зашифрован HTTPS, и, похоже, он подключается к портам, на которых на моих серверах работают веб-серверы (tomcat). С помощью Process Monitor я могу видеть длину и направление (отправка / получение) данных, но он даже не показывает мне зашифрованное содержимое.
Мне интересно, есть ли способ, которым я могу управлять этой программой, чтобы увидеть, какие данные она отправляет с моих машин?
Обновить
Серверное программное обеспечение, с которым связывается этот jnlp, установлено как «пакет», и мне не удалось найти никаких файлов сертификатов SSL в каталоге этого приложения. Я использовал Wireshark, но без закрытых ключей мне не удалось расшифровать трафик.
Решение с виртуальным шлюзом, на котором запущено какое-то прокси (другое?) Программное обеспечение, кажется самым простым для реализации, как бы вы развернули это решение с помощью Virtual Box?
Фидлер - это не сниффер, это прокси. Если вы не можете заставить приложение-нарушитель использовать прокси-сервер, никакой его трафик не будет проходить через Fiddler.
Microsoft Network Monitor покажет вам зашифрованный трафик, как и Wireshark. В версиях Network Monitor 3.x есть приятная возможность фильтрации на основе процесса (поскольку они «тесно связаны» с ОС).
AFAIK, приложения Java не используют «стек» SSL операционной системы, поэтому утилиты перехвата, которые вставляются в стек Windows SSL, также не будут полезны.
Предположительно удаленные серверы не используют стек SSL, который легко отслеживать внутри (поскольку вы говорите, что они используют Tomcat, а также вряд ли используют стек SSL ОС).
Я бы запустил вредоносную программу на виртуальной машине с виртуальной машиной на базе Linux, выступающей в качестве шлюза по умолчанию. Затем вы можете использовать некоторые правила NAT iptables для перенаправления попыток подключения на прокси-сервер HTTPS-to-HTTP, который, в свою очередь, перенаправляет запрос на обратный прокси-сервер HTTP-to-HTTPS и, в конечном итоге, на ваши серверы. Вы сможете регистрировать трафик, когда он находится в состоянии HTTP между прокси и обратным прокси-серверами. Это не изящно (и кто-то другой, вероятно, может придумать более чистый метод, в котором используется меньше движущихся частей), но вы могли бы сделать все с помощью стандартного программного обеспечения (я бы, вероятно, использовал пару экземпляров nginx). Предположительно, приложение-нарушитель не проверяет подлинность того, что на самом деле разговаривает с вашими серверами, но, если это так, вы можете просто экспортировать сертификаты SSL и закрытые ключи со своих серверов, чтобы обман был «полным».
Предполагая, что у вас есть закрытые ключи SSL от ваших серверов, и вы не настраиваете SSL своих серверов для обмена ключами на основе RSA, вы можете просто захватить трафик и расшифровать его с помощью Wireshark.
Wireshark может расшифровать трафик SSL, если вы предоставите ему закрытый ключ. Если вы перейдете в Edit-> Preferences, затем выберите SSL из списка протоколов, там есть поле для ввода местоположения закрытого ключевого файла, а также IP-адресов и портов, с которыми он должен использоваться. Если вам нужно больше, поиск в Google даст вам множество пошаговых руководств. (например: http://support.citrix.com/article/CTX116557)
Это, безусловно, предполагает, что у вас есть доступ к закрытым ключам серверов, с которыми обращается ваше приложение. Но если это так, вы сможете справиться с этим без особых проблем.
- Кристофер Карел
Установите wirehark на сервер