- This topic has 7 replies, 2 voices, and was last updated 19 years, 2 months ago by
.
-
Posts
-
Вынужден снова поднять тему получения ProcessID для пакета, перехваченного при помощи “WinpkFilter SDK”, которая была затронута в обсуждении по теме “Need to know what application is associated with a packet”.
SerpentFly для решения задачи порекомендовал дополнительно использовать “LocalHost SDK”, которая в отличие от “WinpkFilter SDK” предоставляет ProcessID для пакета, но не умеет его “дропать” (блокировать). Т.е. предложил использовать их совместно, а именно сопоставлять пакеты по IP-адресам и портам, локальным и удаленным собранные на одном уровне с пакетами на том уровне, где их можно “дропать”.
Идея вроде ясна. Но, данное сопоставление оказывается ненадежным вовсе не из-за портов (типа, надо просто локальные сравнивать), а из-за того, что пакет от “LocalHost” приходит позже, чем пакет от “WinpkFilter”. Т.е. возможно заблокировать только последующие пакеты, с опозданием, упустив их некоторое количество. Вроде и ничего, но возможна путаница, когда неблокируемое приложение займет локальный порт сразу за тем, как там пыталось работать то приложение, пакеты которого должны дропаться.
Заказчик хочет знать, возможно ли на данных компонентах построить более надежное решение, нежели описанное выше, чтобы решить переходить с “Individual”-лицензии “WinpkFilter” на девелоперскую или нет.
Будьте так добры, помогите разобраться.
Идея вроде ясна. Но, данное сопоставление оказывается ненадежным вовсе не из-за портов (типа, надо просто локальные сравнивать), а из-за того, что пакет от “LocalHost” приходит позже, чем пакет от “WinpkFilter”. Т.е. возможно заблокировать только последующие пакеты, с опозданием, упустив их некоторое количество. Вроде и ничего, но возможна путаница, когда неблокируемое приложение займет локальный порт сразу за тем, как там пыталось работать то приложение, пакеты которого должны дропаться.
Да правильно, я рекомендовал использовать TDI-фильтр (аналогичный LHMON) или LSP для сбора информации процесс<->адрес.порт. Но перехватывать именно пакет данных для построения таблицы соотвествий не нужно. До того момента как любой пакет достигнет NDIS а затем и TDI для него уже существуют ассоциированные структуры представляющие собой соединение (сокет) по которым можно сопоставить пакет процессу(с оговоркой если для пакета существует ассоциированный процесс). LHMON как сниффер не логирует (для user-mode клиента) создаваемые/уничтожаемые соединения но сами эти события отслеживает, чем меньше событий логируется тем меньше нагрузка на процессор (чтение каждой записи лога это переключение контекста). Кстати для одного заказчика делалась модификация драйвера который так же логировал возникновение соединений, для подобных фаервольных целей насколько я понимаю…
Спасибо за пояснения.
Кстати для одного заказчика делалась модификация драйвера который так же логировал возникновение соединений, для подобных фаервольных целей насколько я понимаю…
Можно ли получить (купить) такую модификацию драйвера (LHMON я так понимаю), которая сообщает только про создание/удаление соединений и не логирует сами пакеты (это будет делать WinpkFilter)?
P.S. Хочется обойтись без программирования драйверов, а использовать готовый framework для приложения в user-mode написанного на Delphi, которому нужна возможность блокирования пакетов конкретного приложения (процесса).
Можно ли получить (купить) такую модификацию драйвера (LHMON я так понимаю), которая сообщает только про создание/удаление соединений и не логирует сами пакеты (это будет делать WinpkFilter)?
Можно при условии приобретения Developer или Source Code лицензии.
Хорошо, заказчик готов купить Source Code.
Еще один вопрос – будет ли этот драйвер работать на Windows 98? А то вот заметили, что для “LocaHost SDK” указана поддержка только “Windows NT 4.0, 2000, XP, 2003 Server”.
Если нет, то как с этим быть? Заказчику нужна и эта платформа тоже.
Для поддержки 98 нужно делать отдельный драйвер (там совсем по другому выстроен сетевой стек), или использовать LSP.
- You must be logged in to reply to this topic.