NDIS Firewall

[tayphoon]

Доброго времени суток! Знаю, что на данном форуме куча информации про NDIS драйвер и, в частности, про Passthru. Но вот есть такой вопрос. Я пишу дипломный проект Файрвол. Не хочется сдавать чужой проект, поэтому взялся за дело сам. Перелопатил ваши статьи да так и не нашел, как драйвер может сообщить о пришедшем пакете и передать его в программу, использующую этот драйвер.
Использовал пример Passthru driver вот с этого сайта: h**p://www.wd-3.com/downloads/PassThru3.zip
Отличный сайт, куча примеров, ну а теперь по порядку. Хочу написать кроссплатформенный файрвол. Низкоуровневую часть под Windows собираюсь реализовывать с помощью NDIS driver. Возможно ли в NDIS драйвере реализовать с помощью механизма событий или callback'ов передачу пакета в программу? Необходимо, чтобы при приходе любого пакета программа узнавала об этом и получала его.

Заранее спасибо)

[Ochkarik]

доброго.
по идее NdisInitializeEvent инициализирует Event объявленный как
typedef struct _NDIS_EVENT
{
    KEVENT      Event;
} NDIS_EVENT, *PNDIS_EVENT;

то есть это обычное событие ядра. вроде были методы отобразить его в процесс.. по крайней мере обратно - точно можно при помощи ObReferenceObjectByHandle(). с другой стороны ObReferenceObjectByHandle - это не NDIS функция. для кросплатформенности наверное не стоит ее использовать. да и евенты толго идут...

а насчет callback-ов не знаю...

[tayphoon]

А есть какой-нибуДь другой способ?

[Ochkarik]

штатного увы не соображу. к сожалению я не очень силен в NDIS - а там несколько отдельный набор функций... кросплатформенный.
по идее - альтернатив всего несколько. APC процедуры(Asynchronous Procedure Calls)- не уверен что кроссплатформенно поддержаны в NDIS (но надо проверить - попробуйте поискать аналоги), и, вроде как есть вот такой метод (если я правильно мельком понял):
например http://www.pcausa.com/filters/IPPacketRedirector.pdf
вроде бы это как раз похожая тематика. попробуйте разобраться?) мне показалось что что то разумное в этом подходе есть.


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

[tayphoon]

Смысл в том что анализ должен проводится на верхнем уровне, чтобы проанализировать содержимое пакета, на наличие инструкций вредоносных и вирусов


Так что NDIS driver можно и в линукс использовать? А есть литература или пример?

[Ochkarik]

http://www.google.ru/search?hl=ru&lr=&rlz=1T4ADBF_ruRU321RU322&newwindow=1&q=porting+NDIS+linux&start=10&sa=N
http://en.wikipedia.org/wiki/NDISwrapper

[resource]

То что в твоем понятии кроссплатформенный это значит писать отдельный фаерволл под каждую операционку.

Я тоже недавно решил заморочиться с NDIS файером. Понял следующие вещи.
1. Анализировать на верхнем уровне (я так понял на уровне пользователя) это мягко говоря не лучшая идея. Сеть будет как миниму страшно тупить. В тех же исходниках от pcausa, "фаерволирование" происходит на месте, в самом драйвере.
2. На NDIS неясно какая именно программа шлет пакет, а без этого ни один нормальный фаервол не мыслим. Может ведь и легальный браузер коннектиться на 80 порт по http а может и злодей какой нибудь. Какой смысл в фаерволе если он будет пропускать всё что угодно от кого угодно. Но этот пункт для тебя может быть и не критичным, т.к. твои цели - учебно-тренеровочные.
3. Это самый главный вопрос который встает. Я, например, признаю только один режим "запрещено всё что не разрешено", иначе опять же смысла нет. Так вот как при такой политике фильтровать тот же tcp (с учетом пункта 2)? К примеру, разрешен tcp траффик с твоего компа на определенный удаленный порт. В фаере вижу пакет который желает уйти в большое плавание. Проверяю, вижу что пакет tcp и что он уходит на разрешенный порт - пропускаю. Приходит ответ. И что с ним делать? Откуда я знаю ответ это тому кто спрашивал или вообще "левый" пакет. Да, я могу запомнить порт с которого уходит пакет и смотреть на порт входящего пакета. Но что если та "нормальная" прога вообще уже закрылась, и теперь этот порт заняло что-то зловредное.

в общем я не нашел для себя ответов на эти вопросы. Более того, что касается пункта 2, то мне кажется это вообще невозможно. Майкрософт пишет мол не делайте ничего на tdi, т.к. он якобы уже не поддерживается. Ну по крайней мере и на висте и на 7ке он жив и здоров. Если кому то удалось сделать нормальный файер исключительно на ndis, поделитесь, мне самому очень это интересно

[Ochkarik]

resource, у вас есть исходники psausa, и там действительно все реализовано в драйвере?
Удивительно, но мельком проглядывая  инфу на их сайте я так понял, что они то, как раз умудряются пересылать в приложение? или это они брешут?)
да и в соседней ветке это активно утверждали...

Кстати, а чего вдруг все на этот pcausa набросились? или потому что других нет?)

PS кстати я тоже приверженец того, что все надо делать в драйвере, если встает вопрос пакетной обработки и быстродействия.

[resource]

Я лично заходил на ndis.com (думаю не я один)) ), а от туда как правило все и попадают на pcausa. Может я и "наврал" немного насчет того что исходники с pcausa, но то что их писали люди с pcausa это чистая правда, равно как и насчет того, что фильтрация происходит в драйвере.  Это возможно не те исходники, что вы ожидали, но тоже интересно посмотреть.
http://www.wd-3.com/archive/ExtendingPassthru2.htm

[Ochkarik]

нет счастья на земле...
но тем не менее на сайте несколько другая конфигурация прописана.
есть еще вот такие вещи
1. WinPkFilter
http://www.ntkernel.com/w&p.php?id=7
и тут кажется фильтр встроенныый, правила загружаемые...
2. MicroOLAP's PSSDK
http://www.microolap.com/products/network/pssdk/
правда последнее - всего лишь снифер, а это гораздо проще...

[tayphoon]

Насчет того что фильтрует сам драйвер, ты прав. а для того чтобы написать нормальный файрвол, нужно много уровней ухватить, ну думаю если без анализа одержимого пакетов то достаточно tdi + ndis. потому что на ndis фиг узнаешь кто пакет просит. Еще вычитал что самый быстродейственный способ это переопределение NDIS API функций, типа и драйвер писать не надо и все те же возможности. Но вот если реализовывать файрвол не просто как пакетный фильтр, как в примерах на выше указанном сайте, то нужно инфу с разных уровней собрать а потом решить что делать с пакетом. Сделать это на уровне драйвером можно но хотелось комплексно решить проблему на уровне приложения. Понимаю что может тормозить адцки) но если подойти к проблеме не напрямую получил пакет и пока решишь что с ним делать а другим способом, например помечать пакеты или буферизировать, в общем я пока фантазирую...


Вот по этому и хочу синхронизировать NDIS driver и прогу, чтоб знать когда пришли пакеты, а дальше уже можно решить как быть

То что в твоем понятии кроссплатформенный это значит писать отдельный фаерволл под каждую операционку.

Я тоже недавно решил заморочиться с NDIS файером. Понял следующие вещи.
1. Анализировать на верхнем уровне (я так понял на уровне пользователя) это мягко говоря не лучшая идея. Сеть будет как миниму страшно тупить. В тех же исходниках от pcausa, "фаерволирование" происходит на месте, в самом драйвере.
2. На NDIS неясно какая именно программа шлет пакет, а без этого ни один нормальный фаервол не мыслим. Может ведь и легальный браузер коннектиться на 80 порт по http а может и злодей какой нибудь. Какой смысл в фаерволе если он будет пропускать всё что угодно от кого угодно. Но этот пункт для тебя может быть и не критичным, т.к. твои цели - учебно-тренеровочные.
3. Это самый главный вопрос который встает. Я, например, признаю только один режим "запрещено всё что не разрешено", иначе опять же смысла нет. Так вот как при такой политике фильтровать тот же tcp (с учетом пункта 2)? К примеру, разрешен tcp траффик с твоего компа на определенный удаленный порт. В фаере вижу пакет который желает уйти в большое плавание. Проверяю, вижу что пакет tcp и что он уходит на разрешенный порт - пропускаю. Приходит ответ. И что с ним делать? Откуда я знаю ответ это тому кто спрашивал или вообще "левый" пакет. Да, я могу запомнить порт с которого уходит пакет и смотреть на порт входящего пакета. Но что если та "нормальная" прога вообще уже закрылась, и теперь этот порт заняло что-то зловредное.

в общем я не нашел для себя ответов на эти вопросы. Более того, что касается пункта 2, то мне кажется это вообще невозможно. Майкрософт пишет мол не делайте ничего на tdi, т.к. он якобы уже не поддерживается. Ну по крайней мере и на висте и на 7ке он жив и здоров. Если кому то удалось сделать нормальный файер исключительно на ndis, поделитесь, мне самому очень это интересно

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

То что в твоем понятии кроссплатформенный это значит писать отдельный фаерволл под каждую операционку.

А кроссплатформенный в моем понимании - программа реализующая анализ содержимого пакетов, интерфейс, в общем все кроме модулей уровня ядра(промежуточные драйвера, модули).

[Ochkarik]

вся беда передачи пакетов в ring-3 - время реакции... то есть, не так сложно отправить большой поток, сложно получить быстродействие когда на каждый пакет требуется какая то реакция от приложения.
если можно попытаться свести задачу к потоковой а не пакетной передаче - значительно облегчило бы выполнение)

второе. обычно под кросплатформенностью все таки  портабельность кода с точки зрения использованных функций  на различные ОС...

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

во вторых есть пара слов следующего содержания

Lower Adapter Interface
A handle opened on the Lower Adapter Interface is easiest to understand.
A write on a lower adapter Win32 handle will call a lower-level miniport driver to transmit a packet on the network. Similarly, a read on a lower adapter handle will fetch an incoming packet from the network.
This PCARedir interface can be thought of as the “net side interface”.
Virtual Adapter Interface
A handle opened on the Virtual Adapter Interface may seem confusing. At first it seems “upside down”.
A write on a virtual adapter Win32 handle will inject a packet “up the stack” where it will eventually enter the TCP/IP transport as if it had been received from the network. Similarly, a read on a virtual adapter handle will fetch an outbound packet being sent by a higher-level protocol.

Redirection Filters
The PCARedir driver includes a separate Redirection Filter on each of the two interfaces.
1 Filter on Virtual Adapter Interface – Packet disposition based on inspection of outbound packets from upper-level protocols. A “send filter”.
2 Filter on Lower Adapter Interface – Packet disposition based on inspection of inbound packets from the network. A “receive filter”

[resource]

Нда. Признаться, выглядит немного бредово. Картинка конечно красивая, но нарисовать то можно, что угодно. Например, можно было втиснуть обработку пакетов на удаленной машине. Это я не к тому, что картинка врет, а к тому что посмотреть бы как всё это выглядит на уровне исходного кода. В любом случае, странно, что данные из юзермода проходят через Virtual Adapter, затем через TCP/IP transport, потом снова попадают в Virtual Adapter и в конце концов на Miniport

Добавлено через 4 минуты и 39 секунд:

обычно под кросплатформенностью все таки  портабельность кода с точки зрения использованных функций  на различные ОС...

Я тоже так полагаю

[Ochkarik]

resource, вот и я не понял пока зачем так сложно... но какой то смысл в этом был?

[resource]

но какой то смысл в этом был?

[tayphoon]

Наверное ребята просто перемудрили)


Вообще поковырялся я и пришел к выводу:
1. Для синхронизации программы и драйвера можно использовать события либо механизм APC
2. Для обменом данных лучше использовать разделяемую память
Теперь буду разбираться с этим всем.

[supermaxus]

Возможно ли в NDIS драйвере реализовать с помощью механизма событий или callback'ов передачу пакета в программу? Необходимо, чтобы при приходе любого пакета программа узнавала об этом и получала его.

Далее все ИМХО.

Из нестандартных решений:

Делать callback из ядра в юзермод - безумие с точки зрения безопасности. Если бы MS такое сделала, то на ушах стоял бы весь инет. В свое время программисты долго муссировали возможность записать код(как последовательность символов) вместо логина в окно winlogon и вызвать таймер с адресом функции на этот код для перехода в ring0. А тут предлагается готовая технология В любом случае, концепцию шлюзов x86 никто не отменял. И она на уровне CPU запрещает такие дела: прога из юзермода вызывает шлюз, за шлюзом закреплен обработчик для ring0, который не может предоставить управление на ring уровнем выше своего (1,2,3). Иначе бы любой код из юзермода ходил бы пешком в кернел мод.

Про события (APC) - мысль интересная, но насколько я нарыл в ддк - события кернел-мода и юзермода живут отдельно. И как эмулировать объект синхронизации из кернел-мода для юзермода не совсем понятно.

Теоретически можно в драйвер передать адрес памяти из юзермода и писать в эту память при некоторых условиях. При этом, юзермод будет в цикле читать заголовок в начале этой памяти и по нему(например, первый байт = 1) определять наличие полезных данных. Сбрасывая тот же байт в 0 можно сообщать драйверу о возможности следующего обновления данных. При этом, операции чтения/записи между прогой юзермода и драйвером даже синхронизировать не надо, поскольку если выполняется поток кернел-мода, то пока он не завершит свою работу никакой юзермод не получит управление. Однако, это справедливо для однопроцессорных систем:) Думается, что такой метод покажет более лучшую производительность, чем постоянный опрос драйвера запросами IOCTL (здесь нет накладных расходов на переключение в кернелмод и обратно, за исключением первого раза для передачи адреса буфера).