Недавно я настроил OpenVPN с Dnsmasq в качестве DNS и хочу сделать кое-что, о чем не могу найти никакой информации.
Вот мое текущее понимание, основанное также на том, что я в настоящее время настроил на своем сервере.
A. Клиент подключается к OpenVPN, например, с телефона.
B. Клиенты отправляют трафик, т.е. открывают веб-сайт, например YouTube.
C. Сервер OpenVPN принимает запрос.
D. Пересылает запрос на целевой сервер, т. е. YouTube.
E. YouTube отвечает.
F. OpenVPN пересылает ответ клиенту от A
Конечно, вышеизложенное слишком упрощено.
Что я хочу сделать?
Между этапами C и D, то есть после того, как OpenVPN принимает запрос (или получает ответ от целевого сервера, т. е. D->C), я хочу обработать фактические данные.
Вот типичный пример использования.
Между D и C я хочу передать полезную нагрузку, например, скрипту Python, изменить весь текст «Я люблю тебя» в HTML-коде веб-страницы на «Я ненавижу тебя» перед тем, как полезная нагрузка будет упакована и отправлена клиенту.
Вопрос
Существуют ли какие-либо формы «перехватчиков жизненного цикла» в OpenVPN, с помощью которых я могу прослушивать и изменять полезную нагрузку запроса?
Я понимаю, что любое входящее или исходящее соединение от OpenVPN защищено как 'Fort Knox'. Мне интересен момент, когда полезная нагрузка ответа остается голой на сервере.
Какие у меня есть варианты? Нужно ли мне использовать другой пакет/программное обеспечение, чтобы добиться таких результатов?
решение1
Ваша идея неосуществима по нескольким причинам:
1)
Насколько я помню, в самом OpenVPN нет функции передачи данных из VPN-подключения в пользовательский процесс перед пересылкой.
Для быстрой справки: проверьте, где в стеке OSI используется TCP/IP.
OpenVPN находится на уровне 3 стека OSI (сетевой уровень), тогда как пакеты TCP относятся к уровню 4 (транспортный уровень).
По этой причине ваш вопрос выходит за рамки того, чего хочет достичь OpenVPN.
Единственное, чем вы можете манипулировать, — это то, что происходит, когда клиент подключается к серверу или отключается.
Эти ситуации можно определить в файле конфигурации сервера с помощью следующих настроек:
# client connected to VPN server
client-connect "/script/client_connect.sh"
# client disconnected from VPN server
client-disconnect "/script/client_disconnect.sh"
Все переменные среды, доступные для вашего пользовательского скрипта, доступны здесь:
Но по сути единственная информация, которую вы можете отслеживать, — это какой клиентский сертификат использовался для подключения к серверу и какой IP-адрес был назначен клиенту, а затем реализовать на сервере некоторую пользовательскую логику в зависимости от того, кто подключается, и что делать, когда соединение снова отключается.
Типичной конфигурацией может быть реализация динамической DNS-серверной стороны или выполнение какой-либо пользовательской маршрутизации, например, маршрутизации при отказе в зависимости от того, какое VPN-подключение активно.
2)
Ссылаясь на эту диаграмму пакета IPv4 изВикипедия:
По сути, вам нужно манипулировать полем данных в зависимости от адреса источника или назначения.
Это также известно как атака «человек посередине».
Как вы обнаружили, это трудно сделать, прослушивая интерфейс OpenVPN, поскольку весь контент зашифрован. Происходит то, что пакет IPv4, предназначенный для Интернета, инкапсулируется в другой пакет IPv4, который предназначен для сервера OpenVPN.
Инкапсулированный пакет IPv4 хранится в поле данных на схеме выше.
Это декапсулированный пакет, который пересылается в Интернет с VPN-сервера.
Однако есть одно предостережение:
Я предполагаю, что VPN-клиент делаетнетиметь публичный IP-адрес. Это означает, что задействована трансляция NAT, и исходный адрес перезаписывается на адрес VPN-сервера до того, как какой-либо хост будет подключен в Интернете.
Аналогично, когда хост отвечает ответом, мы получаем тот же IPv4-адрес назначения, что и у VPN-сервера.
Это означает, что для того, чтобы манипулировать полем данных, нам необходимо отслеживать, какие порты используются в network address translation table(т.е. NAT).
Используемые порты обычно являются динамическими по своей природе, поскольку к Интернету через VPN и NAT могут подключаться несколько VPN-клиентов, а каждый сеанс TCP (почта, веб, ssh и т. д.) использует другой порт.
Так что если вы хотите манипулироватьрасшифрованный TCP-пакетэто должно произойти после расшифровки, но до того, как он будет транслирован в NAT.
Теоретически вы можете перехватить пакет с помощью iptables, но это нетривиальная задача, когда VPN и NAT находятся на одной машине.
Другой подход заключается в прямой атаке на зашифрованный трафик OpenVPN. Поскольку вы контролируете сервер OpenVPN, вы также контролируете, какие сертификаты и закрытые ключи используются как на сервере, так и на клиенте.
Это можно сделать как классическую атаку типа «человек посередине». Я не знаю, как это делается. :-)
... но это подводит меня к моему последнему аргументу:
3)
Большая часть трафика в Интернете зашифрована по протоколу TLS.
Таким образом, даже после того, как вы расшифруете трафик OpenVPN, вам придется преодолеть еще один уровень шифрования, чтобы манипулировать содержимым поля данных.
Эту часть атаковать еще сложнее, чем просто атаковать зашифрованный трафик OpenVPN, поскольку вы не контролируете ключи шифрования, используемые для сеанса.
Даже если вы попытаетесь расшифровать трафик TLS и повторно зашифровать контент так, чтобы для конечного пользователя выглядело, что зашифрованный трафик действительно исходит от YouTube или чего-то еще, это все равно будет бесполезно, поскольку сертификат, который вы используете для шифрования трафика https,не доверяютбраузерами на компьютерах конечных пользователей.
Это само по себе делает вашу атаку «человек посередине» бесполезной.
Вот это почти полный ответ на ваш вопрос.
Существуют и другие способы атаки на сеанс TCP, но сейчас мы рассмотрим более сложную область, которая должна обсуждаться на форуме, полном экспертов по безопасности.
Эта часть НАМНОГО выходит за рамки моей квалификации. :-)