Нужно получать информацию о соединениях с локального компа. Т.е. имя процесса и сид пользователя. Сделал TDI фильтр. Все хорошо работает без антивирусов. У всех антивирусов (которые я смотрел), Web Shield реализован как прокси. Т.е. у них есть TDI редиректор который направляет все запросы на их локальный прокси. Соотв. я в своем фильтре получаю 2 соединения 1. На прокси антивируса с правильным именем процесса и сидом, но IP назначения локальный. 2. На реальный IP и порт, но пользователь система и процесс прокси. получается что связать эти два соединения невозможно. что можно придумать?? пытался загрузить свой фильтр перед антивирусом, не помогает.
Чисто теоретически - да, это поможет на 99%, но абсолютной стабильности всё равно не добьёшься. Я бы на твоём месте смирился, ничего с этим не поделаешь. По крайне мере одним TDI-фильтром проблему точно не решишь, NDIS-фильтр здесь также не поможет. Если только посмотреть в сторону ядерных околотисипиайпишных технологий, но на вскидку ничего не придумывается. Да и к тому же, если проблема была бы легкорешаемой, то антивирусы не писали бы в требованиях отсутствие установленных security-продуктов третьих сторон. Однако ж пишут, и скорее всего именно из-за сетевых фильтров. Например, файловый фильтр можно написать так, что он не будет конфликтовать с другими грамотно написанными файловыми фильтрами, а вот в сетевой части с этим сложнее.
ОС Windows. Кто такой NPI? Ну тут не один TDI фильтр, а получается два. Несовместимость может возникать, но как правило это происходит с запретами доступа и т.п. мониторинг, по идее, не должен ничего делать плохого..... Буду пробовать.
если я правильно понимаю проблему, то вот идея... можно ли как-либо заморозить фильтр антивируса, пока процесс прокси не попытался соединиться?
Можно, при чём это делается относительно (тут ещё NDIS-уровень будет играть роль в некоторых случаях) легко для практически любого антивируса (отсоединение фильтра от стека), проблема в том, что сделать такое решение на 100% стабильно не получится.
Я так понимаю, что автор имел в виду следующую схему. Вешается фильтр один сверху антивируса, другой снизу. Фильтр сверху запоминает в каком-нибудь своём списке появление запроса на адрес X (например, 77.88.21.8:80), далее антивирус либо завершает этот запрос и отправляет новый либо отправляет этот же с новыми параметрами, но так или иначе новый запрос, связанный с X, уходит ниже уже с другим адресом Y (например, 127.0.0.1:3128). Далее запрос приходит в локальный прокси, там он обрабатывается, после чего исходный запрос посылается уже второй раз из прокси, фильтр антивируса создаёт для этого запрос с адресом X и отправляет его аккурат нашему нижнему фильтру (это в лучшем случае), при этом процесс-инициатор уже System. В этот момент мы смотрим наш список запросов, которые зафиксировал фильтр сверху, при этом ключом является адрес X, а искомым значением может быть что угодно - путь к файлу-образу процесса-инициатора, SID пользователя или что там ещё сверху сохранили. В этой схеме есть ряд очевидных проблем (навскидку): 1. Необходимо ухитриться встать ровно до и после фильтра антивируса. Этого возможно добиться только не совсем документированными методами (на 64-битных системах, скорее всего, работать не будет). 2. Непонятно, как сопоставить запрос, который видит нижний фильтр, запросу, который ранее был виден верхнему фильтру. Одного адреса X для этого недостаточно.
я если честно имел в виду заморозку при помощи объектов синхронизации но потом когда начал думать над этим всем, в голову полезли всякие дедлоки и т.д.
