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