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

Тема в разделе "WASM.NT.KERNEL", создана пользователем rpy3uH, 9 ноя 2010.

  1. rpy3uH

    rpy3uH New Member

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

    x64 New Member

    Публикаций:
    0
    Регистрация:
    29 июл 2008
    Сообщения:
    1.370
    Адрес:
    Россия
    У меня в избранном много чего есть, в т.ч. и это.
    Ну и ещё я собираюсь в блоге написать об этом поподробнее, да всё никак пока.
     
  3. slesh

    slesh New Member

    Публикаций:
    0
    Регистрация:
    6 фев 2009
    Сообщения:
    214
    А можно и без TDI пойти. Когда создается сокет, то открывается \Device\Afd ну вот к примеру можно взять и похукаеть функции открытие. И там уже фильтровать всё. Тогда получится что как бы непосредственной фильтрации сети нет, но при этом сеть не работает для нужного процесса
     
  4. x64

    x64 New Member

    Публикаций:
    0
    Регистрация:
    29 июл 2008
    Сообщения:
    1.370
    Адрес:
    Россия
    Да можно, конечно, много чего, но:

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

    100gold New Member

    Публикаций:
    0
    Регистрация:
    26 фев 2010
    Сообщения:
    165
    А могут юзермод приложения работать в обход AFD ?
    Кернелмод приложения могут и без TDI в сеть залезть.
     
  6. x64

    x64 New Member

    Публикаций:
    0
    Регистрация:
    29 июл 2008
    Сообщения:
    1.370
    Адрес:
    Россия
    Именно это я и написал.

    Да.
     
  7. z0mailbox

    z0mailbox z0

    Публикаций:
    0
    Регистрация:
    3 фев 2005
    Сообщения:
    635
    Адрес:
    Russia СПБ
    можно и на уровне ндис это сделать как оказалось :)
     
  8. rpy3uH

    rpy3uH New Member

    Публикаций:
    0
    Регистрация:
    14 сен 2006
    Сообщения:
    503
    всем спасибо, я получил нужное направление, больше ничего не надо. TDI - то что надо!
    NDIS это уже ниже TCP/IP, а это дополнительный гемор.
     
  9. WasmDiman

    WasmDiman New Member

    Публикаций:
    0
    Регистрация:
    12 ноя 2010
    Сообщения:
    1
    Разве на NDIS можно узнать процес пославший или принимающий пакет? Помоему нет, только на TDI.
     
  10. x64

    x64 New Member

    Публикаций:
    0
    Регистрация:
    29 июл 2008
    Сообщения:
    1.370
    Адрес:
    Россия
    Если пользоваться только средствами NDIS, то формально - нельзя. Но можно запросить у транспортного драйвера (например, tcpip.sys) таблицу соединений и сопоставить адреса узлов, для найденного адреса можно будет узнать ID процесса.
     
  11. z0mailbox

    z0mailbox z0

    Публикаций:
    0
    Регистрация:
    3 фев 2005
    Сообщения:
    635
    Адрес:
    Russia СПБ
    я не советую делать ндис фильтр только для блокировки
    потому что эти фильтры сами по себе сложные
    плюc алгоритм привязки пакетов в процессу тоже _весьма_ сложный
    мне нужно было шифрованное туннелирование - поэтому я был завязан на ндис

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

    и никаких запросов в tcpip.sys - все вручную :)
     
  12. 100gold

    100gold New Member

    Публикаций:
    0
    Регистрация:
    26 фев 2010
    Сообщения:
    165
    Т.е. TDI-события вообще не перехватывались или имеется в виду что вместо запроса заранее кешировалась таблица соединений путём перехвата TDI_LISTEN\TDI_CONNTECT\итд
     
  13. x64

    x64 New Member

    Публикаций:
    0
    Регистрация:
    29 июл 2008
    Сообщения:
    1.370
    Адрес:
    Россия
    Я допускаю, что есть способ через недокументированные структуры добраться до этой информации, но... почему нет?
     
  14. x64

    x64 New Member

    Публикаций:
    0
    Регистрация:
    29 июл 2008
    Сообщения:
    1.370
    Адрес:
    Россия
    Нет, он имеет в виду, что он получал эту информацию в NDIS-фильтре вообще без каких-либо манипуляций с транспортным драйвером, хотя я лично пока не вижу причин, по которым был выбран именно этот путь.
     
  15. 100gold

    100gold New Member

    Публикаций:
    0
    Регистрация:
    26 фев 2010
    Сообщения:
    165
    Интересно... А как такое делать? Если для исходящих пакетов контекст процесса будет правильный, то для входящих пакетов он будет случайный. И без TDI мне казалось невозможным определить процесс для пакета.
     
  16. z0mailbox

    z0mailbox z0

    Публикаций:
    0
    Регистрация:
    3 фев 2005
    Сообщения:
    635
    Адрес:
    Russia СПБ
    100gold
    не перехватывались. такая таблица легко ведется вручную

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

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

    x64 New Member

    Публикаций:
    0
    Регистрация:
    29 июл 2008
    Сообщения:
    1.370
    Адрес:
    Россия
    Странный вопрос, для протоколов транспортного уровня и выше - разумеется, да.

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

    z0mailbox z0

    Публикаций:
    0
    Регистрация:
    3 фев 2005
    Сообщения:
    635
    Адрес:
    Russia СПБ
    алгоритм эмпирический и относится только к исходящим пакетам
    входящие мне не интересны - такое техзадание - и почти не используются

    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
     
  19. gorodon

    gorodon New Member

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

    100gold New Member

    Публикаций:
    0
    Регистрация:
    26 фев 2010
    Сообщения:
    165
    Получив поток, который инициировал сетевое событие, можно раскрутить юзермодный стек этого потока добравшись до кода который лежит вне системных библиотек. И уже по тому, какой бинарник промаплен по полученному адресу определить, что это за сервис был.