WinpkFilter to drop packets. LocalHost to resolve ProcessID.

Home Forums Discussions Support Portal WinpkFilter to drop packets. LocalHost to resolve ProcessID.

This topic contains 7 replies, has 2 voices, and was last updated by  Vadim Smirnov 12 years, 3 months ago.

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #4943

    Turko Andrey
    Participant

    Вынужден снова поднять тему получения ProcessID для пакета, перехваченного при помощи “WinpkFilter SDK”, которая была затронута в обсуждении по теме “Need to know what application is associated with a packet”.

    SerpentFly для решения задачи порекомендовал дополнительно использовать “LocalHost SDK”, которая в отличие от “WinpkFilter SDK” предоставляет ProcessID для пакета, но не умеет его “дропать” (блокировать). Т.е. предложил использовать их совместно, а именно сопоставлять пакеты по IP-адресам и портам, локальным и удаленным собранные на одном уровне с пакетами на том уровне, где их можно “дропать”.

    Идея вроде ясна. Но, данное сопоставление оказывается ненадежным вовсе не из-за портов (типа, надо просто локальные сравнивать), а из-за того, что пакет от “LocalHost” приходит позже, чем пакет от “WinpkFilter”. Т.е. возможно заблокировать только последующие пакеты, с опозданием, упустив их некоторое количество. Вроде и ничего, но возможна путаница, когда неблокируемое приложение займет локальный порт сразу за тем, как там пыталось работать то приложение, пакеты которого должны дропаться.

    Заказчик хочет знать, возможно ли на данных компонентах построить более надежное решение, нежели описанное выше, чтобы решить переходить с “Individual”-лицензии “WinpkFilter” на девелоперскую или нет.

    Будьте так добры, помогите разобраться.

    #5804

    Vadim Smirnov
    Moderator

    Идея вроде ясна. Но, данное сопоставление оказывается ненадежным вовсе не из-за портов (типа, надо просто локальные сравнивать), а из-за того, что пакет от “LocalHost” приходит позже, чем пакет от “WinpkFilter”. Т.е. возможно заблокировать только последующие пакеты, с опозданием, упустив их некоторое количество. Вроде и ничего, но возможна путаница, когда неблокируемое приложение займет локальный порт сразу за тем, как там пыталось работать то приложение, пакеты которого должны дропаться.

    Да правильно, я рекомендовал использовать TDI-фильтр (аналогичный LHMON) или LSP для сбора информации процесс< ->адрес.порт. Но перехватывать именно пакет данных для построения таблицы соотвествий не нужно. До того момента как любой пакет достигнет NDIS а затем и TDI для него уже существуют ассоциированные структуры представляющие собой соединение (сокет) по которым можно сопоставить пакет процессу(с оговоркой если для пакета существует ассоциированный процесс). LHMON как сниффер не логирует (для user-mode клиента) создаваемые/уничтожаемые соединения но сами эти события отслеживает, чем меньше событий логируется тем меньше нагрузка на процессор (чтение каждой записи лога это переключение контекста). Кстати для одного заказчика делалась модификация драйвера который так же логировал возникновение соединений, для подобных фаервольных целей насколько я понимаю…

    #5805

    Turko Andrey
    Participant

    Спасибо за пояснения.

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

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

    P.S. Хочется обойтись без программирования драйверов, а использовать готовый framework для приложения в user-mode написанного на Delphi, которому нужна возможность блокирования пакетов конкретного приложения (процесса).

    #5806

    Vadim Smirnov
    Moderator

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

    Можно при условии приобретения Developer или Source Code лицензии.

    #5807

    Turko Andrey
    Participant

    Хорошо, заказчик готов купить Source Code.

    Еще один вопрос – будет ли этот драйвер работать на Windows 98? А то вот заметили, что для “LocaHost SDK” указана поддержка только “Windows NT 4.0, 2000, XP, 2003 Server”.

    Если нет, то как с этим быть? Заказчику нужна и эта платформа тоже.

    #5808

    Vadim Smirnov
    Moderator

    Для поддержки 98 нужно делать отдельный драйвер (там совсем по другому выстроен сетевой стек), или использовать LSP.

    #5809

    Turko Andrey
    Participant

    Вот дела. А есть ли у вас уже готовый такой драйвер для Windows 98?

    #5810

    Vadim Smirnov
    Moderator

    Нет готового нет, шаблон для 9x TDI фильтра есть например в VToolsD, так что в принципе сделать аналог можно. Шаблон для LSP есть в MSDN. Так что в принципе задача не слишком сложно решается.

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.