Анализ\Блокировка\Редактирование трафика определенного процесса

Привет. Появилась идея написать что-то аля сниффера который умел бы перехватывать траффик по фильтрам (srsIP\dstIP\PID).
Будет возможность создавать список правил. И если процесс пытается соединится с сервером который в правилах определен как заблокированный - то процесс просто драпал это соединение.
Ну и как бонус еще может редактирование пакетов на лету по шаблону и пересылка от приложения к серверу и от серверу к приложению.

Короче нужно функционал почти идентичный Charles proxy но с возможностью перехвата пакетов уровня Ethernet, как делает WireShark, например.

Пока что почитал, погуглил и вроде как перехват трафика реализовать не очень сложно, просто через драйвер NpCap, а вот редактирование пакетов и пересылка в обе стороны я пока что даже не понимаю как это можно сделать... Пока что только одна идея - Прокси, но тут проблема что трафик нужно как то перенаправлять с процесса на этот прокси, а сторонний софт использовать не хочу.

Есть может быть у кого какие идеи\готовые Open Source решения, или хотя бы примеры? Был бы благодарен за любую инфу по теме. Пока что буду сам пытаться гуглить само собой.

0

Сообщение от siriusED Будет возможность создавать список правил. И если процесс пытается соединится с сервером который в правилах определен как заблокированный - то процесс просто драпал это соединение.

Есть несколько варивнтов реализации (первые два примера под Windows путем реализации драйвера Windows Filtering Platform).
1) Регистрировать в драйвере посредством IRP сообщений те srsIP\dstIP\PID, которы нужно заблокировать, и отслеживать в драйвере исходящий трафик, который проверять перед выходом в сеть на предмет заблокированности и блокировать его, если нужно
2) Перенаправлять трафик в локальную программу, которая будет выступать в качестве фильтрующего моста между программой, которая инициировала соединение и конечным сервером
3) Настройка прокси посредством сторонних софтов, принцип такой же как и в п.2, только вместо собственного драйвера придется еще и сторонний софт ставить, что бы перехватить трафик

Но на этом приключения конечно же не заканчиваются. Нужно еще учесть то, что соединение с сервером может использовать шифрование TLS. По этой причине, вам так же нужно будет реализовать локальный Certificate Authority (CA), чей корневой сертификат должен быть доверенным в рамках ОС.

Так же придется генерировать SSL сертификаты на лету для каждого домена, подписывать их вашим доверенным Certificate Authority, и использовать этот сертификат в TLS рукопожатии, причем домен целевого сервера должен быть прописан в этом сертификате. Так вы сможете перехватить зашифрованный трафик и прочитать его а так же отфильтровать/редактировать согласно заданным правилам.

1

Undisputed,
Я тут еще погуглил по теме, и нашел еще такую технологию как LSP (Layered Service Provider), вроде тоже не плохая, но говорят сложно в разработке ибо любой косяк может сломать всю сеть, как я понял это что-то типа midleware в вин соккетах.

И еще есть драйвер NpCap, его я уже протестировал немного и почитал примеры использования, в принципе вроде как не плохой вариант.

На счет TLS то может быть как нить получится прикрутить что-то готовое, типа mitmproxy или не вариант?

И еще меня интересует генерация пакетов например, я когда-то давно писал что-то типа сниффера, там было реализовано на TCP прокси, типа перенаправлял траффик на этот локальный прокси и на нем уже ловил пакеты, но там ловились не все а только TCP, но там помню можно было генерировать пакеты типа поймал один и можно было его отправить еще раз на сервер, ну либо на клиент в принципе тоже.
Так вот, генерация (отправка в обе стороны) работает только через соккет как я понимаю да? Просто так создать пакет в ручную и открпавить его на сервер через например NpCap не получится или можно?

0

Сообщение от siriusED Просто так создать пакет в ручную и открпавить его на сервер через например NpCap не получится или можно?

pcap_sendpacket()
Но "рисовать" Ethernet фрейм придется вручную.

2

Сообщение от siriusED На счет TLS то может быть как нить получится прикрутить что-то готовое, типа mitmproxy или не вариант?

Именно. Но вы в начале темы упомянали, что нужно решение без использования third party. Если делать самому, то нужно что бы соблюдалась идея MITM.

В целом суть решения с нуля заключается в том что бы был прокси-сервер, который будет вести себя как целевой сервер, к которому собирался подключиться клиент. Когда надо, такой сервер сбрасывает соединение клиента (если соединение попадет под фильтр), а когда надо будет менять контент (прокси берет контент от целевого сервера, но клиенту может отдать его модифицированную версию). Конечно же, такой прокси должен уметь работать с TLS и без него, что бы уметь работать с пользователями независимо от того нужно ли им шифрование или нет.

При этом когда прокси сервер собирается вести себя как целевой сервер клиента, то для случая с TLS он должен предоставлять SSL сертификат, которому доверяет ОС. Именно поэтому нужен собственный (и доверенный со стороны ОС) CA.

Направить трафик в прокси можно как минимум двумя способами:
1) задать программе использующей соединения адрес прокси явным образом
2) реализовать драйвер (ну или взять готовый, если есть) который будет перенаправлять трафик в локальный прокси сервер без необходимости настраивать прокси вручную

Сообщение от siriusED генерация (отправка в обе стороны) работает только через соккет как я понимаю да? Просто так создать пакет в ручную и открпавить его на сервер через например NpCap не получится или можно?

Если нужно отправить что-то по TCP на сервер, то нужно соединение с сервером, а для этого да, нужны будут сокеты.

Насчет готовых решений (в том числе и LSP) не скажу, я ими не пользовался

1

Сообщение от Undisputed Если нужно отправить что-то по TCP на сервер, то нужно соединение с сервером, а для этого да, нужны будут сокеты.

Получается это и есть самая главная проблема, а именно отправка пакета в обе стороны, выходит NpCap годится только и только для просмотра пакетов, и в этом случае если для отправки мне все равно нужен будет прокси на соккетах тогда весь смысл использования NpCap, получается, теряется, ибо если будет прокси сервер то и пакеты через него можно будет ловить\фильтровать\менять.
Выходит, самый идеальный вариант для меня это прокси сервер на соккетах, и какой-то драйвер умеющий перенаправлять траффик.
Типа что бы получилась такой алгоритм работы: Запускаю прокси, сетаплю правила на драйвер что бы он перенаправлял весь траффик по правилу, из нужного мне процесса на мой запущенный прокси, а уже прокси буде передавать пакеты на сервер.

Все верно я понял?

Сообщение от Undisputed Именно. Но вы в начале темы упомянали, что нужно решение без использования third party. Если делать самому, то нужно что бы соблюдалась идея MITM.

На счет third party, тут я скорей имел введу что нужно что б все было реализовано програмно, то есть что бы не надо было запускать дополнительный софт и руками что-то там настраивать или вводить, но если есть готовое решение с хорошим API, которое можно использовать из кода и автоматизировать работу с ним то в принципе это вариант.

0

Сообщение от siriusED Все верно я понял?

Не-а... Драйвер писать не надо... есть же netsh. И вы вполне можете им "заворачивать" пакеты на нужный адрес/порт

0

Сообщение от siriusED Выходит, самый идеальный вариант для меня это прокси сервер на соккетах, и какой-то драйвер умеющий перенаправлять траффик.

Если вы хотите перехватывать трафик на уровне всей ОС то да, нужен драйвер. Попробую объяснить причины.
1) если вы направляете исходящий трафик в локальный прокси (предположим, что трафик TCP), то этот локальный прокси ведь должен иметь возможность подключиться к удаленному серверу, который запросил клиент.. но как только локальный прокси попробует подключиться к удаленному серверу, настроенный прокси снова будет направлять его на себя, так как исходящий от прокси трафик тоже TCP, а весь TCP трафик из ОС как мы до этого выяснили, направляется в локальный прокси-сервер, и таким образом возникает цикл и пропадает возможность для локального прокси выйти в интернет

2) нужна возможность в случае завершения программы (как штатного, так и аварийного завершения) прекратить проксирование трафика... в случае с драйвером, при открытии HANDLE на драйвер, ОС должна будет отправить IRP_MJ_CLOSE драйверу, что бы тот мог прекратить проксирование (если проксирование не прекратить, а процесс локального прокси будет завершен, то на компьютере сломается интернет)

3) утилита которая будет проксировать трафик в локальный сервер, должна так же передавать айпи и порт целевого сервера, и ваш локальный прокси должен поддерживать протокол, по которому эти данные будут передаваться

Все эти проблемы решаются, если правильно реализовать драйвер и взаимодействие с ним. В противном случае будут проблемы, которые частично можно решить, но в целом скорее всего это будет неграмотно и ненадежно. Не буду сейчас вдаваться в подробности, но если будут вопросы/аргументы, то я попробую на них ответить

siriusED,
Если решение которым вы пользуетесь позволяет только просматривать пакеты, то оно не годится. Здесь нужно иметь возможность не только просматривать, но и быть активным участником соединения (т.е иметь возможность отправлять данные).

1

Undisputed, Ну если так грубо сказать, то мне просто нужно сделать проксификатор который сетапится из кода, и прокси сервер.
Тот же Proxifier, например как то же работает И через него же можно перенаправить траффик на свой локальный прокси и траффик пойдет без проблем. Я даже вроде когда-то такое делал для экспериментов.

Так что мне нужно что-то подобное по факту, локальный МИТМ прокси проксифицируующий IP пакеты с возможностю блока\едита\инжекта, и собственно сам проксификатор(драйвер) который будет просто перенаправлять исходящий траффик на мой прокси а уже прокси будет принимать этот траффик и передавать его в интернет на сервер, и принимать ответ от сервера и передавать его на приложение (например браузер).

1.

Сообщение от Undisputed но как только локальный прокси попробует подключиться к удаленному серверу, настроенный прокси снова будет направлять его на себя

Вы тут наверно имели введу "драйвер" будет перенаправлять обратно на локальный прокси. Это да, но ведь прокси будет на каком-то порту а значит пакет будет иметь SrcPort: 5555, например, и через настройки драйвера он будет знать что все пакеты идущие с порта 5555 направляются по адресу без изменений, либо во обще никак не затрагиваются драйвером, думаю как то примерно так и работают проксификаторы. Но конечно, могу и ошибаться, так как только в процессе изучения темы.

2. Ну первое что приходит на ум, сделать пинг моего софта драйвером или проверять запущен ли процесс, если пинга нету или процесс вылетел значит драйвер прекращает свою работу и ни как не взаимодействует с пакетами во обще.

3. Ну тут я тоже могу ошибаться, но разве драйвер не просто будет перенаправлять IP-пакеты по заданному правилу на мой прокси и все? То есть прилетел пакет на интерфейс, драйвер принял его и просто передал полученный пакет на мой прокси, ведь адрес получателя и будет мой прокси который и общается с сервером, а уже на клиент пойдет пакет с измененным адресом отправителя и получателя. Хотя тут я еще сам до конца не понимаю как именно это все работает так что извиняйте если написал бред

А пока что, пойду искать инфу как работают проксификаторы, ибо на сколько я могу видеть на данный момент, мне нужен именно такой же функционал, просто с возможностью управления из кода.

0

Сообщение от siriusED Так что мне нужно что-то подобное по факту, локальный МИТМ прокси проксифицируующий IP пакеты с возможностю блока\едита\инжекта, и собственно сам проксификатор(драйвер) который будет просто перенаправлять исходящий траффик на мой прокси а уже прокси будет принимать этот траффик и передавать его в интернет на сервер, и принимать ответ от сервера и передавать его на приложение (например браузер).

Да

Сообщение от siriusED все пакеты идущие с порта 5555 направляются по адресу без изменений, либо во обще никак не затрагиваются драйвером

Разные варианты могут быть, но в целом идея верная. Однако жестко привязываться к конкретному порту не следует по нескольким причинам... например, если программа захочет сменить порт, то придется перекомпилировать и переподписывать драйвер (если речь о продакшен версии)... можно к примеру по PID понимать, что это трафик локального прокси и его проксировать не надо...

Сообщение от siriusED Ну первое что приходит на ум, сделать пинг моего софта драйвером или проверять запущен ли процесс, если пинга нету или процесс вылетел значит драйвер прекращает свою работу и ни как не взаимодействует с пакетами во обще

Пинг тоже вариант, однако у него есть свои минусы - трата ресурсов на постоянный пинг + некоторый лаг, равный таймауту с которым этот пинг отправляется. Можно например просто ждать IRP_MJ_CLOSE от процесса, по ресурсам это выгоднее.

Сообщение от siriusED но разве драйвер не просто будет перенаправлять IP-пакеты по заданному правилу на мой прокси и все

Не совсем так. В прокси будет приходить новое соединение, которое можно будет получить через условный accept, но целевой IP и порт нужно будет получать отдельно. Драйвер должен положить эти данные в память, а затем процесс уже забирает эти данные из памяти, ведь в рамках accept нет понятия "адрес целевого сервера". Если мы получили коннект в accept, значит считается, что соединились с нами, а не "хотят соединиться с кем-то другим посредством нашей программы"

1

И еще на счет отправки пакетов, а прокси сервер это точно единственный вариант? Нету никакого способа может быть как ни будь получить доступ к сокетам приложения и отправлять пакеты через нужный сокет что бы во обще прокси сервер не использовать, ведь когда приложение хочет связаться с сервером единственный вариант как это сделать это винсокеты, и вот вопрос к этим сокетам точно ни как нельзя получить доспут что бы отправлять пакеты в обе стороны прямо через сокет самого же приложения а не городить целый прокси сервер который по факту и будет двумя сокетами один на клиент(входящий) а второй на сервер(исходящий), нету вариантов если в эту сторону копнуть?

Пока писал сообщение одна идея уже пришла - хукнуть функцию создания сокета и получить указатель на него себе Но я прям очень не хочу ничего хукать, подменять итд, хочу что б все работало без этих костылей...

0

Сообщение от siriusED Пока писал сообщение одна идея уже пришла - хукнуть функцию создания сокета и получить указатель на него себе

Это мало что даст. Ну получите сам сокет, как из него читать будете? Банальный хук recv-а не сработает, так как например для TLS вы будете получать зашифрованные данные, которые не сможете разобрать. Следовательно, пользы от этого сокета не будет.

С другой стороны, вы можете попробовать использовать этот сокет для других функций, которые тоже похукаете. Например, можете попытаться читать из SSL_Read, функции библиотеки OpenSSL. Но спешу вас расстроить. Есть множество библиотек, и не факт что все приложения будут использовать OpenSSL. Нужно будет хукать функции всех возможных библиотек, и в принципе возможна ситуация, где например будет собственная имплементация протокола, и вы даже не поймете что хукать.

В общем это плохая затея, даже если частично будет работать.

Сообщение от siriusED И еще на счет отправки пакетов, а прокси сервер это точно единственный вариант

я не утверждал что это единственный вариант, но другие надежные способы мне неизвестны

1

Undisputed, Да нет, TLS и другие шифрования, сериализацию и упаковку это все, думаю, можно разбирать через драйвер, в самом плохом случае можно будет сделать то же самое что делает mitmproxy, а вот что б именно отправлять собранные пакеты нужен либо прокси сервер либо каким-то образом получить доступ до сокета самого приложения, тогда может быть вышла схема что-то типа: Через драйвер посмотрел пакет, понял что за шифрование, использую все данные - собираю собственный пакет, формирую все хедеры и отправляю на сервер через сокет приложения. Что-то типа такого, но опять таки, что-то погуглил и не очень то и много инфы по доступу к сокетам процесса.

И кстати нашел хорошую инфу где рассказали во обще обо всех технологиях перехвата траффика. Прочитав возможности о описание всех остановился на NDIS Driver, Через него и блочить можно и делать симуляции плохого соединения, потери пакетов, а так же менять пейлоад пакетов. В принципе это куда лучше NpCap. Наверно остановлюсь на этом варианте для захвата траффика.
А вот что с отправкой то тут надо что-то будет еще погуглить либо делать через прокси либо как то найти инфу по доступе к сокетам что бы передавать пакеты через них.

Пока что, гуглю по теме дальше...

0

Господа, вам не кажется что вы просто все переусложняете?
Есть же технология NAT. Заворачиваете все пакеты с нужного ПО/нужного Порта на loopback, где сидит ваш проксификатор, получает пакет и обрабатывает его? Хоть MitM из себя изображает, хоть тупо переправляет..

0

Сообщение от siriusED в самом плохом случае можно будет сделать то же самое что делает mitmproxy

Только в отличии от mitmproxy, у вас не будет доступа к библиотекам пользовательского уровня из-за того то работа будет идти в режиме ядра, что сделает вашу задачу еще сложнее, и это я еще не спрашиваю вас о том, как именно вы собираетесь всё это

Сообщение от siriusED разбирать через драйвер

Дело ваше, будет интересно почитать, к чему вы в итоге придете

Сообщение от Azathtot вам не кажется что вы просто все переусложняете?

Не кажется...

Сообщение от Azathtot Есть же технология NAT. Заворачиваете все пакеты с нужного ПО/нужного Порта на loopback, где сидит ваш проксификатор, получает пакет и обрабатывает его?

Нет. Задача ведь не в этом. Нет задачи "завернуть все пакеты с нужного ПО/Порта на loopback". Есть задача перенаправить ВЕСЬ исходящий трафик в локальную программу, которая может занимать произвольный порт с возможностью отслеживать lifetime этой программы, и когда она завершит работу, вырубить перенаправление всего трафика, что бы не сломать интернет. Кроме того, из перенаправления нужно исключить прокси сервер. И нужно не просто перенаправить трафик, а что бы помимо перенаправления в прокси передавался адрес целевого сервера, и такая программа должна иметь возможность устанавливаться на произвольный компьютер, настройки сети которого защищены паролем и нам недоступны.

Ну вот теперь расскажите мне пожалуйста, как вы это решите.

1

Сообщение от Undisputed Ну вот теперь расскажите мне пожалуйста, как вы это решите.

Ну если перенаправлять всеь трафик с определенного ПО, то да, согласен, без драйвера не обойтись. Но опять же, возиться с TLS...

1

Сообщение от Azathtot Ну если перенаправлять всеь трафик с определенного ПО, то да, согласен, без драйвера не обойтись

Даже не с определенного ПО, а из всей ОС.

Сообщение от Azathtot Но опять же, возиться с TLS...

Как известно, не всё зависит от наших желаний Что бы модифицировать защищенный трафик, его нужно расшифровать... а для этого придется возиться с TLS

1

Сообщение от Undisputed а из всей ОС.

Да, это я чего-то затупил... при маскарадинге "реальный целевой адрес" теряется... его даже из Ethernet фрейма не выцепить...

0

Сообщение от Undisputed Даже не с определенного ПО, а из всей ОС.

Ну на самом деле хотелось бы иметь выбор, либо перехват траффика с заданого процесса либо с заданного адаптера, прям из всех адаптеров думаю это уже перебор А вот выбор либо весь адаптер либо процесс - это вполне адекватно было бы как по мне.

На счет сокетов процесса гуглил вчера до утра и так ничего и не нашел Какой-то один вариант вроде на стаковере нашел, но там че-то слишком костыльно и не надежно... Так что скорей всего придется городить прокси, третьего варианта, видимо, не существует под мои задачи.

На счет NDIS, вчера еще почитал примеры и пару статей по реализации и возможностях, и пока что это лучший вариант из всего, мне пока что все его возможности не нужны, но если вдруг будут нужны то они есть, и это не может не радовать

Сегодня попробую уже что-то покодить, вроде как план накидал можно попробовать начать.

0

Сообщение от siriusED Ну на самом деле хотелось бы иметь выбор, либо перехват траффика с заданого процесса либо с заданного адаптера, прям из всех адаптеров думаю это уже перебор

Нет, это не перебор. У вас должна быть возможность отфильтровать любой трафик в рамках всей ОС, что бы потом можно было выбрать что-то конкретное из всех доступных вариантов. Если у вас нет доступа ко всему трафику, то и выбирать вы по большому счету тоже не можете.

Сообщение от siriusED На счет NDIS, вчера еще почитал примеры и пару статей по реализации и возможностях, и пока что это лучший вариант из всего

Нет, не лучший.

By providing a simpler development platform, WFP is designed to replace previous packet filtering technologies such as Transport Driver Interface (TDI) filters, Network Driver Interface Specification (NDIS) filters, and Winsock Layered Service Providers (LSP).

https://learn.microsoft.com/en... start-page

1