А>А вот есть ли способ обойтись вообще без NDIS-фильтра и при этом не разрешить приложению отослать ни единого пакета?
А>Просто не хочется для такой вроде бы тривиальной задачи городить вспомогательный драйвер .

В принципе, Вы можете легко "угадать" какой интерфейс система выберет. Таблица маршрутизации доступна. Алгоритм маршрутизации — также не секретный . Более того, анализируя маршруты, Вы можете сделать поведение своего фаервола более "умным". В преведенном мной выше примере с двумя картами, одна из которых wifi, Вы могли бы увидеть, что маршрутизатор выберет интерфейс, который запрещен правилом и заранее "подкорректировать" поведение — таким образом реализовав индивидуальную таблицу маршрутизации для каждого процесса ( я честно говоря не пробовал менять адрес интерфейса для созданного соединения, вероятно, это возможно при помощи TDI_SET_INFORMATION. В любом случае, такая коррекция возможна при обработке запроса IRP_MJ_CREATE ).

Как узнать таблицу маршрутизации:
http://tarasc0.blogspot.com/2007/02/blog-post.html

А>Зачем? Какие преимущества даст мне наличие NDIS-фильтра в моём фаерволле?
1. Реализация IDS ( хотя бы элементарный детектор сканирования портов )
2. Более полная фильтрация. TDI — не единственный способ общения с сетевой картой для приложений
3. Возможность реализации своих алгоритмов машрутизации ( NAT )
4. Возможноть организации "скрытого режима". Например TCP протокол должен послать RST пакет в ответ на SYN, пришедший на закрытый порт. Таким образом, станция может обнаружить себя перед сканером. Возможно, пользователь не хочет этого.
5. Статистика

Здравствуйте, Аноним, Вы писали:

А>Хм. А при чём здесь User-Mode ?

А при чем тут вообще mode? Представьте что у вас есть три сетевые карты и на каждой по пять адресов... Как вы определите какой локальный адрес выбрать, кроме как разбирать таблицу маршрутизации... Ну вот "там" как раз и предложено решение как это сделать без разбора.

Привет!

1. Скажите, пожалуйста, возможен ли subj в общем случае на TDI_CONNECT или здесь спасёт только NDIS-фильтр?
2. Есть персональные фаерволлы, работающие на TDI и NDIS уровнях одновременно, имеющие возможность фильтрации по процессам. Каким же образом на уровне NDIS они определяют пускать или нет пакет в сеть, если имя процесса они могут получить только на TDI? Они руководствуются только связкой RemoteIP:RemotePort, а на локальный адрес просто забивают, так что ли?

Спасибо.

А>1. Скажите, пожалуйста, возможен ли subj в общем случае на TDI_CONNECT или здесь спасёт только NDIS-фильтр?

Можно поинтересоваться у драйвера tcpip.sys — послать ему запрос TDI_QUERY_INFORMATION. Тут есть один нюанс. Соединение может быть связано с локальным адресом 0.0.0.0. В этом случае запрос TDI_QUERY_INFORMATION до запроса TDI_CONNECT вернет именно 0.0.0.0, а вот после установления соединения ( например, по факту завершения TDI_CONNECT ) можно узнать адрес интерфейса, который выбрал маршрутизатор.

А>2. Есть персональные фаерволлы, работающие на TDI и NDIS уровнях одновременно, имеющие возможность фильтрации по процессам. Каким же образом на уровне NDIS они определяют пускать или нет пакет в сеть, если имя процесса они могут получить только на TDI? Они руководствуются только связкой RemoteIP:RemotePort, а на локальный адрес просто забивают, так что ли?

Пакетный фильтры ( фаервол NDIS уровня ) работает очень тупо. У них есть набор правил с помощью которых он и оценивают проходящие пакеты. Как выглядит правило — это дело разработчика. Для TCP это обычно четыре условия: диапазон адресов источника, диапазон адресов передатчика, для портов аналогично. А вот откуда берутся правила эти — это уже более интересный вопрос. Например, они могут автоматически генерироваться на основе фильтрации активности на TDI уровне. Упомянутый запрос TDI_CONNECT — подходящий повод для генерации правила.

TC>Можно поинтересоваться у драйвера tcpip.sys — послать ему запрос TDI_QUERY_INFORMATION. Тут есть один нюанс.

Только один?

TC>Соединение может быть связано с локальным адресом 0.0.0.0. В этом случае запрос TDI_QUERY_INFORMATION до запроса TDI_CONNECT вернет именно 0.0.0.0, а вот после установления соединения ( например, по факту завершения TDI_CONNECT ) можно узнать адрес интерфейса, который выбрал маршрутизатор.

"После" уже поздно.

TC>Пакетный фильтры ( фаервол NDIS уровня ) работает очень тупо. У них есть набор правил с помощью которых он и оценивают проходящие пакеты. Как выглядит правило — это дело разработчика. Для TCP это обычно четыре условия: диапазон адресов источника, диапазон адресов передатчика, для портов аналогично. А вот откуда берутся правила эти — это уже более интересный вопрос. Например, они могут автоматически генерироваться на основе фильтрации активности на TDI уровне. Упомянутый запрос TDI_CONNECT — подходящий повод для генерации правила.

Т.е. например возможен ли такой сценарий:

1. После успешного выполнения TDI_CONNECT получаем локальный адрес.
2. Теперь мы имеем на руках всю необходимую информацию — RemoteIP:RemotePort, LocalIP:LocalPort, имя процесса.
3. Если данная информация подходит под некоторое правило, тогда мы отдельно генерируем правило для NDIS-фильтра в таком виде — RemoteIP:RemotePort, LocalIP:LocalPort.
4. NDIS-фильтр тупо фильтрует все пакеты по этому правилу.

Правильно?
Т.е. получается что TDI-фильтр в данном случае нужен только для определения имени процесса?
Значит получается что при реализации персонального фаерволла нет никакой возможности обойтись без NDIS-фильтра — фильтрацию обязательно придёться делать двухступенчатую, так?

А>Правильно?
А>Т.е. получается что TDI-фильтр в данном случае нужен только для определения имени процесса?

не совсем. На TDI также производится проверка — если процесс обращается к запрещенному ресурсу ( адресу, порту ) ему тут же откажут.

А>Значит получается что при реализации персонального фаерволла нет никакой возможности обойтись без NDIS-фильтра — фильтрацию обязательно придёться делать двухступенчатую, так?

Вовсе нет. Вышесказанное это поясняет. Для ПЕРСОНАЛЬНОГО фаервола главным является TDI фильтр. На этом уровне можно управлять доступом приложений к сетевым ресурсам, а это и есть основное его назначение. Если угодно, его задача не дать спамботу приконнектиться к 25 порту, все остальное — это дополнительная защита ( кстати, MS думает совсем по-другому: ) ). Поэтому я все время подчеркиваю ПЕРСОНАЛЬНЫЙ фаервол — противопоставляю его классическим пакетным фильтрам. Все остальные точки контроля носят вспомогательный характер. Но чем больше точек контроля, тем лучше. Хорошие персональные фаерволы имеют даже больше, чем два уровня, это несколько затрудняет жизнь руткитам.

TC>Для ПЕРСОНАЛЬНОГО фаервола главным является TDI фильтр. На этом уровне можно управлять доступом приложений к сетевым ресурсам, а это и есть основное его назначение.

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

А>Ну а как быть, если в этом фаерволле предусмотрено создание правил, включающих в себя локальный интерфейс? Ведь в этом случае обязательно должен быть и NDIS драйвер! Или нет?

А что Вам мешает анализировать правила с локальным интерфейсом на TDI уровне? Например, такая задача — разрешить IE работать только через ethernet и запретить доступ через WiFi. Допустим, мы знаем что интерфейс a.a.a.a принадлежит ethernet карте, а b.b.b.b — wifi. Есть две ситуации: 1. приложение явно прибиндило сокет к локальному интерфейсу. В этом случае Вы на TDI уровне знаете это и можете применять Ваше правило до установки соединения; 2. приложение не указало интерфейс и отдало выбор интерфейса маршрутизатору. Пускай себе установит соединение. Вы можете по факту установки узнать выбранный интерфейс и закрыть его. Для пользователя результат будет одинаков.

PS: я вовсе не агитирую Вас не делать NDIS фильтра, полноценный фаервол должен включать его. Я просто хочу подвести Вас к мысли, что для ПЕРСОНАЛЬНОГО фаервола он носит вспомогательный характер. Это мое личное мнение.

TC>А что Вам мешает анализировать правила с локальным интерфейсом на TDI уровне? Например, такая задача — разрешить IE работать только через ethernet и запретить доступ через WiFi. Допустим, мы знаем что интерфейс a.a.a.a принадлежит ethernet карте, а b.b.b.b — wifi. Есть две ситуации: 1. приложение явно прибиндило сокет к локальному интерфейсу. В этом случае Вы на TDI уровне знаете это и можете применять Ваше правило до установки соединения; 2. приложение не указало интерфейс и отдало выбор интерфейса маршрутизатору. Пускай себе установит соединение. Вы можете по факту установки узнать выбранный интерфейс и закрыть его. Для пользователя результат будет одинаков.

Верно.
Но как-то некрасиво, ведь обмен тремя пакетами (sin, sin-ack, ack) уже состоится!
А вот есть ли способ обойтись вообще без NDIS-фильтра и при этом не разрешить приложению отослать ни единого пакета?
Просто не хочется для такой вроде бы тривиальной задачи городить вспомогательный драйвер .

TC>PS: я вовсе не агитирую Вас не делать NDIS фильтра, полноценный фаервол должен включать его.

А вот с этого места поподробнее.
Зачем? Какие преимущества даст мне наличие NDIS-фильтра в моём фаерволле?

TC>Я просто хочу подвести Вас к мысли, что для ПЕРСОНАЛЬНОГО фаервола он носит вспомогательный характер. Это мое личное мнение.

Я понял, спасибо.
Ваше мнение для меня очень важно.

TC>В принципе, Вы можете легко "угадать" какой интерфейс система выберет.

Т.е. это — единственный способ получить адрес локального сетевого интерфейса до того, как TDI_CONNECT уйдёт вниз ?

А>>Какие преимущества даст мне наличие NDIS-фильтра в моём фаерволле?
TC>1. Реализация IDS ( хотя бы элементарный детектор сканирования портов )
TC>2. Более полная фильтрация. TDI — не единственный способ общения с сетевой картой для приложений
TC>3. Возможность реализации своих алгоритмов машрутизации ( NAT )
TC>4. Возможноть организации "скрытого режима". Например TCP протокол должен послать RST пакет в ответ на SYN, пришедший на закрытый порт. Таким образом, станция может обнаружить себя перед сканером. Возможно, пользователь не хочет этого.
TC>5. Статистика

Спасибо, очень интересная информация.

Один раз подобный вопрос и обсуждение уже было... Мне понравилось решение предложеное... Посмотрите подумайте. Очень оригинальное решение. здесь

Автор: Asker_
Дата: 01.09.06

AWW>Один раз подобный вопрос и обсуждение уже было... Мне понравилось решение предложеное... Посмотрите подумайте. Очень оригинальное решение. здесь

Автор: Asker_
Дата: 01.09.06

Хм. А при чём здесь User-Mode ?

Здравствуйте, TarasCo, Вы писали:

TC>PS: я вовсе не агитирую Вас не делать NDIS фильтра, полноценный фаервол должен включать его. Я просто хочу подвести Вас к мысли, что для ПЕРСОНАЛЬНОГО фаервола он носит вспомогательный характер. Это мое личное мнение.

Забавно, но примерно восемь лет назад, я ровно это говорил одному разработчику из одной питерской компании разработавшей популярный фаервол — "надо на TDI уровне фильтровать" но тот спорил... А по существу ,так я совершенно согласен с TarasCo... — чем выше фильтруешь, тем лучше, но всё равно не обойтись без NDISовской фильтрации... но это как бы вторично.