Как заблокировать сеть для определённого процесса

Есть драйвер-минифильтр который следит за файловой активностью некоторых процессов.
появилась необходимость заблокировать доступ к сети некоторому процессу.
В связи с этим есть вопрос: какие есть документированные способы блокировки доступа к сети для конкретного процесса? и чтобы это работало на XP, Vista и Seven.
знаю что это можно сделать как-то через TDI но не знаю с чего начать, с какой стороны копнуть.

 

У меня в избранном много чего есть, в т.ч. и это.
Ну и ещё я собираюсь в блоге написать об этом поподробнее, да всё никак пока.

 

А можно и без TDI пойти. Когда создается сокет, то открывается \Device\Afd ну вот к примеру можно взять и похукаеть функции открытие. И там уже фильтровать всё. Тогда получится что как бы непосредственной фильтрации сети нет, но при этом сеть не работает для нужного процесса

 

Да можно, конечно, много чего, но:

1. Приложения могут работать с сетью и в обход AFD.
2. AFD сам по себе недокументирован, так что TDI тупо проще.

 

А могут юзермод приложения работать в обход AFD ?
Кернелмод приложения могут и без TDI в сеть залезть.

 

Именно это я и написал.

Да.

 

можно и на уровне ндис это сделать как оказалось

 

всем спасибо, я получил нужное направление, больше ничего не надо. TDI - то что надо!

NDIS это уже ниже TCP/IP, а это дополнительный гемор.

 

Разве на NDIS можно узнать процес пославший или принимающий пакет? Помоему нет, только на TDI.

 

Если пользоваться только средствами NDIS, то формально - нельзя. Но можно запросить у транспортного драйвера (например, tcpip.sys) таблицу соединений и сопоставить адреса узлов, для найденного адреса можно будет узнать ID процесса.

 

я не советую делать ндис фильтр только для блокировки
потому что эти фильтры сами по себе сложные
плюc алгоритм привязки пакетов в процессу тоже _весьма_ сложный
мне нужно было шифрованное туннелирование - поэтому я был завязан на ндис

но это можно - хотя официально считается что нельзя
зато как приятно сделать то что еще никто не делал '

и никаких запросов в tcpip.sys - все вручную

 

Т.е. TDI-события вообще не перехватывались или имеется в виду что вместо запроса заранее кешировалась таблица соединений путём перехвата TDI_LISTEN\TDI_CONNTECT\итд

 

Я допускаю, что есть способ через недокументированные структуры добраться до этой информации, но... почему нет?

 

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

 

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

 

100gold

не перехватывались. такая таблица легко ведется вручную

хм ... а разве для входящих пакетов контекст процесса вообще имеет практический смысл?

x64

там только по фиксированным адресам можно добраться. недопустимо для пром.продукта
так делает микрософтовский ipsec.sys - вставляет себя в цепочку обработки внутрь tcpip.sys по фикс.адресам
но им-то можно - они всегда парой поставляются я же не могу так!

 

Странный вопрос, для протоколов транспортного уровня и выше - разумеется, да.

Ты иногда так напишешь, что непонятно ни хрена. Где "там"? О чём речь вообще? Это первое. Во-вторых, мог бы и рассказать, что там за хитропопый алгоритм извлечения контекста процесса на NDIS-уровне у тебя. В общем-то, именно об этом речь сейчас, так что если есть что по теме сказать, - пиши, я бы тоже послушал.

 

алгоритм эмпирический и относится только к исходящим пакетам
входящие мне не интересны - такое техзадание - и почти не используются

1) для всех протоколов кроме TCP и кроме исключительных случаев (см. ниже) - SEND происходит в контексте посылающего процесса
2) для TCP - SEND SYN-а (начало сессии) происходит в контексте посылающего процесса. Строится таблица сессий и все не-SYN пакеты уже по таблице привязываются к процессу
3) исключительный случай 1 - в ARP таблице нет записи для destIP. при этом вместо пакета посылается ARP-request а пакет становится в очередь и посылается по приходу ARP-reply в произвольном контексте. Решается ведением списка ARP
4) исключительный случай 2 - TCP пакет посылается, но ответ не приходит. В этом случае он несколько раз перепосылается по таймауту. Все SEND-ы по таймауту идут в случайном контексте. Решается исследованием стека и дополнительным кодом в таблице сессий
5) фильтр при этом должен быть установлен наверху стека фильтров - чтобы другой ндис-фильтр не отложил пакет. Решается использованием ключа HKLM\SYSTEM\CurrentControlSet\Control\Network\FilterClass

собственно всё. работает на хп-2к3-виста-7 32/64

 

Вопрос практически по теме топика - только задача немного усложняется...
Есть контейнер сервисов (svchost.exe) в которм запущено 2 десятка сервисов.
Сетевой монитор видит, что этот процесс (svchost.exe) проявляет сетевую активность по некоторым портам.....
Ну а вопрос такой - как определить какие сервисы в этом процессе какие порты занимают (можно ли к номеру потока как-то привзаться?)
Если есть примеры фриварных тулзов - тоже буду очень признателен.

 

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